From nes@amigo.com Mon Dec 1 10:15:08 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 950CA3A67F3 for ; Mon, 1 Dec 2008 10:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.999 X-Spam-Level: X-Spam-Status: No, score=-14.999 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_HU=1.35, HELO_EQ_IP_ADDR=1.119, HOST_EQ_HU=1.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTSX8FevKaS8 for ; Mon, 1 Dec 2008 10:15:08 -0800 (PST) Received: from 91.82.170.31.pool.invitel.hu (91.82.170.31.pool.invitel.hu [91.82.170.31]) by core3.amsl.com (Postfix) with SMTP id E30933A6B78 for ; Mon, 1 Dec 2008 10:15:05 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081201181505.E30933A6B78@core3.amsl.com> Date: Mon, 1 Dec 2008 10:15:05 -0800 (PST) Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Tue Dec 2 11:36:29 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDAFC28B797 for ; Tue, 2 Dec 2008 11:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.26 X-Spam-Level: X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOp-kKinfgET for ; Tue, 2 Dec 2008 11:36:28 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0296E3A6B3A for ; Tue, 2 Dec 2008 11:36:27 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2J1ZgE002491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 12:01:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB2J1Zhr002490; Tue, 2 Dec 2008 12:01:35 -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 colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2J1Ohh002466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 Dec 2008 12:01:34 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mB2IeXUW018946 for ; Tue, 2 Dec 2008 10:40:33 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 11:01:23 -0800 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_01C954B0.5E07FC46" Subject: FW: New Version Notification for draft-hallambaker-ocspagility-02 Date: Tue, 2 Dec 2008 11:01:22 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02 Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYU References: <20081202183941.5A3003A6B4C@core3.amsl.com> From: "Hallam-Baker, Phillip" To: X-OriginalArrivalTime: 02 Dec 2008 19:01:23.0247 (UTC) FILETIME=[5E74F3F0:01C954B0] 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_01C954B0.5E07FC46 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As promised at the meeting, here is an update to the OCSP agility draft. With the WG and chair's permission I will resubmit as a WG draft. The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented. So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC.=20 And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it. So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM To: Hallam-Baker, Phillip Subject: New Version Notification for draft-hallambaker-ocspagility-02=20 =20 A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository. Filename: draft-hallambaker-ocspagility Revision: 02 Title: OCSP Algorithm Agility Creation_date: 2008-12-02 WG ID: Independent Submission Number_of_pages: 8 Abstract: The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. = =20 The IETF Secretariat. ------_=_NextPart_001_01C954B0.5E07FC46 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: New Version Notification for draft-hallambaker-ocspagility-02 =

As promised at the meeting, here is an update to the = OCSP agility draft.

With the WG and chair's permission I will resubmit as a WG draft.


The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented.


So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC.

And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it.


So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in.


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for = draft-hallambaker-ocspagility-02


A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository.

Filename:        = draft-hallambaker-ocspagility
Revision:        02
Title:           OCSP = Algorithm Agility
Creation_date:   2008-12-02
WG ID:           = Independent Submission
Number_of_pages: 8

Abstract:
The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.
            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =         


The IETF Secretariat.

------_=_NextPart_001_01C954B0.5E07FC46-- From newallken.newall@ambulance.net.au Tue Dec 2 17:27:16 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 682463A67BD for ; Tue, 2 Dec 2008 17:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.494 X-Spam-Level: X-Spam-Status: No, score=-18.494 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCP0T67w-tXF for ; Tue, 2 Dec 2008 17:27:15 -0800 (PST) Received: from af-group.com (unknown [96.241.15.216]) by core3.amsl.com (Postfix) with SMTP id E474C3A694F for ; Tue, 2 Dec 2008 17:27:14 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081203012714.E474C3A694F@core3.amsl.com> Date: Tue, 2 Dec 2008 17:27:14 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Tue Dec 2 19:58:44 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CDF13A699A for ; Tue, 2 Dec 2008 19:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8MvV4SWQrLo for ; Tue, 2 Dec 2008 19:58:43 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D33043A67D7 for ; Tue, 2 Dec 2008 19:58:42 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB33Qfcq031238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 20:26:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB33Qfbj031237; Tue, 2 Dec 2008 20:26: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 mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB33QTbu031226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 20:26:40 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from [192.168.1.102] (dslstat-77-ppp-125.fastq.com [65.39.77.125] (may be forged)) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id mB33T2Hj010327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Dec 2008 20:29:03 -0700 Cc: Message-Id: From: Michael Myers To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> Content-Type: multipart/alternative; boundary=Apple-Mail-4-859484553 Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: New Version Notification for draft-hallambaker-ocspagility-02 Date: Tue, 2 Dec 2008 20:26:27 -0700 References: <20081202183941.5A3003A6B4C@core3.amsl.com> <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.912) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-4-859484553 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Phil, I will give it a read and comment accordingly. Mike On Dec 2, 2008, at 12:01 PM, Hallam-Baker, Phillip wrote: > > As promised at the meeting, here is an update to the OCSP agility > draft. > > With the WG and chair's permission I will resubmit as a WG draft. > > > The basic history here is that we tried to deploy an OCSP resolver > that meets a pretty simple set of requirements for multiple > algorithm support and found that the base specification does not > actually say anything about how a response signature algorithm > should be chosen, except that SHA-1 can be implemented. > > > So a perfectly legal OCSP responder could report the status of a > public key certificate for an RSA signature key, signed with an RSA > signature key with ECC. > > And it gets worse, if you have an ocsp responder that is managing > certs signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA- > ECC, DSA, etc. etc.) and a status request comes in for an unknown > cert, there is no data for the responder to choose a reasonble > response alg. You are forced to choose a lowest common denominator > alg which is a problem if you moved to ECC because RSA 4096 does not > cut it. > > > So this is a pretty simple fix to sort it out. I suggest that this > goes on standards track and if we progress OCSP from PROPOSED to > DRAFT we dump the explanatory part and merge the normative text in. > --Apple-Mail-4-859484553 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Phil,

I will give it a read and = comment accordingly.

Mike


On Dec 2, 2008, = at 12:01 PM, Hallam-Baker, Phillip wrote:

=

As = promised at the meeting, here is an update to the OCSP agility = draft.

With the WG and chair's permission I will resubmit as a = WG draft.


The basic history here is that we tried to = deploy an OCSP resolver that meets a pretty simple set of requirements = for multiple algorithm support and found that the base specification = does not actually say anything about how a response signature algorithm = should be chosen, except that SHA-1 can be implemented.


So = a perfectly legal OCSP responder could report the status of a public key = certificate for an RSA signature key, signed with an RSA signature key = with ECC.

And it gets worse, if you have an ocsp responder that = is managing certs signed with umpteen different algs (RSA-SHA1, = RSA-SHA256, RSA-ECC, DSA, etc. etc.) and a status request comes in for = an unknown cert, there is no data for the responder to choose a = reasonble response alg. You are forced to choose a lowest common = denominator alg which is a problem if you moved to ECC because RSA 4096 = does not cut it.


So this is a pretty simple fix to sort it = out. I suggest that this goes on standards track and if we progress OCSP = from PROPOSED to DRAFT we dump the explanatory part and merge the = normative text in.

=

= --Apple-Mail-4-859484553-- From mail@4ad.com Wed Dec 3 04:12:55 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7313A67F1 for ; Wed, 3 Dec 2008 04:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.261 X-Spam-Level: X-Spam-Status: No, score=-27.261 tagged_above=-999 required=5 tests=[AWL=-12.183, BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rus4nh0lgow for ; Wed, 3 Dec 2008 04:12:55 -0800 (PST) Received: from host-92-124-174-179.pppoe.omsknet.ru (host-92-124-174-179.pppoe.omsknet.ru [92.124.174.179]) by core3.amsl.com (Postfix) with SMTP id 013163A67E5 for ; Wed, 3 Dec 2008 04:12:51 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081203121252.013163A67E5@core3.amsl.com> Date: Wed, 3 Dec 2008 04:12:51 -0800 (PST) Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Wed Dec 3 07:36:47 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA75D3A689C for ; Wed, 3 Dec 2008 07:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfgoGWGnkVeb for ; Wed, 3 Dec 2008 07:36:46 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 652483A6882 for ; Wed, 3 Dec 2008 07:36:25 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB3F079A067746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2008 08:00:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB3F07W1067745; Wed, 3 Dec 2008 08:00:07 -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 colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB3ExtLa067684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 3 Dec 2008 08:00:06 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mB3EcgxD021587; Wed, 3 Dec 2008 06:38:55 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 06:59:46 -0800 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_01C95557.C80AEC9A" Subject: RE: OCSP Responder Status Date: Wed, 3 Dec 2008 06:59:46 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFBE1@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCSP Responder Status Thread-Index: AclPKVyaoEzDsqQFQU2YNjZS85ShHgGLJezN References: <052601c94e56$60120f00$c700a8c0@certintra.com.br> <492C01DC.9080508@secunet.com> <492C3342.4050501@mitre.org> From: "Hallam-Baker, Phillip" To: "Timothy J. Miller" , "Liaquat Khan" Cc: "Johannes Merkle" , "Mauricio Balassiano" , X-OriginalArrivalTime: 03 Dec 2008 14:59:46.0856 (UTC) FILETIME=[C858FA80:01C95557] 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_01C95557.C80AEC9A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The trusted responder model makes no sense to me unless you are = delegating the complete trust decision to an external resource as in = SCVP. Which is of course why some of us suggested SCVP be an OCSP = extension. =20 If we were going to do anything more in this area (and I don't think we = should), we should implement the only trusted responder delegation that = makes any sense to me at all and that is where the trusted responder is = responsible for verifying the key in its entirety. =20 If you are doing delegated trust with a PKI capable endpoint device the = computational task of path math is a diminishing concer. The problem of = management of the trusted certificate base and security policy is the = bigger and increasing part of the problem. =20 So if we were to address this point I would suggest doing it through a = profile on SCVP, and SCVP-Lite profile, in which the client provides no = input into the request other than describing what it wants to DO. That = means no talk of trust roots and paths and such. Just 'X wants to do Y = with Z, give me the key and the algorithm context to use' =20 =20 In other words, SCVP-Lite is XKMS but fixing the mistake we made by = making XKMS specific to public key.=20 =20 If XKMS could deliver either a symmetric key OR a public key, then you = can have a mode of communication where the XKMS server is also operating = as a kerberos key server.=20 =20 Now that I am interested in devices that cannot support ethernet, cannot = support IP and certainly cannot support public key (no not even ECC = variants), I am starting to see interesting advantages you can achieve = by using a blend of symmetric and public key techniques rather than the = traditional approach of letting PKI do al the glamorous trusty stuff and = then confining symmetric key to just a bunch of session key stuff. =20 =20 ________________________________ From: owner-ietf-pkix@mail.imc.org on behalf of Timothy J. Miller Sent: Tue 11/25/2008 12:17 PM To: Liaquat Khan Cc: 'Johannes Merkle'; 'Mauricio Balassiano'; ietf-pkix@imc.org Subject: Re: OCSP Responder Status Liaquat Khan wrote: > The problem with your option 3 is that RFC2560 doesn't explain how a = client > can check that the second responder is acting on behalf of the first = CA. > I.e. it may chain to a trust anchor, allowing you to verify the = signature on > the OCSP response, but how do you know that the original CA actually > authorised this second responder to provide status information on the = first > responder's certificate? That's what client configuration control is for. :) That's the whole point of the trusted responder model--trust in that responder is established out-of-band (i.e., not part of the OCSP protocol). > If you are happy to live without this check then this can work, = however I > have not really seen this method actual used (probably because it = introduces > more complexity than the benefit it offers).=20 The DoD OCSP service uses the trusted responder model. It's a real PITA to manage; you have to make sure all the RPs are properly configured. Key changing under this model is even worse; the hoops we had to jump through were seriously sick. We're now migrating to the CA designated model. The CA-issued OCSP signing certs will be short-lived certs with longer-lived keys (IIRC, 30 day cert life with renewal allowed for some period of time). -- Tim ------_=_NextPart_001_01C95557.C80AEC9A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: OCSP Responder Status=0A= =0A= =0A= =0A=
=0A=
The trusted = responder model makes no sense to me unless you are delegating the = complete trust decision to an external resource as in SCVP. Which is of = course why some of us suggested SCVP be an OCSP extension.
=0A=
 
=0A=
If we were going to do = anything more in this area (and I don't think we should), we should = implement the only trusted responder delegation that makes any sense to = me at all and that is where the trusted responder is responsible for = verifying the key in its entirety.
=0A=
 
=0A=
If you are doing delegated = trust with a PKI capable endpoint device the computational task of path = math is a diminishing concer. The problem of management of the trusted = certificate base and security policy is the bigger and increasing part = of the problem.
=0A=
 
=0A=
So if we were to address this = point I would suggest doing it through a profile on SCVP, and SCVP-Lite = profile, in which the client provides no input into the request other = than describing what it wants to DO. That means no talk of trust roots = and paths and such. Just 'X wants to do Y with Z, give me the key and = the algorithm context to use'
=0A=
 
=0A=
 
=0A=
In other words, SCVP-Lite is = XKMS but fixing the mistake we made by making XKMS specific to public = key.
=0A=
 
=0A=
If XKMS could deliver either = a symmetric key OR a public key, then you can have a mode of = communication where the XKMS server is also operating as a kerberos key = server.
=0A=
 
=0A=
Now that I am interested in = devices that cannot support ethernet, cannot support IP and certainly = cannot support public key (no not even ECC variants), I am starting to = see interesting advantages you can achieve by using a blend of symmetric = and public key techniques rather than the traditional approach of = letting PKI do al the glamorous trusty stuff and then confining = symmetric key to just a bunch of session key stuff.
=0A=
 
=0A=
 
=0A=

=0A=
=0A= From: owner-ietf-pkix@mail.imc.org = on behalf of Timothy J. Miller
Sent: Tue 11/25/2008 12:17 = PM
To: Liaquat Khan
Cc: 'Johannes Merkle'; 'Mauricio = Balassiano'; ietf-pkix@imc.org
Subject: Re: OCSP Responder = Status

=0A=
=0A=

Liaquat Khan wrote:
> The problem with your = option 3 is that RFC2560 doesn't explain how a client
> can check = that the second responder is acting on behalf of the first CA.
> = I.e. it may chain to a trust anchor, allowing you to verify the = signature on
> the OCSP response, but how do you know that the = original CA actually
> authorised this second responder to provide = status information on the first
> responder's = certificate?

That's what client configuration control is = for.  :)  That's the whole
point of the trusted responder = model--trust in that responder is
established out-of-band (i.e., not = part of the OCSP protocol).

> If you are happy to live without = this check then this can work, however I
> have not really seen = this method actual used (probably because it introduces
> more = complexity than the benefit it offers). 

The DoD OCSP = service uses the trusted responder model.  It's a real PITA
to = manage; you have to make sure all the RPs are properly = configured.
Key changing under this model is even worse; the hoops we = had to jump
through were seriously sick.

We're now migrating = to the CA designated model.  The CA-issued OCSP
signing certs = will be short-lived certs with longer-lived keys (IIRC, 30
day cert = life with renewal allowed for some period of time).

-- = Tim

------_=_NextPart_001_01C95557.C80AEC9A-- From mftoeh@allencanning.com Sun Dec 7 03:00:02 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF723A68C6 for ; Sun, 7 Dec 2008 03:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ELP0oFHDgVC for ; Sun, 7 Dec 2008 03:00:02 -0800 (PST) Received: from ppp91-76-113-48.pppoe.mtu-net.ru (ppp91-76-113-48.pppoe.mtu-net.ru [91.76.113.48]) by core3.amsl.com (Postfix) with SMTP id D7A363A67AC for ; Sun, 7 Dec 2008 02:59:57 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207110000.D7A363A67AC@core3.amsl.com> Date: Sun, 7 Dec 2008 02:59:57 -0800 (PST) Click to visit Official Web Site! From jeronimo@alpestransportes.com.br Sun Dec 7 03:43:42 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997C13A6839 for ; Sun, 7 Dec 2008 03:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.088 X-Spam-Level: X-Spam-Status: No, score=-13.088 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYAzzeH+yhoo for ; Sun, 7 Dec 2008 03:43:42 -0800 (PST) Received: from ppp-124-120-58-87.revip2.asianet.co.th (ppp-124-120-58-87.revip2.asianet.co.th [124.120.58.87]) by core3.amsl.com (Postfix) with SMTP id 578193A677C for ; Sun, 7 Dec 2008 03:43:39 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207114340.578193A677C@core3.amsl.com> Date: Sun, 7 Dec 2008 03:43:39 -0800 (PST) Click to visit Official Web Site! From karenn@agri-fab.com Sun Dec 7 04:37:18 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79F73A6862 for ; Sun, 7 Dec 2008 04:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.212 X-Spam-Level: X-Spam-Status: No, score=-17.212 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq9Iqf1tsB-5 for ; Sun, 7 Dec 2008 04:37:18 -0800 (PST) Received: from nat-goc-1.aster.pl (nat-goc-1.aster.pl [212.76.37.184]) by core3.amsl.com (Postfix) with SMTP id 4615B3A684A for ; Sun, 7 Dec 2008 04:37:15 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207123716.4615B3A684A@core3.amsl.com> Date: Sun, 7 Dec 2008 04:37:15 -0800 (PST) Click to visit Official Web Site! From maf00151nn@andymaura.com Sun Dec 7 15:19:30 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E613A69F4 for ; Sun, 7 Dec 2008 15:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.825 X-Spam-Level: X-Spam-Status: No, score=-27.825 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_RU=0.595, HELO_MISMATCH_RU=3.1, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdZbKcG1FNpx for ; Sun, 7 Dec 2008 15:19:30 -0800 (PST) Received: from akdgs.ru (unknown [190.84.11.66]) by core3.amsl.com (Postfix) with SMTP id 291953A6874 for ; Sun, 7 Dec 2008 15:19:26 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207231927.291953A6874@core3.amsl.com> Date: Sun, 7 Dec 2008 15:19:26 -0800 (PST) Click here! From owner-ietf-pkix@mail.imc.org Mon Dec 8 14:03:17 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6BF3A6AA9 for ; Mon, 8 Dec 2008 14:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.185 X-Spam-Level: X-Spam-Status: No, score=-104.185 tagged_above=-999 required=5 tests=[AWL=2.414, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7emt3Jqa8eQU for ; Mon, 8 Dec 2008 14:03:16 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2EFB93A6AAB for ; Mon, 8 Dec 2008 14:03:15 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8LTux6002072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 14:29:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB8LTuaN002071; Mon, 8 Dec 2008 14:29: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8LTuCg002064 for ; Mon, 8 Dec 2008 14:29:56 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 3A2713A6823; Mon, 8 Dec 2008 13:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D Action:draft-ietf-pkix-prqp-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081208213001.3A2713A6823@core3.amsl.com> Date: Mon, 8 Dec 2008 13:30:01 -0800 (PST) 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 : PKI Resource Query Protocol (PRQP) Author(s) : M. Pala Filename : draft-ietf-pkix-prqp-02.txt Pages : 35 Date : 2008-12-08 One of the most strategic problems still open in PKIX is locating public data and services associated with a Certification Authority (CA). This issue impacts interoperability and usability in PKIX. This draft describes the PKI Resource Query Protocol (PRQP), its design, definition, and its impact in already deployed PKIX protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pkix-prqp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-08132200.I-D@ietf.org> --NextPart-- From owner-ietf-pkix@mail.imc.org Mon Dec 8 14:47:18 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7938628C107 for ; Mon, 8 Dec 2008 14:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07cs1IlmcL01 for ; Mon, 8 Dec 2008 14:47:17 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2EE9E28C0FD for ; Mon, 8 Dec 2008 14:47:16 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8MOXVL005036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 15:24:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB8MOX0k005035; Mon, 8 Dec 2008 15:24: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 mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8MOLGd005027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Dec 2008 15:24:32 -0700 (MST) (envelope-from Massimiliano.Pala@Dartmouth.edu) Received: from newblitzen.Dartmouth.EDU (newblitzen.dartmouth.edu [129.170.208.36]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id mB8MC1pr019217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Dec 2008 17:24:11 -0500 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from dhcp-212-179.cs.dartmouth.edu [129.170.212.179] by newblitzen.Dartmouth.EDU (Mac) via SMTP for ietf-pkix@imc.org id <138037849>; 08 Dec 2008 17:24:10 -0500 Message-ID: <493D9E8A.7090908@Dartmouth.edu> Date: Mon, 08 Dec 2008 17:24:10 -0500 From: Massimiliano Pala Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: I-D Action:draft-ietf-pkix-prqp-02.txt References: <20081208213001.3A2713A6823@core3.amsl.com> In-Reply-To: <20081208213001.3A2713A6823@core3.amsl.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090101050805030202040209" X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU X-MailScanner-From: massimiliano.pala@dartmouth.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms090101050805030202040209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I just published the new version of the draft. The main difference is the DHCP section where we now have the definition for DHCPv4 *and* DHCPv6 options. I am waiting on the input from the DHC WG. Please let me know if any of you have further comments on this version of the I-D. Cheers, Max Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. [...] > Title : PKI Resource Query Protocol (PRQP) > Author(s) : M. Pala > Filename : draft-ietf-pkix-prqp-02.txt > Pages : 35 > Date : 2008-12-08 > > One of the most strategic problems still open in PKIX is locating > public data and services associated with a Certification Authority > (CA). This issue impacts interoperability and usability in PKIX. > > This draft describes the PKI Resource Query Protocol (PRQP), its > design, definition, and its impact in already deployed PKIX > protocols. --------------ms090101050805030202040209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3 dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z 3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7 PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0 FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/ BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMjA4 MjIyNDEwWjAjBgkqhkiG9w0BCQQxFgQUNkVBxqV40yWlfZR25U3Kidyj3AowUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE gYALii0fWUQB48vnJh4FHbpYlUbJwaOl45jT2pce4rucCziMVNdx7Mxmwnw3EWoFzk/M4jyN ABYGdobQ3x5opC60CKWX9l43NVj5cuPbqAc67Q6OISOpN4tHnXEYyglg9dp9jdCauE591Q6R n9+H6KeuG2pXNlRPGhabf1JS+KYWmgAAAAAAAA== --------------ms090101050805030202040209-- From mmp@alienscutmyhair.com Tue Dec 9 01:27:31 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D6D3A6B04 for ; Tue, 9 Dec 2008 01:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29 X-Spam-Level: X-Spam-Status: No, score=-29 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46HkbpmyU9OD for ; Tue, 9 Dec 2008 01:27:30 -0800 (PST) Received: from host169-166-static.44-85-b.business.telecomitalia.it (host169-166-static.44-85-b.business.telecomitalia.it [85.44.166.169]) by core3.amsl.com (Postfix) with SMTP id 5898D3A695E for ; Tue, 9 Dec 2008 01:27:28 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081209092729.5898D3A695E@core3.amsl.com> Date: Tue, 9 Dec 2008 01:27:28 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mcquade@accedoconsulting.com Wed Dec 10 05:00:43 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D083A6B9B for ; Wed, 10 Dec 2008 05:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.48 X-Spam-Level: X-Spam-Status: No, score=-8.48 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOYO7sFUPbCI for ; Wed, 10 Dec 2008 05:00:43 -0800 (PST) Received: from aitlbd.net (unknown [189.7.103.101]) by core3.amsl.com (Postfix) with SMTP id 1E4B03A6B9F for ; Wed, 10 Dec 2008 05:00:41 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081210130042.1E4B03A6B9F@core3.amsl.com> Date: Wed, 10 Dec 2008 05:00:41 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Wed Dec 10 05:27:13 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2E73A67AC for ; Wed, 10 Dec 2008 05:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l+ejuK90A8I for ; Wed, 10 Dec 2008 05:27:13 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B18553A67A5 for ; Wed, 10 Dec 2008 05:27:12 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBACsh4k030003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 05:54:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBACshSo030002; Wed, 10 Dec 2008 05:54:43 -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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBACsW73029992 for ; Wed, 10 Dec 2008 05:54:43 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.173.171]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LAOaF-000750-Fc for ietf-pkix@imc.org; Wed, 10 Dec 2008 07:54:32 -0500 Mime-Version: 1.0 Message-Id: Date: Wed, 10 Dec 2008 07:52:22 -0500 To: ietf-pkix@imc.org From: Stephen Kent Subject: minutes posted Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have received comments from 2 sources, and made the requested changes. Since over two weeks have elapsed, I am posting final meeting minutes. Steve From jose.silva@altitude.com Wed Dec 10 08:41:55 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3B063A68DD for ; Wed, 10 Dec 2008 08:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.193 X-Spam-Level: X-Spam-Status: No, score=-18.193 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUbxxdNxHrOO for ; Wed, 10 Dec 2008 08:41:55 -0800 (PST) Received: from host246-59-dynamic.16-79-r.retail.telecomitalia.it (host246-59-dynamic.16-79-r.retail.telecomitalia.it [79.16.59.246]) by core3.amsl.com (Postfix) with SMTP id E8C613A69A8 for ; Wed, 10 Dec 2008 08:41:52 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081210164153.E8C613A69A8@core3.amsl.com> Date: Wed, 10 Dec 2008 08:41:52 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Thu Dec 11 01:58:57 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4333D28C0D6 for ; Thu, 11 Dec 2008 01:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWTkWqZoZ6hq for ; Thu, 11 Dec 2008 01:58:50 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 064CD3A6C3C for ; Thu, 11 Dec 2008 01:58:48 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBB9MEBn097238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 02:22:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBB9MEFo097237; Thu, 11 Dec 2008 02:22:14 -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-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBB9M2QQ097213 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 11 Dec 2008 02:22:13 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 11 Dec 2008 09:22:01 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 11 Dec 2008 09:22:01 +0000 From: Stefan Santesson To: "Hallam-Baker, Phillip" , "ietf-pkix@imc.org" Date: Thu, 11 Dec 2008 09:21:37 +0000 Subject: RE: New Version Notification for draft-hallambaker-ocspagility-02 Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02 Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYUAbAkkKA= Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB5BBBECD@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20081202183941.5A3003A6B4C@core3.amsl.com> <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB5BBBECDEAEXMSGC332eu_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_9F11911AED01D24BAA1C2355723C3D321AB5BBBECDEAEXMSGC332eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, I have a few comments on the draft: This is more a nit, but I don't think the following is a compelling argumen= t, strong enough to be mentioned: o An implementation may intentionally wish to guard against the possibility of a compromise resulting from a signature algorithm compromise by employing two separate encryption algorithms. If an implementation is securing two co-dependent messages with two differe= nt algorithms, where breaking one of them successfully compromises the syst= em, then you have increased your risk of compromise rather than reducing it= . Further, I would like to see some explicit text, explaining that this appro= ach is not applicable, or at least should not be used in combination with i= mplementations of 5019. Section 4.2. do state that the server can pre-produce several responses to = the same request signed with different algorithms, but what I'm most concer= ned with is that clients including the extension in the request, in combina= tion with RFC 5019 implementations may mess up http caching. Http caching i= s an important aspect of achieving scalability for LW OCSP. I would prefer to entirely discourage the use of this client extension with= RFC 5019, but at least discuss the issue in the draft to make implementers= aware of the problem. 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 Hallam-Baker, Phillip Sent: den 2 december 2008 20:01 To: ietf-pkix@imc.org Subject: FW: New Version Notification for draft-hallambaker-ocspagility-02 As promised at the meeting, here is an update to the OCSP agility draft. With the WG and chair's permission I will resubmit as a WG draft. The basic history here is that we tried to deploy an OCSP resolver that mee= ts a pretty simple set of requirements for multiple algorithm support and f= ound that the base specification does not actually say anything about how a= response signature algorithm should be chosen, except that SHA-1 can be im= plemented. So a perfectly legal OCSP responder could report the status of a public key= certificate for an RSA signature key, signed with an RSA signature key wit= h ECC. And it gets worse, if you have an ocsp responder that is managing certs sig= ned with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, etc. e= tc.) and a status request comes in for an unknown cert, there is no data fo= r the responder to choose a reasonble response alg. You are forced to choos= e a lowest common denominator alg which is a problem if you moved to ECC be= cause RSA 4096 does not cut it. So this is a pretty simple fix to sort it out. I suggest that this goes on = standards track and if we progress OCSP from PROPOSED to DRAFT we dump the = explanatory part and merge the normative text in. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM To: Hallam-Baker, Phillip Subject: New Version Notification for draft-hallambaker-ocspagility-02 A new version of I-D, draft-hallambaker-ocspagility-02.txt has been success= fuly submitted by Phillip Hallam-Baker and posted to the IETF repository. Filename: draft-hallambaker-ocspagility Revision: 02 Title: OCSP Algorithm Agility Creation_date: 2008-12-02 WG ID: Independent Submission Number_of_pages: 8 Abstract: The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. The IETF Secretariat. --_000_9F11911AED01D24BAA1C2355723C3D321AB5BBBECDEAEXMSGC332eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: New Version Notification for draft-hallambaker-ocspagility-02 </= title> <style> <!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:0cm; font-size:12.0pt; font-family:"Times New Roman","serif";} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Courier New";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:36.0pt; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:612.0pt 792.0pt; margin:70.85pt 70.85pt 70.85pt 70.85pt;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:690883177; mso-list-type:hybrid; mso-list-template-ids:902045572 69009409 69009411 69009413 69009409 690094= 11 69009413 69009409 69009411 69009413;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:38.25pt; text-indent:-18.0pt; font-family:Symbol;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DSV link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style= =3D'font-size: 11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Phil,<o:p></o:p></= span></a></p> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif"; color:#1F497D'>I have a few comments on the draft:<o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif"; color:#1F497D'>This is more a nit, but I don’t think the following is= a compelling argument, strong enough to be mentioned:<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN style=3D'font-family:"Courier New"'>   o  An implementation = may intentionally wish to guard against the<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN style=3D'font-family:"Courier New"'>      possibil= ity of a compromise resulting from a signature algorithm<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN style=3D'font-family:"Courier New"'>      compromi= se by employing two separate encryption algorithms.<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN style=3D'font-family:"Courier New"'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'>If an implementation is securing two co-dependent messages w= ith two different algorithms, where breaking one of them successfully compromis= es the system, then you have increased your risk of compromise rather than reducing it.<o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'>Further, I would like to see some explicit text, explaining = that this approach is not applicable, or at least should not be used in combinat= ion with implementations of 5019.<o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'>Section 4.2. do state that the server can pre-produce severa= l responses to the same request signed with different algorithms, but what I&= #8217;m most concerned with is that clients including the extension in the request,= in combination with RFC 5019 implementations may mess up http caching. Http caching is an important aspect of achieving scalability for LW OCSP. <o:p><= /o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'>I would prefer to entirely discourage the use of this client= extension with RFC 5019, but at least discuss the issue in the draft to make implemen= ters aware of the problem.<o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f= amily: "Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D= EN-GB style=3D'color:#1F497D'><o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami= ly:"Arial","sans-serif"; color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'col= or:navy'><o:p></o:p></span></p> <p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f= amily: "Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p></o:p></span></p> </div> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm = 4.0pt'> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm'> <p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f= amily: "Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz= e:10.0pt; font-family:"Tahoma","sans-serif"'> owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] <b>On Behalf Of </b>Hallam-Baker, Phi= llip<br> <b>Sent:</b> den 2 december 2008 20:01<br> <b>To:</b> ietf-pkix@imc.org<br> <b>Subject:</b> FW: New Version Notification for draft-hallambaker-ocspagility-02 <o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p style=3D'margin-bottom:12.0pt'><span style=3D'font-size:10.0pt'>As promi= sed at the meeting, here is an update to the OCSP agility draft.<br> <br> With the WG and chair's permission I will resubmit as a WG draft.<br> <br> <br> The basic history here is that we tried to deploy an OCSP resolver that mee= ts a pretty simple set of requirements for multiple algorithm support and found = that the base specification does not actually say anything about how a response signature algorithm should be chosen, except that SHA-1 can be implemented.= <br> <br> <br> So a perfectly legal OCSP responder could report the status of a public key certificate for an RSA signature key, signed with an RSA signature key with= ECC.<br> <br> And it gets worse, if you have an ocsp responder that is managing certs sig= ned with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, etc. etc.)= and a status request comes in for an unknown cert, there is no data for the responder to choose a reasonble response alg. You are forced to choose a lo= west common denominator alg which is a problem if you moved to ECC because RSA 4= 096 does not cut it.<br> <br> <br> So this is a pretty simple fix to sort it out. I suggest that this goes on standards track and if we progress OCSP from PROPOSED to DRAFT we dump the explanatory part and merge the normative text in.<br> <br> <br> -----Original Message-----<br> From: IETF I-D Submission Tool [<a href=3D"mailto:idsubmission@ietf.org">ma= ilto:idsubmission@ietf.org</a>]<br> Sent: Tue 12/2/2008 1:39 PM<br> To: Hallam-Baker, Phillip<br> Subject: New Version Notification for draft-hallambaker-ocspagility-02<br> <br> <br> A new version of I-D, draft-hallambaker-ocspagility-02.txt has been success= fuly submitted by Phillip Hallam-Baker and posted to the IETF repository.<br> <br> Filename:        draft-hallambaker-ocspagility<br> Revision:        02<br> Title:           OCSP Algorith= m Agility<br> Creation_date:   2008-12-02<br> WG ID:           Independent Submission<br> Number_of_pages: 8<br> <br> Abstract:<br> The OSCP specification defined in RFC 2560 requires server responses<br> to be signed but does not specify a mechanism for selecting the<br> signature algorithm to be used leading to possible interoperability<br> failures in contexts where multiple signature algorithms are in use.<br> This document specifies an algorithm for server signature algorithm<br> selection and an extension that allows a client to advise a server<br> that specific signature algorithms are supported.<br>             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       <br> <br> <br> The IETF Secretariat.<br> <br> <br> <br> <br> <br> </span><o:p></o:p></p> </div> </div> </body> </html> --_000_9F11911AED01D24BAA1C2355723C3D321AB5BBBECDEAEXMSGC332eu_-- From owner-ietf-pkix@mail.imc.org Thu Dec 11 02:36:27 2008 Return-Path: <owner-ietf-pkix@mail.imc.org> X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71603A6C48 for <ietfarch-pkix-archive@core3.amsl.com>; Thu, 11 Dec 2008 02:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.578 X-Spam-Level: X-Spam-Status: No, score=-10.578 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZI-572wJ2Wj for <ietfarch-pkix-archive@core3.amsl.com>; Thu, 11 Dec 2008 02:36:27 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8A0663A6C45 for <pkix-archive@ietf.org>; Thu, 11 Dec 2008 02:36:26 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBAAxti001017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 03:10:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBBAAxqP001016; Thu, 11 Dec 2008 03:10: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 smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBAAlNX000989 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <ietf-pkix@imc.org>; Thu, 11 Dec 2008 03:10:58 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 11 Dec 2008 10:10:46 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 11 Dec 2008 10:10:35 +0000 From: Stefan Santesson <stefans@microsoft.com> To: "Kemp, David P." <DPKemp@missi.ncsc.mil>, "ietf-pkix@imc.org" <ietf-pkix@imc.org> Date: Thu, 11 Dec 2008 10:10:12 +0000 Subject: RE: Signing and Encrypting with the same key? Thread-Topic: Signing and Encrypting with the same key? Thread-Index: AclHM5GhiwsKjI5xQ6qgVyHzIVGcwwBiHg0QBK8KrkA= Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB5BBBF67@EA-EXMSG-C332.europe.corp.microsoft.com> References: <E1KwTQG-0003Ms-IF@wintermute01.cs.auckland.ac.nz> <B9A9F0E608D94D2CA899102A88789787@AndersPC> <255B9BB34FB7D647A506DC292726F6E11140B81F89@WSMSG3153V.srv.dir.telstra.com> <51604CB892B44C39BAF60D61875EB21E@AndersPC> <491EDDDD.2080409@lockstep.com.au> <C1A47F1540DF3246A8D30C853C05D0DA6B44A2@DABECK.missi.ncsc.mil> In-Reply-To: <C1A47F1540DF3246A8D30C853C05D0DA6B44A2@DABECK.missi.ncsc.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> R3V5cywNCg0KSSBqdXN0IHJlYWxpemVkIHRoYXQgd2UgYWN0dWFsbHkgbWlnaHQgaGF2ZSBldm9s dmVkIGFzIGEgY29tbXVuaXR5Lg0KDQpTb21lb25lIGFza2VkIGZvciB0aGUgdHJ1ZSBtZWFuaW5n IG9mIG5vbi1yZXB1ZGlhdGlvbi4uLi4uLiBhbmQgdGhpcyBlLW1haWwgbGlzdCBkaWRuJ3QgZXhw bG9kZS4NCg0KDQpTdGVmYW4gU2FudGVzc29uDQpTZW5pb3IgUHJvZ3JhbSBNYW5hZ2VyDQpXaW5k b3dzIFNlY3VyaXR5LCBTdGFuZGFyZHMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IG93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmcgW21haWx0bzpvd25lci1pZXRm LQ0KPiBwa2l4QG1haWwuaW1jLm9yZ10gT24gQmVoYWxmIE9mIEtlbXAsIERhdmlkIFAuDQo+IFNl bnQ6IGRlbiAxNyBub3ZlbWJlciAyMDA4IDE1OjA3DQo+IFRvOiBpZXRmLXBraXhAaW1jLm9yZw0K PiBTdWJqZWN0OiBSRTogU2lnbmluZyBhbmQgRW5jcnlwdGluZyB3aXRoIHRoZSBzYW1lIGtleT8N Cj4NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBTdGVwaGVu IFdpbHNvbg0KPiA+DQo+ID4gSSdkIGxpa2UgdG8ga25vdyB0aGUgcHJlY2lzZQ0KPiA+IGhpc3Rv cnkgb2YgdGhlIE5SIGJpdCBpbiBYLjUwOS4gIFdobyBhY3R1YWxseSB0aG91Z2h0IG9mIGl0LCB3 ZXJlDQo+IHRoZXkNCj4gPiBhbiBlbmdpbmVlciBvciBhIGxhd3llciwgYW5kIHdoYXQgaWYgYW55 IGRlYmF0ZSB3ZW50IG9uIGF0IHRoZSB0aW1lPw0KPg0KPiBUcnVzdCBtZSwgeW91IHJlYWxseSwg UkVBTExZIGRvbid0IHdhbnQgdG8ga25vdyA6LSkuDQo+DQo+IFRob3NlIG9uIG9uZSBzaWRlIG9m IHRoZSBhcmd1bWVudCB0aG91Z2h0IHRoYXQgdGhlIE5SIGJpdCBzZXQgc2hvdWxkIGJlDQo+IHVz ZWQgZm9yIHNpZ25hdHVyZXMgdGhhdCBjb3VsZCBiZSB2YWxpZGF0ZWQgaW5kZWZpbml0ZWx5IChp LmUuIGZvciB3aGF0DQo+IG9uZSBub3JtYWxseSB0aGlua3Mgb2YgYXMgInNpZ25pbmciKSwgYW5k IHNpZ25hdHVyZXMgd2l0aCB0aGUgTlIgYml0DQo+IGNsZWFyIGNvdWxkIGJlIHVzZWQgb25seSBm b3Igc2Vzc2lvbiBhdXRoZW50aWNhdGlvbi4gIFRoYXQgd2F5IGEgc2lnbmVkDQo+IG9iamVjdCBj cmVhdGVkIGFzIHBhcnQgb2YgYSBsb2dpbiBzZXNzaW9uIGNvdWxkIG5vdCBiZSBtaXNyZXByZXNl bnRlZA0KPiBhcyBhIHNpZ25lZCBkb2N1bWVudC4NCj4NCj4gVGhvc2Ugb24gdGhlIG90aGVyIHNp ZGUgdGhvdWdodCB0aGF0IHRoZSBOUiBiaXQgYWN0dWFsbHkgaGFkIHNvbWV0aGluZw0KPiB0byBk byB3aXRoICJyZXB1ZGlhdGluZyIgc2lnbmF0dXJlcywgd2hpY2ggSU1ITyBpcyBhIHJpZGljdWxv dXMgaWRlYQ0KPiBmb3IgdGhlIHJlYXNvbnMgeW91IHN1Z2dlc3QuICBUaG9zZSB3aG8gYmVsaWV2 ZSBpbiB0aGUgY3VycmVudCBYLjUwOQ0KPiBpbnRlcnByZXRhdGlvbiBtYXkgZGVmZW5kIGl0IGlm IHRoZXkgd2lzaCwgb3Igc3BhcmUgdXMgdGhlIGRpc2N1c3Npb24uDQo+DQo+IERhdmUNCg== From owner-ietf-pkix@mail.imc.org Thu Dec 11 04:18:00 2008 Return-Path: <owner-ietf-pkix@mail.imc.org> X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED983A6801 for <ietfarch-pkix-archive@core3.amsl.com>; Thu, 11 Dec 2008 04:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GaxC0VAdWvg for <ietfarch-pkix-archive@core3.amsl.com>; Thu, 11 Dec 2008 04:17:59 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C12333A67B3 for <pkix-archive@ietf.org>; Thu, 11 Dec 2008 04:17:57 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBBpELE005778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 04:51:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBBBpEC8005777; Thu, 11 Dec 2008 04:51:14 -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 robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBBp2Bq005761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Thu, 11 Dec 2008 04:51:13 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id mBBBp1pW001257; Thu, 11 Dec 2008 03:51:01 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 03:51:01 -0800 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_01C95B86.BC04481B" Subject: RE: New Version Notification for draft-hallambaker-ocspagility-02 Date: Thu, 11 Dec 2008 03:50:59 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFC15@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02 Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYUAbAkkKAABZs5tw== References: <20081202183941.5A3003A6B4C@core3.amsl.com> <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> <9F11911AED01D24BAA1C2355723C3D321AB5BBBECD@EA-EXMSG-C332.europe.corp.microsoft.com> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "Stefan Santesson" <stefans@microsoft.com>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 11 Dec 2008 11:51:01.0435 (UTC) FILETIME=[BD2CE0B0:01C95B86] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------_=_NextPart_001_01C95B86.BC04481B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On the first issue, it depends on your implementation. If two signature = algorithms are used and clients accept either then the result is to = weaken the protection. If two algorithms are required and either clients = are required to check both or there is a mechanism to disable use of a = compromised algorithm the net result is stronger. In the case of checking a cert chain and an OCSP validation chain the = second considerations apply. On the 5019 issue, happy to extend the draft, just preferred to get = something in ASAP and need to get my head around the concerns first. -----Original Message----- From: owner-ietf-pkix@mail.imc.org on behalf of Stefan Santesson Sent: Thu 12/11/2008 4:21 AM To: Hallam-Baker, Phillip; ietf-pkix@imc.org Subject: RE: New Version Notification for = draft-hallambaker-ocspagility-02=20 =20 Phil, =20 I have a few comments on the draft: =20 This is more a nit, but I don't think the following is a compelling = argument, strong enough to be mentioned: o An implementation may intentionally wish to guard against the possibility of a compromise resulting from a signature algorithm compromise by employing two separate encryption algorithms. =20 If an implementation is securing two co-dependent messages with two = different algorithms, where breaking one of them successfully = compromises the system, then you have increased your risk of compromise = rather than reducing it. =20 Further, I would like to see some explicit text, explaining that this = approach is not applicable, or at least should not be used in = combination with implementations of 5019. Section 4.2. do state that the server can pre-produce several responses = to the same request signed with different algorithms, but what I'm most = concerned with is that clients including the extension in the request, = in combination with RFC 5019 implementations may mess up http caching. = Http caching is an important aspect of achieving scalability for LW = OCSP.=20 =20 I would prefer to entirely discourage the use of this client extension = with RFC 5019, but at least discuss the issue in the draft to make = implementers aware of the problem. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Hallam-Baker, Phillip Sent: den 2 december 2008 20:01 To: ietf-pkix@imc.org Subject: FW: New Version Notification for = draft-hallambaker-ocspagility-02=20 =20 =20 As promised at the meeting, here is an update to the OCSP agility draft. With the WG and chair's permission I will resubmit as a WG draft. The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented. So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC. And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it. So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM To: Hallam-Baker, Phillip Subject: New Version Notification for draft-hallambaker-ocspagility-02 A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository. Filename: draft-hallambaker-ocspagility Revision: 02 Title: OCSP Algorithm Agility Creation_date: 2008-12-02 WG ID: Independent Submission Number_of_pages: 8 Abstract: The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. = =20 The IETF Secretariat. ------_=_NextPart_001_01C95B86.BC04481B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7653.38"> <TITLE>RE: New Version Notification for draft-hallambaker-ocspagility-02 =

On the first issue, it depends on your implementation. = If two signature algorithms are used and clients accept either then the = result is to weaken the protection. If two algorithms are required and = either clients are required to check both or there is a mechanism to = disable use of a compromised algorithm the net result is stronger.

In the case of checking a cert chain and an OCSP validation chain the = second considerations apply.


On the 5019 issue, happy to extend the draft, just preferred to get = something in ASAP and need to get my head around the concerns first.


-----Original Message-----
From: owner-ietf-pkix@mail.imc.org on behalf of Stefan Santesson
Sent: Thu 12/11/2008 4:21 AM
To: Hallam-Baker, Phillip; ietf-pkix@imc.org
Subject: RE: New Version Notification for = draft-hallambaker-ocspagility-02

Phil,



I have a few comments on the draft:



This is more a nit, but I don't think the following is a compelling = argument, strong enough to be mentioned:

   o  An implementation may intentionally wish to guard = against the

      possibility of a compromise resulting = from a signature algorithm

      compromise by employing two separate = encryption algorithms.



If an implementation is securing two co-dependent messages with two = different algorithms, where breaking one of them successfully = compromises the system, then you have increased your risk of compromise = rather than reducing it.



Further, I would like to see some explicit text, explaining that this = approach is not applicable, or at least should not be used in = combination with implementations of 5019.

Section 4.2. do state that the server can pre-produce several responses = to the same request signed with different algorithms, but what I'm most = concerned with is that clients including the extension in the request, = in combination with RFC 5019 implementations may mess up http caching. = Http caching is an important aspect of achieving scalability for LW = OCSP.



I would prefer to entirely discourage the use of this client extension = with RFC 5019, but at least discuss the issue in the draft to make = implementers aware of the problem.





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 Hallam-Baker, Phillip
Sent: den 2 december 2008 20:01
To: ietf-pkix@imc.org
Subject: FW: New Version Notification for = draft-hallambaker-ocspagility-02





As promised at the meeting, here is an update to the OCSP agility = draft.

With the WG and chair's permission I will resubmit as a WG draft.


The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented.


So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC.

And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it.


So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in.


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for = draft-hallambaker-ocspagility-02


A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository.

Filename:        = draft-hallambaker-ocspagility
Revision:        02
Title:           OCSP = Algorithm Agility
Creation_date:   2008-12-02
WG ID:           = Independent Submission
Number_of_pages: 8

Abstract:
The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.
            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =        


The IETF Secretariat.

------_=_NextPart_001_01C95B86.BC04481B-- From marlousscammerhornd@6notes.com Thu Dec 11 08:51:30 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74E93A69A0 for ; Thu, 11 Dec 2008 08:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hwUfAQwu9+D for ; Thu, 11 Dec 2008 08:51:30 -0800 (PST) Received: from 83-238-238-19.adsl.inetia.pl (83-238-230-143.adsl.inetia.pl [83.238.230.143]) by core3.amsl.com (Postfix) with SMTP id DB15E3A6BEC for ; Thu, 11 Dec 2008 08:51:28 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211165128.DB15E3A6BEC@core3.amsl.com> Date: Thu, 11 Dec 2008 08:51:28 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From martini@accortour.com.br Thu Dec 11 09:05:56 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C753A68F0 for ; Thu, 11 Dec 2008 09:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.608 X-Spam-Level: X-Spam-Status: No, score=-18.608 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_MISMATCH_COM=0.553, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drg78Pg+F44j for ; Thu, 11 Dec 2008 09:05:55 -0800 (PST) Received: from 24hourmall.com (eju19.internetdsl.tpnet.pl [83.15.102.19]) by core3.amsl.com (Postfix) with SMTP id 9E62B3A6A77 for ; Thu, 11 Dec 2008 09:05:53 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 080516-1, 2008-05-16), Outbound message X-Antivirus-Status: Clean Message-Id: <20081211170554.9E62B3A6A77@core3.amsl.com> Date: Thu, 11 Dec 2008 09:05:53 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From jgvlazjrgeuww@agriquem.com Thu Dec 11 10:57:47 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D44028C152 for ; Thu, 11 Dec 2008 10:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.239 X-Spam-Level: X-Spam-Status: No, score=-16.239 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uykZQkHZF0rM for ; Thu, 11 Dec 2008 10:57:47 -0800 (PST) Received: from 1klik.dk (unknown [92.112.200.0]) by core3.amsl.com (Postfix) with SMTP id B099528C147 for ; Thu, 11 Dec 2008 10:57:45 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211185745.B099528C147@core3.amsl.com> Date: Thu, 11 Dec 2008 10:57:45 -0800 (PST)
Visit site now!

From owner-ietf-pkix@mail.imc.org Thu Dec 11 10:59:43 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFA83A6996 for ; Thu, 11 Dec 2008 10:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_PACBELL_D=3.944, GB_I_INVITATION=-2, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZAeRJtvBOvr for ; Thu, 11 Dec 2008 10:59:42 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9C7463A67D2 for ; Thu, 11 Dec 2008 10:59:41 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBISU2N026781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 11:28:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBBISUwb026779; Thu, 11 Dec 2008 11:28: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 mailhost.noorhome.net (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBISJmV026763 for ; Thu, 11 Dec 2008 11:28:30 -0700 (MST) (envelope-from arshad.noor@strongauth.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.noorhome.net (Postfix) with ESMTP id 198DF3AF1C7 for ; Thu, 11 Dec 2008 13:28:19 -0500 (EST) Received: from mailhost.noorhome.net ([127.0.0.1]) by localhost (mailhost.noorhome.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8qBjhb6hNNk for ; Thu, 11 Dec 2008 13:28:18 -0500 (EST) Received: from mailhost.noorhome.net (mailhost.noorhome.net [63.194.79.229]) by mailhost.noorhome.net (Postfix) with ESMTP id 31E413AF1A2 for ; Thu, 11 Dec 2008 13:28:18 -0500 (EST) Date: Thu, 11 Dec 2008 13:28:18 -0500 (EST) From: Arshad Noor To: ietf-pkix Message-ID: <2447964.1001229020098078.JavaMail.root@gw.noorhome.net> In-Reply-To: <49413ff7.c6c1f10a.5a88.302c@mx.google.com> Subject: Fwd: [members] Public Review of SKSML v1.0 - 15 day review MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [72.18.244.116] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI. Arshad Noor StrongAuth, Inc. ----- Forwarded Message ----- From: "Mary McRae" To: members@lists.oasis-open.org, tc-announce@lists.oasis-open.org Sent: Thursday, December 11, 2008 8:29:35 AM (GMT-0800) America/Los_Angeles Subject: [members] Public Review of SKSML v1.0 - 15 day review To OASIS members, Public Announce Lists: The OASIS Enterprise Key Management Infrastructure (EKMI) TC has recently approved the following specification as a Committee Draft and approved the package for public review: Symmetric Key Services Markup Language (SKSML) Version 1.0 The public review starts today , 11 December 2008 , and ends 26 December 2008 . This specification was previously submitted for a 60-day public review on 24 Jul 08 - 23 Sep 08 [1]; this 15-day review is limited in scope to changes made from the previous review. All changes are noted below[2]. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. More non-normative information about the specification and the technical committee may be found at the public home page of the TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi ]. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked "Send A Comment" at the top of that page, or directly at http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ekmi ]. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at http://lists.oasis-open.org/archives/ekmi-comment/ . All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. The specification document and related files are available here: Editable Source: http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/SKSML-1.0-Specification.odt PDF: http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/SKSML-1.0-Specification.pdf HTML: http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/SKSML-1.0-Specification.html The schema files are available at: Schema: http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/schema/ OASIS and the EKMI TC welcome your comments. --------------------------------------------------- Mary P McRae Director, Technical Committee Administration OASIS: Advancing open standards for the information society email: mary.mcrae@oasis-open.org web: www.oasis-open.org phone: 1. 603.232.9090 [1] http://lists.oasis-open.org/archives/tc-announce/200807/msg00011.html [2] changes since last Public Review: 1) Section 3.9 - added an example of a Request for a symmetric key with an Encryption Certificate 2) Section 3.12 - added an example of a Response with a pending Request ID 3) Section 3.13 - added an example of a Request with an update of a pending Request ID 4) Section 4.4 - added definition for element 5) Section 4.5 - added definition for element 6) Section 4.6 - modified definition of to now also return a element 7) Section 4.8 - added definition for element 8) Section 4.9 - modified definition of to now also return errors related to elements 9) Section 4.30 - added definition for Use of SKMS Error Codes and Messages 10) Appendix C - added Standard Error Codes and Messages 11) Appendix D - added process definition for Vendors to apply for a reserved block of codes From owner-ietf-pkix@mail.imc.org Fri Dec 12 05:01:19 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A8A3A6B07 for ; Fri, 12 Dec 2008 05:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.596 X-Spam-Level: X-Spam-Status: No, score=-10.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2ox-S5olSeK for ; Fri, 12 Dec 2008 05:01:15 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C00C83A6AC0 for ; Fri, 12 Dec 2008 05:01:14 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCCPf7a078467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 05:25:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBCCPf5X078466; Fri, 12 Dec 2008 05:25: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 smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCCPTae078452 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 12 Dec 2008 05:25:40 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 12 Dec 2008 12:25:28 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 12 Dec 2008 12:25:28 +0000 From: Stefan Santesson To: "ietf-pkix@imc.org" Date: Fri, 12 Dec 2008 12:25:25 +0000 Subject: TA requirements doc - do we need it? Thread-Topic: TA requirements doc - do we need it? Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rg== Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB5CB52E5@EA-EXMSG-C332.europe.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB5CB52E5EAEXMSGC332eu_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_9F11911AED01D24BAA1C2355723C3D321AB5CB52E5EAEXMSGC332eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After all discussions in Minneapolis and going back and looking at the curr= ent situation, I feel less and less convinced that we need to approve any T= A requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may = be a lot more harmful than beneficiary to us as an RFC. I have two major reasons: First, as I have argued and tried to explain with my slide in Minneapolis, = there is no general overall approach to TA management in a complex IT envir= onment. The requirements are radically different in a device oriented environment w= ith disconnected units compared with a centrally managed IT environment wit= h a common network and data sharing infrastructure. Secondly, the requirements didn't come first. These requirements were writt= en with an existing protocol in mind. The lasting impression is therefore t= hat the requirements document was written to match and support the original= protocol, making it a tool to grandfather the original protocol into IETF.= I'm not claiming that this is the case, but it remains to be my impression= . The question one have to ask is if these requirements, in the form of an RF= C, would serve us as a community if we encounter a problem with the propose= d protocol. I doubt that it will as it at most will strengthen the argument= for those having an interest to adopt the original protocol. My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to ref= lect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before= the scope is in harmony with the requirements. Stefan Santesson Senior Program Manager Windows Security, Standards --_000_9F11911AED01D24BAA1C2355723C3D321AB5CB52E5EAEXMSGC332eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After all discussions in Minneapoli= s and going back and looking at the current situation, I feel less and less convi= nced that we need to approve any TA requirements document as an RFC. At least no= t in its current form.

I’m fine with having it aroun= d as a draft for reference, but I fear it may be a lot more harmful than beneficia= ry to us as an RFC.

 

I have two major reasons:

 

First, as I have argued and tried t= o explain with my slide in Minneapolis, there is no general overall approach = to TA management in a complex IT environment.

The requirements are radically diff= erent in a device oriented environment with disconnected units compared with a centr= ally managed IT environment with a common network and data sharing infrastructur= e.

 

Secondly, the requirements didnR= 17;t come first. These requirements were written with an existing protocol in mi= nd. The lasting impression is therefore that the requirements document was writ= ten to match and support the original protocol, making it a tool to grandfather= the original protocol into IETF. I’m not claiming that this is the case, = but it remains to be my impression.

 

 

The question one have to ask is if = these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it = at most will strengthen the argument for those having an interest to adopt the original protocol.

 

My proposal going forward is to do = the following:

-          In any case adjust the sc= ope of the requirements document to reflect the problem space the problem space it= is designed for.

-          Leave it as a draft, or a= t least not publish it as an RFC before the scope is in harmony with the requ= irements.

 

 

 

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 

--_000_9F11911AED01D24BAA1C2355723C3D321AB5CB52E5EAEXMSGC332eu_-- From owner-ietf-pkix@mail.imc.org Fri Dec 12 11:03:04 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892C53A6B49 for ; Fri, 12 Dec 2008 11:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.639 X-Spam-Level: X-Spam-Status: No, score=-102.639 tagged_above=-999 required=5 tests=[AWL=3.960, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPmXOZVxYnVz for ; Fri, 12 Dec 2008 11:03:01 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6B1283A68E8 for ; Fri, 12 Dec 2008 11:03:00 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCITu4H098430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 11:29:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBCITuqF098429; Fri, 12 Dec 2008 11:29: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCITt4d098423 for ; Fri, 12 Dec 2008 11:29:55 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 45BA03A6870; Fri, 12 Dec 2008 10:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-11.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081212183001.45BA03A6870@core3.amsl.com> Date: Fri, 12 Dec 2008 10:30:01 -0800 (PST) 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 : Elliptic Curve Cryptography Subject Public Key Information Author(s) : S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk Filename : draft-ietf-pkix-ecc-subpubkeyinfo-11.txt Pages : 22 Date : 2008-12-12 This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3279. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pkix-ecc-subpubkeyinfo-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-12102205.I-D@ietf.org> --NextPart-- From owner-ietf-pkix@mail.imc.org Fri Dec 12 11:09:09 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6393A6B49 for ; Fri, 12 Dec 2008 11:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.944 X-Spam-Level: X-Spam-Status: No, score=-102.944 tagged_above=-999 required=5 tests=[AWL=3.655, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmeKS6dO9xY1 for ; Fri, 12 Dec 2008 11:09:09 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B45A03A6870 for ; Fri, 12 Dec 2008 11:09:08 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCIiuaj099003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 11:44:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBCIiuFR099001; Fri, 12 Dec 2008 11:44: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCIiuN1098989 for ; Fri, 12 Dec 2008 11:44:56 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id CAA8528C131; Fri, 12 Dec 2008 10:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-3281update-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081212184501.CAA8528C131@core3.amsl.com> Date: Fri, 12 Dec 2008 10:45:01 -0800 (PST) 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 : An Internet Attribute Certificate Profile for Authorization Author(s) : R. Housley, S. Farrell, S. Turner Filename : draft-ietf-pkix-3281update-02.txt Pages : 45 Date : 2008-12-12 This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. This document obsoletes RFC 3281. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-3281update-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pkix-3281update-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-12104338.I-D@ietf.org> --NextPart-- From mail@alexander-bernard.info Fri Dec 12 13:09:19 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 964D23A6B1A for ; Fri, 12 Dec 2008 13:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.038 X-Spam-Level: X-Spam-Status: No, score=-17.038 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx37k0MQNAT6 for ; Fri, 12 Dec 2008 13:09:19 -0800 (PST) Received: from adventisthealthcare.com (unknown [201.19.91.233]) by core3.amsl.com (Postfix) with SMTP id C46083A68B4 for ; Fri, 12 Dec 2008 13:09:17 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081212210917.C46083A68B4@core3.amsl.com> Date: Fri, 12 Dec 2008 13:09:17 -0800 (PST)
Go to site!

Give her some best drilling



Ronaldo which was aimed for a wide open Alan Smith.suspected of eating the food.
 From oilmeal@agriwatch.com Fri Dec 12 20:10:39 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5253A6986 for ; Fri, 12 Dec 2008 20:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.173 X-Spam-Level: X-Spam-Status: No, score=-9.173 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSKsA2MxApiS for ; Fri, 12 Dec 2008 20:10:38 -0800 (PST) Received: from amboxco.com (unknown [201.29.177.145]) by core3.amsl.com (Postfix) with SMTP id E6FBA3A67D7 for ; Fri, 12 Dec 2008 20:10:34 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081213041035.E6FBA3A67D7@core3.amsl.com> Date: Fri, 12 Dec 2008 20:10:34 -0800 (PST)
Go to site!

You'll tap any woman you want



Mr Tsvangirai said in an interview from his hospital bedsaid: "The world community again has been shown that the
 From krisspooner@aeropostale.com Sat Dec 13 00:52:46 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79EF3A687E for ; Sat, 13 Dec 2008 00:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.091 X-Spam-Level: X-Spam-Status: No, score=-12.091 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xZrMH3fF-rS for ; Sat, 13 Dec 2008 00:52:46 -0800 (PST) Received: from dhw207.neoplus.adsl.tpnet.pl (dhw207.neoplus.adsl.tpnet.pl [83.23.204.207]) by core3.amsl.com (Postfix) with SMTP id CD6DC3A6882 for ; Sat, 13 Dec 2008 00:52:44 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081213085244.CD6DC3A6882@core3.amsl.com> Date: Sat, 13 Dec 2008 00:52:44 -0800 (PST)
Go to site!

Anti-crisis big sale



wedding ceremony. He built up the excitement during hisas Domanick Davis, leaves as the Texans all-time rushing
 From oca@aldoca.com.ve Sat Dec 13 01:43:42 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C02F3A6869 for ; Sat, 13 Dec 2008 01:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.031 X-Spam-Level: X-Spam-Status: No, score=-22.031 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0JtIe6zQkVX for ; Sat, 13 Dec 2008 01:43:42 -0800 (PST) Received: from alaplaya.com (unknown [190.50.52.123]) by core3.amsl.com (Postfix) with SMTP id 4577D3A6841 for ; Sat, 13 Dec 2008 01:43:40 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081213094341.4577D3A6841@core3.amsl.com> Date: Sat, 13 Dec 2008 01:43:40 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From michael.babbdd@3abn.org Sat Dec 13 18:26:51 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396F33A680E for ; Sat, 13 Dec 2008 18:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.074 X-Spam-Level: X-Spam-Status: No, score=-13.074 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIo6Gi659WHd for ; Sat, 13 Dec 2008 18:26:45 -0800 (PST) Received: from afnor.fr (unknown [196.202.30.249]) by core3.amsl.com (Postfix) with SMTP id 74E2D3A682E for ; Sat, 13 Dec 2008 18:26:41 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081214022642.74E2D3A682E@core3.amsl.com> Date: Sat, 13 Dec 2008 18:26:41 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Mon Dec 15 07:21:09 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3B03A6A11 for ; Mon, 15 Dec 2008 07:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.873, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9-JIKGlY+a4 for ; Mon, 15 Dec 2008 07:21:08 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3838F3A695B for ; Mon, 15 Dec 2008 07:21:07 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFEhAra032870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 07:43:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFEhAxQ032869; Mon, 15 Dec 2008 07:43: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 zombie2.ncsc.mil (zombie2.ncsc.mil [144.51.88.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFEgwxJ032858 for ; Mon, 15 Dec 2008 07:43:09 -0700 (MST) (envelope-from llziegl@tycho.ncsc.mil) Received: from smtp.ncsc.mil (jazzdrum.ncsc.mil [144.51.5.7]) by zombie2.ncsc.mil (8.12.10/8.12.10) with ESMTP id mBFEedEN025511; Mon, 15 Dec 2008 14:40:39 GMT Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95EC3.6BA2BC69" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: NSA SuiteB Certificate and CRL Profile Date: Mon, 15 Dec 2008 09:42:57 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSA SuiteB Certificate and CRL Profile Thread-Index: Aclew2qfI4gj78GSRAWOB65GfvTcUw== From: "Zieglar, Lydia L." To: Cc: "Wallner, Debbie M" , 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_01C95EC3.6BA2BC69 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have recently submitted the National Security Agency's Suite B Certificate and CRL Profile to the IETF as an Internet-Draft.=20 =20 Even though this is an individual submission, we believe that you may be interested and we encourage you to review the document. Please send your comments to llziegl@tycho.ncsc.mil =20 You may reach the document at: =20 http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-profile-00 .txt =20 Thanks, Lydia Zieglar =20 Lydia Zieglar 301-688-1028 llziegl@tycho.ncsc.mil =20 ------_=_NextPart_001_01C95EC3.6BA2BC69 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We = have recently=20 submitted the National Security Agency's Suite B Certificate and CRL = Profile to=20 the IETF as an Internet-Draft.
 
Even = though this is=20 an individual submission, we believe that you may be interested and we = encourage=20 you to review the document. Please send your comments to llziegl@tycho.ncsc.mil<= /FONT>
 
You = may reach the=20 document at:
 
http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cer= t-profile-00.txt
 
Thanks,
Lydia=20 Zieglar
 
Lydia Zieglar
301-688-1028
llziegl@tycho.ncsc.mil
 
------_=_NextPart_001_01C95EC3.6BA2BC69-- From owner-ietf-pkix@mail.imc.org Mon Dec 15 09:21:38 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF1B3A69E6 for ; Mon, 15 Dec 2008 09:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.394 X-Spam-Level: X-Spam-Status: No, score=-1.394 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q0b7bWQooV4 for ; Mon, 15 Dec 2008 09:21:32 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BEBA33A6804 for ; Mon, 15 Dec 2008 09:21:26 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFGl5Xw038899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 09:47:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFGl5tc038898; Mon, 15 Dec 2008 09:47: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBFGksmg038886 for ; Mon, 15 Dec 2008 09:47:04 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 5374 invoked from network); 15 Dec 2008 16:46:12 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;15 Dec 2008 16:46:12 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 15 Dec 2008 16:46:11 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95ED4.BB20D3C0" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: TA requirements doc - do we need it? Date: Mon, 15 Dec 2008 11:46:51 -0500 Message-ID: In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AB5CB52E5@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TA requirements doc - do we need it? thread-index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9A References: <9F11911AED01D24BAA1C2355723C3D321AB5CB52E5@EA-EXMSG-C332.europe.corp.microsoft.com> 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_01C95ED4.BB20D3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 See my responses in-line below.=20 =20 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Friday, December 12, 2008 7:25 AM To: ietf-pkix@imc.org Subject: TA requirements doc - do we need it? =20 After all discussions in Minneapolis and going back and looking at the current situation, I feel less and less convinced that we need to approve any TA requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may be a lot more harmful than beneficiary to us as an RFC. =20 I have two major reasons: =20 First, as I have argued and tried to explain with my slide in Minneapolis, there is no general overall approach to TA management in a complex IT environment. [Santosh] In a complex distributed environment that needs to scale across Enterprises, applying requisite security services to the payload provides a scalable, interoperable, extensible, and secure solution. =20 The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure. [Santosh] The requirements are generally the same in terms of security services. Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network. But, that solution may not be as scalable or open. =20 Secondly, the requirements didn't come first. These requirements were written with an existing protocol in mind. The lasting impression is therefore that the requirements document was written to match and support the original protocol, making it a tool to grandfather the original protocol into IETF. I'm not claiming that this is the case, but it remains to be my impression. [Santosh] If you look at many of the engineering endeavors we undertake, requirements are based on past experience, security vulnerabilities we have encountered, past systems, etc. I do not know of many successful efforts where requirements were developed in vacuum. In short, it is fair to say that the requirements and protocol benefited from each other and from past experiences with protocols and vulnerabilities. =20 The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols. If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc. =20 My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to reflect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before the scope is in harmony with the requirements. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C95ED4.BB20D3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefan,

=

 

See my responses in-line below. =

 

From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Friday, December = 12, 2008 7:25 AM
To: ietf-pkix@imc.org
Subject: TA requirements = doc - do we need it?

 

After all discussions in Minneapolis and going back and looking at the current situation, I feel less and = less convinced that we need to approve any TA requirements document as an = RFC. At least not in its current form.

I’m fine with having it around as a draft for reference, but I fear it may = be a lot more harmful than beneficiary to us as an = RFC.

 

I have two major reasons:

 

First, as I have argued and tried to explain with my slide in Minneapolis, there is no general = overall approach to TA management in a complex IT = environment.

[Santosh] In a complex distributed environment that = needs to scale across Enterprises, applying requisite security services to the = payload provides a scalable, interoperable, extensible, and secure = solution.

 

The requirements are radically different in a device oriented environment = with disconnected units compared with a centrally managed IT environment with = a common network and data sharing = infrastructure.

[Santosh] The requirements are generally the same in = terms of security services.  Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and = security services provided by the Enterprise network.  But, that solution may not be as scalable or = open.

 

Secondly, the requirements didn’t come first. These requirements were = written with an existing protocol in mind. The lasting impression is therefore that = the requirements document was written to match and support the original = protocol, making it a tool to grandfather the original protocol into IETF. = I’m not claiming that this is the case, but it remains to be my = impression.

[Santosh] If you look at many of the engineering = endeavors we undertake, requirements are based on past experience, security = vulnerabilities we have encountered, past systems, etc.  I do not know of many = successful efforts where requirements were developed in vacuum. In short, it is fair to say = that the requirements and protocol benefited from each other and from past = experiences with protocols and vulnerabilities.

 

The question one have to ask is if these requirements, in the form of an = RFC, would serve us as a community if we encounter a problem with the proposed = protocol. I doubt that it will as it at most will strengthen the argument for those = having an interest to adopt the original protocol.

[Santosh] Having a requirements document that is a = living document, permits us to evaluate various solutions and protocols.  If we do = encounter a security problem, it should be useful to analyze where the engineering = process failed, e.g., did we not articulate some requirement, did we not have = sufficient detail for a requirement, did our analysis of protocol meeting a = requirement was flawed, etc.

 

My proposal going forward is to do the = following:

-          In any case adjust the = scope of the requirements document to reflect the problem space the problem space = it is designed for.

-          Leave it as a draft, or at = least not publish it as an RFC before the scope is in harmony with the = requirements.

 

 

 

Stefan Santesson

Senior = Program Manager

Windows Security, Standards

 

------_=_NextPart_001_01C95ED4.BB20D3C0-- From ku-2682-3647@ai.tnc.ne.jp Mon Dec 15 14:13:58 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6273A697F for ; Mon, 15 Dec 2008 14:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.264 X-Spam-Level: X-Spam-Status: No, score=-13.264 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD22VGjYEW+L for ; Mon, 15 Dec 2008 14:13:58 -0800 (PST) Received: from agora.bungi.com (d70-p1-as03-zagreb.net.vip.hr [212.91.100.70]) by core3.amsl.com (Postfix) with SMTP id 9B7A23A6872 for ; Mon, 15 Dec 2008 14:13:55 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215221356.9B7A23A6872@core3.amsl.com> Date: Mon, 15 Dec 2008 14:13:55 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From megurmoko@alti.jp Mon Dec 15 23:09:53 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D868928C0E2 for ; Mon, 15 Dec 2008 23:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -40.031 X-Spam-Level: X-Spam-Status: No, score=-40.031 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0EGgf5bWqKx for ; Mon, 15 Dec 2008 23:09:52 -0800 (PST) Received: from aktivpc.de (unknown [216.198.106.198]) by core3.amsl.com (Postfix) with SMTP id 961FA28C0DF for ; Mon, 15 Dec 2008 23:09:50 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081216070951.961FA28C0DF@core3.amsl.com> Date: Mon, 15 Dec 2008 23:09:50 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Tue Dec 16 07:06:08 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862513A6A5E for ; Tue, 16 Dec 2008 07:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU3zoKXwg96S for ; Tue, 16 Dec 2008 07:06:07 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 501D43A6A6E for ; Tue, 16 Dec 2008 07:06:06 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGETCIo004324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 07:29:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGETCjO004323; Tue, 16 Dec 2008 07:29: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGET2Yc004313 for ; Tue, 16 Dec 2008 07:29:12 -0700 (MST) (envelope-from kent@bbn.com) Received: from ros-dhcp233-050-110.bbn.com ([192.233.50.110]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LCauz-0007p7-Cz for ietf-pkix@imc.org; Tue, 16 Dec 2008 09:29:01 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 16 Dec 2008 09:29:06 -0500 To: ietf-pkix@imc.org From: Stephen Kent Subject: straw poll Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At a previous IETF meeting (Dublin) I agreed to conduct a straw poll on adding a new WG item to address OCSP algorithm agility concerns, after PHB sent a message indicating what status he envisioned for the work. This action for both me and PHB fell through the cracks. At the MSP IETF meeting PHB provided a briefing on the problems that he saw re OCSP ambiguities re algorithm agility, and proposed a standards track document to address these issues (see PHB's message of 12/2). So, we now have a concrete proposal (draft-hallambaker-ocspagility) available for review. PHB would like to publish this and then merge it into the OCSP document when it progresses from PROPOSED to DRAFT (see his message of 12/2). Please send a message to the list by January 9th (allowing for holiday outages) indicating whether 1. your support PKIX work in this area 2. you support adopting PHB's document as a starting point for such work Thanks & Happy Hoplidays, Steve From owner-ietf-pkix@mail.imc.org Tue Dec 16 07:35:12 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF863A688B for ; Tue, 16 Dec 2008 07:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.43 X-Spam-Level: X-Spam-Status: No, score=-10.43 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3frkPUEJEawo for ; Tue, 16 Dec 2008 07:35:02 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 38A803A6A99 for ; Tue, 16 Dec 2008 07:35:01 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGEw2f3005912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 07:58:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGEw2pO005911; Tue, 16 Dec 2008 07:58: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-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGEvotx005898 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 16 Dec 2008 07:58:01 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 16 Dec 2008 14:57:49 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 16 Dec 2008 14:57:49 +0000 From: Stefan Santesson To: Santosh Chokhani , "ietf-pkix@imc.org" Date: Tue, 16 Dec 2008 14:57:51 +0000 Subject: RE: TA requirements doc - do we need it? Thread-Topic: TA requirements doc - do we need it? Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrA= Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0@EA-EXMSG-C332.europe.corp.microsoft.com> References: <9F11911AED01D24BAA1C2355723C3D321AB5CB52E5@EA-EXMSG-C332.europe.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0EAEXMSGC332eu_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0EAEXMSGC332eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Santosh, As I expect, I sense that we have a slightly different view of the generali= ty of the proposed solution, but we seem to agree on the main issue: The question one have to ask is if these requirements, in the form of an RF= C, would serve us as a community if we encounter a problem with the propose= d protocol. I doubt that it will as it at most will strengthen the argument= for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits= us to evaluate various solutions and protocols. If we do encounter a secu= rity problem, it should be useful to analyze where the engineering process = failed, e.g., did we not articulate some requirement, did we not have suffi= cient detail for a requirement, did our analysis of protocol meeting a requ= irement was flawed, etc. I would also prefer to see the requirements document as a living document a= s you suggest. I think that purpose is best served if the requirements docu= ment remains in draft form. 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 15 december 2008 17:47 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? Stefan, See my responses in-line below. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On= Behalf Of Stefan Santesson Sent: Friday, December 12, 2008 7:25 AM To: ietf-pkix@imc.org Subject: TA requirements doc - do we need it? After all discussions in Minneapolis and going back and looking at the curr= ent situation, I feel less and less convinced that we need to approve any T= A requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may = be a lot more harmful than beneficiary to us as an RFC. I have two major reasons: First, as I have argued and tried to explain with my slide in Minneapolis, = there is no general overall approach to TA management in a complex IT envir= onment. [Santosh] In a complex distributed environment that needs to scale across E= nterprises, applying requisite security services to the payload provides a = scalable, interoperable, extensible, and secure solution. The requirements are radically different in a device oriented environment w= ith disconnected units compared with a centrally managed IT environment wit= h a common network and data sharing infrastructure. [Santosh] The requirements are generally the same in terms of security serv= ices. Some Enterprise IT management implementations may have implemented E= nterprise specific solutions taking advantages of existing infrastructure a= nd security services provided by the Enterprise network. But, that solutio= n may not be as scalable or open. Secondly, the requirements didn't come first. These requirements were writt= en with an existing protocol in mind. The lasting impression is therefore t= hat the requirements document was written to match and support the original= protocol, making it a tool to grandfather the original protocol into IETF.= I'm not claiming that this is the case, but it remains to be my impression= . [Santosh] If you look at many of the engineering endeavors we undertake, re= quirements are based on past experience, security vulnerabilities we have e= ncountered, past systems, etc. I do not know of many successful efforts wh= ere requirements were developed in vacuum. In short, it is fair to say that= the requirements and protocol benefited from each other and from past expe= riences with protocols and vulnerabilities. The question one have to ask is if these requirements, in the form of an RF= C, would serve us as a community if we encounter a problem with the propose= d protocol. I doubt that it will as it at most will strengthen the argument= for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits= us to evaluate various solutions and protocols. If we do encounter a secu= rity problem, it should be useful to analyze where the engineering process = failed, e.g., did we not articulate some requirement, did we not have suffi= cient detail for a requirement, did our analysis of protocol meeting a requ= irement was flawed, etc. My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to ref= lect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before= the scope is in harmony with the requirements. Stefan Santesson Senior Program Manager Windows Security, Standards --_000_9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0EAEXMSGC332eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Santosh,

 =

As I expect= , I sense that we have a slightly different view of the generality of the proposed so= lution, but we seem to agree on the main issue:

 =

The question one have to ask is if = these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it = at most will strengthen the argument for those having an interest to adopt the original protocol.

[Santosh] Having a requirements document t= hat is a living document, permits us to evaluate various solutions and protocol= s.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc.<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col= or:navy'>

 =

I would als= o prefer to see the requirements document as a living document as you suggest. I thi= nk that purpose is best served if the requirements document remains in draft f= orm.

 =

 =

 =

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 =

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani<= br> Sent: den 15 december 2008 17:47
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need it?<= /p>

 

Stefan,

 

See my responses in-line below.

 

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson<= br> Sent: Friday, December 12, 2008 7:25 AM
To: ietf-pkix@imc.org
Subject: TA requirements doc - do we need it?

 

After all discussions in Minneapoli= s and going back and looking at the current situation, I feel less and less convi= nced that we need to approve any TA requirements document as an RFC. At least no= t in its current form.

I’m fine with having it aroun= d as a draft for reference, but I fear it may be a lot more harmful than beneficia= ry to us as an RFC.

 

I have two major reasons:

 

First, as I have argued and tried t= o explain with my slide in Minneapolis, there is no general overall approach = to TA management in a complex IT environment.

[Santosh] In a complex distributed environ= ment that needs to scale across Enterprises, applying requisite security service= s to the payload provides a scalable, interoperable, extensible, and secure solution.

 

The requirements are radically diff= erent in a device oriented environment with disconnected units compared with a centr= ally managed IT environment with a common network and data sharing infrastructur= e.

[Santosh] The requirements are generally t= he same in terms of security services.  Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network.  But, that solution may not be as scalable or open= .

 

Secondly, the requirements didnR= 17;t come first. These requirements were written with an existing protocol in mi= nd. The lasting impression is therefore that the requirements document was writ= ten to match and support the original protocol, making it a tool to grandfather= the original protocol into IETF. I’m not claiming that this is the case, = but it remains to be my impression.

[Santosh] If you look at many of the engineering endeavors we undertake, requirements are based on past experien= ce, security vulnerabilities we have encountered, past systems, etc.  I do= not know of many successful efforts where requirements were developed in vacuum= . In short, it is fair to say that the requirements and protocol benefited from = each other and from past experiences with protocols and vulnerabilities.<= /i>

 

The question one have to ask is if = these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it = at most will strengthen the argument for those having an interest to adopt the original protocol.

[Santosh] Having a requirements document t= hat is a living document, permits us to evaluate various solutions and protocol= s.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc.<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col= or:navy'>

 

My proposal going forward is to do = the following:

-          In any case adjust the sc= ope of the requirements document to reflect the problem space the problem space it= is designed for.

-          Leave it as a draft, or a= t least not publish it as an RFC before the scope is in harmony with the requirements.

 

 

 

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 

--_000_9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0EAEXMSGC332eu_-- From owner-ietf-pkix@mail.imc.org Tue Dec 16 07:41:32 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E333A6A87 for ; Tue, 16 Dec 2008 07:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.443 X-Spam-Level: X-Spam-Status: No, score=-10.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCO6S2u9nanC for ; Tue, 16 Dec 2008 07:41:32 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E863B3A695B for ; Tue, 16 Dec 2008 07:41:31 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFFnDP007171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 08:15:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGFFnVb007170; Tue, 16 Dec 2008 08:15:49 -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-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFFbVn007156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 16 Dec 2008 08:15:48 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 16 Dec 2008 15:15:37 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Tue, 16 Dec 2008 15:15:37 +0000 From: Stefan Santesson To: Stephen Kent , "ietf-pkix@imc.org" Date: Tue, 16 Dec 2008 15:15:40 +0000 Subject: RE: straw poll Thread-Topic: straw poll Thread-Index: AclfkMbj9Mz4GZIQRs2Bt/jsEmq9dgAABI+A Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB5D9DE2A@EA-EXMSG-C332.europe.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1&2 I support work in the area and I support using PHB's document as starting p= oint. 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 Stephen Kent > Sent: den 16 december 2008 15:29 > To: ietf-pkix@imc.org > Subject: straw poll > > > At a previous IETF meeting (Dublin) I agreed to conduct a straw poll > on adding a new WG item to address OCSP algorithm agility concerns, > after PHB sent a message indicating what status he envisioned for the > work. This action for both me and PHB fell through the cracks. At the > MSP IETF meeting PHB provided a briefing on the problems that he saw > re OCSP ambiguities re algorithm agility, and proposed a standards > track document to address these issues (see PHB's message of 12/2). > > So, we now have a concrete proposal (draft-hallambaker-ocspagility) > available for review. PHB would like to publish this and then merge > it into the OCSP document when it progresses from PROPOSED to DRAFT > (see his message of 12/2). > > Please send a message to the list by January 9th (allowing for > holiday outages) indicating whether > > 1. your support PKIX work in this area > 2. you support adopting PHB's document as a starting point > for such work > > Thanks & Happy Hoplidays, > > Steve > From owner-ietf-pkix@mail.imc.org Tue Dec 16 08:28:05 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130AD3A696C for ; Tue, 16 Dec 2008 08:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyVQlqGwR8V7 for ; Tue, 16 Dec 2008 08:28:04 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E08BB3A695B for ; Tue, 16 Dec 2008 08:28:03 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFwje2009846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 08:58:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGFwjED009845; Tue, 16 Dec 2008 08:58: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 stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFwYZ0009833 for ; Tue, 16 Dec 2008 08:58:45 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: straw poll Date: Tue, 16 Dec 2008 10:58:20 -0500 Message-ID: <200812161558.mBGFwYhj004620@stingray.missi.ncsc.mil> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: straw poll Thread-Index: AclfkM/lPsmO8eQLRsii96PH/Om8VAABjnCw References: From: "Kemp, David P." To: X-OriginalArrivalTime: 16 Dec 2008 15:55:30.0375 (UTC) FILETIME=[B89C3D70:01C95F96] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. yes 2. yes -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Tuesday, December 16, 2008 9:29 AM To: ietf-pkix@imc.org Subject: straw poll At a previous IETF meeting (Dublin) I agreed to conduct a straw poll=20 on adding a new WG item to address OCSP algorithm agility concerns,=20 after PHB sent a message indicating what status he envisioned for the=20 work. This action for both me and PHB fell through the cracks. At the=20 MSP IETF meeting PHB provided a briefing on the problems that he saw=20 re OCSP ambiguities re algorithm agility, and proposed a standards=20 track document to address these issues (see PHB's message of 12/2). So, we now have a concrete proposal (draft-hallambaker-ocspagility)=20 available for review. PHB would like to publish this and then merge=20 it into the OCSP document when it progresses from PROPOSED to DRAFT=20 (see his message of 12/2). Please send a message to the list by January 9th (allowing for=20 holiday outages) indicating whether 1. your support PKIX work in this area 2. you support adopting PHB's document as a starting point=20 for such work Thanks & Happy Hoplidays, Steve From owner-ietf-pkix@mail.imc.org Tue Dec 16 10:02:32 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529D53A6800 for ; Tue, 16 Dec 2008 10:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MltpzPr85UAR for ; Tue, 16 Dec 2008 10:02:21 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3F0A43A684F for ; Tue, 16 Dec 2008 10:02:20 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGHCt8I014283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 10:12:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGHCt4w014282; Tue, 16 Dec 2008 10:12:55 -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 stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGHCsRZ014274 for ; Tue, 16 Dec 2008 10:12:54 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95FA1.71A77FB7" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: TA requirements doc - do we need it? Date: Tue, 16 Dec 2008 12:12:15 -0500 Message-ID: <200812161712.mBGHCsVQ008014@stingray.missi.ncsc.mil> In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TA requirements doc - do we need it? Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrAAApWoQA== References: <9F11911AED01D24BAA1C2355723C3D321AB5CB52E5@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0@EA-EXMSG-C332.europe.corp.microsoft.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 16 Dec 2008 17:09:50.0062 (UTC) FILETIME=[1ACA78E0:01C95FA1] 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_01C95FA1.71A77FB7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 Refining the requirements as a series of I-Ds until "the scope of the requirements is in harmony with problem space", then publishing as an RFC once the requirements have converged, certainly sounds like the best approach. =20 But you have not explained how "The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure." The requirements in either case are for managed devices/applications/services to receive configuration items from managers without those items being compromised in transit, yes? =20 * Are you claiming that adversaries have no access to a "common network and data sharing infrastructure" and therefore no protection is needed in the networked case? That is patently false for all networks of interest to the IETF. * Or that the protection mechanisms appropriate for managing networked platforms (Connection-oriented? MACs?) are different than those needed for managing disconnected platforms (Datagram/message-oriented? Signatures?) =20 Without understanding the nature of your objections it's hard to tell whether the scope of the requirements is already in harmony with the entire problem space or not. Your 4-quadrant slide from Minneapolis is not self-explanatory - I thought we had already disposed of the push-pull issue by determining that there is no security-relevant difference between posting to a repository from which a client may pull and pushing directly to the client. Therefore the TAM requirements already cover the left half of the space. If there is a single existing TAM requirement that precludes pull, or a single missing TAM requirement needed for pull, please provide an example. =20 And I need help understanding the difference you see between TA and TA Policy - if policy is "Host/App A will trust provider X for security critical firmware category Z", and the TA store of Host/App A has provider X's TA in the slot for firmware category Z, what is the difference, other than level of abstraction, between "determine current TAs in store" and "demonstrate compliance with policy"? Again, an example of a missing TAM requirement needed to satisfy the right half of your slide would go a long way toward understanding the scope issue. =20 Dave =20 =20 =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Tuesday, December 16, 2008 9:58 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Hi Santosh, =20 As I expect, I sense that we have a slightly different view of the generality of the proposed solution, but we seem to agree on the main issue: =20 The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols. If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc. =20 I would also prefer to see the requirements document as a living document as you suggest. I think that purpose is best served if the requirements document remains in draft form. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 15 december 2008 17:47 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Stefan, =20 See my responses in-line below.=20 =20 _____ =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Friday, December 12, 2008 7:25 AM To: ietf-pkix@imc.org Subject: TA requirements doc - do we need it? =20 After all discussions in Minneapolis and going back and looking at the current situation, I feel less and less convinced that we need to approve any TA requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may be a lot more harmful than beneficiary to us as an RFC. =20 I have two major reasons: =20 First, as I have argued and tried to explain with my slide in Minneapolis, there is no general overall approach to TA management in a complex IT environment. [Santosh] In a complex distributed environment that needs to scale across Enterprises, applying requisite security services to the payload provides a scalable, interoperable, extensible, and secure solution. =20 The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure. [Santosh] The requirements are generally the same in terms of security services. Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network. But, that solution may not be as scalable or open. =20 Secondly, the requirements didn't come first. These requirements were written with an existing protocol in mind. The lasting impression is therefore that the requirements document was written to match and support the original protocol, making it a tool to grandfather the original protocol into IETF. I'm not claiming that this is the case, but it remains to be my impression. [Santosh] If you look at many of the engineering endeavors we undertake, requirements are based on past experience, security vulnerabilities we have encountered, past systems, etc. I do not know of many successful efforts where requirements were developed in vacuum. In short, it is fair to say that the requirements and protocol benefited from each other and from past experiences with protocols and vulnerabilities. =20 The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols. If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc. =20 My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to reflect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before the scope is in harmony with the requirements. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C95FA1.71A77FB7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefan,

 

Refining the = requirements as a series of I-Ds until “the scope of the requirements is in harmony = with problem space”, then publishing as an RFC once the requirements have = converged, certainly sounds like the best approach.

 

But you have not = explained how “The requirements are radically different in a device oriented environment = with disconnected units compared with a centrally managed IT environment with = a common network and data sharing infrastructure.”  The requirements in either case are for managed = devices/applications/services to receive configuration items from managers without those items being = compromised in transit, yes?

 

·         Are you = claiming that adversaries have no access to a “common network and data = sharing infrastructure” and therefore no protection is needed in the = networked case?  That is patently false for all networks of interest to the = IETF.

·         Or that the protection mechanisms appropriate for managing networked platforms = (Connection-oriented?  MACs?) are different than those needed for managing disconnected = platforms (Datagram/message-oriented? Signatures?)

 

Without understanding = the nature of your objections it’s hard to tell whether the scope of the = requirements is already in harmony with the entire problem space or not.   = Your 4-quadrant slide from Minneapolis is not self-explanatory – I thought we had = already disposed of the push-pull issue by determining that there is no = security-relevant difference between posting to a repository from which a client may pull = and pushing directly to the client.  Therefore the TAM requirements = already cover the left half of the space.  If there is a single existing TAM = requirement that precludes pull, or a single missing TAM requirement needed for pull, = please provide an example.

 

And I need help = understanding the difference you see between TA and TA Policy – if policy is = “Host/App A will trust provider X for security critical firmware category Z”, and = the TA store of Host/App A has provider X’s TA in the slot for firmware = category Z, what is the difference, other than level of abstraction, between = “determine current TAs in store” and “demonstrate compliance with = policy”?  Again, an example of a missing TAM requirement needed to satisfy the right half of your slide = would go a long way toward understanding the scope issue.

 

Dave

 

 

 

From:= owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On = Behalf Of Stefan Santesson
Sent: Tuesday, December 16, 2008 9:58 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need = it?

 

Hi Santosh,

 

As I expect, I sense = that we have a slightly different view of the generality of the proposed = solution, but we seem to agree on the main issue:

 

The question one have to ask is if these = requirements, in the form of an RFC, would serve us as a community if we encounter a = problem with the proposed protocol. I doubt that it will as it at most will = strengthen the argument for those having an interest to adopt the original = protocol.

[Santosh] Having a requirements document that is a living = document, permits us to evaluate various solutions and protocols.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some = requirement, did we not have sufficient detail for a requirement, did our analysis of = protocol meeting a requirement was flawed, etc.

 

I would also prefer = to see the requirements document as a living document as you suggest. I think that = purpose is best served if the requirements document remains in draft = form.

 

 

 

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 15 december 2008 17:47
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need = it?

 

Stefan,

 

See my responses in-line below.

 

From:= owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On = Behalf Of Stefan Santesson
Sent: Friday, December 12, 2008 7:25 AM
To: ietf-pkix@imc.org
Subject: TA requirements doc - do we need it?

 

After all discussions in Minneapolis and going back = and looking at the current situation, I feel less and less convinced that we = need to approve any TA requirements document as an RFC. At least not in its = current form.

I’m fine with having it around as a draft for = reference, but I fear it may be a lot more harmful than beneficiary to us as an = RFC.

 

I have two major reasons:

 

First, as I have argued and tried to explain with = my slide in Minneapolis, there is no general overall approach to TA management in = a complex IT environment.

[Santosh] In a complex distributed environment that needs to = scale across Enterprises, applying requisite security services to the payload provides a scalable, interoperable, extensible, and secure = solution.

 

The requirements are radically different in a = device oriented environment with disconnected units compared with a centrally = managed IT environment with a common network and data sharing = infrastructure.

[Santosh] The requirements are generally the same in terms = of security services.  Some Enterprise IT management implementations = may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network.  But, that solution may not be as scalable or = open.

 

Secondly, the requirements didn’t come first. = These requirements were written with an existing protocol in mind. The lasting impression is therefore that the requirements document was written to = match and support the original protocol, making it a tool to grandfather the = original protocol into IETF. I’m not claiming that this is the case, but it = remains to be my impression.

[Santosh] If you look at many of the engineering endeavors = we undertake, requirements are based on past experience, security = vulnerabilities we have encountered, past systems, etc.  I do not know of many = successful efforts where requirements were developed in vacuum. In short, it is = fair to say that the requirements and protocol benefited from each other and = from past experiences with protocols and = vulnerabilities.

 

The question one have to ask is if these = requirements, in the form of an RFC, would serve us as a community if we encounter a = problem with the proposed protocol. I doubt that it will as it at most will = strengthen the argument for those having an interest to adopt the original = protocol.

[Santosh] Having a requirements document that is a living = document, permits us to evaluate various solutions and protocols.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some = requirement, did we not have sufficient detail for a requirement, did our analysis of = protocol meeting a requirement was flawed, etc.

 

My proposal going forward is to do the = following:

-          In any case adjust the scope of the requirements document to reflect the problem space the problem space it is designed = for.

-          Leave it as a draft, or at least not publish it = as an RFC before the scope is in harmony with the requirements.

 

 

 

Stefan Santesson

Senior Program Manager

Windows Security, = Standards

 

------_=_NextPart_001_01C95FA1.71A77FB7-- From ndour@3mklawfirm.com Wed Dec 17 12:17:05 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64FB03A67E1 for ; Wed, 17 Dec 2008 12:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -41.531 X-Spam-Level: X-Spam-Status: No, score=-41.531 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vtrBYN1ryoy for ; Wed, 17 Dec 2008 12:17:01 -0800 (PST) Received: from allianz.de (unknown [189.74.71.9]) by core3.amsl.com (Postfix) with SMTP id DEEEC3A6962 for ; Wed, 17 Dec 2008 12:16:58 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081217201659.DEEEC3A6962@core3.amsl.com> Date: Wed, 17 Dec 2008 12:16:58 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From liwio@aacal.tk Thu Dec 18 04:20:06 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F9C828C21B for ; Thu, 18 Dec 2008 04:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.455 X-Spam-Level: X-Spam-Status: No, score=-15.455 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMSngi-Z9BCH for ; Thu, 18 Dec 2008 04:20:00 -0800 (PST) Received: from amidoduco.com (unknown [78.128.108.66]) by core3.amsl.com (Postfix) with SMTP id B775928C21F for ; Thu, 18 Dec 2008 04:19:56 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081218121957.B775928C21F@core3.amsl.com> Date: Thu, 18 Dec 2008 04:19:56 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Thu Dec 18 09:44:30 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2173A6B23 for ; Thu, 18 Dec 2008 09:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.172 X-Spam-Level: X-Spam-Status: No, score=-10.172 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ1WTSrBrMJq for ; Thu, 18 Dec 2008 09:44:15 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A005F3A6A0A for ; Thu, 18 Dec 2008 09:44:14 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIGlNfP083413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 09:47:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIGlNjY083412; Thu, 18 Dec 2008 09: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 smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIGlAIx083401 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 18 Dec 2008 09:47:21 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 18 Dec 2008 16:47:09 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.54]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 18 Dec 2008 16:47:09 +0000 From: Stefan Santesson To: "ietf-pkix@imc.org" , "Kemp, David P." Date: Thu, 18 Dec 2008 16:47:13 +0000 Subject: FW: TA requirements doc - do we need it? Thread-Topic: TA requirements doc - do we need it? Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrAAApWoQAAk2WagAEDwEFA= Message-ID: <9F11911AED01D24BAA1C2355723C3D321AF3E6206D@EA-EXMSG-C332.europe.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AF3E6206DEAEXMSGC332eu_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_9F11911AED01D24BAA1C2355723C3D321AF3E6206DEAEXMSGC332eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm resending this as my original mail got filtered due to exceeding pkix m= essage size restrictions. I have now replaced the embedded picture with a URL to the screenshot. Stefan Santesson Senior Program Manager Windows Security, Standards From: Stefan Santesson Sent: den 17 december 2008 11:43 To: 'Kemp, David P.'; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? Dave, You raise valid points and I partly try to avoid them because the answer is= somewhat long and complex. Long and complex answers are seldom successful = in standards discussions :) Let me try to show my point through a screenshot that helped explain this i= ssue to at least one of the original contributors to the proposed protocol.= This is a screenshot of the Microsoft certificate management snap-in: http://www.fiddler.nu/pkix/certmgr_mmc.jpg What you see here is the certificate trust policies in my laptop. It is not= one root store and it is not just about trust anchors. In my laptop I have= a certificate trust management snap-in for: * Each host (local machine) * Each user account * Each service running on any host In the Certificate snap-in window to the right, you see a fraction of the l= ist of services with individual certificate trust settings for one host/mac= hine. And it is not about just TA:s. It is about: * My personal certificates * Trusted roots * Intermediary CAs * Directly trusted or untrusted certificates * Etc, etc (See above) The structure of this information is not globally agreed and generic. It is= just how Microsoft have structured this in the Microsoft OS. One could call this a set of certificate trust policies that are dynamicall= y managed and as you get closer to reality, the border between roles, peopl= es and machines are getting more and more virtual and dynamic and it become= s harder and harder to reduce this into one generic, intrusive and centrall= y managed TA management protocol. Let me take a few examples from the requirements: * The assumed roles and authorization model * The assumption that there exist clearly identifiable TA stores. The TA requirements are assuming a TA manager responsible for a TA store. T= he TA manager have authority over this TA store and have the power update i= t or replace it. This also assumes that each TA store is individually ident= ifiable in the protocol itself. In my environment above, I first of all don= 't have any isolated identifiable TA stores. Secondly I don't have a clear= ly defined TA manager that has the right to view and update this informatio= n on a local machine. The applications or services that eventually are being affected by these tr= ust policy updates will not have a clue about what information that was pas= sed in any TA management protocol, or any IETF defined TA format file sever= al layers and APIs below their existence. So any discussion about how appli= cations should take into account specific path processing preferences provi= ded by passing TA format information around, such as applying specific cons= traints rules, is just pretty theory without substance unless it is made pa= rt of standard RFC 5280 path processing and implemented in the APIs for pat= h validation. In the environment I'm working with, I have no use for a transaction based = TA management protocol based on the simplified relationship between a TA ma= nager and a TA store. If I had one, I would not know how to use it. The only thing I would know how to use, is the TA format specification. Tha= t one I can use to pass TAs around in my existing trust policy framework. I hope this was a useful clarification and my apology for passing graphics = in a PKIX posting. I hope you can view it. 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 Kemp, David P. Sent: den 16 december 2008 18:12 To: ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? Stefan, Refining the requirements as a series of I-Ds until "the scope of the requi= rements is in harmony with problem space", then publishing as an RFC once t= he requirements have converged, certainly sounds like the best approach. But you have not explained how "The requirements are radically different in= a device oriented environment with disconnected units compared with a cent= rally managed IT environment with a common network and data sharing infrast= ructure." The requirements in either case are for managed devices/applicat= ions/services to receive configuration items from managers without those it= ems being compromised in transit, yes? * Are you claiming that adversaries have no access to a "common net= work and data sharing infrastructure" and therefore no protection is needed= in the networked case? That is patently false for all networks of interes= t to the IETF. * Or that the protection mechanisms appropriate for managing networ= ked platforms (Connection-oriented? MACs?) are different than those needed= for managing disconnected platforms (Datagram/message-oriented? Signatures= ?) Without understanding the nature of your objections it's hard to tell wheth= er the scope of the requirements is already in harmony with the entire prob= lem space or not. Your 4-quadrant slide from Minneapolis is not self-expl= anatory - I thought we had already disposed of the push-pull issue by deter= mining that there is no security-relevant difference between posting to a r= epository from which a client may pull and pushing directly to the client. = Therefore the TAM requirements already cover the left half of the space. = If there is a single existing TAM requirement that precludes pull, or a sin= gle missing TAM requirement needed for pull, please provide an example. And I need help understanding the difference you see between TA and TA Poli= cy - if policy is "Host/App A will trust provider X for security critical f= irmware category Z", and the TA store of Host/App A has provider X's TA in = the slot for firmware category Z, what is the difference, other than level = of abstraction, between "determine current TAs in store" and "demonstrate c= ompliance with policy"? Again, an example of a missing TAM requirement nee= ded to satisfy the right half of your slide would go a long way toward unde= rstanding the scope issue. Dave From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On= Behalf Of Stefan Santesson Sent: Tuesday, December 16, 2008 9:58 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? Hi Santosh, As I expect, I sense that we have a slightly different view of the generali= ty of the proposed solution, but we seem to agree on the main issue: The question one have to ask is if these requirements, in the form of an RF= C, would serve us as a community if we encounter a problem with the propose= d protocol. I doubt that it will as it at most will strengthen the argument= for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits= us to evaluate various solutions and protocols. If we do encounter a secu= rity problem, it should be useful to analyze where the engineering process = failed, e.g., did we not articulate some requirement, did we not have suffi= cient detail for a requirement, did our analysis of protocol meeting a requ= irement was flawed, etc. I would also prefer to see the requirements document as a living document a= s you suggest. I think that purpose is best served if the requirements docu= ment remains in draft form. 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 15 december 2008 17:47 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? Stefan, See my responses in-line below. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On= Behalf Of Stefan Santesson Sent: Friday, December 12, 2008 7:25 AM To: ietf-pkix@imc.org Subject: TA requirements doc - do we need it? After all discussions in Minneapolis and going back and looking at the curr= ent situation, I feel less and less convinced that we need to approve any T= A requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may = be a lot more harmful than beneficiary to us as an RFC. I have two major reasons: First, as I have argued and tried to explain with my slide in Minneapolis, = there is no general overall approach to TA management in a complex IT envir= onment. [Santosh] In a complex distributed environment that needs to scale across E= nterprises, applying requisite security services to the payload provides a = scalable, interoperable, extensible, and secure solution. The requirements are radically different in a device oriented environment w= ith disconnected units compared with a centrally managed IT environment wit= h a common network and data sharing infrastructure. [Santosh] The requirements are generally the same in terms of security serv= ices. Some Enterprise IT management implementations may have implemented E= nterprise specific solutions taking advantages of existing infrastructure a= nd security services provided by the Enterprise network. But, that solutio= n may not be as scalable or open. Secondly, the requirements didn't come first. These requirements were writt= en with an existing protocol in mind. The lasting impression is therefore t= hat the requirements document was written to match and support the original= protocol, making it a tool to grandfather the original protocol into IETF.= I'm not claiming that this is the case, but it remains to be my impression= . [Santosh] If you look at many of the engineering endeavors we undertake, re= quirements are based on past experience, security vulnerabilities we have e= ncountered, past systems, etc. I do not know of many successful efforts wh= ere requirements were developed in vacuum. In short, it is fair to say that= the requirements and protocol benefited from each other and from past expe= riences with protocols and vulnerabilities. The question one have to ask is if these requirements, in the form of an RF= C, would serve us as a community if we encounter a problem with the propose= d protocol. I doubt that it will as it at most will strengthen the argument= for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits= us to evaluate various solutions and protocols. If we do encounter a secu= rity problem, it should be useful to analyze where the engineering process = failed, e.g., did we not articulate some requirement, did we not have suffi= cient detail for a requirement, did our analysis of protocol meeting a requ= irement was flawed, etc. My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to ref= lect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before= the scope is in harmony with the requirements. Stefan Santesson Senior Program Manager Windows Security, Standards --_000_9F11911AED01D24BAA1C2355723C3D321AF3E6206DEAEXMSGC332eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m resending this as my original mail got filtered due to e= xceeding pkix message size restrictions.

I have now = replaced the embedded picture with a URL to the screenshot.

 =

 =

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 =

From: Stefan Santesson
Sent: den 17 december 2008 11:43
To: 'Kemp, David P.'; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need it?<= /p>

 

Dave,<= /p>

 =

You raise v= alid points and I partly try to avoid them because the answer is somewhat long a= nd complex. Long and complex answers are seldom successful in standards discussions J

 =

Let me try = to show my point through a screenshot that helped explain this issue to at least one o= f the original contributors to the proposed protocol. This is a screenshot of= the Microsoft certificate management snap-in:

 =

http://www.fiddler.nu/p= kix/certmgr_mmc.jpg

 =

What you se= e here is the certificate trust policies in my laptop. It is not one root store and i= t is not just about trust anchors. In my laptop I have a certificate trust management snap-in for:

·      =    E= ach host (local machine)

·      =    E= ach user account

·      =    E= ach service running on any host

 =

In the Cert= ificate snap-in window to the right, you see a fraction of the list of services wit= h individual certificate trust settings for one host/machine.

 =

And it is n= ot about just TA:s. It is about:

·      =    M= y personal certificates

·      =    T= rusted roots

·      =    I= ntermediary CAs

·      =    D= irectly trusted or untrusted certificates

·      =    E= tc, etc (See above)

 =

The structu= re of this information is not globally agreed and generic. It is just how Microsoft ha= ve structured this in the Microsoft OS.

 =

One could c= all this a set of certificate trust policies that are dynamically managed and as you g= et closer to reality, the border between roles, peoples and machines are getti= ng more and more virtual and dynamic and it becomes harder and harder to reduc= e this into one generic, intrusive and centrally managed TA management protoc= ol.

 =

Let me take= a few examples from the requirements:

·      =    T= he assumed roles and authorization model

·      =    T= he assumption that there exist clearly identifiable TA stores.

 =

The TA requ= irements are assuming a TA manager responsible for a TA store. The TA manager have authority over this TA store and have the power update it or replace it. Th= is also assumes that each TA store is individually identifiable in the protoco= l itself. In my environment above, I first of all don’t have any isolat= ed  identifiable TA stores. Secondly I don’t have a clearly defined= TA manager that has the right to view and update this information on a local machine.

 =

The applica= tions or services that eventually are being affected by these trust policy updates w= ill not have a clue about what information that was passed in any TA management protocol, or any IETF defined TA format file several layers and APIs below their existence. So any discussion about how applications should take into account specific path processing preferences provided by passing TA format information around, such as applying specific constraints rules, is just pr= etty theory without substance unless it is made part of standard RFC 5280 path processing and implemented in the APIs for path validation.

 =

In the envi= ronment I’m working with, I have no use for a transaction based TA management= protocol based on the simplified relationship between a TA manager and a TA store. <= o:p>

If I had on= e, I would not know how to use it.

The only th= ing I would know how to use, is the TA format specification. That one I can use t= o pass TAs around in my existing trust policy framework.

 =

I hope this= was a useful clarification and my apology for passing graphics in a PKIX posting. I hope= you can view it.

 =

 =

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 =

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Kemp, David P. Sent: den 16 december 2008 18:12
To: ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need it?<= /p>

 

Stefan,

 =

Refining th= e requirements as a series of I-Ds until “the scope of the requirements= is in harmony with problem space”, then publishing as an RFC once the requi= rements have converged, certainly sounds like the best approach.<= /p>

 =

But you hav= e not explained how “The requirements are radical= ly different in a device oriented environment with disconnected units compared with a ce= ntrally managed IT environment with a common network and data sharing infrastructure.”  The requirements= in either case are for managed devices/applications/services to receive configuration items from managers without those items being compromised in transit, yes?<= o:p>

 =

·      =    A= re you claiming that adversaries have no access to a “common network and dat= a sharing infrastructure” and therefore no protection is needed in the networke= d case?  That is patently false for all networks of interest to the IETF= .

·      =    O= r that the protection mechanisms appropriate for managing networked platforms (Connection-oriented?  MACs?) are different than those needed for mana= ging disconnected platforms (Datagram/message-oriented? Signatures?)<= /span>

 =

Without und= erstanding the nature of your objections it’s hard to tell whether the scope of = the requirements is already in harmony with the entire problem space or not.   Your 4-quadrant slide from Minneapolis is not self-explana= tory – I thought we had already disposed of the push-pull issue by determi= ning that there is no security-relevant difference between posting to a repository fr= om which a client may pull and pushing directly to the client.  Therefore= the TAM requirements already cover the left half of the space.  If there i= s a single existing TAM requirement that precludes pull, or a single missing TA= M requirement needed for pull, please provide an example.

 =

And I need = help understanding the difference you see between TA and TA Policy – if po= licy is “Host/App A will trust provider X for security critical firmware cate= gory Z”, and the TA store of Host/App A has provider X’s TA in the slot for fi= rmware category Z, what is the difference, other than level of abstraction, betwee= n “determine current TAs in store” and “demonstrate complia= nce with policy”?  Again, an example of a missing TAM requirement needed to satisfy the right = half of your slide would go a long way toward understanding the scope issue.

 =

Dave

 =

 =

 =

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson<= br> Sent: Tuesday, December 16, 2008 9:58 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need it?<= /p>

 

Hi Santosh,

 =

As I expect= , I sense that we have a slightly different view of the generality of the proposed solution, but we seem to agree on the main issue:

 =

The question one have to ask is if = these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it = at most will strengthen the argument for those having an interest to adopt the original protocol.

[Santosh] Having a requirements document t= hat is a living document, permits us to evaluate various solutions and protocol= s.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc.<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col= or:navy'>

 =

I would als= o prefer to see the requirements document as a living document as you suggest. I thi= nk that purpose is best served if the requirements document remains in draft f= orm.

 =

 =

 =

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 =

From: owner-ietf-pkix@mail.imc.org [mailto:ow= ner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani
Sent: den 15 december 2008 17:47
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need it?<= /p>

 

Stefan,

 

See my responses in-line below.

 

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson<= br> Sent: Friday, December 12, 2008 7:25 AM
To: ietf-pkix@imc.org
Subject: TA requirements doc - do we need it?

 

After all discussions in Minneapoli= s and going back and looking at the current situation, I feel less and less convi= nced that we need to approve any TA requirements document as an RFC. At least no= t in its current form.

I’m fine with having it aroun= d as a draft for reference, but I fear it may be a lot more harmful than beneficiary to = us as an RFC.

 

I have two major reasons:

 

First, as I have argued and tried t= o explain with my slide in Minneapolis, there is no general overall approach = to TA management in a complex IT environment.

[Santosh] In a complex distributed environ= ment that needs to scale across Enterprises, applying requisite security service= s to the payload provides a scalable, interoperable, extensible, and secure solution.

 

The requirements are radically diff= erent in a device oriented environment with disconnected units compared with a centr= ally managed IT environment with a common network and data sharing infrastructur= e.

[Santosh] The requirements are generally t= he same in terms of security services.  Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network.  But, that solution may not be as scalable or open= .

 

Secondly, the requirements didnR= 17;t come first. These requirements were written with an existing protocol in mind. T= he lasting impression is therefore that the requirements document was written to match= and support the original protocol, making it a tool to grandfather the original protocol into IETF. I’m not claiming that this is the case, but it re= mains to be my impression.

[Santosh] If you look at many of the engineering endeavors we undertake, requirements are based on past experien= ce, security vulnerabilities we have encountered, past systems, etc.  I do= not know of many successful efforts where requirements were developed in vacuum= . In short, it is fair to say that the requirements and protocol benefited from = each other and from past experiences with protocols and vulnerabilities.<= /i>

 

The question one have to ask is if = these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it = at most will strengthen the argument for those having an interest to adopt the original protocol.

[Santosh] Having a requirements document t= hat is a living document, permits us to evaluate various solutions and protocol= s.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc.<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col= or:navy'>

 

My proposal going forward is to do = the following:

-          In any case adjust the sc= ope of the requirements document to reflect the problem space the problem space it= is designed for.

-          Leave it as a draft, or a= t least not publish it as an RFC before the scope is in harmony with the requirements.

 

 

 

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 

--_000_9F11911AED01D24BAA1C2355723C3D321AF3E6206DEAEXMSGC332eu_-- From owner-ietf-pkix@mail.imc.org Thu Dec 18 10:15:33 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AA5D28C0EB for ; Thu, 18 Dec 2008 10:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYxmqi-UAuoC for ; Thu, 18 Dec 2008 10:15:32 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 24DDA3A6A1E for ; Thu, 18 Dec 2008 10:15:31 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIHppEj086742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 10:51:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIHppon086741; Thu, 18 Dec 2008 10:51:51 -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 mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIHpcBe086726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 18 Dec 2008 10:51:50 -0700 (MST) (envelope-from Pasi.Eronen@nokia.com) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mBIHpY8Y010772 for ; Thu, 18 Dec 2008 19:51:36 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Dec 2008 19:51:34 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Dec 2008 19:51:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AD review comments for draft-ietf-pkix-rfc4055-update-01 Date: Thu, 18 Dec 2008 19:51:34 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7202A049A8@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review comments for draft-ietf-pkix-rfc4055-update-01 Thread-Index: AclhOURfo6N+b0JqRwyqq4U9konBCw== From: To: X-OriginalArrivalTime: 18 Dec 2008 17:51:34.0375 (UTC) FILETIME=[444DCF70:01C96139] X-Nokia-AV: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've now reviewed draft-ietf-pkix-rfc4055-update-01, and it looks good. I have only one nit: the draft doesn't touch any of the parts related to PKCS#1 v1.5 signatures (RFC 4055 also specified OIDs=20 for PKCS#1 v1.5 signatures with SHA-224/256/384/512), so I'd=20 suggest the following edits: Abstract: OLD:=20 It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm with the Public-Key Cryptography Standards (PKCS) #1 = version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). NEW: It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Section 1: OLD: RFC 4055 specifies conventions for using the RSA Encryption Scheme -=20 Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport=20 algorithm with the Public-Key Cryptography Standards (PKCS) #1=20 version 1.5 signature algorithm in the Internet X.509 Public Key=20 Infrastructure (PKI). NEW: RFC 4055 specifies conventions for using the RSA Encryption Scheme -=20 Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport=20 algorithm in the Internet X.509 Public Key Infrastructure (PKI). Sean and others, do these look correct? Best regards, Pasi From owner-ietf-pkix@mail.imc.org Thu Dec 18 11:01:46 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADD23A6AB7 for ; Thu, 18 Dec 2008 11:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgmYs3CYGBm7 for ; Thu, 18 Dec 2008 11:01:45 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5455C3A69FB for ; Thu, 18 Dec 2008 11:01:45 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIIbvoS089248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 11:37:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIIbvA6089247; Thu, 18 Dec 2008 11:37: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 smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBIIbj9G089219 for ; Thu, 18 Dec 2008 11:37:56 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 99910 invoked from network); 18 Dec 2008 18:37:45 -0000 Received: from unknown (HELO Wylie) (turners@96.241.96.241 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 18 Dec 2008 18:37:44 -0000 X-YMail-OSG: Havn4LwVM1l3S1zRHQ5eiGE0btx5mBjgb2lI3t2f0Pc53jzV7MUdQ7if48MyPzlvFjNnTHhfcNOHvpb0La7xa7MjEGFFOWoXJ8I6_5DiShFg9b_kJVJ.nv2ozzGe.731tnwCZDNHMC9d4WEUoJxBvg3q7qI78MaL2WgbdAzc9fva5Nf0DqyMaPttHW7ZjTe8.MUE3GVUQwETQeOWcHOkSddCEOc- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: , References: <1696498986EFEC4D9153717DA325CB7202A049A8@vaebe104.NOE.Nokia.com> Subject: RE: AD review comments for draft-ietf-pkix-rfc4055-update-01 Date: Thu, 18 Dec 2008 13:37:19 -0500 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclhOURfo6N+b0JqRwyqq4U9konBCwABkvJA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <1696498986EFEC4D9153717DA325CB7202A049A8@vaebe104.NOE.Nokia.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: These look correct to me. spt >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org >[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of >Pasi.Eronen@nokia.com >Sent: Thursday, December 18, 2008 12:52 PM >To: ietf-pkix@imc.org >Subject: AD review comments for draft-ietf-pkix-rfc4055-update-01 > > > >I've now reviewed draft-ietf-pkix-rfc4055-update-01, and it >looks good. I have only one nit: the draft doesn't touch any >of the parts related to PKCS#1 v1.5 signatures (RFC 4055 also >specified OIDs for PKCS#1 v1.5 signatures with >SHA-224/256/384/512), so I'd suggest the following edits: > >Abstract: >OLD: > It updates the conventions for using the RSA Encryption Scheme - > Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport > algorithm with the Public-Key Cryptography Standards (PKCS) >#1 version > 1.5 signature algorithm in the Internet X.509 Public Key > Infrastructure (PKI). >NEW: > It updates the conventions for using the RSA Encryption Scheme - > Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport > algorithm in the Internet X.509 Public Key Infrastructure (PKI). > >Section 1: >OLD: > RFC 4055 specifies conventions for using the RSA Encryption >Scheme - > Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport > algorithm with the Public-Key Cryptography Standards (PKCS) #1 > version 1.5 signature algorithm in the Internet X.509 Public Key > Infrastructure (PKI). >NEW: > RFC 4055 specifies conventions for using the RSA Encryption >Scheme - > Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport > algorithm in the Internet X.509 Public Key Infrastructure (PKI). > > >Sean and others, do these look correct? > >Best regards, >Pasi > From mail@ambotech.com Thu Dec 18 22:57:35 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C459B3A687D for ; Thu, 18 Dec 2008 22:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.589 X-Spam-Level: X-Spam-Status: No, score=-16.589 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A63knttWSsX7 for ; Thu, 18 Dec 2008 22:57:35 -0800 (PST) Received: from ppp-124-121-188-13.revip2.asianet.co.th (ppp-124-121-188-13.revip2.asianet.co.th [124.121.188.13]) by core3.amsl.com (Postfix) with SMTP id D9C0E3A67CF for ; Thu, 18 Dec 2008 22:57:31 -0800 (PST) To: Subject: Get more pleasure with her From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081219065732.D9C0E3A67CF@core3.amsl.com> Date: Thu, 18 Dec 2008 22:57:31 -0800 (PST)
Click now!
From owner-ietf-pkix@mail.imc.org Fri Dec 19 11:29:55 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875E93A6A86 for ; Fri, 19 Dec 2008 11:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.446 X-Spam-Level: X-Spam-Status: No, score=-104.446 tagged_above=-999 required=5 tests=[AWL=2.153, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKUc4u9y1vDv for ; Fri, 19 Dec 2008 11:29:49 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 433FF3A6A49 for ; Fri, 19 Dec 2008 11:29:49 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBJIxsIK054686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2008 11:59:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBJIxsQF054685; Fri, 19 Dec 2008 11:59:54 -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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBJIxsUa054679 for ; Fri, 19 Dec 2008 11:59:54 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 4E1CA3A6906; Fri, 19 Dec 2008 11:00:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-tac-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081219190001.4E1CA3A6906@core3.amsl.com> Date: Fri, 19 Dec 2008 11:00:01 -0800 (PST) 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 : Traceable Anonymous Certificate Author(s) : S. Park, H. Park, Y. Won, J. Lee, S. Kent Filename : draft-ietf-pkix-tac-02.txt Pages : 34 Date : 2008-12-19 Public Key Infrastructure (PKI) provides a powerful means of authenticating individuals, organizations, and computers(e.g., web servers). However, when individuals use certificates to access resources on the public Internet, there are legitimate concerns about personal privacy, and thus there are increasing demands for privacy enhancing techniques on the Internet. In a PKI, an authorized entity such as a certification Authority (CA) or a Registration Authority (RA) may be perceived, from a privacy perspective, as a "big brother," even when a CA issues a certificate containing a Subject name that is a pseudonym. This is because such entities can always map a pseudonym in a certificate they issued to the name of the real user to whom it was issued. This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 [3], CMC[4]. The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymous Issuer). The end-entity(EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-tac-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pkix-tac-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-19105607.I-D@ietf.org> --NextPart-- From jcuestann@amara.es Sun Dec 21 07:32:18 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14D328C0EE for ; Sun, 21 Dec 2008 07:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.507 X-Spam-Level: X-Spam-Status: No, score=-21.507 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03gPNqwdFEUc for ; Sun, 21 Dec 2008 07:32:18 -0800 (PST) Received: from advancedfinancialcompany.com (unknown [93.177.159.231]) by core3.amsl.com (Postfix) with SMTP id 1E25A3A69F0 for ; Sun, 21 Dec 2008 07:31:51 -0800 (PST) To: Subject: Get quit of health disorders From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081221153203.1E25A3A69F0@core3.amsl.com> Date: Sun, 21 Dec 2008 07:31:51 -0800 (PST) We'll help you to receive your treatment at little cost! Get more info here… From owner-ietf-pkix@mail.imc.org Sun Dec 21 10:36:37 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D683A67EA for ; Sun, 21 Dec 2008 10:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-AB+ybxB8on for ; Sun, 21 Dec 2008 10:36:36 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4E4183A679C for ; Sun, 21 Dec 2008 10:36:35 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBLI2bAb069859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Dec 2008 11:02:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBLI2bc5069858; Sun, 21 Dec 2008 11:02: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBLI2QJm069851 for ; Sun, 21 Dec 2008 11:02:37 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812211802.mBLI2QJm069851@balder-227.proper.com> Received: (qmail 17156 invoked from network); 21 Dec 2008 18:02:20 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 21 Dec 2008 18:02:20 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 21 Dec 2008 12:27:36 -0500 To: From: Russ Housley Subject: RE: straw poll 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: 1. Yes 2. Yes -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Tuesday, December 16, 2008 9:29 AM To: ietf-pkix@imc.org Subject: straw poll At a previous IETF meeting (Dublin) I agreed to conduct a straw poll on adding a new WG item to address OCSP algorithm agility concerns, after PHB sent a message indicating what status he envisioned for the work. This action for both me and PHB fell through the cracks. At the MSP IETF meeting PHB provided a briefing on the problems that he saw re OCSP ambiguities re algorithm agility, and proposed a standards track document to address these issues (see PHB's message of 12/2). So, we now have a concrete proposal (draft-hallambaker-ocspagility) available for review. PHB would like to publish this and then merge it into the OCSP document when it progresses from PROPOSED to DRAFT (see his message of 12/2). Please send a message to the list by January 9th (allowing for holiday outages) indicating whether 1. your support PKIX work in this area 2. you support adopting PHB's document as a starting point for such work Thanks & Happy Holidays, Steve From jensend@acutecprecision.com Mon Dec 22 04:32:21 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD27D3A6882 for ; Mon, 22 Dec 2008 04:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.648 X-Spam-Level: X-Spam-Status: No, score=-36.648 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Pvn3VxP3g4W for ; Mon, 22 Dec 2008 04:32:15 -0800 (PST) Received: from agreenthumb.net (unknown [122.162.43.177]) by core3.amsl.com (Postfix) with SMTP id B9A383A6807 for ; Mon, 22 Dec 2008 04:32:12 -0800 (PST) To: Subject: This may be useful for your wellness From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081222123213.B9A383A6807@core3.amsl.com> Date: Mon, 22 Dec 2008 04:32:12 -0800 (PST) Click Here to start! From owner-ietf-pkix@mail.imc.org Mon Dec 22 05:21:23 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA263A687F for ; Mon, 22 Dec 2008 05:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.557 X-Spam-Level: * X-Spam-Status: No, score=1.557 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li7ZBB44jv5a for ; Mon, 22 Dec 2008 05:21:23 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0D8333A6829 for ; Mon, 22 Dec 2008 05:21:22 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCvv5i018746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 05:57:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMCvvoO018744; Mon, 22 Dec 2008 05:57: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 WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCvhUl018724; Mon, 22 Dec 2008 05:57:55 -0700 (MST) (envelope-from A.Hoenes@tr-sys.de) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA080420566; Mon, 22 Dec 2008 13:56:06 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA13071; Mon, 22 Dec 2008 13:56:05 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200812221256.NAA13071@TR-Sys.de> Subject: consisten use of top-level oid branch name joint-iso-itu-t(2) To: turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org Date: Mon, 22 Dec 2008 13:56:04 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks / to whom it concerns, during recent reviews of active I-Ds containing ASN.1 related to the X.500 framework, I found that a couple of these do not consistently employ the revised name of the top-level OID branch joint-iso-itu-t(2) , but instead use the outdated/legacy name joint-iso-ccitt(2) . Some drafts use a mix of both names. I suggest that the modern version joint-iso-itu-t(2) be used consistently within all new drafts / draft versions, unless intentionally and explicitely for historical evidence reference has to be made to the old name. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From owner-ietf-pkix@mail.imc.org Mon Dec 22 06:22:23 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28B23A6A1A for ; Mon, 22 Dec 2008 06:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8p1HsRzX7GJ for ; Mon, 22 Dec 2008 06:22:22 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 311B73A6882 for ; Mon, 22 Dec 2008 06:22:21 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCtLQn018637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 05:55:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMCtLTM018636; Mon, 22 Dec 2008 05:55:21 -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 mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCt2gN018622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Dec 2008 05:55:20 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from [192.168.1.102] (dslstat-77-ppp-125.fastq.com [65.39.77.125] (may be forged)) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id mBMCqlCQ027942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Dec 2008 05:53:43 -0700 Cc: ietf-pkix@imc.org Message-Id: <32405ED5-269D-4E6C-BBB5-1E06CCAD476A@fastq.com> From: Michael Myers To: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: straw poll Date: Mon, 22 Dec 2008 05:51:02 -0700 References: X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. yes 2. yes Mike On Dec 16, 2008, at 7:29 AM, Stephen Kent wrote: > > At a previous IETF meeting (Dublin) I agreed to conduct a straw poll > on adding a new WG item to address OCSP algorithm agility concerns, > after PHB sent a message indicating what status he envisioned for > the work. This action for both me and PHB fell through the cracks. > At the MSP IETF meeting PHB provided a briefing on the problems that > he saw re OCSP ambiguities re algorithm agility, and proposed a > standards track document to address these issues (see PHB's message > of 12/2). > > So, we now have a concrete proposal (draft-hallambaker-ocspagility) > available for review. PHB would like to publish this and then merge > it into the OCSP document when it progresses from PROPOSED to DRAFT > (see his message of 12/2). > > Please send a message to the list by January 9th (allowing for > holiday outages) indicating whether > > 1. your support PKIX work in this area > 2. you support adopting PHB's document as a starting point for such > work > > Thanks & Happy Hoplidays, > > Steve From owner-ietf-pkix@mail.imc.org Mon Dec 22 06:31:01 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88D2C3A6944 for ; Mon, 22 Dec 2008 06:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.996 X-Spam-Level: X-Spam-Status: No, score=-101.996 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cc8-zydspFl9 for ; Mon, 22 Dec 2008 06:31:00 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7843A3A6A64 for ; Mon, 22 Dec 2008 06:31:00 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBME0eMV022581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 07:00:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBME0eRF022579; Mon, 22 Dec 2008 07:00: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBME0S1G022564 for ; Mon, 22 Dec 2008 07:00:38 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812221400.mBME0S1G022564@balder-227.proper.com> Received: (qmail 3615 invoked from network); 22 Dec 2008 14:00:25 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 22 Dec 2008 14:00:25 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Dec 2008 08:33:51 -0500 To: Alfred =?hp-roman8?B?SM5uZXM=?= From: Russ Housley Subject: Re: consistent use of top-level oid branch name joint-iso-itu-t(2) Cc: turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org In-Reply-To: <200812221256.NAA13071@TR-Sys.de> References: <200812221256.NAA13071@TR-Sys.de> 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: Alfred: This is a result of the name change from CCITT to ITU-T. So, different documents use different names depending on when they were published. The bits on the wire are not impacted, so I have never worried about it. Russ At 07:56 AM 12/22/2008, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >Folks / to whom it concerns, > >during recent reviews of active I-Ds containing ASN.1 related >to the X.500 framework, I found that a couple of these do not >consistently employ the revised name of the top-level OID branch > > joint-iso-itu-t(2) , > >but instead use the outdated/legacy name > > joint-iso-ccitt(2) . > >Some drafts use a mix of both names. > >I suggest that the modern version joint-iso-itu-t(2) be used >consistently within all new drafts / draft versions, unless >intentionally and explicitely for historical evidence reference >has to be made to the old name. > >Kind regards, > Alfred. > >-- > >+------------------------+--------------------------------------------+ >| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | >| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | >| D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | >+------------------------+--------------------------------------------+ From owner-ietf-pkix@mail.imc.org Mon Dec 22 07:03:25 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0943A69F8 for ; Mon, 22 Dec 2008 07:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.523 X-Spam-Level: * X-Spam-Status: No, score=1.523 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UayB6J5f2VfZ for ; Mon, 22 Dec 2008 07:03:24 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 10F7E3A69ED for ; Mon, 22 Dec 2008 07:03:23 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMEalxR024585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 07:36:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMEalV8024583; Mon, 22 Dec 2008 07:36:47 -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 WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMEagXw024570; Mon, 22 Dec 2008 07:36:44 -0700 (MST) (envelope-from A.Hoenes@tr-sys.de) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA080886501; Mon, 22 Dec 2008 15:35:01 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA13232; Mon, 22 Dec 2008 15:34:56 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200812221434.PAA13232@TR-Sys.de> Subject: Re: consistent use of top-level oid branch name joint-iso-itu-t(2) To: housley@vigilsec.com Date: Mon, 22 Dec 2008 15:34:56 +0100 (MEZ) Cc: turners@ieca.com, ietf-smime@imc.org, ietf-pkix@imc.org In-Reply-To: <200812221358.AA080714339@w.> from Russ Housley at Dec "22," 2008 "08:33:51" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, thanks for your response. > Alfred: > > This is a result of the name change from CCITT to ITU-T. So, > different documents use different names depending on when they were > published. The bits on the wire are not impacted, so I have never > worried about it. > > Russ I am fully aware of the history, but that change is back quite a couple of years now. IIRC, that must have been more than 15 years ago; in particular, the X.680 1994 Edition (== ISO/IEC 8824-1:1995) already specified the new name(s) as the primary identifier(s). My arguments are primarily: o avoiding possible confusion; o making new documents easier to read for newcomers not aware of the history of the ITU-T; o self-consistency within new documents (a major goal of RFC Editor policy); o consistency within the set of related document revisions currently in progress; o using current terminology and names in new documents; o referring to the new name when making citations of the X.680 series of IUT-T Recommendations (and that's the way SMIME and PKIX are moving forward). Kind regards, Alfred. From owner-ietf-pkix@mail.imc.org Mon Dec 22 08:10:41 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086ED3A6A53 for ; Mon, 22 Dec 2008 08:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+Rkrxo--C2L for ; Mon, 22 Dec 2008 08:10:40 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8F3DF3A6A30 for ; Mon, 22 Dec 2008 08:10:39 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMFmORn029597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 08:48:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMFmO90029594; Mon, 22 Dec 2008 08:48: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 smtp816.mail.ird.yahoo.com (smtp816.mail.ird.yahoo.com [77.238.189.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBMFmBgA029575 for ; Mon, 22 Dec 2008 08:48:23 -0700 (MST) (envelope-from j.larmouth@btinternet.com) Received: (qmail 20008 invoked from network); 22 Dec 2008 15:48:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=tQkoL9owhPwHWzOzbPimY2Dt9JLv9nU5CWYe5StO2PIWznWDtp9LPE29yxgnkSh5p8FCRwMbeYsCDH0gIdW6yYtovDwrpS3BpGS1jCw403OGtrbrc9pUWokxAf3jy0SmO3OIR/qUTkI8GHgcJXuL/In61WOVFOZ+PzzhYby+X1U= ; Received: from unknown (HELO ?192.168.1.67?) (j.larmouth@217.44.207.2 with plain) by smtp816.mail.ird.yahoo.com with SMTP; 22 Dec 2008 15:48:10 -0000 X-YMail-OSG: Rhsm3igVM1nRvqWJciSouoY2o6CT9wZveZw3YFTc9fQIuZHvz7kL1MGbOApNbshcIfLe78WzVfRaVJspyziFxx2Xc10jC7vH5WxKe_96btpwxv4OEbQEtxiUo5SZVvvIcA.aMYmWsReum7fstMynnnCtCoEmr.C8ANenOiYBqSp.Hy2stujeRFiUsQ1X61Yo X-Yahoo-Newman-Property: ymail-3 Message-ID: <494FB6BA.9080402@btinternet.com> Date: Mon, 22 Dec 2008 15:48:10 +0000 From: John Larmouth Reply-To: j.larmouth@btinternet.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= CC: turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2) References: <200812221256.NAA13071@TR-Sys.de> In-Reply-To: <200812221256.NAA13071@TR-Sys.de> Content-Type: multipart/alternative; boundary="------------060306020603010708080909" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------060306020603010708080909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Alfred, The synonyms were introduced some time ago, and, indeed, the names are non-normative, and may not even be unambiguous. Only the numbers matter in an OID in an encoding. However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired. The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels. Unicode labels with names similar to the old ASCII names have been assigned for many of the top-level arcs, and more will be added over time. The OID_IRI type is related to (but not dependent on) the application for an "oid" IRI scheme, but for consistency this is desired. See I-D draft-larmouth-oid-iri-00. John L Alfred � wrote: >Folks / to whom it concerns, > >during recent reviews of active I-Ds containing ASN.1 related >to the X.500 framework, I found that a couple of these do not >consistently employ the revised name of the top-level OID branch > > joint-iso-itu-t(2) , > >but instead use the outdated/legacy name > > joint-iso-ccitt(2) . > >Some drafts use a mix of both names. > >I suggest that the modern version joint-iso-itu-t(2) be used >consistently within all new drafts / draft versions, unless >intentionally and explicitely for historical evidence reference >has to be made to the old name. > >Kind regards, > Alfred. > > > -- Prof John Larmouth Larmouth T&PDS Ltd (Training and Protocol Design Services Ltd) 1 Blueberry Road Bowdon j.larmouth@btinternet.com Altrincham Cheshire WA14 3LS England Tel: +44 161 928 1605 --------------060306020603010708080909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Alfred,

The synonyms were introduced some time ago, and, indeed, the names are non-normative, and may not even be unambiguous.  Only the numbers matter in an OID in an encoding.

However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired.  The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels.  Unicode labels with names similar to the old ASCII names have been assigned for many of the top-level arcs, and more will be added over time.

The OID_IRI type  is related to (but not dependent on) the application for an "oid" IRI scheme,  but for consistency this is desired.  See I-D draft-larmouth-oid-iri-00.

John L

Alfred � wrote: 
Folks / to whom it concerns,

during recent reviews of active I-Ds containing ASN.1 related
to the X.500 framework, I found that a couple of these do not
consistently employ the revised name of the top-level OID branch

    joint-iso-itu-t(2) ,

but instead use the outdated/legacy name

    joint-iso-ccitt(2) .

Some drafts use a mix of both names.

I suggest that the modern version  joint-iso-itu-t(2)  be used
consistently within all new drafts / draft versions, unless
intentionally and explicitely for historical evidence reference
has to be made to the old name.

Kind regards,
  Alfred.

  

-- 
   Prof John Larmouth
   Larmouth T&PDS Ltd
   (Training and Protocol Design Services Ltd)
   1 Blueberry Road                     
   Bowdon                               j.larmouth@btinternet.com
   Altrincham
   Cheshire
   WA14 3LS                 
   England
   Tel: +44 161 928 1605
--------------060306020603010708080909-- From owner-ietf-pkix@mail.imc.org Mon Dec 22 09:18:12 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736153A6A59 for ; Mon, 22 Dec 2008 09:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClmyfSBFB1eA for ; Mon, 22 Dec 2008 09:18:11 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 843E53A6A51 for ; Mon, 22 Dec 2008 09:18:08 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMGow4d034237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 09:50:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMGowgI034236; Mon, 22 Dec 2008 09:50: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 [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMGon8p034216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 09:50:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <494FB6BA.9080402@btinternet.com> References: <200812221256.NAA13071@TR-Sys.de> <494FB6BA.9080402@btinternet.com> Date: Mon, 22 Dec 2008 08:50:47 -0800 To: j.larmouth@btinternet.com, Alfred ? From: Paul Hoffman Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2) Cc: turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 3:48 PM +0000 12/22/08, John Larmouth wrote: >However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired. Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups. >The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels. Paging Peter Gutmann.... --Paul Hoffman, Director --VPN Consortium From owner-ietf-pkix@mail.imc.org Mon Dec 22 10:28:26 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C280D3A68F4 for ; Mon, 22 Dec 2008 10:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.42 X-Spam-Level: X-Spam-Status: No, score=-104.42 tagged_above=-999 required=5 tests=[AWL=2.179, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuLTJP58dPax for ; Mon, 22 Dec 2008 10:28:26 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A454D3A6829 for ; Mon, 22 Dec 2008 10:28:25 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMHxrJd037374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 10:59:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMHxrBG037373; Mon, 22 Dec 2008 10:59:53 -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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMHxrgB037367 for ; Mon, 22 Dec 2008 10:59:53 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 44D393A6A56; Mon, 22 Dec 2008 10:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-3281update-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081222180001.44D393A6A56@core3.amsl.com> Date: Mon, 22 Dec 2008 10:00:01 -0800 (PST) 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 : An Internet Attribute Certificate Profile for Authorization Author(s) : R. Housley, S. Farrell, S. Turner Filename : draft-ietf-pkix-3281update-03.txt Pages : 45 Date : 2008-12-22 This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. This document obsoletes RFC 3281. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-3281update-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pkix-3281update-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-22095610.I-D@ietf.org> --NextPart-- From owner-ietf-pkix@mail.imc.org Mon Dec 22 12:57:24 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D991528C0D8 for ; Mon, 22 Dec 2008 12:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgwiKbhqb6F4 for ; Mon, 22 Dec 2008 12:57:24 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9528C3A6AAA for ; Mon, 22 Dec 2008 12:57:23 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMKQ2sk044002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 13:26:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMKQ2O2044001; Mon, 22 Dec 2008 13:26: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMKPsKO043973 for ; Mon, 22 Dec 2008 13:26:01 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id 2809B3A6AA0; Mon, 22 Dec 2008 12:26:02 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , pkix mailing list , pkix chair Subject: Protocol Action: 'Elliptic Curve Cryptography Subject Public Key Information' to Proposed Standard Message-Id: <20081222202602.2809B3A6AA0@core3.amsl.com> Date: Mon, 22 Dec 2008 12:26:02 -0800 (PST) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'Elliptic Curve Cryptography Subject Public Key Information ' as a Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-11.txt Technical Summary The subjectPublicKeyInfo field of an X.509 certificate carries three data items: an algorithm identifier, optional parameters, and a bit string that represents the public key. The parameters are specific to the algorithm and this field usually contains simple values needed to characterize the public key algorithm, e.g., the generator and modulus for Diffie-Hellman. However, X.509 does not constrain the scope of this parameters field. The ANSI X9.62 standards allow parameters to name the curve via an object identifier, inherit the curve from an issuer, or fully specify the curve. To fully specify the curve a complex structure is required. Further, the ANSI X9.62 standards committee elected to use this field to express potentially complex limitations on how the public key in the certificate can be used, e.g., which key derivation functions can be applied to the bit string that results from a Diffie-Hellman key exchange. After considerable debate the PKIX WG decided to limit the number of parameter choices to one: the name the curve with an object identifier (namedCurve). This decision was based on implementers desire to use well known curves from NIST and the complexity of the specifiedCurve field (not to mention the 20+ pages it saved). The WG also decided to restrict the number of algorithm identifiers to three: id-ecPublicKey, id-ecDH, and id-ECMQV. The id-ecPublicKey object identifier is when a CA does not want to limit the key for use with a particular ECC algorithm. ECDSA will use this object identifier, as it is already widely implemented. The id-ecDH and id-ecMQV object identifiers are used to restrict the key for use with ECDH and ECMQV, respectively. The SHA-224, SHA-256, SHA-384, and SHA-512 algorithms and the NIST curves were added to the ASN.1 modules. Working Group Summary This ID was discussed extensively on the PKIX WG mailing list. A poll was taken to remove the specifiedCurve option. The WG was in favor of the change. The other comments were about document quality. Document Quality This document is a fairly length update of three sections of RFC 3279 (Sections 2.3.5, 3, and 5) and includes a long ASN.1 module. The quality of the draft is comparable in quality to its predecessor Personnel The document shepherd is Stefan Santesson. The responsible area director is Pasi Eronen. From lsq@ahedu.gov.cn Mon Dec 22 13:23:39 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DBE23A6806 for ; Mon, 22 Dec 2008 13:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.296 X-Spam-Level: X-Spam-Status: No, score=-11.296 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7njbPpnSycrp for ; Mon, 22 Dec 2008 13:23:33 -0800 (PST) Received: from 190.222-136-217.adsl-static.isp.belgacom.be (190.222-136-217.adsl-static.isp.belgacom.be [217.136.222.190]) by core3.amsl.com (Postfix) with SMTP id BB5EF3A6A62 for ; Mon, 22 Dec 2008 13:23:30 -0800 (PST) To: Subject: Don't go home now! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081222212331.BB5EF3A6A62@core3.amsl.com> Date: Mon, 22 Dec 2008 13:23:30 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From nietomauricio.nieto@aeromar.com.mx Mon Dec 22 13:29:48 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516683A6806 for ; Mon, 22 Dec 2008 13:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.17 X-Spam-Level: X-Spam-Status: No, score=-14.17 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9b6uKGDvUBy for ; Mon, 22 Dec 2008 13:29:41 -0800 (PST) Received: from r190-135-155-42.dialup.adsl.anteldata.net.uy (r190-135-155-42.dialup.adsl.anteldata.net.uy [190.135.155.42]) by core3.amsl.com (Postfix) with SMTP id 52CC63A67A7 for ; Mon, 22 Dec 2008 13:29:34 -0800 (PST) To: Subject: We were looking for you! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081222212938.52CC63A67A7@core3.amsl.com> Date: Mon, 22 Dec 2008 13:29:34 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From joanna.korejczuk@amplicolife.pl Mon Dec 22 22:34:18 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F76D3A698D for ; Mon, 22 Dec 2008 22:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -49.683 X-Spam-Level: X-Spam-Status: No, score=-49.683 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_PL=1.135, HELO_MISMATCH_PL=1.448, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DryU2NRkyLFn for ; Mon, 22 Dec 2008 22:34:17 -0800 (PST) Received: from advantech.pl (unknown [122.164.225.104]) by core3.amsl.com (Postfix) with SMTP id DB1C93A67EC for ; Mon, 22 Dec 2008 22:34:14 -0800 (PST) To: Subject: We need you here, now! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223063415.DB1C93A67EC@core3.amsl.com> Date: Mon, 22 Dec 2008 22:34:14 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Tue Dec 23 03:39:49 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F9E28C158 for ; Tue, 23 Dec 2008 03:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGBcVCOv0Bis for ; Tue, 23 Dec 2008 03:39:42 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D67B23A6834 for ; Tue, 23 Dec 2008 03:39:41 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBNBCPA1081225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2008 04:12:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBNBCP7P081221; Tue, 23 Dec 2008 04:12: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 smtp811.mail.ird.yahoo.com (smtp811.mail.ird.yahoo.com [217.146.188.71]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBNBCD5j081188 for ; Tue, 23 Dec 2008 04:12:23 -0700 (MST) (envelope-from j.larmouth@btinternet.com) Received: (qmail 19382 invoked from network); 23 Dec 2008 11:12:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=ZgjNwUWwaAPfQyogg8vHfLojoDj2f6PPl6jLyMT1LX+GOZgYVsd+zYVe1pstplrU7roUTsoWhQU7rM+hxAxtO3KVP5DSctcXkIPh3CNNymNj4/TAan4LVlRGK07rc8liEWhvwMooVHIdWKw5LD8yHCu2xqLJhg7WxlFKcO54JdA= ; Received: from unknown (HELO ?192.168.1.67?) (j.larmouth@217.44.207.2 with plain) by smtp811.mail.ird.yahoo.com with SMTP; 23 Dec 2008 11:12:12 -0000 X-YMail-OSG: vrgTfU8VM1mhkBOfr2CSHGEqUVui2P3Vnd3ljSE7EVqJa89BjIvhiI93Btn7MNC9fVMoUaSwuOrYO4OSMY882lno3YQrlrLp5P8jEjFTpTp_wFt6VP8hPxnFtyPN_Lx5ksOKw39eNumGWr57Q0Sw3cKgBLS2H37M3bNaMaCviyfwvDRRD0xxU_Y5r.Abk3_Lxf2L8VqTfMACOHM4ip3OB39LJI6k_diIJGQh X-Yahoo-Newman-Property: ymail-3 Message-ID: <4950C78C.8090306@btinternet.com> Date: Tue, 23 Dec 2008 11:12:12 +0000 From: John Larmouth Reply-To: j.larmouth@btinternet.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Paul Hoffman CC: Alfred ? , turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2) References: <200812221256.NAA13071@TR-Sys.de> <494FB6BA.9080402@btinternet.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050009060805000700080909" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------050009060805000700080909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please note my use of "if desired" below. This presents an opportunity, not a requirement. Nothing has been removed from the old OID capability. I agree that the use of Unicode labels has not been adopted by PKIX or S/MIME (and may well never be), nor presented to them. However, unless or until the "oid" IRI format is accepted by URI-review, it would be premature for PKIX or SMIME to even consider it. John L Paul Hoffman wrote: >At 3:48 PM +0000 12/22/08, John Larmouth wrote: > > >>However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired. >> >> > >Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups. > > > >>The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels. >> >> > >Paging Peter Gutmann.... > >--Paul Hoffman, Director >--VPN Consortium > > > -- Prof John Larmouth Larmouth T&PDS Ltd (Training and Protocol Design Services Ltd) 1 Blueberry Road Bowdon j.larmouth@btinternet.com Altrincham Cheshire WA14 3LS England Tel: +44 161 928 1605 --------------050009060805000700080909 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Please note my use of "if desired" below.  This presents an opportunity, not a requirement.

Nothing has been removed from the old OID capability.

I agree that the use of Unicode labels has not been adopted by PKIX or S/MIME (and may well never be), nor presented to them.  However, unless or until the "oid" IRI format is accepted by URI-review, it would be premature for PKIX or SMIME to even consider it.

John L

Paul Hoffman wrote:
At 3:48 PM +0000 12/22/08, John Larmouth wrote:
  
However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired. 
    

Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups.

  
The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels.
    

Paging Peter Gutmann....

--Paul Hoffman, Director
--VPN Consortium

  

-- 
   Prof John Larmouth
   Larmouth T&PDS Ltd
   (Training and Protocol Design Services Ltd)
   1 Blueberry Road                     
   Bowdon                               j.larmouth@btinternet.com
   Altrincham
   Cheshire
   WA14 3LS                 
   England
   Tel: +44 161 928 1605
--------------050009060805000700080909-- From oom32red@32red.com Tue Dec 23 05:25:08 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93FE23A6935 for ; Tue, 23 Dec 2008 05:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.052 X-Spam-Level: X-Spam-Status: No, score=-33.052 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_OB_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5rwN12J60AJ for ; Tue, 23 Dec 2008 05:25:06 -0800 (PST) Received: from alcoa.com.au (unknown [87.121.13.199]) by core3.amsl.com (Postfix) with SMTP id 8F0183A680F for ; Tue, 23 Dec 2008 05:25:03 -0800 (PST) To: Subject: Have the greatest night ever From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223132505.8F0183A680F@core3.amsl.com> Date: Tue, 23 Dec 2008 05:25:03 -0800 (PST) Try us when you are looking for the best enhancement supplement! From melhem.mousallem@aishti.com Tue Dec 23 13:25:25 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322DA3A6B22 for ; Tue, 23 Dec 2008 13:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -41.384 X-Spam-Level: X-Spam-Status: No, score=-41.384 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duOX5G4shK3n for ; Tue, 23 Dec 2008 13:25:25 -0800 (PST) Received: from host-23-140-gornik.igloonet.pl (host-23-140-gornik.igloonet.pl [77.65.140.23]) by core3.amsl.com (Postfix) with SMTP id E38CD28C0DF for ; Tue, 23 Dec 2008 13:25:22 -0800 (PST) To: Subject: Come upstairs! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223212523.E38CD28C0DF@core3.amsl.com> Date: Tue, 23 Dec 2008 13:25:22 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Wed Dec 24 12:46:54 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB7B3A682A for ; Wed, 24 Dec 2008 12:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.279 X-Spam-Level: X-Spam-Status: No, score=-4.279 tagged_above=-999 required=5 tests=[AWL=1.679, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSuVGugo2uCo for ; Wed, 24 Dec 2008 12:46:54 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 221713A6846 for ; Wed, 24 Dec 2008 12:46:53 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBOJFZYk016887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Dec 2008 12:15:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBOJFZ9Y016884; Wed, 24 Dec 2008 12:15:35 -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 e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBOJFMd1016857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Dec 2008 12:15:33 -0700 (MST) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBOJFARG009894; Wed, 24 Dec 2008 14:15:10 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBOJFJlC197854; Wed, 24 Dec 2008 14:15:19 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id mBOJFJPr026105; Wed, 24 Dec 2008 14:15:19 -0500 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id mBOJFIoj026095; Wed, 24 Dec 2008 14:15:18 -0500 In-Reply-To: <494FB6BA.9080402@btinternet.com> To: j.larmouth@btinternet.com Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , ietf-pkix@imc.org, ietf-smime@imc.org, turners@ieca.com MIME-Version: 1.0 Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2) X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Tom Gindin Message-ID: Date: Wed, 24 Dec 2008 14:15:17 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/24/2008 14:15:18, Serialize complete at 12/24/2008 14:15:18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ICAgICAgICBKb2huOg0KDQogICAgICAgIFRoaXMgZHJhZnQgaXMgaW50ZXJlc3RpbmcgYW5kIHVz ZWZ1bCBmb3Igc29tZSBwdXJwb3NlcywgYnV0IEkgDQpkb24ndCBzZWUgaG93IGl0IGFkZHJlc3Nl cyB0aGUgY2FzZSB3aGVyZSBhIGhpZ2gtbGV2ZWwgYXJjIChiZXlvbmQgdGhlIA0KY29udHJvbCBv ZiB0aGUgZGV2ZWxvcG1lbnQgb3JnYW5pemF0aW9uKSBpcyByZW5hbWVkLiAgU2luY2UgdGhhdCdz IA0KcHJlY2lzZWx5IHRoZSBjYXNlIHdlIGFyZSBkaXNjdXNzaW5nIGhlcmUgKGFsdGhvdWdoIHRo ZSBjaGFuZ2UgdG9vayBwbGFjZSANCnF1aXRlIGEgd2hpbGUgYWdvIGFuZCBpdCdzIHJlYXNvbmFi bGUgdG8gZXhwZWN0IHBlb3BsZSB0byBhZGp1c3QpLCBpdCANCmRvZXNuJ3QgYWN0dWFsbHkgc2Vl bSB0byBoZWxwIHVzLiAgQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCiAgICAgICAgQWxzbywgdW5s ZXNzIEkgaGF2ZSBtaXNzZWQgc29tZXRoaW5nLCB0aGVyZSBhcmUgb25seSB0aHJlZSANCnRvcC1s ZXZlbCBhcmNzIGRlZmluZWQgZm9yIE9JRCdzIGFuZCB0aGV5IGFsbCBub3cgaGF2ZSBuYW1lcy4N Cg0KICAgICAgICAgICAgICAgIFRvbSBHaW5kaW4NCg0KDQoNCg0KSm9obiBMYXJtb3V0aCA8ai5s YXJtb3V0aEBidGludGVybmV0LmNvbT4gDQpTZW50IGJ5OiBvd25lci1pZXRmLXBraXhAbWFpbC5p bWMub3JnDQoxMi8yMi8yMDA4IDEwOjQ4IEFNDQpQbGVhc2UgcmVzcG9uZCB0bw0Kai5sYXJtb3V0 aEBidGludGVybmV0LmNvbQ0KDQoNClRvDQpBbGZyZWQg77+9IDxhaEB0ci1zeXMuZGU+DQpjYw0K dHVybmVyc0BpZWNhLmNvbSwgaWV0Zi1wa2l4QGltYy5vcmcsIGlldGYtc21pbWVAaW1jLm9yZw0K U3ViamVjdA0KUmU6IGNvbnNpc3RlbiB1c2Ugb2YgdG9wLWxldmVsIG9pZCBicmFuY2ggbmFtZSBq b2ludC1pc28taXR1LXQoMikNCg0KDQoNCg0KDQoNCkFsZnJlZCwNCg0KVGhlIHN5bm9ueW1zIHdl cmUgaW50cm9kdWNlZCBzb21lIHRpbWUgYWdvLCBhbmQsIGluZGVlZCwgdGhlIG5hbWVzIGFyZSAN Cm5vbi1ub3JtYXRpdmUsIGFuZCBtYXkgbm90IGV2ZW4gYmUgdW5hbWJpZ3VvdXMuICBPbmx5IHRo ZSBudW1iZXJzIG1hdHRlciANCmluIGFuIE9JRCBpbiBhbiBlbmNvZGluZy4NCg0KSG93ZXZlciwg dGhlIHJlY2VudCBpbnRyb2R1Y3Rpb24gb2YgVW5pY29kZSBsYWJlbHMsIGFzIG5vcm1hdGl2ZSBh bmQgDQp1bmFtYmlnb3VzIG5hbWVzIGdpdmVzIGEgbmV3IG5hbWluZyBzY2hlbWUgdG8gdGhlIChz YW1lKSBPSUQgdHJlZSB0aGF0IA0KZW5hYmxlcyBuYW1lcyAoVW5pY29kZSBsYWJlbHMpIHRvIGJl IHVzZWQgaW4gbWFjaGluZSBjb21tdW5pY2F0aW9uIGlmIA0KZGVzaXJlZC4gIFRoZSBBU04uMSB0 eXBlIGlzIGNhbGxlZCBPSURfSVJJIGFuZCBwcm92aWRlcyBmb3Igbm9kZSANCmlkZW50aWZpY2F0 aW9uIHVzaW5nIFVuaWNvZGUgbGFiZWxzLiAgVW5pY29kZSBsYWJlbHMgd2l0aCBuYW1lcyBzaW1p bGFyIHRvIA0KdGhlIG9sZCBBU0NJSSBuYW1lcyBoYXZlIGJlZW4gYXNzaWduZWQgZm9yIG1hbnkg b2YgdGhlIHRvcC1sZXZlbCBhcmNzLCBhbmQgDQptb3JlIHdpbGwgYmUgYWRkZWQgb3ZlciB0aW1l Lg0KDQpUaGUgT0lEX0lSSSB0eXBlICBpcyByZWxhdGVkIHRvIChidXQgbm90IGRlcGVuZGVudCBv bikgdGhlIGFwcGxpY2F0aW9uIGZvciANCmFuICJvaWQiIElSSSBzY2hlbWUsICBidXQgZm9yIGNv bnNpc3RlbmN5IHRoaXMgaXMgZGVzaXJlZC4gIFNlZSBJLUQgDQpkcmFmdC1sYXJtb3V0aC1vaWQt aXJpLTAwLg0KDQpKb2huIEwNCg0KQWxmcmVkIO+/vSB3cm90ZTogDQpGb2xrcyAvIHRvIHdob20g aXQgY29uY2VybnMsDQoNCmR1cmluZyByZWNlbnQgcmV2aWV3cyBvZiBhY3RpdmUgSS1EcyBjb250 YWluaW5nIEFTTi4xIHJlbGF0ZWQNCnRvIHRoZSBYLjUwMCBmcmFtZXdvcmssIEkgZm91bmQgdGhh dCBhIGNvdXBsZSBvZiB0aGVzZSBkbyBub3QNCmNvbnNpc3RlbnRseSBlbXBsb3kgdGhlIHJldmlz ZWQgbmFtZSBvZiB0aGUgdG9wLWxldmVsIE9JRCBicmFuY2gNCg0KICAgIGpvaW50LWlzby1pdHUt dCgyKSAsDQoNCmJ1dCBpbnN0ZWFkIHVzZSB0aGUgb3V0ZGF0ZWQvbGVnYWN5IG5hbWUNCg0KICAg IGpvaW50LWlzby1jY2l0dCgyKSAuDQoNClNvbWUgZHJhZnRzIHVzZSBhIG1peCBvZiBib3RoIG5h bWVzLg0KDQpJIHN1Z2dlc3QgdGhhdCB0aGUgbW9kZXJuIHZlcnNpb24gIGpvaW50LWlzby1pdHUt dCgyKSAgYmUgdXNlZA0KY29uc2lzdGVudGx5IHdpdGhpbiBhbGwgbmV3IGRyYWZ0cyAvIGRyYWZ0 IHZlcnNpb25zLCB1bmxlc3MNCmludGVudGlvbmFsbHkgYW5kIGV4cGxpY2l0ZWx5IGZvciBoaXN0 b3JpY2FsIGV2aWRlbmNlIHJlZmVyZW5jZQ0KaGFzIHRvIGJlIG1hZGUgdG8gdGhlIG9sZCBuYW1l Lg0KDQpLaW5kIHJlZ2FyZHMsDQogIEFsZnJlZC4NCg0KIA0KDQotLSANCiAgIFByb2YgSm9obiBM YXJtb3V0aA0KICAgTGFybW91dGggVCZQRFMgTHRkDQogICAoVHJhaW5pbmcgYW5kIFByb3RvY29s IERlc2lnbiBTZXJ2aWNlcyBMdGQpDQogICAxIEJsdWViZXJyeSBSb2FkIA0KICAgQm93ZG9uICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGoubGFybW91dGhAYnRpbnRlcm5ldC5jb20NCiAg IEFsdHJpbmNoYW0NCiAgIENoZXNoaXJlDQogICBXQTE0IDNMUyANCiAgIEVuZ2xhbmQNCiAgIFRl bDogKzQ0IDE2MSA5MjggMTYwNQ0KDQoNCg== From omalopsinae@a54321.com Thu Dec 25 14:30:54 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451A03A6828 for ; Thu, 25 Dec 2008 14:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.423 X-Spam-Level: X-Spam-Status: No, score=-14.423 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O3iyTrM4hxe for ; Thu, 25 Dec 2008 14:30:53 -0800 (PST) Received: from 201-43-54-233.dsl.telesp.net.br (201-43-54-233.dsl.telesp.net.br [201.43.54.233]) by core3.amsl.com (Postfix) with SMTP id 28B1E3A697B for ; Thu, 25 Dec 2008 14:30:50 -0800 (PST) To: Subject: We are committed to your total health! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081225223052.28B1E3A697B@core3.amsl.com> Date: Thu, 25 Dec 2008 14:30:50 -0800 (PST)

If you are unable to see the message below, click here to view.

Check it now, while our discounts for the best treatments are in effect!

PLEASE DO NOT REPLY - This is being sent from an unattended mailbox.

Copyright © 2008 MaxGentleman, Inc. All rights reserved.
5 Trowbridge Drive, Bethel, CT 803056

You have received this message because you
opted in to receives MaxGentleman pecial offers via email.

You can unsubscribe here

 From nattawut@ais.co.th Thu Dec 25 18:57:10 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81D9B3A6841 for ; Thu, 25 Dec 2008 18:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.836 X-Spam-Level: X-Spam-Status: No, score=-17.836 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJ7Il-HXtoIv for ; Thu, 25 Dec 2008 18:57:09 -0800 (PST) Received: from c-24-6-35-226.hsd1.ca.comcast.net (c-24-6-35-226.hsd1.ca.comcast.net [24.6.35.226]) by core3.amsl.com (Postfix) with SMTP id 097153A6839 for ; Thu, 25 Dec 2008 18:57:08 -0800 (PST) To: Subject: We are aimed at promoting your health From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081226025709.097153A6839@core3.amsl.com> Date: Thu, 25 Dec 2008 18:57:08 -0800 (PST)

If you are unable to see the message below, click here to view.

Start getting more and more pleasure from life with these treatments!

PLEASE DO NOT REPLY - This is being sent from an unattended mailbox.

Copyright © 2008 MaxGentleman, Inc. All rights reserved.
5 Trowbridge Drive, Bethel, CT 093279

You have received this message because you
opted in to receives MaxGentleman pecial offers via email.

You can unsubscribe here

 From lydiam@alternatives.co.uk Fri Dec 26 14:55:50 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6CD03A6A2B for ; Fri, 26 Dec 2008 14:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.713 X-Spam-Level: X-Spam-Status: No, score=-31.713 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkHsK4kHb4fF for ; Fri, 26 Dec 2008 14:55:50 -0800 (PST) Received: from aeronimbus.com (unknown [85.106.254.154]) by core3.amsl.com (Postfix) with SMTP id E97943A63D3 for ; Fri, 26 Dec 2008 14:55:48 -0800 (PST) To: Subject: I've got problems, can't find u From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081226225548.E97943A63D3@core3.amsl.com> Date: Fri, 26 Dec 2008 14:55:48 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Fri Dec 26 22:28:07 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077603A6982 for ; Fri, 26 Dec 2008 22:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[AWL=-1.457, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQPbHCv+mnBK for ; Fri, 26 Dec 2008 22:27:50 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B0D463A67AB for ; Fri, 26 Dec 2008 22:27:48 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBR5knsi097244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Dec 2008 22:46:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBR5knVg097243; Fri, 26 Dec 2008 22:46:49 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBR5kb3k097231 for ; Fri, 26 Dec 2008 22:46:48 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 29194 invoked from network); 27 Dec 2008 05:47:05 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;27 Dec 2008 05:47:05 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 27 Dec 2008 05:47:04 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C967E6.7A3B5275" Subject: RE: TA requirements doc - do we need it? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 27 Dec 2008 00:46:34 -0500 Message-ID: In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AF3E6206D@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TA requirements doc - do we need it? Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrAAApWoQAAk2WagAEDwEFAACsxGQA== References: <9F11911AED01D24BAA1C2355723C3D321AF3E6206D@EA-EXMSG-C332.europe.corp.microsoft.com> From: "Santosh Chokhani" To: "Stefan Santesson" , , "Kemp, David P." 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_01C967E6.7A3B5275 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 I for one do not see how your e-mail relates to the TA requirements document or Dave's post. See responses in-line. =20 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Thursday, December 18, 2008 11:47 AM To: ietf-pkix@imc.org; Kemp, David P. Subject: FW: TA requirements doc - do we need it? I'm resending this as my original mail got filtered due to exceeding pkix message size restrictions. I have now replaced the embedded picture with a URL to the screenshot. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: Stefan Santesson=20 Sent: den 17 december 2008 11:43 To: 'Kemp, David P.'; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Dave, =20 You raise valid points and I partly try to avoid them because the answer is somewhat long and complex. Long and complex answers are seldom successful in standards discussions :-) =20 Let me try to show my point through a screenshot that helped explain this issue to at least one of the original contributors to the proposed protocol. This is a screenshot of the Microsoft certificate management snap-in: =20 http://www.fiddler.nu/pkix/certmgr_mmc.jpg =20 What you see here is the certificate trust policies in my laptop. It is not one root store and it is not just about trust anchors. In my laptop I have a certificate trust management snap-in for: * Each host (local machine) * Each user account * Each service running on any host [Santosh] This is consistent with TA requirements since TA requirements deal with each TA store. In your case, the TA and TAMP will be applied to three stores. =20 In the Certificate snap-in window to the right, you see a fraction of the list of services with individual certificate trust settings for one host/machine. [Santosh] This is consistent with TA material in that constraints can be associated individually with the TAs. =20 And it is not about just TA:s. It is about: [Santosh] This is not relevant to the topic since it does not relate to TA management.=20 * My personal certificates * Trusted roots * Intermediary CAs=20 * Directly trusted or untrusted certificates * Etc, etc (See above) =20 The structure of this information is not globally agreed and generic. It is just how Microsoft have structured this in the Microsoft OS. [Santosh] This is precisely why we need TAF and TAMP. That is what requirements highlight. =20 One could call this a set of certificate trust policies that are dynamically managed and as you get closer to reality,=20 [Santosh] I would say a more accurate and complete characterization of these is the constraints on the trust anchors. =20 the border between roles, peoples and machines are getting more and more virtual and dynamic and it becomes harder and harder to reduce this into one generic, intrusive and centrally managed TA management protocol. [Santosh] One would think that as things become more virtual and dynamic, more you need the associated data with the TA and TAMP that can enforce the constraints on the TA and on the associated data. =20 Let me take a few examples from the requirements: * The assumed roles and authorization model * The assumption that there exist clearly identifiable TA stores. =20 The TA requirements are assuming a TA manager responsible for a TA store. [Santosh] While operationally this may be one manager managing the TA store, the requirements and TAMP should be oriented towards many to many. A TA manager can manage one or more TA in the TA store. A TA in a TA store can be managed by more that one manager. =20 The TA manager have authority over this TA store and have the power update it or replace it. This also assumes that each TA store is individually identifiable in the protocol itself. In my environment above, I first of all don't have any isolated identifiable TA stores. [Santosh] The TA need not be in a specific store, but it is always identifiable by some combination of name, SPKI, and SKID.=20 =20 Secondly I don't have a clearly defined TA manager that has the right to view and update this information on a local machine. [Santosh] The TA requirements and TAMP should clarify this with the constraints on the TAs.=20 =20 The applications or services that eventually are being affected by these trust policy updates will not have a clue about what information that was passed in any TA management protocol, or any IETF defined TA format file several layers and APIs below their existence.=20 [Santosh] Agree and the applications do not do this. This is part of TA management and not part of applications using the TA. =20 So any discussion about how applications should take into account specific path processing preferences provided by passing TA format information around, such as applying specific constraints rules, is just pretty theory without substance unless it is made part of standard RFC 5280 path processing and implemented in the APIs for path validation. [Santosh] The TA requirements in the area of path processing are consistent with 5280. 5280 specifically cites additional checks based on the information associated with TA. See section 6.2 of 5280. =20 In the environment I'm working with, I have no use for a transaction based TA management protocol based on the simplified relationship between a TA manager and a TA store.=20 [Santosh] That does not mean others do not need it. It also does not mean that the environment you cited above would not benefit from in-band re-key of the TA. =20 If I had one, I would not know how to use it. The only thing I would know how to use, is the TA format specification. That one I can use to pass TAs around in my existing trust policy framework. [Santosh] You as a person will need not be aware of it, just like many of nuances of PKI. The processing software will securely process the transactions and update the TAs. =20 I hope this was a useful clarification and my apology for passing graphics in a PKIX posting. I hope you can view it. [Santosh] The primary purpose of TA work is to permit in band, secure installation and rekey of TAs. Unless you propose an alternative mechanism to achieve this securely, the discourse you are having is not providing any critique of the TA work. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Kemp, David P. Sent: den 16 december 2008 18:12 To: ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Stefan, =20 Refining the requirements as a series of I-Ds until "the scope of the requirements is in harmony with problem space", then publishing as an RFC once the requirements have converged, certainly sounds like the best approach. =20 But you have not explained how "The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure." The requirements in either case are for managed devices/applications/services to receive configuration items from managers without those items being compromised in transit, yes? =20 * Are you claiming that adversaries have no access to a "common network and data sharing infrastructure" and therefore no protection is needed in the networked case? That is patently false for all networks of interest to the IETF. * Or that the protection mechanisms appropriate for managing networked platforms (Connection-oriented? MACs?) are different than those needed for managing disconnected platforms (Datagram/message-oriented? Signatures?) =20 Without understanding the nature of your objections it's hard to tell whether the scope of the requirements is already in harmony with the entire problem space or not. Your 4-quadrant slide from Minneapolis is not self-explanatory - I thought we had already disposed of the push-pull issue by determining that there is no security-relevant difference between posting to a repository from which a client may pull and pushing directly to the client. Therefore the TAM requirements already cover the left half of the space. If there is a single existing TAM requirement that precludes pull, or a single missing TAM requirement needed for pull, please provide an example. =20 And I need help understanding the difference you see between TA and TA Policy - if policy is "Host/App A will trust provider X for security critical firmware category Z", and the TA store of Host/App A has provider X's TA in the slot for firmware category Z, what is the difference, other than level of abstraction, between "determine current TAs in store" and "demonstrate compliance with policy"? Again, an example of a missing TAM requirement needed to satisfy the right half of your slide would go a long way toward understanding the scope issue. =20 Dave =20 =20 =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Tuesday, December 16, 2008 9:58 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Hi Santosh, =20 As I expect, I sense that we have a slightly different view of the generality of the proposed solution, but we seem to agree on the main issue: =20 The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols. If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc. =20 I would also prefer to see the requirements document as a living document as you suggest. I think that purpose is best served if the requirements document remains in draft form. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 15 december 2008 17:47 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Stefan, =20 See my responses in-line below.=20 =20 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Friday, December 12, 2008 7:25 AM To: ietf-pkix@imc.org Subject: TA requirements doc - do we need it? =20 After all discussions in Minneapolis and going back and looking at the current situation, I feel less and less convinced that we need to approve any TA requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may be a lot more harmful than beneficiary to us as an RFC. =20 I have two major reasons: =20 First, as I have argued and tried to explain with my slide in Minneapolis, there is no general overall approach to TA management in a complex IT environment. [Santosh] In a complex distributed environment that needs to scale across Enterprises, applying requisite security services to the payload provides a scalable, interoperable, extensible, and secure solution. =20 The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure. [Santosh] The requirements are generally the same in terms of security services. Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network. But, that solution may not be as scalable or open. =20 Secondly, the requirements didn't come first. These requirements were written with an existing protocol in mind. The lasting impression is therefore that the requirements document was written to match and support the original protocol, making it a tool to grandfather the original protocol into IETF. I'm not claiming that this is the case, but it remains to be my impression. [Santosh] If you look at many of the engineering endeavors we undertake, requirements are based on past experience, security vulnerabilities we have encountered, past systems, etc. I do not know of many successful efforts where requirements were developed in vacuum. In short, it is fair to say that the requirements and protocol benefited from each other and from past experiences with protocols and vulnerabilities. =20 The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols. If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc. =20 My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to reflect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before the scope is in harmony with the requirements. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C967E6.7A3B5275 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefan,

 

I for one do not = see how your e-mail relates to the TA requirements document or Dave’s = post.  See responses in-line.

 =

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stefan Santesson
Sent: Thursday, December = 18, 2008 11:47 AM
To: ietf-pkix@imc.org; = Kemp, David P.
Subject: FW: TA = requirements doc - do we need it?

I’m = resending this as my original mail got filtered due to exceeding pkix message size restrictions.

I have now replaced the = embedded picture with a URL to the screenshot.

 <= /p>

 <= /p>

Stefan Santesson

Senior = Program Manager

Windows Security, Standards

 <= /p>

From: = Stefan Santesson
Sent: den 17 december = 2008 11:43
To: 'Kemp, David P.'; ietf-pkix@imc.org
Subject: RE: TA = requirements doc - do we need it?

 

Dave,

 <= /p>

You raise valid points and I = partly try to avoid them because the answer is somewhat long and complex. Long and = complex answers are seldom successful in standards discussions = J

 <= /p>

Let me try to show my point = through a screenshot that helped explain this issue to at least one of the = original contributors to the proposed protocol. This is a screenshot of the = Microsoft certificate management snap-in:

 <= /p>

http://www.fiddler.nu= /pkix/certmgr_mmc.jpg

 <= /p>

What you see here is the = certificate trust policies in my laptop. It is not one root store and it is not just = about trust anchors. In my laptop I have a certificate trust management = snap-in for:

·         = Each host (local = machine)

·         = Each user = account

·         = Each service running on = any host

[Santosh] This is consistent with TA requirements = since TA requirements deal with each TA store.  In your case, the TA and = TAMP will be applied to three stores.

 <= /p>

In the Certificate snap-in = window to the right, you see a fraction of the list of services with individual = certificate trust settings for one host/machine.

[Santosh] This is consistent with TA material in that constraints can be associated individually with the = TAs.

 <= /p>

And it is not about just TA:s. = It is about:

[Santosh] This is not relevant to the topic since it = does not relate to TA management.

·         = My personal = certificates

·         = Trusted = roots

·         = Intermediary CAs =

·         = Directly trusted or = untrusted certificates

·         = Etc, etc (See = above)

 <= /p>

The structure of this = information is not globally agreed and generic. It is just how Microsoft have structured = this in the Microsoft OS.

[Santosh] This is precisely why we need TAF and TAMP. =  That is what requirements highlight.

 <= /p>

One could call this a set of = certificate trust policies that are dynamically managed and as you get closer to = reality,

[Santosh] I would say a more accurate and complete = characterization of these is the constraints on the trust = anchors.

 <= /p>

the border between roles, = peoples and machines are getting more and more virtual and dynamic and it becomes = harder and harder to reduce this into one generic, intrusive and centrally = managed TA management protocol.

[Santosh] One would think that as things become more = virtual and dynamic, more you need the associated data with the TA and TAMP that = can enforce the constraints on the TA and on the associated = data.

 <= /p>

Let me take a few examples from = the requirements:

·         = The assumed roles and = authorization model

·         = The assumption that = there exist clearly identifiable TA stores.

 <= /p>

The TA requirements are = assuming a TA manager responsible for a TA store.

[Santosh] While operationally this may be one manager managing the TA store, the requirements and TAMP should be oriented = towards many to many.  A TA manager can manage one or more TA in the TA = store.  A TA in a TA store can be managed by more that one = manager.

 <= /p>

 The TA manager have = authority over this TA store and have the power update it or replace it. This also = assumes that each TA store is individually identifiable in the protocol itself. = In my environment above, I first of all don’t have any isolated  identifiable TA stores.

[Santosh] The TA need not be in a specific store, but = it is always identifiable by some combination of name, SPKI, and SKID. =

 <= /p>

Secondly I don’t have a = clearly defined TA manager that has the right to view and update this = information on a local machine.

[Santosh] The TA requirements and TAMP should clarify = this with the constraints on the TAs.

 <= /p>

The applications or services = that eventually are being affected by these trust policy updates will not = have a clue about what information that was passed in any TA management = protocol, or any IETF defined TA format file several layers and APIs below their = existence.

[Santosh] Agree and the applications do not do this. =  This is part of TA management and not part of applications using the = TA.

 <= /p>

So any discussion about how = applications should take into account specific path processing preferences provided = by passing TA format information around, such as applying specific = constraints rules, is just pretty theory without substance unless it is made part of standard RFC 5280 path processing and implemented in the APIs for path validation.

[Santosh] The TA requirements in the area of path = processing are consistent with 5280.  5280 specifically cites additional = checks based on the  information associated with TA.  See section 6.2 of = 5280.

 <= /p>

In the environment I’m = working with, I have no use for a transaction based TA management protocol based = on the simplified relationship between a TA manager and a TA store. =

[Santosh] That does not mean others do not need it. =  It also does not mean that the environment you cited above would not = benefit from in-band re-key of the TA.

 <= /p>

If I had one, I would not know = how to use it.

The only thing I would know how = to use, is the TA format specification. That one I can use to pass TAs around in = my existing trust policy framework.

[Santosh] You as a person will need not be aware of = it, just like many of nuances of PKI.  The processing software will securely process the transactions and update the TAs.

 <= /p>

I hope this was a useful = clarification and my apology for passing graphics in a PKIX posting. I hope you can = view it.

[Santosh] The primary purpose of TA work is to permit = in band, secure installation and rekey of TAs.  Unless you propose an alternative mechanism to achieve this securely, the discourse you are = having is not providing any critique of the TA work.

 <= /p>

 <= /p>

Stefan Santesson

Senior = Program Manager

Windows Security, Standards

 <= /p>

From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Kemp, David P.
Sent: den 16 december = 2008 18:12
To: ietf-pkix@imc.org
Subject: RE: TA = requirements doc - do we need it?

 

Stefan,=

 <= /p>

Refining the requirements as a = series of I-Ds until “the scope of the requirements is in harmony with = problem space”, then publishing as an RFC once the requirements have = converged, certainly sounds like the best approach.

 <= /p>

But you have not explained how = “The requirements are radically different in a device oriented environment = with disconnected units compared with a centrally managed IT environment with = a common network and data sharing infrastructure.”  The requirements in = either case are for managed devices/applications/services to receive configuration items = from managers without those items being compromised in transit, = yes?

 <= /p>

·         = Are you claiming that = adversaries have no access to a “common network and data sharing infrastructure” and therefore no protection is needed in the = networked case?  That is patently false for all networks of interest to the = IETF.

·         = Or that the protection = mechanisms appropriate for managing networked platforms (Connection-oriented?  = MACs?) are different than those needed for managing disconnected platforms (Datagram/message-oriented? Signatures?)

 <= /p>

Without understanding the = nature of your objections it’s hard to tell whether the scope of the requirements = is already in harmony with the entire problem space or not.   = Your 4-quadrant slide from Minneapolis is not self-explanatory – I = thought we had already disposed of the push-pull issue by determining that there is = no security-relevant difference between posting to a repository from which = a client may pull and pushing directly to the client.  Therefore the = TAM requirements already cover the left half of the space.  If there is = a single existing TAM requirement that precludes pull, or a single missing = TAM requirement needed for pull, please provide an = example.

 <= /p>

And I need help understanding = the difference you see between TA and TA Policy – if policy is “Host/App A will trust provider X for security critical firmware = category Z”, and the TA store of Host/App A has provider X’s TA in = the slot for firmware category Z, what is the difference, other than level of abstraction, between “determine current TAs in store” and “demonstrate compliance with policy”?  Again, an = example of a missing TAM requirement needed to satisfy the right half of your slide = would go a long way toward understanding the scope = issue.

 <= /p>

Dave

 <= /p>

 <= /p>

 <= /p>

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stefan Santesson
Sent: Tuesday, December = 16, 2008 9:58 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: TA = requirements doc - do we need it?

 

Hi = Santosh,

 <= /p>

As I expect, I sense that we = have a slightly different view of the generality of the proposed solution, but = we seem to agree on the main issue:

 <= /p>

The question one have to ask is if these requirements, in the form of an = RFC, would serve us as a community if we encounter a problem with the proposed = protocol. I doubt that it will as it at most will strengthen the argument for those = having an interest to adopt the original protocol.

[Santosh] Having a requirements document that is a = living document, permits us to evaluate various solutions and protocols. =  If we do encounter a security problem, it should be useful to analyze where = the engineering process failed, e.g., did we not articulate some = requirement, did we not have sufficient detail for a requirement, did our analysis of = protocol meeting a requirement was flawed, etc.

 <= /p>

I would also prefer to see the requirements document as a living document as you suggest. I think that = purpose is best served if the requirements document remains in draft = form.

 <= /p>

 <= /p>

 <= /p>

Stefan Santesson

Senior = Program Manager

Windows Security, Standards

 <= /p>

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 15 december = 2008 17:47
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: TA = requirements doc - do we need it?

 

Stefan,

=

 

See my responses in-line below. =

 

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stefan Santesson
Sent: Friday, December = 12, 2008 7:25 AM
To: ietf-pkix@imc.org
Subject: TA requirements = doc - do we need it?

 

After all discussions in Minneapolis and going back and looking at the current situation, I feel less and = less convinced that we need to approve any TA requirements document as an = RFC. At least not in its current form.

I’m fine with having it around as a draft for reference, but I fear it may = be a lot more harmful than beneficiary to us as an = RFC.

 

I have two major reasons:

 

First, as I have argued and tried to explain with my slide in Minneapolis, there is no general = overall approach to TA management in a complex IT = environment.

[Santosh] In a complex distributed environment that = needs to scale across Enterprises, applying requisite security services to the = payload provides a scalable, interoperable, extensible, and secure = solution.

 

The requirements are radically different in a device oriented environment = with disconnected units compared with a centrally managed IT environment with = a common network and data sharing = infrastructure.

[Santosh] The requirements are generally the same in = terms of security services.  Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and = security services provided by the Enterprise network.  But, that solution may not be as scalable or = open.

 

Secondly, the requirements didn’t come first. These requirements were = written with an existing protocol in mind. The lasting impression is therefore that = the requirements document was written to match and support the original = protocol, making it a tool to grandfather the original protocol into IETF. = I’m not claiming that this is the case, but it remains to be my = impression.

[Santosh] If you look at many of the engineering = endeavors we undertake, requirements are based on past experience, security vulnerabilities we have encountered, past systems, etc.  I do not = know of many successful efforts where requirements were developed in vacuum. In = short, it is fair to say that the requirements and protocol benefited from each = other and from past experiences with protocols and = vulnerabilities.

 

The question one have to ask is if these requirements, in the form of an = RFC, would serve us as a community if we encounter a problem with the proposed = protocol. I doubt that it will as it at most will strengthen the argument for those = having an interest to adopt the original protocol.

[Santosh] Having a requirements document that is a = living document, permits us to evaluate various solutions and protocols. =  If we do encounter a security problem, it should be useful to analyze where = the engineering process failed, e.g., did we not articulate some = requirement, did we not have sufficient detail for a requirement, did our analysis of = protocol meeting a requirement was flawed, etc.

 

My proposal going forward is to do the = following:

-          In any case adjust the scope of the requirements document = to reflect the problem space the problem space it is designed = for.

-          Leave it as a draft, or at least not publish it as an RFC = before the scope is in harmony with the requirements.

 

 

 

Stefan Santesson

Senior = Program Manager

Windows Security, Standards

 

------_=_NextPart_001_01C967E6.7A3B5275-- From nney@aagtg.com Sat Dec 27 01:31:38 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD45C3A6A13 for ; Sat, 27 Dec 2008 01:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.579 X-Spam-Level: X-Spam-Status: No, score=-14.579 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lVGoTQyuNnM for ; Sat, 27 Dec 2008 01:31:38 -0800 (PST) Received: from alfa.com (unknown [122.167.56.195]) by core3.amsl.com (Postfix) with SMTP id B12993A6982 for ; Sat, 27 Dec 2008 01:31:34 -0800 (PST) To: Subject: Be healthier and live longer! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081227093135.B12993A6982@core3.amsl.com> Date: Sat, 27 Dec 2008 01:31:34 -0800 (PST)

If you are unable to see the message below, click here to view.

We specialize in selling the highest quality remedies. Visit our store now!

PLEASE DO NOT REPLY - This is being sent from an unattended mailbox.

Copyright © 2008 MaxGentleman, Inc. All rights reserved.
5 Trowbridge Drive, Bethel, CT 364870

You have received this message because you
opted in to receives MaxGentleman pecial offers via email.

You can unsubscribe here

 From mailbox@agririsk.com.au Sat Dec 27 09:04:18 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40AAC3A69A0 for ; Sat, 27 Dec 2008 09:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.4 X-Spam-Level: X-Spam-Status: No, score=-12.4 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4F+TwE5qAamW for ; Sat, 27 Dec 2008 09:04:18 -0800 (PST) Received: from 203-82-17-190.fibertel.com.ar (203-82-17-190.fibertel.com.ar [190.17.82.203]) by core3.amsl.com (Postfix) with SMTP id 08A093A691D for ; Sat, 27 Dec 2008 09:04:16 -0800 (PST) To: Subject: We need you here, now! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081227170417.08A093A691D@core3.amsl.com> Date: Sat, 27 Dec 2008 09:04:16 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Sun Dec 28 02:37:31 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70513A6894 for ; Sun, 28 Dec 2008 02:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev77iTSsUUMQ for ; Sun, 28 Dec 2008 02:37:30 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A11193A6358 for ; Sun, 28 Dec 2008 02:37:27 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSA6Ggv020552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 03:06:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBSA6G42020546; Sun, 28 Dec 2008 03:06:16 -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 smtp812.mail.ird.yahoo.com (smtp812.mail.ird.yahoo.com [217.146.188.72]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBSA5teu020340 for ; Sun, 28 Dec 2008 03:06:13 -0700 (MST) (envelope-from j.larmouth@btinternet.com) Received: (qmail 82718 invoked from network); 28 Dec 2008 10:05:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=H1hf/YBxnVdvsuhHfSDvf2GAbZlm4/WkF/SI/9WiPWKca7LOP0Qyhdb2VSe7i0CM4OJp3AdgsxsC0FYF/n+Q7ePDjLdeNzC7qW4kCrT0jjh6i+sLbbMq1mnrTCB+l5P40JUvYJUc29fbGiiyhWqIZJ2PUheymAhxCslw4XAe5Yo= ; Received: from unknown (HELO ?192.168.1.67?) (j.larmouth@217.44.207.2 with plain) by smtp812.mail.ird.yahoo.com with SMTP; 28 Dec 2008 10:05:54 -0000 X-YMail-OSG: kc7VFaEVM1nlVjqlZ7Cid.ujlJyL78D6T6.eF28dxzVps_NNxOT.RXIyRnxY5wmAM_6.DkCgBm_Pvkn_1G8BSprCsTk60nX6nPvOx6wiRSQUzD0oYsgjXX_6t52x1Sz3Up9mX8QW6VNrg8YtmCBFYgfa1D0mJjTsovT6FdYeYc_QdBSoKuX7ATaZ1XUzzKSXB7DhXrjCFUrH5REbVOq19eFZETY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49574F82.6010206@btinternet.com> Date: Sun, 28 Dec 2008 10:05:54 +0000 From: John Larmouth Reply-To: j.larmouth@btinternet.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Tom Gindin CC: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , ietf-pkix@imc.org, ietf-smime@imc.org, turners@ieca.com, asn1dev Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, There are several comments to be made. Forgive me for being verbose, but I think that in this area, brief replies can so easily be misunderstood. 1) First, forget the old stuff with identifiers (that is the old and correct term) for names on arcs of the OID tree. They were always (and still are) ASCII text, with an initial lower-case letter. Originally, they were expected to be unique (but were never carried in protocol, only in human value notation). Then later, it was recognised that company names changed (due to take-over, merger, etc, and that they wanted to use a different name for their arc (but not to change the numerical value). It was then (circa 1992) that they should NOT be regarded as unique, and that variants would be allowed (this brought the Standard into line with existing practice). About the same time, CCITT changed its name, and synonyms were formally assigned for some top-level arcs - but still restricted to ASCII characters, starting with a lower case letter. **Forget that stuff - it is historical! But, of course, still in use.** 2) Formally, an arc now has an always unique and unambiguous numerical value (as before); the old not-necessarily-unique-or-unambiguous identifiers (as before); but also has one or more Unicode labels (any - more-or-less - Unicode characters) that is required to be unambiguous from the superior node, but not necessarily unique (multiple Unicode labels are allowed on an arc to allow for different language variants). This was much discussed and fought over, but was eventually agreed as the best solution, but with some people still dissenting, and wanting only one (unique) Unicode label on an arc. 3) As part of this extension, it was recognised that the limitation to three top-level arcs (itu-t(0), iso(1), and joint-iso-itu-t(2)) was too limiting. Fortunately, arc 2 had already been used to provide allocations for other SDOs, and provided the x is less than 47, the OID {2, x} encodes into a single octet. We now restrict the allocation of arcs {2, x} to organisations that need the single octet encoding, but there are still quite a few x values left for future allocation. For encoding purposes, the top two levels are effectively a single set of top-level arcs, encoding into a single octet, provided x is less than 47 for arc 2, with similar restrictions on the arcs beneath arcs 0 and 1. 4) When Unicode labels were introduced, the concept of "long arcs" were included specifically for use at the top level. So it is now possible for long arcs to be allocated, with Unicode labels (but no numeric identifier) directly from the root to an arc beneath arc 2, and it is now common practice to allocate a long arc whenever an arc is allocated beneath arc 2 for any major organisation or SDO. 5) Finally, there was recognition of the problem of mapping a sequence of Unicode labels (representing a set of arcs) into a canonical list of integers for the numerical values of those arcs (in the case of a long arc, a Unicode label would map into - typically - two integers, for example 2.13). This gave rise to "work in progress" on an "OID resolution process". You will recognise that this is very much what the ubiquitous DNS service provides - a mapping from a set of names (domain names, little-endian order in the set) to a set of numbers (IP addresses, big-endian order in the set). DNS look-up is universally supported, and well-established, and the current hope/intent is to be able to do OID resolution using the DNS service, but discussions are still in progress on this. The alternative of an X.500 base for OID resolution has also been much discussed, and not abandonned. But deployment of X.500 look-up software is not as ubiquitous as DNS resolution software and databases. It may be that at the stardardisation level, we will see two resolution services documented - DNS-based and X.500-based. But it is too early to comment on that. 6) Now we come to IRI registration of the "oid" scheme, which is what the Internet Draft is concerned with. This is not essential to support these developments, but was a target from the start of the work. The sequence of Unicode labels on a path from the root to a node is undoubtedly, in plain English language terms, an internationalised resource identifier. So registration of an IRI "oid" scheme with IANA was always a target for the work. It was felt that the Standard should be in place before the registration was attempted. So we now have an Internet Draft under review with uri-review, in the hope that this can be "massaged" into a form that would allow us to proceed with the formal IANA registration of the "oid" IRI scheme in the not too distant future. I hope this has gone some way towards answering your questions. John L Tom Gindin wrote: > John: > > This draft is interesting and useful for some purposes, but I >don't see how it addresses the case where a high-level arc (beyond the >control of the development organization) is renamed. Since that's >precisely the case we are discussing here (although the change took place >quite a while ago and it's reasonable to expect people to adjust), it >doesn't actually seem to help us. Am I missing something? > Also, unless I have missed something, there are only three >top-level arcs defined for OID's and they all now have names. > > Tom Gindin > > > > >John Larmouth >Sent by: owner-ietf-pkix@mail.imc.org >12/22/2008 10:48 AM >Please respond to >j.larmouth@btinternet.com > > >To >Alfred � >cc >turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org >Subject >Re: consisten use of top-level oid branch name joint-iso-itu-t(2) > > > > > > >Alfred, > >The synonyms were introduced some time ago, and, indeed, the names are >non-normative, and may not even be unambiguous. Only the numbers matter >in an OID in an encoding. > >However, the recent introduction of Unicode labels, as normative and >unambigous names gives a new naming scheme to the (same) OID tree that >enables names (Unicode labels) to be used in machine communication if >desired. The ASN.1 type is called OID_IRI and provides for node >identification using Unicode labels. Unicode labels with names similar to >the old ASCII names have been assigned for many of the top-level arcs, and >more will be added over time. > >The OID_IRI type is related to (but not dependent on) the application for >an "oid" IRI scheme, but for consistency this is desired. See I-D >draft-larmouth-oid-iri-00. > >John L > >Alfred � wrote: >Folks / to whom it concerns, > >during recent reviews of active I-Ds containing ASN.1 related >to the X.500 framework, I found that a couple of these do not >consistently employ the revised name of the top-level OID branch > > joint-iso-itu-t(2) , > >but instead use the outdated/legacy name > > joint-iso-ccitt(2) . > >Some drafts use a mix of both names. > >I suggest that the modern version joint-iso-itu-t(2) be used >consistently within all new drafts / draft versions, unless >intentionally and explicitely for historical evidence reference >has to be made to the old name. > >Kind regards, > Alfred. > > > > > -- Prof John Larmouth Larmouth T&PDS Ltd (Training and Protocol Design Services Ltd) 1 Blueberry Road Bowdon j.larmouth@btinternet.com Altrincham Cheshire WA14 3LS England Tel: +44 161 928 1605 From owner-ietf-pkix@mail.imc.org Sun Dec 28 05:51:08 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8803A679F for ; Sun, 28 Dec 2008 05:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3ICJc1e+25b for ; Sun, 28 Dec 2008 05:51:08 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 948003A67FF for ; Sun, 28 Dec 2008 05:51:06 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDNnSx052283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 06:23:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBSDNneh052282; Sun, 28 Dec 2008 06:23:49 -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 robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDNbc3052156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 28 Dec 2008 06:23:48 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id mBSDNTHV015723; Sun, 28 Dec 2008 05:23:29 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Dec 2008 05:23:29 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C968EF.78855DA5" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: straw poll Date: Sun, 28 Dec 2008 05:22:58 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFC31@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: straw poll Thread-Index: AclfldXoaVlJ2Y9ATQKYgYj+/Dr6oAJWZBwc References: From: "Hallam-Baker, Phillip" To: "Stephen Kent" , X-OriginalArrivalTime: 28 Dec 2008 13:23:29.0403 (UTC) FILETIME=[790B5CB0:01C968EF] 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_01C968EF.78855DA5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1 yes 2 yes -----Original Message----- From: owner-ietf-pkix@mail.imc.org on behalf of Stephen Kent Sent: Tue 12/16/2008 9:29 AM To: ietf-pkix@imc.org Subject: straw poll =20 At a previous IETF meeting (Dublin) I agreed to conduct a straw poll=20 on adding a new WG item to address OCSP algorithm agility concerns,=20 after PHB sent a message indicating what status he envisioned for the=20 work. This action for both me and PHB fell through the cracks. At the=20 MSP IETF meeting PHB provided a briefing on the problems that he saw=20 re OCSP ambiguities re algorithm agility, and proposed a standards=20 track document to address these issues (see PHB's message of 12/2). So, we now have a concrete proposal (draft-hallambaker-ocspagility)=20 available for review. PHB would like to publish this and then merge=20 it into the OCSP document when it progresses from PROPOSED to DRAFT=20 (see his message of 12/2). Please send a message to the list by January 9th (allowing for=20 holiday outages) indicating whether 1. your support PKIX work in this area 2. you support adopting PHB's document as a starting point=20 for such work Thanks & Happy Hoplidays, Steve ------_=_NextPart_001_01C968EF.78855DA5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: straw poll

1 yes
2 yes

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org on behalf of Stephen Kent
Sent: Tue 12/16/2008 9:29 AM
To: ietf-pkix@imc.org
Subject: straw poll


At a previous IETF meeting (Dublin) I agreed to conduct a straw poll
on adding a new WG item to address OCSP algorithm agility concerns,
after PHB sent a message indicating what status he envisioned for = the
work. This action for both me and PHB fell through the cracks. At = the
MSP IETF meeting PHB provided a briefing on the problems that he saw
re OCSP ambiguities re algorithm agility, and proposed a standards
track document to address these issues (see PHB's message of 12/2).

So, we now have a concrete proposal (draft-hallambaker-ocspagility)
available for review. PHB would like to publish this and then merge
it into the OCSP document when it progresses from PROPOSED to DRAFT
(see his message of 12/2).

Please send a message to the list by January 9th (allowing for
holiday outages) indicating whether

        1. your support PKIX work in = this area
        2. you support adopting PHB's = document as a starting point
for such work

Thanks & Happy Hoplidays,

Steve

------_=_NextPart_001_01C968EF.78855DA5-- From owner-ietf-pkix@mail.imc.org Sun Dec 28 06:08:14 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69D63A6B11 for ; Sun, 28 Dec 2008 06:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.173 X-Spam-Level: X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oke8Kfp3RMHw for ; Sun, 28 Dec 2008 06:08:13 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 59A783A679F for ; Sun, 28 Dec 2008 06:08:12 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDgUl0064477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 06:42:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBSDgUVJ064476; Sun, 28 Dec 2008 06:42: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 robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDgTI8064469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 28 Dec 2008 06:42:30 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id mBSDgTBV016209; Sun, 28 Dec 2008 05:42:29 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Dec 2008 05:42:29 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C968F2.1F8A2075" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: New Version Notification for draft-hallambaker-ocspagility-02 Date: Sun, 28 Dec 2008 05:42:27 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFC32@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02 Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYUAbAkkKADYA7QBQ== References: <20081202183941.5A3003A6B4C@core3.amsl.com> <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> <9F11911AED01D24BAA1C2355723C3D321AB5BBBECD@EA-EXMSG-C332.europe.corp.microsoft.com> From: "Hallam-Baker, Phillip" To: "Stefan Santesson" , X-OriginalArrivalTime: 28 Dec 2008 13:42:29.0287 (UTC) FILETIME=[2077DB70:01C968F2] 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_01C968F2.1F8A2075 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1) On the issue of algorithm strength. The problem here is that the = accepted strength of an algorithm may change during the validity period = of the cert. So RSA 1024 might be perfectly acceptable for use in = conjunction with an OCSP validity check mechanism, provided that the = OCSP check is solid. We have for many years had the luxury of being able to avoid concerns = for crypto algorithm strength by simply adding more bits. Let that = continue for as long as possible, but if it does happen there are a lot = of edge cases that are likely to be thrown up during the transition that = are ugly. Another case that I have been looking at a lot recently is one where a = device that is incapable of doing public key crypto is being used in a = PKI. This is for SCADA type applications. Believe it or not it is = entirely possible to make this situation work with very low cost, low = power micro-controller devices. There was a lot of work done on this = early on in the development of PKI but the ideas were mostly dropped as = (1) workstation class machines became ubiquitous and the CPU overhead = issue became moot and (2) these approaches decrease the CPU overhead at = the periphery by concentrating it at the server, not a winning strategy = in 1985, but one that is entirely practical today. These are devices that have too little RAM to generate an RSA 2048 bit = signature, let alone an Ethernet packet. But they can do AES and there = are serious reasons for doing so. 2) I left RFC 5019 out of consideration entirely when writing the draft. = Looking over it again I think that it already makes the decisions for = us, all we need to do is to make reference to the existing decision = here, perhaps adding an explanation of the reason why. Cache busting is = already discouraged in 5019. Use of request extensions is already a SHOULD NOT in RFC 5019, so this = would be carried over here. Applications SHOULD NOT be using the = algorithm selector extension unless there is a compatibility driven = reason not to. I think we should state this and give the reason (cache = busting) as the whole point of a SHOULD NOT is that there is a potential = balance. If an application absolutely needs to specify the extension to = function then that takes priority over cache busting. -----Original Message----- From: owner-ietf-pkix@mail.imc.org on behalf of Stefan Santesson Sent: Thu 12/11/2008 4:21 AM To: Hallam-Baker, Phillip; ietf-pkix@imc.org Subject: RE: New Version Notification for = draft-hallambaker-ocspagility-02=20 =20 Phil, =20 I have a few comments on the draft: =20 This is more a nit, but I don't think the following is a compelling = argument, strong enough to be mentioned: o An implementation may intentionally wish to guard against the possibility of a compromise resulting from a signature algorithm compromise by employing two separate encryption algorithms. =20 If an implementation is securing two co-dependent messages with two = different algorithms, where breaking one of them successfully = compromises the system, then you have increased your risk of compromise = rather than reducing it. =20 Further, I would like to see some explicit text, explaining that this = approach is not applicable, or at least should not be used in = combination with implementations of 5019. Section 4.2. do state that the server can pre-produce several responses = to the same request signed with different algorithms, but what I'm most = concerned with is that clients including the extension in the request, = in combination with RFC 5019 implementations may mess up http caching. = Http caching is an important aspect of achieving scalability for LW = OCSP.=20 =20 I would prefer to entirely discourage the use of this client extension = with RFC 5019, but at least discuss the issue in the draft to make = implementers aware of the problem. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Hallam-Baker, Phillip Sent: den 2 december 2008 20:01 To: ietf-pkix@imc.org Subject: FW: New Version Notification for = draft-hallambaker-ocspagility-02=20 =20 =20 As promised at the meeting, here is an update to the OCSP agility draft. With the WG and chair's permission I will resubmit as a WG draft. The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented. So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC. And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it. So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM To: Hallam-Baker, Phillip Subject: New Version Notification for draft-hallambaker-ocspagility-02 A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository. Filename: draft-hallambaker-ocspagility Revision: 02 Title: OCSP Algorithm Agility Creation_date: 2008-12-02 WG ID: Independent Submission Number_of_pages: 8 Abstract: The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. = =20 The IETF Secretariat. ------_=_NextPart_001_01C968F2.1F8A2075 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: New Version Notification for draft-hallambaker-ocspagility-02 =

1) On the issue of algorithm strength. The problem = here is that the accepted strength of an algorithm may change during the = validity period of the cert. So RSA 1024 might be perfectly acceptable = for use in conjunction with an OCSP validity check mechanism, provided = that the OCSP check is solid.

We have for many years had the luxury of being able to avoid concerns = for crypto algorithm strength by simply adding more bits. Let that = continue for as long as possible, but if it does happen there are a lot = of edge cases that are likely to be thrown up during the transition that = are ugly.

Another case that I have been looking at a lot recently is one where a = device that is incapable of doing public key crypto is being used in a = PKI. This is for SCADA type applications. Believe it or not it is = entirely possible to make this situation work with very low cost, low = power micro-controller devices. There was a lot of work done on this = early on in the development of PKI but the ideas were mostly dropped as = (1) workstation class machines became ubiquitous and the CPU overhead = issue became moot and (2) these approaches decrease the CPU overhead at = the periphery by concentrating it at the server, not a winning strategy = in 1985, but one that is entirely practical today.

These are devices that have too little RAM to generate an RSA 2048 bit = signature, let alone an Ethernet packet. But they can do AES and there = are serious reasons for doing so.


2) I left RFC 5019 out of consideration entirely when writing the draft. = Looking over it again I think that it already makes the decisions for = us, all we need to do is to make reference to the existing decision = here, perhaps adding an explanation of the reason why. Cache busting is = already discouraged in 5019.

Use of request extensions is already a SHOULD NOT in RFC 5019, so this = would be carried over here. Applications SHOULD NOT be using the = algorithm selector extension unless there is a compatibility driven = reason not to. I think we should state this and give the reason (cache = busting) as the whole point of a SHOULD NOT is that there is a potential = balance. If an application absolutely needs to specify the extension to = function then that takes priority over cache busting.




-----Original Message-----
From: owner-ietf-pkix@mail.imc.org on behalf of Stefan Santesson
Sent: Thu 12/11/2008 4:21 AM
To: Hallam-Baker, Phillip; ietf-pkix@imc.org
Subject: RE: New Version Notification for = draft-hallambaker-ocspagility-02

Phil,



I have a few comments on the draft:



This is more a nit, but I don't think the following is a compelling = argument, strong enough to be mentioned:

   o  An implementation may intentionally wish to guard = against the

      possibility of a compromise resulting = from a signature algorithm

      compromise by employing two separate = encryption algorithms.



If an implementation is securing two co-dependent messages with two = different algorithms, where breaking one of them successfully = compromises the system, then you have increased your risk of compromise = rather than reducing it.



Further, I would like to see some explicit text, explaining that this = approach is not applicable, or at least should not be used in = combination with implementations of 5019.

Section 4.2. do state that the server can pre-produce several responses = to the same request signed with different algorithms, but what I'm most = concerned with is that clients including the extension in the request, = in combination with RFC 5019 implementations may mess up http caching. = Http caching is an important aspect of achieving scalability for LW = OCSP.



I would prefer to entirely discourage the use of this client extension = with RFC 5019, but at least discuss the issue in the draft to make = implementers aware of the problem.





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 Hallam-Baker, Phillip
Sent: den 2 december 2008 20:01
To: ietf-pkix@imc.org
Subject: FW: New Version Notification for = draft-hallambaker-ocspagility-02





As promised at the meeting, here is an update to the OCSP agility = draft.

With the WG and chair's permission I will resubmit as a WG draft.


The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented.


So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC.

And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it.


So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in.


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for = draft-hallambaker-ocspagility-02


A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository.

Filename:        = draft-hallambaker-ocspagility
Revision:        02
Title:           OCSP = Algorithm Agility
Creation_date:   2008-12-02
WG ID:           = Independent Submission
Number_of_pages: 8

Abstract:
The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.
            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =        


The IETF Secretariat.

------_=_NextPart_001_01C968F2.1F8A2075-- From nikolaooguyette@ahm.com Mon Dec 29 07:43:38 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6223A680A for ; Mon, 29 Dec 2008 07:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.991 X-Spam-Level: X-Spam-Status: No, score=-94.991 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-dZvw-4KjRs for ; Mon, 29 Dec 2008 07:43:37 -0800 (PST) Received: from akzonobel.com (unknown [94.179.44.12]) by core3.amsl.com (Postfix) with SMTP id 40E043A6802 for ; Mon, 29 Dec 2008 07:43:25 -0800 (PST) To: Subject: Returned mail: Over quota From: MIME-Version: 1.0 Importance: High Content-Type: base64 Message-Id: <20081229154330.40E043A6802@core3.amsl.com> Date: Mon, 29 Dec 2008 07:43:25 -0800 (PST) IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPEhUTUw+PEhFQUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMiI+DQo8L0hFQUQ+DQo8Qk9EWT48dHI+PHRkPg0KPGRpdiBhbGlnbj1jZW50ZXI+IDxhIGhyZWY9Imh0dHA6Ly90cmFkZW90aGVyLmNvbS8iIHRhcmdldD0iX2JsYW5rIj4NCjxpbWcgc3JjPSJodHRwOi8vdHJhZGVvdGhlci5jb20vYWR2MS5qcGciIGJvcmRlcj0wIGFsdD0iQ2xpY2sgSGVyZSEiPjwvYT48L2Rpdj4NCjwvdGQ+PC90cj48dHI+PHRkIGNsYXNzPUVDX2xlZ2FsPjxzdHJvbmc+QWJvdXQgdGhpcyBtYWlsaW5nOiA8L3N0cm9uZz48YnI+DQpZb3UgYXJlIHJlY2VpdmluZyB0aGlzIGUtbWFpbCBiZWNhdXNlIHlvdSBzdWJzY3JpYmVkIHRvIE1TTiBGZWF0dXJlZCBPZmZlcnMuIA0KTWljcm9zb2Z0IHJlc3BlY3RzIHlvdXIgcHJpdmFjeS4gSWYgeW91IGRvIG5vdCB3aXNoIHRvIHJlY2VpdmUgdGhpcyBNU04gRmVhdHVyZWQgDQpPZmZlcnMgZS1tYWlsLCBwbGVhc2UgY2xpY2sgdGhlICJVbnN1YnNjcmliZSIgbGluayBiZWxvdy4gVGhpcyB3aWxsIG5vdCB1bnN1YnNjcmliZSANCnlvdSBmcm9tIGUtbWFpbCBjb21tdW5pY2F0aW9ucyBmcm9tIHRoaXJkLXBhcnR5IGFkdmVydGlzZXJzIHRoYXQgbWF5IGFwcGVhciBpbiBNU04gDQpGZWF0dXJlIE 9mZmVycy4gVGhpcyBzaGFsbCBub3QgY29uc3RpdHV0ZSBhbiBvZmZlciBieSBNU04uIE1TTiBzaGFsbCBub3QgYmUgDQpyZXNwb25zaWJsZSBvciBsaWFibGUgZm9yIHRoZSBhZHZlcnRpc2VycycgY29udGVudCBub3IgYW55IG9mIHRoZSBnb29kcyBvciBzZXJ2aWNlDQogYWR2ZXJ0aXNlZC4gUHJpY2VzIGFuZCBpdGVtIGF2YWlsYWJpbGl0eSBzdWJqZWN0IHRvIGNoYW5nZSB3aXRob3V0IG5vdGljZS48YnI+PGJyPg0KQzIwMDggTWljcm9zb2Z0IHwgPGEgaHJlZj0iaHR0cDovL3RyYWRlb3RoZXIuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPlVuc3Vic2NyaWJlPC9hPiB8IA0KPGEgaHJlZj0iaHR0cDovL3RyYWRlb3RoZXIuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPk1vcmUgTmV3c2xldHRlcnM8L2E+IHwgDQo8YSBocmVmPSJodHRwOi8vdHJhZGVvdGhlci5jb20vIiB0YXJnZXQ9Il9ibGFuayI+UHJpdmFjeTwvYT48YnI+PGJyPg0KICAgICAgICAgIE1pY3Jvc29mdCBDb3Jwb3JhdGlvbiwgT25lIE1pY3Jvc29mdCBXYXksIFJlZG1vbmQsIFdBIDk4MDUyDQo8L3RkPjwvdHI+PC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT48L2Rpdj48L2Rpdj48L2Rpdj48L0JPRFk+PC9IVE1MPnsvQkFTRTY0X0VOQ09ERUR9DQoNCgAAAAAAAAAAAAAAAA== From owner-ietf-pkix@mail.imc.org Tue Dec 30 08:39:14 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983223A6A65 for ; Tue, 30 Dec 2008 08:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.115 X-Spam-Level: X-Spam-Status: No, score=-102.115 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXdYYUBNglOE for ; Tue, 30 Dec 2008 08:39:13 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 493C33A6A59 for ; Tue, 30 Dec 2008 08:39:13 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUG5kww018631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 09:05:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUG5jD9018622; Tue, 30 Dec 2008 09:05: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUG5YRs018576 for ; Tue, 30 Dec 2008 09:05:44 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812301605.mBUG5YRs018576@balder-227.proper.com> Received: (qmail 4826 invoked by uid 0); 30 Dec 2008 16:05:29 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 16:05:29 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 11:05:28 -0500 To: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org From: Russ Housley Subject: Further MD5 breaks: Creating a rogue CA certificate 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: http://www.win.tue.nl/hashclash/rogue-ca/ MD5 considered harmful today Creating a rogue CA certificate December 30, 2008 Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol. Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 "collision". Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats. From owner-ietf-pkix@mail.imc.org Tue Dec 30 10:58:53 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719683A69A0 for ; Tue, 30 Dec 2008 10:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=0.706, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqAMedbGtnXj for ; Tue, 30 Dec 2008 10:58:53 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E97813A6925 for ; Tue, 30 Dec 2008 10:58:52 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUIY5KW027105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 11:34:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUIY5K6027104; Tue, 30 Dec 2008 11:34: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 chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUIXrB8027081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 11:34:04 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUIXkTS014008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:33:47 -0500 (EST) Date: Tue, 30 Dec 2008 13:33:46 -0500 From: Jeffrey Hutzelman To: Russ Housley , ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org cc: jhutz@cmu.edu Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate Message-ID: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> In-Reply-To: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, December 30, 2008 11:05:28 AM -0500 Russ Housley wrote: > http://www.win.tue.nl/hashclash/rogue-ca/ > > MD5 considered harmful today > Creating a rogue CA certificate > > December 30, 2008 > > Alexander Sotirov, Marc Stevens, > Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de > Weger > > We have identified a vulnerability in the Internet Public Key > Infrastructure (PKI) used to issue digital certificates for secure > websites. As a proof of concept we executed a practical attack scenario > and successfully created a rogue Certification Authority (CA) certificate > trusted by all common web browsers. This certificate allows us to > impersonate any website on the Internet, including banking and e-commerce > sites secured using the HTTPS protocol. > > Our attack takes advantage of a weakness in the MD5 cryptographic hash > function that allows the construction of different messages with the same > MD5 hash. This is known as an MD5 "collision". Previous work on MD5 > collisions between 2004 and 2007 showed that the use of this hash > function in digital signatures can lead to theoretical attack scenarios. > Our current work proves that at least one attack scenario can be > exploited in practice, thus exposing the security infrastructure of the > web to realistic threats. This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. -- Jeff From majdhussein@all4j.com Tue Dec 30 11:31:49 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C06C3A6835 for ; Tue, 30 Dec 2008 11:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.923 X-Spam-Level: X-Spam-Status: No, score=-21.923 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l68tWQ5Ixnb for ; Tue, 30 Dec 2008 11:31:48 -0800 (PST) Received: from CBL217-132-147-93.bb.netvision.net.il (CBL217-132-147-93.bb.netvision.net.il [217.132.147.93]) by core3.amsl.com (Postfix) with SMTP id D84503A67CC for ; Tue, 30 Dec 2008 11:31:44 -0800 (PST) To: Subject: We need you here, now! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081230193145.D84503A67CC@core3.amsl.com> Date: Tue, 30 Dec 2008 11:31:44 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-pkix@mail.imc.org Tue Dec 30 12:32:19 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4AB63A685D for ; Tue, 30 Dec 2008 12:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu1bYVlwZN6f for ; Tue, 30 Dec 2008 12:32:18 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5809D3A67EF for ; Tue, 30 Dec 2008 12:32:18 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUK78Ju034463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:07:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUK78Cg034461; Tue, 30 Dec 2008 13:07:08 -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 romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUK6sZq034429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:07:08 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DFF4550822; Tue, 30 Dec 2008 12:23:11 -0800 (PST) Date: Tue, 30 Dec 2008 12:23:11 -0800 From: Eric Rescorla To: Jeffrey Hutzelman Cc: Russ Housley , ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081230202311.DFF4550822@romeo.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Tue, 30 Dec 2008 13:33:46 -0500, Jeffrey Hutzelman wrote: > > --On Tuesday, December 30, 2008 11:05:28 AM -0500 Russ Housley > wrote: > > > http://www.win.tue.nl/hashclash/rogue-ca/ > > > > MD5 considered harmful today > > Creating a rogue CA certificate > > > > December 30, 2008 > > > > Alexander Sotirov, Marc Stevens, > > Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de > > Weger > > > > We have identified a vulnerability in the Internet Public Key > > Infrastructure (PKI) used to issue digital certificates for secure > > websites. As a proof of concept we executed a practical attack scenario > > and successfully created a rogue Certification Authority (CA) certificate > > trusted by all common web browsers. This certificate allows us to > > impersonate any website on the Internet, including banking and e-commerce > > sites secured using the HTTPS protocol. > > > > Our attack takes advantage of a weakness in the MD5 cryptographic hash > > function that allows the construction of different messages with the same > > MD5 hash. This is known as an MD5 "collision". Previous work on MD5 > > collisions between 2004 and 2007 showed that the use of this hash > > function in digital signatures can lead to theoretical attack scenarios. > > Our current work proves that at least one attack scenario can be > > exploited in practice, thus exposing the security infrastructure of the > > web to realistic threats. > > > This is a practical application of an approach that I remember being > brought up during discussions about MD5 at a saag meeting some time ago. I > also recall someone mentioning at the time that many/most CA's were already > issuing certificates with random rather than sequential serial numbers, > which would have thwarted this particular attack. Yep. Would that they all were. FWIW, here is my writeup of this issue, targeted towards a broader community: http://www.educatedguesswork.org/2008/12/understanding_the_sotirov_et_a.html -Ekr From owner-ietf-pkix@mail.imc.org Tue Dec 30 12:36:29 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D3CC3A68C0 for ; Tue, 30 Dec 2008 12:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.113 X-Spam-Level: X-Spam-Status: No, score=-102.113 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dU+74TDI06ni for ; Tue, 30 Dec 2008 12:36:29 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 917E43A685D for ; Tue, 30 Dec 2008 12:36:28 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUKGsOx035034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:16:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUKGs2c035033; Tue, 30 Dec 2008 13:16:54 -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 [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUKGhdl035004 for ; Tue, 30 Dec 2008 13:16:53 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812302016.mBUKGhdl035004@balder-227.proper.com> Received: (qmail 14731 invoked by uid 0); 30 Dec 2008 20:16:37 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 20:16:37 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 15:10:45 -0500 To: Jeffrey Hutzelman From: Russ Housley Subject: Re: Further MD5 breaks: Creating a rogue CA certificate Cc: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org In-Reply-To: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> 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: Jeff: >>http://www.win.tue.nl/hashclash/rogue-ca/ >> >>MD5 considered harmful today >>Creating a rogue CA certificate >> >>December 30, 2008 >> >>Alexander Sotirov, Marc Stevens, >>Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de >>Weger >> >>We have identified a vulnerability in the Internet Public Key >>Infrastructure (PKI) used to issue digital certificates for secure >>websites. As a proof of concept we executed a practical attack scenario >>and successfully created a rogue Certification Authority (CA) certificate >>trusted by all common web browsers. This certificate allows us to >>impersonate any website on the Internet, including banking and e-commerce >>sites secured using the HTTPS protocol. >> >>Our attack takes advantage of a weakness in the MD5 cryptographic hash >>function that allows the construction of different messages with the same >>MD5 hash. This is known as an MD5 "collision". Previous work on MD5 >>collisions between 2004 and 2007 showed that the use of this hash >>function in digital signatures can lead to theoretical attack scenarios. >>Our current work proves that at least one attack scenario can be >>exploited in practice, thus exposing the security infrastructure of the >>web to realistic threats. > > >This is a practical application of an approach that I remember being >brought up during discussions about MD5 at a saag meeting some time >ago. I also recall someone mentioning at the time that many/most >CA's were already issuing certificates with random rather than >sequential serial numbers, which would have thwarted this particular attack. RFC 5280 does not include this advice. It is sound advice that was discussed in PKIX and other venues. Perhaps a BCP is in order. Russ From owner-ietf-pkix@mail.imc.org Tue Dec 30 13:13:37 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F5328C269 for ; Tue, 30 Dec 2008 13:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcvHQjQiUeYw for ; Tue, 30 Dec 2008 13:13:37 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8F9E328C20C for ; Tue, 30 Dec 2008 13:13:36 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUKrcEw036778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:53:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUKrcNS036777; Tue, 30 Dec 2008 13:53:38 -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 [10.20.30.158] ([207.62.247.66]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUKrXOU036766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:53:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> Date: Tue, 30 Dec 2008 12:53:06 -0800 To: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org From: Paul Hoffman Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: >This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. Your recollection may be off. I believe I was the person who brought up the serial number hack at the mic, and I'm pretty sure I said "some", not "many" (and certainly not "most"!). When I looked at a handful of popular CAs earlier this week, I only found a few who are using randomization in their serial numbers. Regardless of that, the authors of the MD5 paper are correct: trust anchors signed with MD5 are highly questionable as of today (well, actually, since they published their last paper). Hopefully, the maintainers of the popular trust anchor repositories (Microsoft, Mozilla, etc.) will yank out the trust anchors signed with MD5 (and MD2!) as soon as possible. At 3:10 PM -0500 12/30/08, Russ Housley wrote: >RFC 5280 does not include this advice. It is sound advice that was discussed in PKIX and other venues. Perhaps a BCP is in order. Man, that is really stretching the definition of "best". For one, it is only needed in signatures that use known-attackable hash functions. A "best practice" in that case is to use a better hash function in the signature. Also, it relies on the ability of the software using the random number to be sure that the result is a positive integer in ASN.1, which seems overly optimistic. If the IETF feels that adding randomization to signatures is important, we should define randomized signature functions. We could start with NIST Draft SP 800-106 (). However, I think that doing so is sending the wrong message: we should instead be encouraging the use of non-broken hash functions. --Paul Hoffman, Director --VPN Consortium From owner-ietf-pkix@mail.imc.org Tue Dec 30 13:41:47 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A183A6403 for ; Tue, 30 Dec 2008 13:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.926 X-Spam-Level: X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[AWL=0.673, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lhp9w6CKowB for ; Tue, 30 Dec 2008 13:41:46 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 49B753A6A46 for ; Tue, 30 Dec 2008 13:41:46 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULIest037910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:18:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULIefq037903; Tue, 30 Dec 2008 14:18: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 mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULIShF037889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 14:18:39 -0700 (MST) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout5.cac.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id mBULIO3h014517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Dec 2008 13:18:24 -0800 X-Auth-Received: from D-140-142-21-194.dhcp4.washington.edu (D-140-142-21-194.dhcp4.washington.edu [140.142.21.194]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id mBULIOpq023005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Dec 2008 13:18:24 -0800 Date: Tue, 30 Dec 2008 13:17:50 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: Paul Hoffman cc: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: Message-ID: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.5.0.356843, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2008.12.30.210424 X-Uwash-Spam: Gauge=IIIIIII, Probability=8%, Report='BODY_SIZE_1000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_700_799 0, FROM_EDU_TLD 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Regardless of that, the authors of the MD5 paper are correct: trust > anchors signed with MD5 are highly questionable as of today (well, > actually, since they published their last paper). Hopefully, the > maintainers of the popular trust anchor repositories (Microsoft, > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5 signatures", which is what I as an amateur take away from a quick scan of the material. Obviously MD5 is suspect in various ways, but does this new work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" From owner-ietf-pkix@mail.imc.org Tue Dec 30 14:00:45 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5FB928C283 for ; Tue, 30 Dec 2008 14:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaW6i0n3iNdj for ; Tue, 30 Dec 2008 14:00:45 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id AB62128C271 for ; Tue, 30 Dec 2008 14:00:44 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULdmOx038675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:39:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULdmIX038674; Tue, 30 Dec 2008 14:39:48 -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 prospect.joyent.us (prospect.joyent.us [8.12.36.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULdaRA038639; Tue, 30 Dec 2008 14:39:46 -0700 (MST) (envelope-from pmhesse@geminisecurity.com) Received: from PeterVistaSP1 (static-68-163-72-26.res.east.verizon.net [68.163.72.26]) by prospect.joyent.us (Postfix) with ESMTPSA id 14CD01ECC7; Tue, 30 Dec 2008 21:39:34 +0000 (GMT) From: "Peter Hesse" To: "'RL 'Bob' Morgan'" , "'Paul Hoffman'" Cc: , , , References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> In-Reply-To: Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Tue, 30 Dec 2008 16:39:34 -0500 Message-ID: <08bb01c96ac7$1cd5a750$5680f5f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclqxboXk3PuIMY0SLuDtNKXm7F2qQAAEKtA Content-Language: en-us Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ceasing the issuance of certificates with MD5 used in the signature doesn't solve the problem of the certificates that have already been issued and are still out there, any number of which may be rogue. Replacing, or marking as untrusted all root certificates which have any current valid (i.e. non-expired, non-revoked) certificates with MD5 used in the signature could have tremendous undesirable impact and be an untenable solution. The right tool for the job is a client-side solution to fail validation of any signature which uses MD5, especially certificate signatures. I will not hold my breath for such a solution. --Peter ---------------------------------------------------------------- Peter Hesse pmhesse@geminisecurity.com http://securitymusings.com http://geminisecurity.com -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of RL 'Bob' Morgan Sent: Tuesday, December 30, 2008 4:18 PM To: Paul Hoffman Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate > Regardless of that, the authors of the MD5 paper are correct: trust > anchors signed with MD5 are highly questionable as of today (well, > actually, since they published their last paper). Hopefully, the > maintainers of the popular trust anchor repositories (Microsoft, > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5 signatures", which is what I as an amateur take away from a quick scan of the material. Obviously MD5 is suspect in various ways, but does this new work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" From owner-ietf-pkix@mail.imc.org Tue Dec 30 14:19:43 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0C128C2F6 for ; Tue, 30 Dec 2008 14:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.111 X-Spam-Level: X-Spam-Status: No, score=-102.111 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W7sYuZcwYiO for ; Tue, 30 Dec 2008 14:19:43 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 986D428C2E6 for ; Tue, 30 Dec 2008 14:19:42 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM2L0u039828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:02:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM2L1x039826; Tue, 30 Dec 2008 15:02:21 -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 [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUM2J2p039808 for ; Tue, 30 Dec 2008 15:02:20 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812302202.mBUM2J2p039808@balder-227.proper.com> Received: (qmail 12655 invoked by uid 0); 30 Dec 2008 22:02:12 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:02:12 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 16:33:19 -0500 To: Paul Hoffman From: Russ Housley Subject: Re: Further MD5 breaks: Creating a rogue CA certificate Cc: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org In-Reply-To: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> 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: Paul: >If the IETF feels that adding randomization to signatures is >important, we should define randomized signature functions. We could >start with NIST Draft SP 800-106 >(). >However, I think that doing so is sending the wrong message: we >should instead be encouraging the use of non-broken hash functions. This is a very different thing than a BCP that the recommends that the certificate serial number include some random bits. Russ From owner-ietf-pkix@mail.imc.org Tue Dec 30 14:25:22 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23C0128C2F8 for ; Tue, 30 Dec 2008 14:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAkG0dx18jh2 for ; Tue, 30 Dec 2008 14:25:22 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 72ED428C271 for ; Tue, 30 Dec 2008 14:25:15 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM6bm0039982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:06:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM6bFA039981; Tue, 30 Dec 2008 15:06: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-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM6P1i039959; Tue, 30 Dec 2008 15:06:36 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBUM6OPb025827; Tue, 30 Dec 2008 17:06:25 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBUM6Ocb025814; Tue, 30 Dec 2008 17:06:24 -0500 Received: from [129.83.200.2] (129.83.200.2) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 30 Dec 2008 17:06:24 -0500 Message-ID: <495A9B44.1010201@mitre.org> Date: Tue, 30 Dec 2008 16:05:56 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Eric Rescorla CC: Paul Hoffman , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "cfrg@irtf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> In-Reply-To: <20081230213934.C219450822@romeo.rtfm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000706050700070408070900" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms000706050700070408070900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > At Tue, 30 Dec 2008 12:53:06 -0800, > Paul Hoffman wrote: >> Your recollection may be off. I believe I was the person who brought >> up the serial number hack at the mic, and I'm pretty sure I said >> "some", not "many" (and certainly not "most"!). When I looked at a >> handful of popular CAs earlier this week, I only found a few who are >> using randomization in their serial numbers. > I don't know whether many or most do it. IMO everyone should. Randomizing serial numbers has implications for OCSP operations, particularly those that use presigned responses in order to optimize performance. Why presign? Because for a large network with varying levels of support, it may be easier to move around sets of pre-produced responses to distributed keyless OCSP responders than to guarantee connectivity to a keyed OCSP service. Why presign batches rather than individual responses? Because for a large PKI the response pre-production time can exceed the CRL update frequency. -- Tim --------------ms000706050700070408070900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzAyMjA1NTZaMCMGCSqGSIb3DQEJBDEWBBQ4RbejFRP0hZy6Vjhh795xqhnGfDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgELzHlPR7X3MOFLP5ZcY1mbMXJyVuu8D6m/7NK0eZrsmu7YMbLzv7t5txCiQ 6CHlVuWg0WcLwT24dUazLur+cNII/+p5MiS42K0qScSEoWc7uJDgKtmol40n1brGU7mVvLVm oNAh3ZUvQV/gAJ3VbnN61DL/Eld+TlsdEjGJ8SirAAAAAAAA --------------ms000706050700070408070900-- From owner-ietf-pkix@mail.imc.org Tue Dec 30 14:39:17 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57BEA28C2E6 for ; Tue, 30 Dec 2008 14:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.107 X-Spam-Level: X-Spam-Status: No, score=-102.107 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtYpjQzqlMXe for ; Tue, 30 Dec 2008 14:39:16 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3DA7928C274 for ; Tue, 30 Dec 2008 14:39:15 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMH83B040617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:17:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMH8pE040614; Tue, 30 Dec 2008 15:17:08 -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 [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUMH7XD040595 for ; Tue, 30 Dec 2008 15:17:07 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812302217.mBUMH7XD040595@balder-227.proper.com> Received: (qmail 20400 invoked by uid 0); 30 Dec 2008 22:17:00 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:17:00 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 17:12:02 -0500 To: "RL 'Bob' Morgan" , Paul Hoffman From: Russ Housley Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate Cc: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org In-Reply-To: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> 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: >>Regardless of that, the authors of the MD5 paper are correct: trust >>anchors signed with MD5 are highly questionable as of today (well, >>actually, since they published their last paper). Hopefully, the >>maintainers of the popular trust anchor repositories (Microsoft, >>Mozilla, etc.) will yank out the trust anchors signed with MD5 (and >>MD2!) as soon as possible. > >This is a different claim than "CAs should stop issuing certs with >MD5 signatures", which is what I as an amateur take away from a >quick scan of the material. Obviously MD5 is suspect in various >ways, but does this new work lead to the conclusion that MD5-signed >roots are untrustworthy today? We recommended a migration (walk, don't run) away from MD2, MD4, and SHA-1 toward SHA-256 a few years ago. MD2 and MD4 generate 128 bit hash values; even without the attacks, these are getting to be too small. SHA-1 has been shown to be weaker than its design goal, and the 160 bit hash value will be getting too short in a couple of years. We recommended SHA-256 while fully recognizing that NIST was starting a hash competition, and that we might recommend the winner of that competition as the successor to SHA-256. I still strongly encourage the migration to SHA-256. The use of the random bits in the serial number are insurance against similar problems being found in other hash functions. This insurance will hopefully provide time to migrate to another hash function when cryptanalysis begins to show flaws in any future hash function. Russ From owner-ietf-pkix@mail.imc.org Tue Dec 30 14:44:16 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C148C28C2F6 for ; Tue, 30 Dec 2008 14:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.104 X-Spam-Level: X-Spam-Status: No, score=-102.104 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPmcVTk7ZXdJ for ; Tue, 30 Dec 2008 14:44:16 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C0E5A28C2F8 for ; Tue, 30 Dec 2008 14:44:11 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMNsTb040975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:23:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMNsm7040974; Tue, 30 Dec 2008 15:23:54 -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 [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUMNqIJ040944 for ; Tue, 30 Dec 2008 15:23:52 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812302223.mBUMNqIJ040944@balder-227.proper.com> Received: (qmail 24294 invoked by uid 0); 30 Dec 2008 22:23:45 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:23:45 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 17:23:33 -0500 To: Eric Rescorla From: Russ Housley Subject: Re: Further MD5 breaks: Creating a rogue CA certificate Cc: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org In-Reply-To: <20081230223500.48BD350822@romeo.rtfm.com> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.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: >I'm not sure I understand the issue here, but >they don't actually have to be totally randomized. You could use a >PRF so they were predictable to the CA. That works. This works too: the serial number could be composed of two parts, where the most significant bits are a counter and the least significant bits are randomly generated. Russ From owner-ietf-pkix@mail.imc.org Tue Dec 30 14:50:17 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE11628C2F6 for ; Tue, 30 Dec 2008 14:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8pM---JZMSx for ; Tue, 30 Dec 2008 14:50:17 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 87C383A67F0 for ; Tue, 30 Dec 2008 14:50:16 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMVYbx041608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:31:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMVYcL041606; Tue, 30 Dec 2008 15:31:34 -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 mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMVLtP041578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:31:32 -0700 (MST) (envelope-from Scott.Rea@Dartmouth.edu) Received: from newdasher.Dartmouth.EDU (newdasher.dartmouth.edu [129.170.208.30]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id mBULqtr9007948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 17:30:44 -0500 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from c-65-96-146-181.hsd1.nh.comcast.net [65.96.146.181] by newdasher.Dartmouth.EDU (Mac) via SMTP for id <138927721>; 30 Dec 2008 17:30:43 -0500 Message-ID: <495AA0F6.7060604@Dartmouth.edu> Date: Tue, 30 Dec 2008 17:30:14 -0500 From: Scott Rea User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Russ Housley CC: "RL 'Bob' Morgan" , Paul Hoffman , ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302217.mBUMH7XD040595@balder-227.proper.com> In-Reply-To: <200812302217.mBUMH7XD040595@balder-227.proper.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU X-MailScanner-SpamCheck: spam, SpamAssassin on mailhub2 (score=1.651, required 1, BAYES_00 -2.60, BLITZ_DISCLAIMER 0.05, HELO_DYNAMIC_IPADDR 4.20) X-MailScanner-SpamScore: s X-MailScanner-From: scott.rea@dartmouth.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley wrote: > > >>> Regardless of that, the authors of the MD5 paper are correct: trust >>> anchors signed with MD5 are highly questionable as of today (well, >>> actually, since they published their last paper). Hopefully, the >>> maintainers of the popular trust anchor repositories (Microsoft, >>> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and >>> MD2!) as soon as possible. >> >> This is a different claim than "CAs should stop issuing certs with >> MD5 signatures", which is what I as an amateur take away from a quick >> scan of the material. Obviously MD5 is suspect in various ways, but >> does this new work lead to the conclusion that MD5-signed roots are >> untrustworthy today? > > We recommended a migration (walk, don't run) away from MD2, MD4, and > SHA-1 toward SHA-256 a few years ago. MD2 and MD4 generate 128 bit > hash values; even without the attacks, these are getting to be too > small. SHA-1 has been shown to be weaker than its design goal, and > the 160 bit hash value will be getting too short in a couple of > years. We recommended SHA-256 while fully recognizing that NIST was > starting a hash competition, and that we might recommend the winner of > that competition as the successor to SHA-256. > > I still strongly encourage the migration to SHA-256. > > The use of the random bits in the serial number are insurance against > similar problems being found in other hash functions. This insurance > will hopefully provide time to migrate to another hash function when > cryptanalysis begins to show flaws in any future hash function. > > Russ But one of the things that has kept the brakes on migration has been support in clients for SHA256 - the largest vendor of client machines only just recently added SHA256 to its XP platform (if you upgrade to SP3). I keep running into folks using OpenSSL as their crypto base and they haven't updated to a distribution that supports SHA256. I think it will take a little more time before it becomes the default... -- Scott Rea From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:07:14 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0893A693D for ; Tue, 30 Dec 2008 15:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFARWZI0buXp for ; Tue, 30 Dec 2008 15:07:13 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DA1F93A6835 for ; Tue, 30 Dec 2008 15:07:12 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM1XIL039746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:01:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM1Xvo039744; Tue, 30 Dec 2008 15:01: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 chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM1Lqj039727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 15:01:32 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from atlantis-home.pc.cs.cmu.edu (173-101-98-177.pools.spcsdns.net [173.101.98.177]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUM1Cht017220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 17:01:14 -0500 (EST) Date: Tue, 30 Dec 2008 17:01:12 -0500 From: Jeffrey Hutzelman To: Eric Rescorla , Paul Hoffman cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate Message-ID: <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> In-Reply-To: <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, December 30, 2008 01:39:34 PM -0800 Eric Rescorla wrote: > At Tue, 30 Dec 2008 12:53:06 -0800, > Paul Hoffman wrote: >> >> At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: >> > This is a practical application of an approach that I remember being >> > brought up during discussions about MD5 at a saag meeting some time >> > ago. I also recall someone mentioning at the time that many/most CA's >> > were already issuing certificates with random rather than sequential >> > serial numbers, which would have thwarted this particular attack. >> >> Your recollection may be off. I believe I was the person who brought >> up the serial number hack at the mic, and I'm pretty sure I said >> "some", not "many" (and certainly not "most"!). When I looked at a >> handful of popular CAs earlier this week, I only found a few who are >> using randomization in their serial numbers. > > So it's in my deck from SAAG at IETF 62. > > http://www.ietf.org/proceedings/05mar/slides/saag-3.pdf > > I don't know whether many or most do it. IMO everyone should. I just checked my records, and shortly after that IETF, our internal CA started issuing certificates with SHA-1 signatures and randomized serial numbers, as a direct result of that discussion. > >> > RFC 5280 does not include this advice. It is sound advice that was >> > discussed in PKIX and other venues. Perhaps a BCP is in order. >> >> Man, that is really stretching the definition of "best". >> >> For one, it is only needed in signatures that use known-attackable >> hash functions. A "best practice" in that case is to use a better >> hash function in the signature. Also, it relies on the ability of >> the software using the random number to be sure that the result is a >> positive integer in ASN.1, which seems overly optimistic. On the contrary, IMHO best practice is to take every reasonable measure to reduce the likelyhood of an attack. In my book, that means both using a better hash function _and_ using randomized serial numbers, since the latter clearly helps when the hash is broken, and hash functions may become broken over time, and before you realize it. >> If the IETF feels that adding randomization to signatures is >> important, we should define randomized signature functions. I think that's a very good idea. However... > I certainly agree we should be encouraging the use of non-broken hash > functions. However, randomizing the SN seems like very cheap backward > compatible insurance against the fact that that's going to take a long > time. "what he said". Incidentally, the recently reported problems with CBC mode ciphers in SSH have gotten me to thinking that in some situations, a single REQUIRED algorithm isn't enough, because if something goes wrong and you have to abandon that algorithm in a hurry, operators may be in a position of having to choose between seriously compromising either security or interoperability. In the case of usages like certificates where no live negotiation is possible and implementations may have to interoperate over a long period of time, I believe additional care is necessary. For example, I think it would be a good idea to define a composite signature function which uses more than one hash computed independently. This would likely make some attacks harder, but more importantly, it means that as long as at least one of the underlying hashes is strong enough, the signature is still usable. -- Jeff From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:19:18 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969EA28C22D for ; Tue, 30 Dec 2008 15:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.6 X-Spam-Level: X-Spam-Status: No, score=-5.6 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arvJ1nW8oww3 for ; Tue, 30 Dec 2008 15:19:18 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8B96E28C20A for ; Tue, 30 Dec 2008 15:19:17 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUN0k3L042872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:00:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUN0kvd042870; Tue, 30 Dec 2008 16:00:46 -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 brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUN0Z99042846; Tue, 30 Dec 2008 16:00:46 -0700 (MST) (envelope-from Nicolas.Williams@sun.com) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBUN0ZCC027191; Tue, 30 Dec 2008 23:00:35 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBUN0ZOK044664; Tue, 30 Dec 2008 16:00:35 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBUMb2LL003035; Tue, 30 Dec 2008 16:37:02 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBUMaCUE003034; Tue, 30 Dec 2008 16:36:12 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 30 Dec 2008 16:36:12 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Eric Rescorla , Paul Hoffman , ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate Message-ID: <20081230223612.GN1872@Sun.COM> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Dec 30, 2008 at 05:01:12PM -0500, Jeffrey Hutzelman wrote: > Incidentally, the recently reported problems with CBC mode ciphers in SSH > have gotten me to thinking that in some situations, a single REQUIRED > algorithm isn't enough, because if something goes wrong and you have to > abandon that algorithm in a hurry, operators may be in a position of having > to choose between seriously compromising either security or > interoperability. +1 But note that in the case of the SSH CBC mode ciphers the vulnerable ciphers had only the cipher mode in common. The SSH vulnerability, in any case, doesn't stem from the use of CBC, but is more general, and well could have been worse, but let's ignore that for this argument. So in the SSH case one would have liked to have seen two or more REQUIRED to implement ciphers with very distinct properties. Say 3DES in CBC mode, AES in counter mode, and arcfour. Applying a principle of redundancy in RTI algorithms to symmetric key protocols is fairly simple. Applying such a principle to PKI seems rather more difficult -- it's not just hash algorithms, but pk algorithms too. Your example was to require not just the implementation of multiple hash (but not pk) algorithms, but to require the *use* of those. That makes sense to me, but it's not quite the same principle being applied to PKI as to SSH. Nico -- From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:21:47 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4249F28C303 for ; Tue, 30 Dec 2008 15:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbfRwPDWH2nJ for ; Tue, 30 Dec 2008 15:21:46 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 312E528C20A for ; Tue, 30 Dec 2008 15:21:45 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMcbFf041941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:38:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMcaGr041938; Tue, 30 Dec 2008 15: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 romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMcaVV041923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:38:36 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 0E36550822; Tue, 30 Dec 2008 14:54:54 -0800 (PST) Date: Tue, 30 Dec 2008 14:54:53 -0800 From: Eric Rescorla To: "Timothy J. Miller" Cc: Eric Rescorla , Paul Hoffman , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "cfrg@irtf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: <20081230223500.48BD350822@romeo.rtfm.com> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081230225454.0E36550822@romeo.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here's Tim Callan from VEriSign posting about this: https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php -Ekr y From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:21:53 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FBA28C303 for ; Tue, 30 Dec 2008 15:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijBVlPfSQvJz for ; Tue, 30 Dec 2008 15:21:52 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EAE1D28C20A for ; Tue, 30 Dec 2008 15:21:51 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULNIAn038040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:23:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULNIdv038039; Tue, 30 Dec 2008 14:23:18 -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 romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULNH61038023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:23:17 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id C219450822; Tue, 30 Dec 2008 13:39:34 -0800 (PST) Date: Tue, 30 Dec 2008 13:39:34 -0800 From: Eric Rescorla To: Paul Hoffman Cc: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081230213934.C219450822@romeo.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Tue, 30 Dec 2008 12:53:06 -0800, Paul Hoffman wrote: > > At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: > >This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. > > Your recollection may be off. I believe I was the person who brought > up the serial number hack at the mic, and I'm pretty sure I said > "some", not "many" (and certainly not "most"!). When I looked at a > handful of popular CAs earlier this week, I only found a few who are > using randomization in their serial numbers. So it's in my deck from SAAG at IETF 62. http://www.ietf.org/proceedings/05mar/slides/saag-3.pdf I don't know whether many or most do it. IMO everyone should. > >RFC 5280 does not include this advice. It is sound advice that was > >discussed in PKIX and other venues. Perhaps a BCP is in order. > > Man, that is really stretching the definition of "best". > > For one, it is only needed in signatures that use known-attackable > hash functions. A "best practice" in that case is to use a better > hash function in the signature. Also, it relies on the ability of > the software using the random number to be sure that the result is a > positive integer in ASN.1, which seems overly optimistic. > > If the IETF feels that adding randomization to signatures is > important, we should define randomized signature functions. We could > start with NIST Draft SP 800-106 > (). However, > I think that doing so is sending the wrong message: we should > instead be encouraging the use of non-broken hash functions. I certainly agree we should be encouraging the use of non-broken hash functions. However, randomizing the SN seems like very cheap backward compatible insurance against the fact that that's going to take a long time. -Ekr From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:21:58 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF32D28C303 for ; Tue, 30 Dec 2008 15:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrE+qXM9T8sX for ; Tue, 30 Dec 2008 15:21:58 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 999ED28C20A for ; Tue, 30 Dec 2008 15:21:57 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMNs7f040972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:23:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMNsLw040969; Tue, 30 Dec 2008 15:23:54 -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 rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.246]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMNgDm040924; Tue, 30 Dec 2008 15:23:53 -0700 (MST) (envelope-from blaker@gmail.com) Received: by rv-out-0708.google.com with SMTP id c5so5433808rvf.34 for ; Tue, 30 Dec 2008 14:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SOjf1T9xI3MBJb+v+mg2/Dsw2wPmsmYSixQ9iXiIRcA=; b=jLU/hS5jNIbna5Zku6U+axs1KV2KLYrQTa+hHCR/6kqe207G+tXYDsVPGgTJk0qupA RJNQu5TWWaiQBDzj6O/tCx4phcCEZunboOs+VpniRcdvoADq3XwUZ1mzr83/ud5RY47H 8qdO/4Hzhx0900vj2XpDMmQJIaimvjR/nKQhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fNUP7Tab+VzvZPlIZjRGwRfpijhSl5e12WjdlWGoMMTJAQLgGCUXaBh6fPtA/Uex4x SNJMbQy/susUqr3OwRpb03aw46n6l9v8rUN4Gu8YA/jVRFYUFah7cKKcTeg4ApodNWJq EylztJzNVq1Niy3z4I7ag/Xk1/BlZfI+34MHY= Received: by 10.140.226.14 with SMTP id y14mr7464473rvg.59.1230675822107; Tue, 30 Dec 2008 14:23:42 -0800 (PST) Received: by 10.141.169.13 with HTTP; Tue, 30 Dec 2008 14:23:42 -0800 (PST) Message-ID: <985966520812301423g7f9b5b33o9219f27216b17d18@mail.gmail.com> Date: Tue, 30 Dec 2008 14:23:42 -0800 From: "Blake Ramsdell" To: "Timothy J. Miller" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate Cc: "Eric Rescorla" , "Paul Hoffman" , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "cfrg@irtf.org" In-Reply-To: <495A9B44.1010201@mitre.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Dec 30, 2008 at 2:05 PM, Timothy J. Miller wrote: > Randomizing serial numbers has implications for OCSP operations, > particularly those that use presigned responses in order to optimize > performance. It seems that the disruption caused by modifying serial number generation for existing CAs is pretty high. Would an easier solution be to either a) make the validity period vary slightly (in the documented attack, the notBefore was always a fixed interval from the submission time, and making this vary in a period of just a few minutes would have thwarted it, if I'm understanding correctly), or b) the CA sticks some random junk in the subject DN (not an MPEG of a cat, but maybe OU=sf9fj3 [some base64 PRNG data]). Blake -- Blake Ramsdell | http://www.blakeramsdell.com From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:22:13 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3900F28C305 for ; Tue, 30 Dec 2008 15:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJZ-NApnEJNu for ; Tue, 30 Dec 2008 15:22:12 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9C38A28C20A for ; Tue, 30 Dec 2008 15:22:11 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM2X1N039872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:02:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM2WJQ039871; Tue, 30 Dec 2008 15:02: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 dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM2UYN039852; Tue, 30 Dec 2008 15:02:31 -0700 (MST) (envelope-from ynir@checkpoint.com) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E614A29C002; Wed, 31 Dec 2008 00:02:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7F09C29C001; Wed, 31 Dec 2008 00:02:08 +0200 (IST) X-CheckPoint: {495A98AD-10000-88241DC2-7B6} Received: from [172.31.21.158] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBUM27fE029359; Wed, 31 Dec 2008 00:02:08 +0200 (IST) Cc: Paul Hoffman , ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org Message-Id: <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> From: Yoav Nir To: "RL 'Bob' Morgan" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Wed, 31 Dec 2008 00:02:07 +0200 References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Regardless of that, the authors of the MD5 paper are correct: trust >> anchors signed with MD5 are highly questionable as of today (well, >> actually, since they published their last paper). Hopefully, the >> maintainers of the popular trust anchor repositories (Microsoft, >> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and >> MD2!) as soon as possible. > > This is a different claim than "CAs should stop issuing certs with > MD5 signatures", which is what I as an amateur take away from a > quick scan of the material. Obviously MD5 is suspect in various > ways, but does this new work lead to the conclusion that MD5-signed > roots are untrustworthy today? > Replacing a root is a much bigger deal then changing signing > practices. > > - RL "Bob" CAs should have stopped issuing certs with MD5 signatures 4 years ago, when the first practical attacks on MD5 were published. Now it would be more correct to say that "relying parties should treat as invalid any certificate chain that contains an MD5 (or MD2, MD4) signature" Since in the HTTPS context the relying parties are the browsers, it falls to the vendors (if Microsoft leads, everyone will follow) to, as Paul said, yank the trust anchors. It should be noted, though, that yanking the trust anchors is not enough. You really should change the relying party to not recognize this algorithm. Otherwise, it's perfectly valid for a CA whose certificate is signed with SHA1 to sign an intermediate CA certificate with MD5 (although they usually don't do that, I hope) Email secured by Check Point From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:28:45 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A87A28C312 for ; Tue, 30 Dec 2008 15:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqWQk3k+JQvB for ; Tue, 30 Dec 2008 15:28:44 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1B85328C311 for ; Tue, 30 Dec 2008 15:28:41 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUN7SiP043207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:07:28 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUN7SjU043206; Tue, 30 Dec 2008 16:07:28 -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.14.2/8.14.2) with ESMTP id mBUN7GLB043196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Dec 2008 16:07:27 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBUN7AO5030377 for ; Tue, 30 Dec 2008 18:07:10 -0500 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id mBUN6xjD020656 for ; Tue, 30 Dec 2008 18:06:59 -0500 Message-ID: <495AA992.5040504@nist.gov> Date: Tue, 30 Dec 2008 18:06:58 -0500 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 To: pkix Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> In-Reply-To: <495A9B44.1010201@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: 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: I have heard that using non-sequential serial numbers can cause problems for OCSP responders that pre-produce responses as well. There is an alternative, however, for CAs that do not wish to use randomized serial numbers. Randomness can be included in the validity dates. The described attack relied on the ability to guess both the serial number and validity dates of the certificate that would be issued. The authors were able to find a CA that always used validity dates of notBefore = T (where T was the time of issuance) and notAfter = T + 1 year, where T was always 6 seconds after the time that the certificate request was submitted. Suppose, however, that the CA selected two random numbers R1 and R2 and then used notBefore = T + R1 seconds and notAfter = T + R2 seconds + (normal validity period [e.g., 1 year]). If R1 and R2 were each chosen from the range [-15 ... 16] then the attacker would only have a 1 in 1024 chance of guessing the validity dates. If R1 and R2 were each chosen from the range [-511 ... 512] then the attacker would only have a 1 in 1,048,576 chance of guessing the validity dates. Since notBefore and notAfter would be modified by at most a few minutes, the randomization should not create any practical problems for users. Of course, randomizing the serial number is a more effective means of counteracting the attack since the serial number could be made a random 159-bit number and since the serial number appears earlier in the certificate, but incorporating some randomness into the validity dates would be a second best choice if the serial number cannot be randomized. Dave Timothy J. Miller wrote: > Eric Rescorla wrote: >> At Tue, 30 Dec 2008 12:53:06 -0800, >> Paul Hoffman wrote: >>> Your recollection may be off. I believe I was the person who brought >>> up the serial number hack at the mic, and I'm pretty sure I said >>> "some", not "many" (and certainly not "most"!). When I looked at a >>> handful of popular CAs earlier this week, I only found a few who are >>> using randomization in their serial numbers. >> I don't know whether many or most do it. IMO everyone should. > > Randomizing serial numbers has implications for OCSP operations, > particularly those that use presigned responses in order to optimize > performance. > > Why presign? Because for a large network with varying levels of > support, it may be easier to move around sets of pre-produced > responses to distributed keyless OCSP responders than to guarantee > connectivity to a keyed OCSP service. > > Why presign batches rather than individual responses? Because for a > large PKI the response pre-production time can exceed the CRL update > frequency. > > -- Tim From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:35:47 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1836A28C2F6 for ; Tue, 30 Dec 2008 15:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ei7V4vo2yQA for ; Tue, 30 Dec 2008 15:35:46 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0C87B28C20A for ; Tue, 30 Dec 2008 15:35:45 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMIheK040690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:18:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMIhrR040686; Tue, 30 Dec 2008 15:18:43 -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 romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMIg9v040670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:18:42 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 48BD350822; Tue, 30 Dec 2008 14:35:00 -0800 (PST) Date: Tue, 30 Dec 2008 14:34:59 -0800 From: Eric Rescorla To: "Timothy J. Miller" Cc: Eric Rescorla , Paul Hoffman , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "cfrg@irtf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: <495A9B44.1010201@mitre.org> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081230223500.48BD350822@romeo.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Tue, 30 Dec 2008 16:05:56 -0600, Timothy J. Miller wrote: > > [1 ] > Eric Rescorla wrote: > > At Tue, 30 Dec 2008 12:53:06 -0800, > > Paul Hoffman wrote: > > >> Your recollection may be off. I believe I was the person who brought > >> up the serial number hack at the mic, and I'm pretty sure I said > >> "some", not "many" (and certainly not "most"!). When I looked at a > >> handful of popular CAs earlier this week, I only found a few who are > >> using randomization in their serial numbers. > > > I don't know whether many or most do it. IMO everyone should. > > Randomizing serial numbers has implications for OCSP operations, > particularly those that use presigned responses in order to optimize > performance. > > Why presign? Because for a large network with varying levels of > support, it may be easier to move around sets of pre-produced responses > to distributed keyless OCSP responders than to guarantee connectivity to > a keyed OCSP service. > > Why presign batches rather than individual responses? Because for a > large PKI the response pre-production time can exceed the CRL update > frequency. I'm not sure I understand the issue here, but they don't actually have to be totally randomized. You could use a PRF so they were predictable to the CA. -Ekr From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:36:19 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94D128C2F6 for ; Tue, 30 Dec 2008 15:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBGsSvtVgqRh for ; Tue, 30 Dec 2008 15:36:19 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B365F28C20A for ; Tue, 30 Dec 2008 15:36:18 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNF3jE043682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:15:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNF3Ok043680; Tue, 30 Dec 2008 16:15:03 -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 chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNF1RH043670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 16:15:02 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUNEtxp017907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:14:56 -0500 (EST) Date: Tue, 30 Dec 2008 18:14:55 -0500 From: Jeffrey Hutzelman To: Nicolas Williams cc: Eric Rescorla , Paul Hoffman , ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate Message-ID: <8A695EE544FEFDB0EDE3DD1A@atlantis.pc.cs.cmu.edu> In-Reply-To: <20081230223612.GN1872@Sun.COM> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> <20081230223612.GN1872@Sun.COM> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, December 30, 2008 04:36:12 PM -0600 Nicolas Williams wrote: > Applying a principle of redundancy in RTI algorithms to symmetric key > protocols is fairly simple. Applying such a principle to PKI seems > rather more difficult -- it's not just hash algorithms, but pk > algorithms too. Your example was to require not just the implementation > of multiple hash (but not pk) algorithms, but to require the *use* of > those. That makes sense to me, but it's not quite the same principle > being applied to PKI as to SSH. Correct. I'm suggesting that in the case of PKI, merely having two RTI algorithms wouldn't be sufficient; at least for long-term certificates you need to actually sign using two algorithms in order to get the interoperability benefit. Validating using both isn't necessary, though it does have a benefit, in that no code or configuration changes are required to continue to be safe as long as at least one is good enough. IMHO, one of the biggest problems in the current PKI standards is that there is no ability to future-proof certificates by generating signatures with multiple algorithms. The result is that you can't start signing with a new algorithm until everyone understands it, and you can't stop accepting an old algorithm without either reissuing lots of certificates with a new one or waiting for them to expire. This means movement is very slow and we are unable to abandon a broken algorithm in a hurry. The former is poor; the latter is a disaster waiting to happen. -- Jeff From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:46:40 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2973A6919 for ; Tue, 30 Dec 2008 15:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igR14Zklpdpb for ; Tue, 30 Dec 2008 15:46:40 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 59FBE28C325 for ; Tue, 30 Dec 2008 15:46:16 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNNTwV044009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:23:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNNT9h044005; Tue, 30 Dec 2008 16:23:29 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNNG8c043975 for ; Tue, 30 Dec 2008 16:23:27 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 29788 invoked from network); 30 Dec 2008 23:23:40 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:23:40 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:23:40 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Tue, 30 Dec 2008 18:23:15 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclqwLMO5Ztz1GDZSjWorp7026VgfQAFJdBA References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu><9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> From: "Santosh Chokhani" To: "Paul Hoffman" , , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul, I disagree in the matter of trust anchors, assuming you mean self-signed ones. Signatures on Trust anchors are inherently useless from security viewpoint. Thus, they could be signed using even MD4. Their security relies on protecting them from unauthorized modification. -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Paul Hoffman Sent: Tuesday, December 30, 2008 3:53 PM To: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: >This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. Your recollection may be off. I believe I was the person who brought up the serial number hack at the mic, and I'm pretty sure I said "some", not "many" (and certainly not "most"!). When I looked at a handful of popular CAs earlier this week, I only found a few who are using randomization in their serial numbers. Regardless of that, the authors of the MD5 paper are correct: trust anchors signed with MD5 are highly questionable as of today (well, actually, since they published their last paper). Hopefully, the maintainers of the popular trust anchor repositories (Microsoft, Mozilla, etc.) will yank out the trust anchors signed with MD5 (and MD2!) as soon as possible. At 3:10 PM -0500 12/30/08, Russ Housley wrote: >RFC 5280 does not include this advice. It is sound advice that was discussed in PKIX and other venues. Perhaps a BCP is in order. Man, that is really stretching the definition of "best". For one, it is only needed in signatures that use known-attackable hash functions. A "best practice" in that case is to use a better hash function in the signature. Also, it relies on the ability of the software using the random number to be sure that the result is a positive integer in ASN.1, which seems overly optimistic. If the IETF feels that adding randomization to signatures is important, we should define randomized signature functions. We could start with NIST Draft SP 800-106 (). However, I think that doing so is sending the wrong message: we should instead be encouraging the use of non-broken hash functions. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:48:53 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189F93A68CF for ; Tue, 30 Dec 2008 15:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7y-3t-HHCpC for ; Tue, 30 Dec 2008 15:48:52 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id AE37D3A68C9 for ; Tue, 30 Dec 2008 15:48:51 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNSAXN044294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:28:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNSAvI044292; Tue, 30 Dec 2008 16:28: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNS8eB044271 for ; Tue, 30 Dec 2008 16:28:08 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 29840 invoked from network); 30 Dec 2008 23:28:32 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:28:32 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:28:32 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Tue, 30 Dec 2008 18:28:07 -0500 Message-ID: In-Reply-To: <08bb01c96ac7$1cd5a750$5680f5f0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclqxboXk3PuIMY0SLuDtNKXm7F2qQAAEKtAAAQJILA= References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <08bb01c96ac7$1cd5a750$5680f5f0$@com> From: "Santosh Chokhani" To: "Peter Hesse" , "RL 'Bob' Morgan" , "Paul Hoffman" Cc: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Roots need not be replaced since they need protected migration and storage. Since the attack is computing pre-image, I suspect that past MD5 certificates are safe until the attack was devised. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Peter Hesse Sent: Tuesday, December 30, 2008 4:40 PM To: 'RL 'Bob' Morgan'; 'Paul Hoffman' Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Ceasing the issuance of certificates with MD5 used in the signature doesn't solve the problem of the certificates that have already been issued and are still out there, any number of which may be rogue. Replacing, or marking as untrusted all root certificates which have any current valid (i.e. non-expired, non-revoked) certificates with MD5 used in the signature could have tremendous undesirable impact and be an untenable solution. The right tool for the job is a client-side solution to fail validation of any signature which uses MD5, especially certificate signatures. I will not hold my breath for such a solution. --Peter=20 ---------------------------------------------------------------- Peter Hesse pmhesse@geminisecurity.com http://securitymusings.com http://geminisecurity.com -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of RL 'Bob' Morgan Sent: Tuesday, December 30, 2008 4:18 PM To: Paul Hoffman Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate > Regardless of that, the authors of the MD5 paper are correct: trust=20 > anchors signed with MD5 are highly questionable as of today (well,=20 > actually, since they published their last paper). Hopefully, the=20 > maintainers of the popular trust anchor repositories (Microsoft,=20 > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and=20 > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5=20 signatures", which is what I as an amateur take away from a quick scan of=20 the material. Obviously MD5 is suspect in various ways, but does this new=20 work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:52:17 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F07203A687E for ; Tue, 30 Dec 2008 15:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.341 X-Spam-Level: X-Spam-Status: No, score=-1.341 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASUvToi6sWxL for ; Tue, 30 Dec 2008 15:52:17 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C1BCA3A67C0 for ; Tue, 30 Dec 2008 15:52:16 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNUGpd044381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:30:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNUGKr044380; Tue, 30 Dec 2008 16:30:16 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNUEbL044362 for ; Tue, 30 Dec 2008 16:30:15 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 29881 invoked from network); 30 Dec 2008 23:30:38 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:30:38 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:30:38 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Tue, 30 Dec 2008 18:30:13 -0500 Message-ID: In-Reply-To: <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclqylLTk2EWxsuuQ1C7rI9Jvd/JmAADAnAQ References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu><9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> From: "Santosh Chokhani" To: "Yoav Nir" , "RL 'Bob' Morgan" Cc: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Let us leave the trust anchors alone. Your challenge of protecting trust anchors does not change even if you use SHA 512 or next generation hash function yet to be determined. -----Original Message----- From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, December 30, 2008 5:02 PM To: RL 'Bob' Morgan Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate >> Regardless of that, the authors of the MD5 paper are correct: trust =20 >> anchors signed with MD5 are highly questionable as of today (well, =20 >> actually, since they published their last paper). Hopefully, the =20 >> maintainers of the popular trust anchor repositories (Microsoft, =20 >> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and =20 >> MD2!) as soon as possible. > > This is a different claim than "CAs should stop issuing certs with =20 > MD5 signatures", which is what I as an amateur take away from a =20 > quick scan of the material. Obviously MD5 is suspect in various =20 > ways, but does this new work lead to the conclusion that MD5-signed =20 > roots are untrustworthy today? > Replacing a root is a much bigger deal then changing signing =20 > practices. > > - RL "Bob" CAs should have stopped issuing certs with MD5 signatures 4 years ago, =20 when the first practical attacks on MD5 were published. Now it would be more correct to say that "relying parties should treat =20 as invalid any certificate chain that contains an MD5 (or MD2, MD4) =20 signature" Since in the HTTPS context the relying parties are the browsers, it =20 falls to the vendors (if Microsoft leads, everyone will follow) to, as =20 Paul said, yank the trust anchors. It should be noted, though, that yanking the trust anchors is not =20 enough. You really should change the relying party to not recognize =20 this algorithm. Otherwise, it's perfectly valid for a CA whose =20 certificate is signed with SHA1 to sign an intermediate CA certificate =20 with MD5 (although they usually don't do that, I hope) Email secured by Check Point _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From owner-ietf-pkix@mail.imc.org Tue Dec 30 15:59:39 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BA153A69A0 for ; Tue, 30 Dec 2008 15:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdHtxZwFAA5O for ; Tue, 30 Dec 2008 15:59:37 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 07BEB3A6955 for ; Tue, 30 Dec 2008 15:59:36 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNeokg044868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:40:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNeoUw044867; Tue, 30 Dec 2008 16:40:50 -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 fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNebSX044839; Tue, 30 Dec 2008 16:40:48 -0700 (MST) (envelope-from hugokraw@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2736323fgb.26 for ; Tue, 30 Dec 2008 15:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=DDpekhM52VkOAoRXt2PZCjhH4t1PiBNvOlzCNzEqzL4=; b=ZZz3YvRMqfdLQsd/8ahiFloECdUPBawdLeuuNZH8Cr46ZHYLNXsoZ+HMY+zLRX6zYI h+P2eWBjHI0CacQWPFxFZXccAWRnZLdIAa2ZIivutA9pgNYpKm9PZOVdbDda45599etK ntwcXzkHyb9uMG1+RTH91bwmHp47itVwiUsgY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=rIO56ncxno48IvUn931cZzc48cPja3c6sVugRkSlz07p+kL31iFVgv0xYSnUpIRGhc 9l8VIIu5uelDeSjEMvZMXmMvlH94d3yEPdueUvJdVnE1X+piIepre66GsXldcD7HYouL S1ChvvQEJXezzzv/SuiCz/3ifmbLVWzeW8SV8= Received: by 10.86.95.20 with SMTP id s20mr2438156fgb.39.1230680436423; Tue, 30 Dec 2008 15:40:36 -0800 (PST) Received: by 10.86.93.6 with HTTP; Tue, 30 Dec 2008 15:40:36 -0800 (PST) Message-ID: Date: Tue, 30 Dec 2008 18:40:36 -0500 From: "Hugo Krawczyk" To: "Eric Rescorla" Subject: Re: Further MD5 breaks: Creating a rogue CA certificate Cc: "Paul Hoffman" , ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org In-Reply-To: <20081230213934.C219450822@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_143378_5086089.1230680436411" References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> X-Google-Sender-Auth: 51d21de5a352475d Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_Part_143378_5086089.1230680436411 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Paul, Eric and everyone else, Paul said > > If the IETF feels that adding randomization to signatures is > important, we should define randomized signature functions. We could > start with NIST Draft SP 800-106 > (< http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>). However, > I think that doing so is sending the wrong message: we should > instead be encouraging the use of non-broken hash functions. and Eric responded > I certainly agree we should be encouraging the use of non-broken hash > functions. However, randomizing the SN seems like very cheap backward > compatible insurance against the fact that that's going to take a long time. I believe that the best answer to the above arguments regarding the use of randomized hashing vs. the "patch" of using random SNs is given by Sotirov et al, the cryptanalysts that carried out the remarkable MD5-certificate attack (see their website). They say: *We do note however that this use of randomness in the serial number is a workaround, made possible by lucky choices in the X.509 standard. It is not a bad idea in general to add randomness to a hash input when a possible attacker is able to choose the input. A much more reliable, since designed, solution is to use randomized hashing, see [HK]. Such a solution introduces randomization as a "mode of operation" for hash functions, which is a much more fundamental approach to the problem than relying on features that happen to be present in existing standards for non-security reasons, or for no reason at all.* In this light, I disagree with Paul's statement: > I think that doing so is sending the wrong message: we should > instead be encouraging the use of non-broken hash functions. The two things are not exclusive. We should do BOTH: Adopt a randomized hashing technique (as a mode of operation for hash functions) and continue our quest for better hash functions. We must aim at the best possible hash function, but we cannot guarantee its security in the long term. As stated in the above text by Sotirov et al, randomized hashing is a more fundamental (I would call it "infrastructural") approach. It strengthens digital signatures with any hash function and for any digital signature application, not just certificates. Let's take the example of HMAC: Its development in mid-90's was motivated to a large extent by the weaknesses found in MD5 by Dobbertin and others. If we took the approach of "let's use a better hash function" we should have adopted the key-append method MAC(K,X) = SHA1(X||K) which used SHA1 for which there was ample belief that it was a very good collision resistant hash function. However, had we done that, we would now have a broken MAC since the above design breaks with collisions on the underlying hash function. I believe that the responsible course of action for the IETF and particularly SAAG is to adopt the standardization process started by NIST with http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf and create a deployment path that could accommodate a randomized hashing approach as a mode of operation. This includes the consideration of randomized hashing in protocol changes and new protocol design that support algorithm agility. No one in the world will think that by doing that we should keep using MD5, or not pay attention to NIST's hash competition, or should stop from moving to SHA2. The just-published attack indicates that it is time that we take seriously our digital signatures, and randomized hashing is the best long-term insurance we know against future collision vulnerabilities. You can find more details on the specific randomized hashing approach behind NIST's document in http://www.ee.technion.ac.il/~hugo/rhash/ In particular, some of the documents in that site provide some guidance regarding implementation and deployment issues (it also includes a now-expired internet draft). Hugo ------=_Part_143378_5086089.1230680436411 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Paul, Eric and everyone else,

Paul said

    >
    > If the IETF feels that adding randomization to signatures is
    > important, we should define randomized signature functions. We could
    > start with NIST Draft SP 800-106
    > (<http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>). However,
    > I think that doing so is sending the wrong message: we should
    > instead be encouraging the use of non-broken hash functions.

and Eric responded

   >  I certainly agree we should be encouraging the use of non-broken hash
   >  functions. However, randomizing the SN seems like very cheap backward
   >  compatible insurance against the fact that that's going to take a long time.


I believe that the best answer to the above arguments regarding the use of
randomized hashing vs. the "patch" of using random SNs is given by Sotirov et
al, the cryptanalysts that carried out the remarkable MD5-certificate attack
(see their website). They say:

  We do note however that this use of randomness in the serial number is a
  workaround, made possible by lucky choices in the X.509 standard. It is not a
  bad idea in general to add randomness to a hash input when a possible attacker
  is able to choose the input. A much more reliable, since designed, solution is
  to use randomized hashing, see [HK]. Such a solution introduces randomization
  as a "mode of operation" for hash functions, which is a much more fundamental
  approach to the problem than relying on features that happen to be present in
  existing standards for non-security reasons, or for no reason at all.

In this light, I disagree with Paul's statement:

> I think that doing so is sending the wrong message: we should
> instead be encouraging the use of non-broken hash functions.

The two things are not exclusive. We should do BOTH:
Adopt a randomized hashing technique (as a mode of operation for hash
functions) and continue our quest for better hash functions.

We must aim at the best possible hash function, but we cannot guarantee its
security in the long term. As stated in the above text by Sotirov et al,
randomized hashing is a more fundamental (I would call it "infrastructural")
approach. It strengthens digital signatures with any hash function and for any
digital signature application, not just certificates.

Let's take the example of HMAC: Its development in mid-90's was motivated to a
large extent by the weaknesses found in MD5 by Dobbertin and others.
If we took the approach of "let's use a better hash function" we should have
adopted the key-append method
  MAC(K,X) = SHA1(X||K)
which used SHA1 for which there was ample belief that it was a very good
collision resistant hash function.  However, had we done that, we would now
have a broken MAC since the above design breaks with collisions on the
underlying hash function.

I believe that the responsible course of action for the IETF and particularly
SAAG is to adopt the standardization process started by NIST with
http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf
and create a deployment path that could accommodate a randomized hashing
approach as a mode of operation. This includes the consideration of randomized
hashing in protocol changes and new protocol design that support algorithm
agility.

No one in the world will think that by doing that we should keep using MD5,
or not pay attention to NIST's hash competition, or should stop from moving to
SHA2.

The just-published attack indicates that it is time that we take seriously our
digital signatures, and randomized hashing is the best long-term insurance
we know against future collision vulnerabilities.

You can find more details on the specific randomized hashing approach behind
NIST's document in http://www.ee.technion.ac.il/~hugo/rhash/
In particular, some of the documents in that site provide some guidance
regarding implementation and deployment issues (it also includes a now-expired
internet draft).

Hugo

------=_Part_143378_5086089.1230680436411-- From owner-ietf-pkix@mail.imc.org Tue Dec 30 16:47:33 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891BE3A68D1 for ; Tue, 30 Dec 2008 16:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFOIrNPswAZK for ; Tue, 30 Dec 2008 16:47:32 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7ABA43A68B3 for ; Tue, 30 Dec 2008 16:47:32 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNQ7DX044211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:26:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNQ7Tp044209; Tue, 30 Dec 2008 16:26:07 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNQ5kV044188 for ; Tue, 30 Dec 2008 16:26:05 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 29815 invoked from network); 30 Dec 2008 23:26:29 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:26:29 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:26:29 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Tue, 30 Dec 2008 18:26:04 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclqxZr3n+guWOOLTkmzRrRAnrk5JgAEETnQ References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> From: "Santosh Chokhani" To: "RL 'Bob' Morgan" , "Paul Hoffman" Cc: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As mentioned, self-signed roots have their own problems and hash is not one of them. They need other means to protect since signatures on them are useless. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of RL 'Bob' Morgan Sent: Tuesday, December 30, 2008 4:18 PM To: Paul Hoffman Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate > Regardless of that, the authors of the MD5 paper are correct: trust=20 > anchors signed with MD5 are highly questionable as of today (well,=20 > actually, since they published their last paper). Hopefully, the=20 > maintainers of the popular trust anchor repositories (Microsoft,=20 > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and=20 > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5=20 signatures", which is what I as an amateur take away from a quick scan of=20 the material. Obviously MD5 is suspect in various ways, but does this new=20 work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" From owner-ietf-pkix@mail.imc.org Tue Dec 30 17:04:04 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53CD3A689D for ; Tue, 30 Dec 2008 17:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6otnXZTwK1cl for ; Tue, 30 Dec 2008 17:04:04 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9A9833A67AA for ; Tue, 30 Dec 2008 17:04:03 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNjtPp045193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:45:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNjtPr045191; Tue, 30 Dec 2008 16:45:55 -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 chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNjr9K045178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 16:45:54 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUNjjIx018330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:45:46 -0500 (EST) Date: Tue, 30 Dec 2008 18:45:45 -0500 From: Jeffrey Hutzelman To: Santosh Chokhani , Peter Hesse , "RL 'Bob' Morgan" , Paul Hoffman cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate Message-ID: <411C6DBE577BC8F60969AF29@atlantis.pc.cs.cmu.edu> In-Reply-To: <200812302328.mBUNSDJj019534@raisinbran.srv.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <08bb01c96ac7$1cd5a750$5680f5f0$@com> <200812302328.mBUNSDJj019534@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, December 30, 2008 06:28:07 PM -0500 Santosh Chokhani wrote: > Since the attack is computing pre-image, I suspect that past MD5 > certificates are safe until the attack was devised. The attack does _not_ involve computing a preimage; it involves computing a colliding pair one of which has a prefix which is predictable but not controllable, followed by a controllable component consisting of some minimum number of bits followed by at least three aligned message blocks. What makes existing certificates safe is that there are no known preimage attacks against MD5, couple with limitations of the technique used to construct the colliding pair. However, there is a limit to how "safe" existing certificates are, because the attack does not require anything that was not known 3-4 years ago. The only change is that with the latest techniques for computing collisions, it is possible to do so in a short enough time to be able to predict the validity and serial number that will be used by the issuer with fairly high probability. -- Jeff From owner-ietf-pkix@mail.imc.org Tue Dec 30 17:42:54 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7614A3A68C9 for ; Tue, 30 Dec 2008 17:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9SooP2Cd4+t for ; Tue, 30 Dec 2008 17:42:54 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EE8193A67AA for ; Tue, 30 Dec 2008 17:42:53 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBV1Kxgu050092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:20:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBV1Kx1e050089; Tue, 30 Dec 2008 18:20: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 mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBV1KkLi050051; Tue, 30 Dec 2008 18:20:58 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C6E079D3C9; Wed, 31 Dec 2008 14:20:45 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ47zQCpU9p7; Wed, 31 Dec 2008 14:20:45 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EF5B69D3C8; Wed, 31 Dec 2008 14:20:44 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 0EEEE1BE4002; Wed, 31 Dec 2008 14:20:40 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LHplH-0006Xw-V6; Wed, 31 Dec 2008 14:20:39 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: paul.hoffman@vpnc.org, pmhesse@geminisecurity.com, rlmorgan@washington.edu Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Cc: cfrg@irtf.org, ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org In-Reply-To: <08bb01c96ac7$1cd5a750$5680f5f0$@com> Message-Id: Date: Wed, 31 Dec 2008 14:20:39 +1300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Peter Hesse" writes: >Ceasing the issuance of certificates with MD5 used in the signature doesn't >solve the problem of the certificates that have already been issued and are >still out there, any number of which may be rogue. > >Replacing, or marking as untrusted all root certificates which have any >current valid (i.e. non-expired, non-revoked) certificates with MD5 used in >the signature could have tremendous undesirable impact and be an untenable >solution. I hate to be the one to point to the elephant in the room (well OK, I don't hate it, it's rather fun actually) but you need to keep this in perspective: one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks have no problems at all obtaining certs from commercial CAs using stolen identities and credentials for pretty much any use they want. The current MD5 attack is very cool but there's no need to worry about bad guys doing much with it because it's much, much easier to get legitimate CA-issued certs the normal way, you buy them just like everyone else does (except that you use someone else's credit card and identity, obviously). In other words, if this problem is fixed, would anyone other than security geeks even notice? I doubt the crooks will. Peter. From owner-ietf-pkix@mail.imc.org Wed Dec 31 00:34:08 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA1128C107 for ; Wed, 31 Dec 2008 00:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.386 X-Spam-Level: X-Spam-Status: No, score=-1.386 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DPEMzTkWq7D for ; Wed, 31 Dec 2008 00:34:08 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A6EEC28C0E1 for ; Wed, 31 Dec 2008 00:34:07 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBV87fBK065613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 01:07:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBV87fct065610; Wed, 31 Dec 2008 01:07: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBV87SWk065597 for ; Wed, 31 Dec 2008 01:07:38 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 936 invoked from network); 31 Dec 2008 08:07:51 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 08:07:51 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 08:07:51 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 03:07:26 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: Aclq5ghrPG8EOOIcREilhQIvujxQYwAOEaVA References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> From: "Santosh Chokhani" To: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One would think we want to start using SHA-1 or even SHA256 (assuming client vendors implement SHA256 ASAP) and ask the CAs emanating from commercial roots to perform responsible I&A before issuing certificates. It will also help if the client side certificate policy processing became more of a norm. But, all of this is probably expecting too much. My fear is that expecting any of this is also too much. -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Peter Gutmann Sent: Tuesday, December 30, 2008 8:21 PM To: paul.hoffman@vpnc.org; pmhesse@geminisecurity.com; rlmorgan@washington.edu Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate "Peter Hesse" writes: >Ceasing the issuance of certificates with MD5 used in the signature doesn't >solve the problem of the certificates that have already been issued and are >still out there, any number of which may be rogue. > >Replacing, or marking as untrusted all root certificates which have any >current valid (i.e. non-expired, non-revoked) certificates with MD5 used in >the signature could have tremendous undesirable impact and be an untenable >solution. I hate to be the one to point to the elephant in the room (well OK, I don't hate it, it's rather fun actually) but you need to keep this in perspective: one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks have no problems at all obtaining certs from commercial CAs using stolen identities and credentials for pretty much any use they want. The current MD5 attack is very cool but there's no need to worry about bad guys doing much with it because it's much, much easier to get legitimate CA-issued certs the normal way, you buy them just like everyone else does (except that you use someone else's credit card and identity, obviously). In other words, if this problem is fixed, would anyone other than security geeks even notice? I doubt the crooks will. Peter. _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg From owner-ietf-pkix@mail.imc.org Wed Dec 31 07:11:37 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C17D28C0EC for ; Wed, 31 Dec 2008 07:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7frexz2aPWF for ; Wed, 31 Dec 2008 07:11:36 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D10113A69C9 for ; Wed, 31 Dec 2008 07:11:35 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEhec4085339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:43:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVEhe7w085337; Wed, 31 Dec 2008 07:43: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 smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEhQJ1085321; Wed, 31 Dec 2008 07:43:37 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVEhO1a005883; Wed, 31 Dec 2008 09:43:24 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVEhOWH005873; Wed, 31 Dec 2008 09:43:24 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 09:43:24 -0500 Message-ID: <495B84F0.3030506@mitre.org> Date: Wed, 31 Dec 2008 08:42:56 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Russ Housley CC: Eric Rescorla , "cfrg@irtf.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "ietf-pkix@imc.org" Subject: Re: Further MD5 breaks: Creating a rogue CA certificate References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.com> <200812302223.mBUMNqDL040943@balder-227.proper.com> In-Reply-To: <200812302223.mBUMNqDL040943@balder-227.proper.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090606080405090908050504" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms090606080405090908050504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Russ Housley wrote: > >> I'm not sure I understand the issue here, but >> they don't actually have to be totally randomized. You could use a >> PRF so they were predictable to the CA. > > That works. This works too: the serial number could be composed of > two parts, where the most significant bits are a counter and the > least significant bits are randomly generated. How would Corestreet's miniCRL format fare under this? -- Tim --------------ms090606080405090908050504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExNDQyNTZaMCMGCSqGSIb3DQEJBDEWBBTfbxF7sn3oqEN3WXpHFQsd8theZDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgBZT/e02nOU5oLHw8SlL6T03B11F/xNZ0nz2O8tH5cZlJO9MLivLWFMt7kuj +OfGq/Rbd1s8iuLaOutkrqN86npxL/gDNTA9HhiOUS7uN6rWywF/2tptx4S0l7lJRMDg/BcX 0kefE1Ivxq3RU/taMplV1KFiHkJ7LJUnlyHecbu2AAAAAAAA --------------ms090606080405090908050504-- From owner-ietf-pkix@mail.imc.org Wed Dec 31 07:16:38 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E35D3A67FF for ; Wed, 31 Dec 2008 07:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJbcGF9JJRlr for ; Wed, 31 Dec 2008 07:16:37 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1FD9A3A69D4 for ; Wed, 31 Dec 2008 07:15:58 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEn07r085545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:49:00 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVEn06Z085543; Wed, 31 Dec 2008 07:49:00 -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 romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEmnk9085526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:48:59 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id BFE4650822; Wed, 31 Dec 2008 07:05:05 -0800 (PST) Date: Wed, 31 Dec 2008 07:05:05 -0800 From: Eric Rescorla To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: paul.hoffman@vpnc.org, pmhesse@geminisecurity.com, rlmorgan@washington.edu, ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081231150505.BFE4650822@romeo.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Wed, 31 Dec 2008 14:20:39 +1300, Peter Gutmann wrote: > > "Peter Hesse" writes: > > >Ceasing the issuance of certificates with MD5 used in the signature doesn't > >solve the problem of the certificates that have already been issued and are > >still out there, any number of which may be rogue. > > > >Replacing, or marking as untrusted all root certificates which have any > >current valid (i.e. non-expired, non-revoked) certificates with MD5 used in > >the signature could have tremendous undesirable impact and be an untenable > >solution. > > I hate to be the one to point to the elephant in the room (well OK, I don't > hate it, it's rather fun actually) but you need to keep this in perspective: > one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks > have no problems at all obtaining certs from commercial CAs using stolen > identities and credentials for pretty much any use they want. The current MD5 > attack is very cool but there's no need to worry about bad guys doing much > with it because it's much, much easier to get legitimate CA-issued certs the > normal way, you buy them just like everyone else does (except that you use > someone else's credit card and identity, obviously). > > In other words, if this problem is fixed, would anyone other than security > geeks even notice? I doubt the crooks will. Well, if we're going to be pointing ot the obvious, then code signing actually seems kind of off-point as well. > 50% of IE users are not running up-to-date copies of their browser.[0] In many cases this means that the browsers have remote exploits. Why worry about AuthentiCode? -Ekr [0] http://www.techzoom.net/publications/insecurity-iceberg/index.en From owner-ietf-pkix@mail.imc.org Wed Dec 31 07:26:10 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603613A687F for ; Wed, 31 Dec 2008 07:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRgXFxhzfE7k for ; Wed, 31 Dec 2008 07:26:09 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 57B163A679F for ; Wed, 31 Dec 2008 07:26:09 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVF4tQJ086353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:04:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVF4sib086351; Wed, 31 Dec 2008 08:04:54 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVF4gaD086329 for ; Wed, 31 Dec 2008 08:04:52 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 3140 invoked from network); 31 Dec 2008 15:05:05 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 15:05:05 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 15:05:04 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Further MD5 breaks: Creating a rogue CA certificate Date: Wed, 31 Dec 2008 10:04:40 -0500 Message-ID: In-Reply-To: <495B84F0.3030506@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclrWAfbgnf2g3ujTbSdpg9MXzs4IAAANDWw References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.com> <200812302223.mBUMNqDL040943@balder-227.proper.com> <495B84F0.3030506@mitre.org> From: "Santosh Chokhani" To: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mini CRL are not a standard. That said, using implementators agreement (based on whether high order to low order bits are true serial number) one bit per certificate can be assigned and the random prefix or appendage to the serial number ignored. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Timothy J. Miller Sent: Wednesday, December 31, 2008 9:43 AM To: Russ Housley Cc: Eric Rescorla; cfrg@irtf.org; ietf-smime@imc.org; saag@ietf.org; ietf-pkix@imc.org Subject: Re: Further MD5 breaks: Creating a rogue CA certificate Russ Housley wrote: >=20 >> I'm not sure I understand the issue here, but >> they don't actually have to be totally randomized. You could use a >> PRF so they were predictable to the CA. >=20 > That works. This works too: the serial number could be composed of=20 > two parts, where the most significant bits are a counter and the=20 > least significant bits are randomly generated. How would Corestreet's miniCRL format fare under this? -- Tim From owner-ietf-pkix@mail.imc.org Wed Dec 31 07:41:04 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A0A3A67FF for ; Wed, 31 Dec 2008 07:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b+svwREgNNi for ; Wed, 31 Dec 2008 07:41:03 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 369963A69D0 for ; Wed, 31 Dec 2008 07:41:02 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFIaeD086981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:18:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFIaGL086979; Wed, 31 Dec 2008 08:18:36 -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-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFIY1l086966; Wed, 31 Dec 2008 08:18:34 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVFIXwR002392; Wed, 31 Dec 2008 10:18:33 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVFIXZb002386; Wed, 31 Dec 2008 10:18:33 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 10:18:33 -0500 Message-ID: <495B8D28.6070601@mitre.org> Date: Wed, 31 Dec 2008 09:18:00 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani CC: "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050306030909090007020003" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms050306030909090007020003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh Chokhani wrote: > One would think we want to start using SHA-1 or even SHA256 (assuming > client vendors implement SHA256 ASAP) and ask the CAs emanating from > commercial roots to perform responsible I&A before issuing certificates. Speaking of I&A, I found it interesting to note that the CA/Browser forum guidelines for EV certs allows (but recommends against) MD5 until 2010. The spot check of EV issuers I did yesterday didn't turn up anyone actually using MD5, but I didn't have all of 'em available. -- Tim --------------ms050306030909090007020003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExNTE4MDBaMCMGCSqGSIb3DQEJBDEWBBTYJibxLOyG1SEmTVXB/AhI0/Bt8jBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgAZCH6+J56WxRyI0sA7T1gbC1tsCwYnjNsqIpESy0TwpwrdIYDgtwOARQOev InbqiDYQerQmWIIH+ovlzYIUazy21FVc8ReHKFTXOrx4GLrDvGSwGfsDrc8Rz8l5dcP0rXUS J6/YQsvvbM90MY/o0TBIWI2i8PG5c5mVmkkYr+E9AAAAAAAA --------------ms050306030909090007020003-- From owner-ietf-pkix@mail.imc.org Wed Dec 31 08:05:39 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A30728C101 for ; Wed, 31 Dec 2008 08:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG2qxGySeukf for ; Wed, 31 Dec 2008 08:05:38 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4E8C13A68E5 for ; Wed, 31 Dec 2008 08:05:36 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFbC6Z087821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:37:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFbCqc087819; Wed, 31 Dec 2008 08:37: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 sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVFaxkC087772 for ; Wed, 31 Dec 2008 08:37:10 -0700 (MST) (envelope-from tim.moses@entrust.com) Received: (qmail 28690 invoked from network); 31 Dec 2008 15:36:57 -0000 Received: from tim.moses@entrust.com by sottccs1.entrust.com with EntrustECS-Server-8.0;31 Dec 2008 15:36:57 -0000 Received: from unknown (HELO sottexch1.corp.ad.entrust.com) (10.4.51.28) by sottccs1.entrust.com with SMTP; 31 Dec 2008 15:36:56 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="--=_NextPart_EE_103656811.38200976" Date: Wed, 31 Dec 2008 10:36:56 -0500 Message-ID: <04398A2C9F306C4690265C144089972D0D3B3B13@sottexch1.corp.ad.entrust.com> In-Reply-To: <495B8D28.6070601@mitre.org> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrXBEEqsU/Y6e/ROuPhuoyz8ZfcAAAQNmw References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> From: "Tim Moses" To: "Timothy J. Miller" Cc: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----=_NextPart_EE_103656811.38200976 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Colleagues - It has been confirmed that no EV issuer is signing certific= ates with MD5. Also, EV certificates cannot be issued by an automated p= rocess, putting another obstacle in the path of an attacker. All the be= st. Tim. Tim Moses +1 613 270 3183 -----Original Message----- From: owner-ietf-smime=40mail.imc.org =5Bmailto:owner-ietf-smime=40mail.= imc.org=5D On Behalf Of Timothy J. Miller Sent: Wednesday, December 31, 2008 10:18 AM To: Santosh Chokhani Cc: ietf-pkix=40imc.org; ietf-smime=40imc.org; cfrg=40irtf.org; saag=40i= etf.org Subject: Re: =5BCfrg=5D =5Bsaag=5D Further MD5 breaks: Creating a rogue C= Acertificate Santosh Chokhani wrote: > One would think we want to start using SHA-1 or even SHA256 (assuming=20 > client vendors implement SHA256 ASAP) and ask the CAs emanating from=20 > commercial roots to perform responsible I&A before issuing certificate= s. Speaking of I&A, I found it interesting to note that the CA/Browser foru= m guidelines for EV certs allows (but recommends against) MD5 until 2010= =2E The spot check of EV issuers I did yesterday didn't turn up anyone actua= lly using MD5, but I didn't have all of 'em available. -- Tim ----=_NextPart_EE_103656811.38200976 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCTAHBgUrDgMCGjCABgkqhkiG9w0BBwEAAKCCIIIwggKf MIICCKADAgECAgRGJ7vgMA0GCSqGSIb3DQEBBQUAMCwxCzAJBgNVBAYTAkNBMR0wGwYDVQQK ExRFbnRydXN0IFRlY2hub2xvZ2llczAeFw0wODA1MDcxMzA4MzlaFw0xMTA1MDcxMzM4Mzla MDIxCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczCB nTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEA0IBgoGWlwptmAbxopaoSELaZIvJHlWg+vqcq kQlA6mSAzTEHQl79k5aUq4cPZQTK5SnsUoY3aPN8IyTN8+SDmIJ/3qwFvxG1Xkbi1UDo6qB/ TR1zwBoxpz7iL8XH5gLWSaijFab+bMeTamSeL05l0JjF0AoAmxnwAjU7Zl4kdWkCAQOjgckw gcYwHQYDVR0OBBYEFAUkiCBOsLJRzMuh2elnJIbV+bBFME4GA1UdHwRHMEUwQ6BBoD+kPTA7 MQswCQYDVQQGEwJDQTEdMBsGA1UEChMURW50cnVzdCBUZWNobm9sb2dpZXMxDTALBgNVBAMT BENSTDEwCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFDGPKjFGWl7oabci0fgBq6xQXgF1MAwG A1UdEwQFMAMBAf8wGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCAIEwDQYJKoZIhvcNAQEFBQAD gYEAbdDF5a/A+vjthvR7ofXzM3UxI/62yW9yJPzQ7sN1AS9zKgPB9Nm4tySDwSeFvqQ1/KOv JTEeYABGRaZ1YrTXc2mFhTlcLQAZ16DsS2VxnKqhEVWq4JaUaJAe9qvKvdkvpDieKQMkfM0c WZCa9b396rZKqSd+j86yP6FauYSrw6wwggLfMIICSKADAgECAgRGS07GMA0GCSqGSIb3DQEB BQUAMC4xCzAJBgNVBAYTAmNhMRAwDgYDVQQKEwdlbnRydXN0MQ0wCwYDVQQLEwRQcm9kMB4X DTA3MDUyMjE0NTQ0N1oXDTEwMDUyMjE1MjQ0N1owLDELMAkGA1UEBhMCQ0ExHTAbBgNVBAoT FEVudHJ1c3QgVGVjaG5vbG9naWVzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5SPAE WITHCc04wRiDaJpJY8ZF7bCJ1ohhSyKRA2ouJ+sjRMqzfxXcxQTKuE4GQg1dvZjvmmZJq5KZ 71yZnvK+Kb1ixXP1y/zAy6CiiatTPrf8SNzXpSDon3VdKo8zuKQ6ELKaWP3nK4O4eOiXdmfn a2bOLzFi7TpKICfieMOdlQIDAQABo4IBCjCCAQYwHQYDVR0OBBYEFDGPKjFGWl7oabci0fgB q6xQXgF1MIGNBgNVHR8EgYUwgYIwRaBDoEGkPzA9MQswCQYDVQQGEwJjYTEQMA4GA1UEChMH ZW50cnVzdDENMAsGA1UECxMEUHJvZDENMAsGA1UEAxMEQ1JMMTA5oDegNYYzZmlsZTovL1xc U09UVFBST0RDQVxDUkxccHJvZF9lbnRydXN0X2NhX2NybGZpbGUuY3JsMAsGA1UdDwQEAwIB BjAfBgNVHSMEGDAWgBTR5DvPp2uwBfGx/my5EmQy0JQbujAMBgNVHRMEBTADAQH/MBkGCSqG SIb2fQdBAAQMMAobBFY3LjEDAgCBMA0GCSqGSIb3DQEBBQUAA4GBAEnSrabNwGiiZNjhIFce 7VctEE5uR6RaADbc6hszcn50pYoliCY5T53dUpOvznUuDX0HWFfH+YXl3Isol2p0DbSSAFNv 8OWyEAd2SoYRinBNpMOyQlrTWt5FBiCB2dglbxx/I2eyTqr5COy8u/ijLKvVn00yBf3f1kCw d+//jQluMIIC7TCCAlagAwIBAgIEMkbEozANBgkqhkiG9w0BAQUFADAyMQswCQYDVQQGEwJD QTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5lc3MwHhcNOTgwODE5MTkxMjA2 WhcNMTgwODE5MTk0MjA2WjAyMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8G A1UECxMIQnVzaW5lc3MwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBANCAYKBlpcKbZgG8 aKWqEhC2mSLyR5VoPr6nKpEJQOpkgM0xB0Je/ZOWlKuHD2UEyuUp7FKGN2jzfCMkzfPkg5iC f96sBb8RtV5G4tVA6Oqgf00dc8AaMac+4i/Fx+YC1kmooxWm/mzHk2pkni9OZdCYxdAKAJsZ 8AI1O2ZeJHVpAgEDo4IBEDCCAQwwEQYJYIZIAYb4QgEBBAQDAgAHMFQGA1UdHwRNMEswSaBH oEWkQzBBMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5l c3MxDTALBgNVBAMTBENSTDEwKwYDVR0QBCQwIoAPMTk5ODA4MTkxOTEyMDZagQ8yMDE4MDgx OTE5MTIwNlowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFAUkiCBOsLJRzMuh2elnJIbV+bBF MB0GA1UdDgQWBBQFJIggTrCyUczLodnpZySG1fmwRTAMBgNVHRMEBTADAQH/MBkGCSqGSIb2 fQdBAAQMMAobBFY0LjADAgSQMA0GCSqGSIb3DQEBBQUAA4GBAJg+gIo2VG7EqPRBAJ3Q6sho xP/8pMCk/3UyKbuu4En4aRn+5kAXmjhqJR98uZsR89G5S1I68pn+xhg6FK3gNgC/OLOZ6bRG ABcQGkRov8vvIoJPRRN3JYcAyJSRykY2CZhPsW99pO69qlxS4lRIfIFuflaXs7PY2LTzftsO 6o1cMIIDJTCCAo6gAwIBAgIERktOCjANBgkqhkiG9w0BAQUFADAuMQswCQYDVQQGEwJjYTEQ MA4GA1UEChMHZW50cnVzdDENMAsGA1UECxMEUHJvZDAeFw0wNzA1MTYxODAxMzhaFw0xNzA1 MTYxODMxMzhaMC4xCzAJBgNVBAYTAmNhMRAwDgYDVQQKEwdlbnRydXN0MQ0wCwYDVQQLEwRQ cm9kMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpd6zp2+OYdJe2JvS/+IlSax3c1GWf xpm/6G11szZ9iRTy0UCpcVZ7e7pEnu/ySNSDN0CLFfj2XMnC2b5YgnuL9/rDz+jVCylLJbuJ HjpYmGWQqG1vbmSUBQeH9TCdTHEqScibjV77r81cfyOpjWe0iETErEUlq5jsnuZOYKkuXQID AQABo4IBTjCCAUowEQYJYIZIAYb4QgEBBAQDAgAHMIGNBgNVHR8EgYUwgYIwRaBDoEGkPzA9 MQswCQYDVQQGEwJjYTEQMA4GA1UEChMHZW50cnVzdDENMAsGA1UECxMEUHJvZDENMAsGA1UE AxMEQ1JMMTA5oDegNYYzZmlsZTovL1xcU09UVFBST0RDQVxDUkxccHJvZF9lbnRydXN0X2Nh X2NybGZpbGUuY3JsMCsGA1UdEAQkMCKADzIwMDcwNTE2MTgwMTM4WoEPMjAxNzA1MTYxODMx MzhaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBTR5DvPp2uwBfGx/my5EmQy0JQbujAdBgNV HQ4EFgQU0eQ7z6drsAXxsf5suRJkMtCUG7owDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAE EDAOGwhWNy4xOjQuMAMCBJAwDQYJKoZIhvcNAQEFBQADgYEAWATjTT62BcA4MaxLVJTG5alA BUYnKzbtbpoZrckpmEVZfcoLooJcgRq58DeGVihhvl9lfUOE3YIQUFxDXA6svFD8Fn99y3Iy RGM+itL/rRdbSAlH2Xa6HLBhjTJff9oa6n67WW/RU0106O8jqS3bcVjWeI0WLh7LKxxHnGz3 TFUwggMwMIICmaADAgECAgQ4xeeqMA0GCSqGSIb3DQEBBQUAMDIxCzAJBgNVBAYTAkNBMRAw DgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczAeFw0wNDA5MjkxNzExNThaFw0w ODA5MjkxNzQxNThaMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQL EwdSIGFuZCBEMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvIeIjfoD5D86sD8C ehB+kVhYJTL+VuaUZiVijGevUTlnUAwy1WpOYVpFCa8VK116TJ+o99axN1jMbsVBYfRzFk9S Wl4iAH+PyJ1S6D5Yl593KjHPhBCfdD0v9KoPqXhCwRlkvupreNlFx3FFk2Uf5jG/i9SCP925 OXbz3wod2mdIu8ueNWgTmA2XAOBdHZg6HYKo50BWUIgtRwFvzbh1J57+gNdHxMYLZmvj5saS 1mDTSibkPH/AY+D+xAozRmyOYa4SY2HVfZSM2SP7MkuVtKp17pzhwicoWAGKXrKeDRWDYeZB TJjHoNP/SXKdpSzY7rV8GPrfWFoogc4350VbowIDAQABo4HPMIHMMB0GA1UdDgQWBBTz8Cwo 5jmnNBmrmpGopmZAkpzicTBUBgNVHR8ETTBLMEmgR6BFpEMwQTELMAkGA1UEBhMCQ0ExEDAO BgNVBAoTB0VudHJ1c3QxETAPBgNVBAsTCEJ1c2luZXNzMQ0wCwYDVQQDEwRDUkwxMAsGA1Ud DwQEAwIBBjAfBgNVHSMEGDAWgBQFJIggTrCyUczLodnpZySG1fmwRTAMBgNVHRMEBTADAQH/ MBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgCBMA0GCSqGSIb3DQEBBQUAA4GBAI8B1Aa8TTla mxl1BgP6ch4CZUEADT/1xNwEaPveZFajVrURlnKqMfDQ704aNc2qFnLHJDI3dS49vJEJ8LsK Hvd7sf6WqRCuGkF3D8qsIWKxBK6muWdSfKAYWLB/4wDm2CcZDyXt/A3OYFjMzQ5pVBKeAXNA k6fZ32SGLVNvVqc/MIIDMDCCApmgAwIBAgIESCCkSzANBgkqhkiG9w0BAQUFADAyMQswCQYD VQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5lc3MwHhcNMDgwOTI0 MTQzNjA0WhcNMTIwOTI0MTUwNjA0WjAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVz dDEQMA4GA1UECxMHUiBhbmQgRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALyH iI36A+Q/OrA/AnoQfpFYWCUy/lbmlGYlYoxnr1E5Z1AMMtVqTmFaRQmvFStdekyfqPfWsTdY zG7FQWH0cxZPUlpeIgB/j8idUug+WJefdyoxz4QQn3Q9L/SqD6l4QsEZZL7qa3jZRcdxRZNl H+Yxv4vUgj/duTl2898KHdpnSLvLnjVoE5gNlwDgXR2YOh2CqOdAVlCILUcBb824dSee/oDX R8TGC2Zr4+bGktZg00om5Dx/wGPg/sQKM0ZsjmGuEmNh1X2UjNkj+zJLlbSqde6c4cInKFgB il6yng0Vg2HmQUyYx6DT/0lynaUs2O61fBj631haKIHON+dFW6MCAwEAAaOBzzCBzDAdBgNV HQ4EFgQU8/AsKOY5pzQZq5qRqKZmQJKc4nEwVAYDVR0fBE0wSzBJoEegRaRDMEExCzAJBgNV BAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczENMAsGA1UEAxME Q1JMMTALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUBSSIIE6wslHMy6HZ6WckhtX5sEUwDAYD VR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkqhkiG9w0BAQUFAAOB gQDHUhDfQdNFmborkeOSyqtTmpiIESBES6KULodyCmdHbcoV4L1H5vpjBO0HdUx+YXlIZxUj pTKDv2mowbCAdcWihfW3LjY+3RoqoMu2iR8nSDexR+TesS8drRF9Mrmy30/ddj+sneR7KeaG KL8WGcZBDmxGIvoOaCYGuxsgrC9/LzCCA2gwggLRoAMCAQICBEZLTsUwDQYJKoZIhvcNAQEF BQAwLjELMAkGA1UEBhMCY2ExEDAOBgNVBAoTB2VudHJ1c3QxDTALBgNVBAsTBFByb2QwHhcN MDcwNTIyMTQ0MTIxWhcNMTAwNTIyMTUxMTIxWjAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMH RW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALyHiI36A+Q/OrA/AnoQfpFYWCUy/lbmlGYlYoxnr1E5Z1AMMtVqTmFaRQmvFStdekyf qPfWsTdYzG7FQWH0cxZPUlpeIgB/j8idUug+WJefdyoxz4QQn3Q9L/SqD6l4QsEZZL7qa3jZ RcdxRZNlH+Yxv4vUgj/duTl2898KHdpnSLvLnjVoE5gNlwDgXR2YOh2CqOdAVlCILUcBb824 dSee/oDXR8TGC2Zr4+bGktZg00om5Dx/wGPg/sQKM0ZsjmGuEmNh1X2UjNkj+zJLlbSqde6c 4cInKFgBil6yng0Vg2HmQUyYx6DT/0lynaUs2O61fBj631haKIHON+dFW6MCAwEAAaOCAQow ggEGMB0GA1UdDgQWBBTz8Cwo5jmnNBmrmpGopmZAkpzicTCBjQYDVR0fBIGFMIGCMEWgQ6BB pD8wPTELMAkGA1UEBhMCY2ExEDAOBgNVBAoTB2VudHJ1c3QxDTALBgNVBAsTBFByb2QxDTAL BgNVBAMTBENSTDEwOaA3oDWGM2ZpbGU6Ly9cXFNPVFRQUk9EQ0FcQ1JMXHByb2RfZW50cnVz dF9jYV9jcmxmaWxlLmNybDALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU0eQ7z6drsAXxsf5s uRJkMtCUG7owDAYDVR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkq hkiG9w0BAQUFAAOBgQCQBw6L+mclwk7Z64xW4jbrS1CZpTHFGNmVuow0GbxBdFWHsDNE9H0s 4AUS59qW2T8JQRhm062vhZwpj29bCkOwDgciGq2POfOachGypOnV09x5Dcs3s+5M7c3gpbEP dcO8G7GPIcociDNPPj+Kd8ceoMvcZySp22u4MWuI1bOxyjCCA28wggJXoAMCAQICBEZD+x4w DQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNV BAsTB1IgYW5kIEQwHhcNMDgxMDIxMTMyOTM2WhcNMDkwNDIxMTM1OTM2WjBVMQswCQYDVQQG EwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEiMA4GA1UEBRMHMDUw NDA2NzAQBgNVBAMTCVRpbSBNb3NlczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0gtt TXg2dN9WsLP92LJQzIYPjdXOXewCcdviTglJfIFKO+RU3O76TPR6pKsZNgPADZL6Q0QHo5I2 ygrRBXCnMOH7xKutmI2QujgX5FW6kEFrHPRom65/XkuMXNW57BjRt+C4hXKU8fHp6WaiKhOM It2WG2jTHU8IYcYnWiiK4dMCAwEAAaOB7jCB6zALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EV dGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBBMQswCQYDVQQGEwJD QTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwGA1UEAxMFQ1JMNDIw HwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYEFMXxKqPWd83GEHAC aXkPSw+P2UHrMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCBLAwDQYJKoZI hvcNAQEFBQADggEBAClPCYWYRjj5Q0uz74Ldr4FhH4KYkt35rgTXAWR9T2cSLbq6wssHiBS5 YGmM9lsYkQHXc9yPji03n9/Xco/0VjkZY2Fmc03f+3+6WkvvnfAbZFV0HfK1IR/i3hKC5vp9 D8DjcoSXOGwucv7L9iKARJ6jJSXIHl/fTIkt1gqtpfcSAesOhq9u/XO+zxGD8GL1tKF5k1F9 0GN5MQd7HNAZsrwEBDWAO7P3MbCBmOiArjno61cQMUU7k+tgMTt4W2Eeoc0yyzIrRtamz2q8 zbxmnKdEHt140yUXmsxuG04ZM2+iL/MtVD0F69WTAr2JNGsBeeNB8KMGDlCmM8Co2uQOSTkw ggOeMIIChqADAgECAgRGQ/sdMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNVBAYTAkNBMRAwDgYD VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTA4MTAyMTEzMjkzNloXDTA5MDQy MTEzNTkzNlowVTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1Ig YW5kIEQxIjAOBgNVBAUTBzA1MDQwNjcwEAYDVQQDEwlUaW0gTW9zZXMwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBALT3bXGkvn4caHYy/u5MXZsEw0q0/s9nj6j7wNkOkyrw394HoLN7 JY404tmf3zCa+qbCXS5eC9hmbU2Rdxo1eZhlB2sZpP/aY8KaHSzUAUcv0LmtQS25qEkSZkLn WSgczRts/EvOf7q0U4COQwI0dP/vBNk+fvJ+jkjVRZxZX32dAgMBAAGjggEcMIIBGDALBgNV HQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwODEwMjExMzI5MzZagQ8yMDA5MDIyNTIyNTkzNlow IAYDVR0RBBkwF4EVdGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBB MQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwG A1UEAxMFQ1JMNDIwHwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYE FCrFDow3ATgAarWOHil+N5udd2xJMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcu MQMCBLAwDQYJKoZIhvcNAQEFBQADggEBAFGhTfDY3PVBPb1xQezRSKyd6kfj6d1Gl/rqsOk7 1skHSE89plfdYHMoNEBfSCkr+O2au7hx2DBLLK/zjfaqfpr5Scu8IsYz5LrNKsukP46qwOna 2yprT9VVyCsTuByOnG//9U2CEDIwCZ/GBw1i6MHCXssSdZIjxn5oxmO4OBDHhfBIFXT2vIKC x/yEM+BgU+qWPu5T8V3Q3XR+kCE6jQDRp9cSTJy2Otzw+k+ASXASWO4hzEOH/X8Prd/lx1iS clEK1lOXl5k4gCnQu/KcpM5CGKUhwFjcO9LJb/Xkeab4+Z8yEXSvNrjc5xLuFDW3BLaFPyNa hWsrINpm/kC1goAwggP1MIIC3aADAgECAgQySKogMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNV BAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTAyMDQxNzAy MjAyNloXDTIyMDQxNzAyNTAyNlowMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3Qx EDAOBgNVBAsTB1IgYW5kIEQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8h4iN +gPkPzqwPwJ6EH6RWFglMv5W5pRmJWKMZ69ROWdQDDLVak5hWkUJrxUrXXpMn6j31rE3WMxu xUFh9HMWT1JaXiIAf4/InVLoPliXn3cqMc+EEJ90PS/0qg+peELBGWS+6mt42UXHcUWTZR/m Mb+L1II/3bk5dvPfCh3aZ0i7y541aBOYDZcA4F0dmDodgqjnQFZQiC1HAW/NuHUnnv6A10fE xgtma+PmxpLWYNNKJuQ8f8Bj4P7ECjNGbI5hrhJjYdV9lIzZI/syS5W0qnXunOHCJyhYAYpe sp4NFYNh5kFMmMeg0/9Jcp2lLNjutXwY+t9YWiiBzjfnRVujAgMBAAGjggETMIIBDzARBglg hkgBhvhCAQEEBAMCAAcwUwYDVR0fBEwwSjBIoEagRKRCMEAxCzAJBgNVBAYTAkNBMRAwDgYD VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMQ0wCwYDVQQDEwRDUkwxMCsGA1UdEAQk MCKADzIwMDIwNDE3MDIyMDI2WoEPMjAyMjA0MTcwMjUwMjZaMAsGA1UdDwQEAwIBBjAfBgNV HSMEGDAWgBTz8Cwo5jmnNBmrmpGopmZAkpzicTAdBgNVHQ4EFgQU8/AsKOY5pzQZq5qRqKZm QJKc4nEwDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAEEDAOGwhWNi4wOjQuMAMCBJAwDQYJ KoZIhvcNAQEFBQADggEBAIA+ebVGmfnJrmQEsWlyRG3D5e5j8bmbq5Af2FVeB5yGn6Lr+1eV iNDxxycnLUdw6Y9LvXwuQbh2vEF+uGM71pO52/5M0gxH2LNrLv3qGwGTutoGli3Fq84SPFvy N+n4R6XO2BxJmjvfuZjNyuv2kOPMmV2yuILM8NT83TnZH5EnhGz/QiK5bMhUfvL31L076sbX g+MQo1CEDf2BPCD2IwG1CiSwN8q7T1QJoWwTtphQLx4TTDOSLgb4OXlEoTnswZpgCH5xxybI 9HpfD+CXxijdgaE5bPepq0CFtumUAKb0tKZ24xItdDJuR7pyrklRvxz1UzOL1wiK/odt/X/E 5s8xggJoMIICZAIBATA5MDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYD VQQLEwdSIGFuZCBEAgRGQ/sdMAcGBSsOAwIaoIIBiTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEyMzExNTM2NTZaMCMGCSqGSIb3DQEJBDEWBBRJYJQR 3LOeOmLPQl5+lI5BWAQlBjCCASgGCSqGSIb3DQEJDzGCARkwggEVMAoGCCqGSIb3DQMHMAcG BSsOAwIaMAoGCCqGSIb3DQICMAoGCCqGSIb3DQIEMAoGCCqGSIb3DQIFMA4GCCqGSIb3DQME AgIAgDANBggqhkiG9w0DBAIBKDAHBgUrDgMCBzAOBgkqhkiG9n0HQgMCAUAwDgYJKoZIhvZ9 B0IDAgEoMA8GCSqGSIb2fQdCCgICAIAwEQYLKwYBBAGBPAcBAQICAgCAMA8GCWCGSAFlAwQB AgICAIAwDwYJYIZIAWUDBAEWAgIAwDAPBglghkgBZQMEASoCAgEAMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBODANBggqhkiG9w0DAgIBKDALBgkqhkiG 9w0BAQEEgYAZ5wG6uFoDAwofzu92qRcG76k3WrqXjHB3b6RsWMe+Jt5xlI2JRzHZbSD10yJu ETUcGMyhvZEVDEwaR3dsN6N3kjF+WpqoK6OAQNA1OO6WmXXfpDJYsucllmfv+JWA0GX4M5Ux uMCHY3dvQnet5UldSEs3dAMT6wfaMlkXHTghlwAAAAAAAA== ----=_NextPart_EE_103656811.38200976-- From owner-ietf-pkix@mail.imc.org Wed Dec 31 08:13:55 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C1C3A6882 for ; Wed, 31 Dec 2008 08:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUfe+XrB+NOU for ; Wed, 31 Dec 2008 08:13:54 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4579F3A6830 for ; Wed, 31 Dec 2008 08:13:53 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFLFWt087123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:21:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFLFvN087121; Wed, 31 Dec 2008 08:21: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVFLD34087108 for ; Wed, 31 Dec 2008 08:21:13 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 3243 invoked from network); 31 Dec 2008 15:21:36 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 15:21:36 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 15:21:36 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 10:21:12 -0500 Message-ID: In-Reply-To: <495B8D28.6070601@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrWwxnY5KUcnr6RkKSgCgRHyNxcgAADcag References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> From: "Santosh Chokhani" To: "Timothy J. Miller" Cc: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We are simply not vigilant enough. This issue has been on our plate since 2004. SHA-1 is next and neither the client side vendors nor the big Enterprises have pushed to move to SHA-256. -----Original Message----- From: Timothy J. Miller [mailto:tmiller@mitre.org]=20 Sent: Wednesday, December 31, 2008 10:18 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Santosh Chokhani wrote: > One would think we want to start using SHA-1 or even SHA256 (assuming > client vendors implement SHA256 ASAP) and ask the CAs emanating from > commercial roots to perform responsible I&A before issuing certificates. Speaking of I&A, I found it interesting to note that the CA/Browser=20 forum guidelines for EV certs allows (but recommends against) MD5 until=20 2010. The spot check of EV issuers I did yesterday didn't turn up anyone=20 actually using MD5, but I didn't have all of 'em available. -- Tim From owner-ietf-pkix@mail.imc.org Wed Dec 31 09:30:35 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD75D3A69F3 for ; Wed, 31 Dec 2008 09:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHkGf7abQHAL for ; Wed, 31 Dec 2008 09:30:35 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A9D7E28C111 for ; Wed, 31 Dec 2008 09:30:34 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVH4LtH091875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 10:04:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVH4Lhn091873; Wed, 31 Dec 2008 10:04:21 -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 sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVH4AP1091758; Wed, 31 Dec 2008 10:04:20 -0700 (MST) (envelope-from mike-list@pobox.com) Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id A7EB98CD08; Wed, 31 Dec 2008 12:04:09 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id AD05D8CCFD; Wed, 31 Dec 2008 12:04:05 -0500 (EST) Message-ID: <495BA5E9.8040305@pobox.com> Date: Wed, 31 Dec 2008 09:03:37 -0800 From: Mike User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ietf-pkix@imc.org CC: ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 0A5CA3DC-D75D-11DD-B70C-5720C92D7133-38729857!a-sasl-fastnet.pobox.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > We are simply not vigilant enough. This issue has been on our plate > since 2004. > > SHA-1 is next and neither the client side vendors nor the big > Enterprises have pushed to move to SHA-256. There is a simple fix -- a CA can just reorder the extensions prior to issuing a certificate. Mike From owner-ietf-pkix@mail.imc.org Wed Dec 31 10:11:15 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0104C3A6A01 for ; Wed, 31 Dec 2008 10:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D7exfRDCTEP for ; Wed, 31 Dec 2008 10:11:14 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id F20803A68FD for ; Wed, 31 Dec 2008 10:11:13 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVHoasA094528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 10:50:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVHoawe094525; Wed, 31 Dec 2008 10:50:36 -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 sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVHoPh7094500; Wed, 31 Dec 2008 10:50:35 -0700 (MST) (envelope-from mike-list@pobox.com) Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 88E0F1B777; Wed, 31 Dec 2008 12:50:24 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id B7C771B787; Wed, 31 Dec 2008 12:50:19 -0500 (EST) Message-ID: <495BB0B9.9000807@pobox.com> Date: Wed, 31 Dec 2008 09:49:45 -0800 From: Mike User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ietf-pkix@imc.org CC: ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> In-Reply-To: <495BA5E9.8040305@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 80508BAC-D763-11DD-889F-F83E113D384A-38729857!a-sasl-quonix.pobox.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I sent my last message a bit too hastily. Other ideas that I was contemplating should have been mentioned including: - remove any unrecognized extensions - remove tumors Those could potentially cause problems if for some reason they were actually needed. This one, though, shouldn't cause trouble: - add a private EKU with a random number (or two) in the OID That would not mess up the serial number scheme in use or modify the subject name as has been suggested. Mike I wrote: > There is a simple fix -- a CA can just reorder the extensions prior > to issuing a certificate. > > Mike From owner-ietf-pkix@mail.imc.org Wed Dec 31 10:21:50 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC37F3A6A01 for ; Wed, 31 Dec 2008 10:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw-xDsRPqRhB for ; Wed, 31 Dec 2008 10:21:49 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 80AEF3A68DC for ; Wed, 31 Dec 2008 10:21:49 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVI3Gpv095203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:03:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVI3GDN095201; Wed, 31 Dec 2008 11:03:16 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVI3Erg095186 for ; Wed, 31 Dec 2008 11:03:15 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 4249 invoked from network); 31 Dec 2008 18:03:37 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:03:37 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:03:37 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 13:03:13 -0500 Message-ID: In-Reply-To: <495BB0B9.9000807@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrcaZvjthE5F+NRLKwI78nj+9Z5AAACsDQ References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> From: "Santosh Chokhani" To: "Mike" , Cc: , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Private EKU could cause problems if EKU is not otherwise present in the certificate. The certificate may not be usable for intended purpose. Not all clients may recognize "any key purpose" as intended by 5280. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Mike Sent: Wednesday, December 31, 2008 12:50 PM To: ietf-pkix@imc.org Cc: ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate I sent my last message a bit too hastily. Other ideas that I was contemplating should have been mentioned including: - remove any unrecognized extensions - remove tumors Those could potentially cause problems if for some reason they were actually needed. This one, though, shouldn't cause trouble: - add a private EKU with a random number (or two) in the OID That would not mess up the serial number scheme in use or modify the subject name as has been suggested. Mike I wrote: > There is a simple fix -- a CA can just reorder the extensions prior > to issuing a certificate. >=20 > Mike From owner-ietf-pkix@mail.imc.org Wed Dec 31 10:48:39 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3DAD3A69F1 for ; Wed, 31 Dec 2008 10:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSmrNks94kib for ; Wed, 31 Dec 2008 10:48:38 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2F7F93A6820 for ; Wed, 31 Dec 2008 10:48:37 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIUkZQ096660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:30:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIUk5u096659; Wed, 31 Dec 2008 11:30:46 -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-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIUiF3096646; Wed, 31 Dec 2008 11:30:44 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIUhxA026624; Wed, 31 Dec 2008 13:30:44 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIUh7u026614; Wed, 31 Dec 2008 13:30:43 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:30:43 -0500 Message-ID: <495BBA35.9000404@mitre.org> Date: Wed, 31 Dec 2008 12:30:13 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Dr Stephen Henson CC: "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> In-Reply-To: <495BB5D7.7040106@drh-consultancy.demon.co.uk> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060500070900000409080503" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms060500070900000409080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dr Stephen Henson wrote: > Mike wrote: >> I sent my last message a bit too hastily. Other ideas that I was >> contemplating should have been mentioned including: >> >> - remove any unrecognized extensions >> - remove tumors >> >> Those could potentially cause problems if for some reason they were >> actually needed. This one, though, shouldn't cause trouble: >> >> - add a private EKU with a random number (or two) in the OID >> >> That would not mess up the serial number scheme in use or modify the >> subject name as has been suggested. >> > > Or add a non-critical extension with some randomness in it... Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER ::= {id-ce 55} or should I? :) -- Tim --------------ms060500070900000409080503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODMwMTNaMCMGCSqGSIb3DQEJBDEWBBTDOGnW2taEtjPNTda+B7sp3jwHXjBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgI4Tiunxma0T7GovwYWUekJusn0Fg6S544dlebV3nxswPVkGqdvuGRb4yaBq qYonL0ehGR+ZMi1kFYNOLd0bBOibJOtHdubkqmjHMBENsjbiaUnFwd8pN4NW0GIinVLnUTYa 1vfzSaor2vdmDWTBBGF8QAXJPFF76ZsLkkqoz8BJAAAAAAAA --------------ms060500070900000409080503-- From owner-ietf-pkix@mail.imc.org Wed Dec 31 10:52:06 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B603A6A00 for ; Wed, 31 Dec 2008 10:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2PyR6VizKw0 for ; Wed, 31 Dec 2008 10:52:06 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9DD7E3A68DC for ; Wed, 31 Dec 2008 10:52:05 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIYbiD096921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:34:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIYbHd096920; Wed, 31 Dec 2008 11:34: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-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIYZ0D096908; Wed, 31 Dec 2008 11:34:35 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIYY60003982; Wed, 31 Dec 2008 13:34:35 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIYYd0003979; Wed, 31 Dec 2008 13:34:34 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:34:34 -0500 Message-ID: <495BBB1C.3050404@mitre.org> Date: Wed, 31 Dec 2008 12:34:04 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Dr Stephen Henson CC: "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBA35.9000404@mitre.org> In-Reply-To: <495BBA35.9000404@mitre.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070406060900010800080503" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms070406060900010800080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Timothy J. Miller wrote: > Dr Stephen Henson wrote: >> Mike wrote: >>> I sent my last message a bit too hastily. Other ideas that I was >>> contemplating should have been mentioned including: >>> >>> - remove any unrecognized extensions >>> - remove tumors >>> >>> Those could potentially cause problems if for some reason they were >>> actually needed. This one, though, shouldn't cause trouble: >>> >>> - add a private EKU with a random number (or two) in the OID >>> >>> That would not mess up the serial number scheme in use or modify the >>> subject name as has been suggested. >>> >> >> Or add a non-critical extension with some randomness in it... > > Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER ::= {id-ce > 55} or should I? :) draft-01 already: Make that id-ce-magicNumber instead. :) -- Tim --------------ms070406060900010800080503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODM0MDRaMCMGCSqGSIb3DQEJBDEWBBSSJNMK3zrvAhp1fLThyKuCS2ZbzDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgChOMbV+0oDSDKO7kDjIuxQIjRDbYZag6cll5l/fgLT0BVA+ko8npPtOmf1v ctmCWIwx3wUmGBqLvXlnZIJ17XPwuT8Pkkqwte0q7M4aY3HW0J7UICoVIi9PXBsV75NklUR9 nh8lnb3TROTWQO2G2MG/8Z7Po5Sw1wOvBlDbyElIAAAAAAAA --------------ms070406060900010800080503-- From owner-ietf-pkix@mail.imc.org Wed Dec 31 10:52:44 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4333A6A00 for ; Wed, 31 Dec 2008 10:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af39uQq1YsFG for ; Wed, 31 Dec 2008 10:52:43 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4AD8C3A68DC for ; Wed, 31 Dec 2008 10:52:43 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIZgIw096978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:35:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIZgjE096977; Wed, 31 Dec 2008 11:35:42 -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-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIZesj096966; Wed, 31 Dec 2008 11:35:40 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIZdvc006788; Wed, 31 Dec 2008 13:35:40 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIZdEj006785; Wed, 31 Dec 2008 13:35:39 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:35:39 -0500 Message-ID: <495BBB5D.40507@mitre.org> Date: Wed, 31 Dec 2008 12:35:09 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani CC: Dr Stephen Henson , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010007000707070000040106" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms010007000707070000040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh Chokhani wrote: > I am a bit concerned about random goo when random goo is one of the > things the attacker uses to cause collision. This may limit human or > machine's ability to discern mischief. I don't see how, if the random goo is added by the CA. It defeats chosen prefix attacks as a class. -- Tim --------------ms010007000707070000040106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODM1MDlaMCMGCSqGSIb3DQEJBDEWBBQ7wSCe4F6a7ye+v4kS0uvOGSEZxjBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgCTIqWUo25RX2p72ZoyshHyXDNPdtnFa2cGv0bRgIZSCX0rIi5+1Nl8n3imi L3lCMkQOeE0Ai3QU62e1BzsBzXl4VavVhoeb8JHhzeTZAdrXmxQCJ48CB4R1k+TKB8mtkCCT E1FJ8rPqf9EeE4BVdvHvPSb8zf3mUy3iG4rA9D7zAAAAAAAA --------------ms010007000707070000040106-- From owner-ietf-pkix@mail.imc.org Wed Dec 31 11:10:53 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D593A696F for ; Wed, 31 Dec 2008 11:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWL3aDiU2TkN for ; Wed, 31 Dec 2008 11:10:52 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3C4B93A6824 for ; Wed, 31 Dec 2008 11:10:50 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIoGWb097941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:50:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIoGo9097940; Wed, 31 Dec 2008 11:50:16 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVIoE0c097927 for ; Wed, 31 Dec 2008 11:50:15 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 4597 invoked from network); 31 Dec 2008 18:50:37 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:50:37 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:50:37 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 13:50:13 -0500 Message-ID: In-Reply-To: <495BBB5D.40507@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrdpWRZ2DsZT93SYeylkbr3Wg+mAAAUebw References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBB5D.40507@mitre.org> From: "Santosh Chokhani" To: "Timothy J. Miller" Cc: "Dr Stephen Henson" , , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: These things need to be thought through. If all the CAs did this, it might work. But, what if the client side was looking for junk in the certificate as evidence of collision? Also, client will not enforce this. So, if you are relying on CAs, why not ask them to switch to SHA-1 as opposed to adding more software to the CA. SHA-1 is purely a configuration item for the CA deployments. I just find that all three mail lists are getting work out and real message and analysis is getting lost. For example, folks are still posting misinformation that self-signed roots have a hash problem. Signatures on self-signed roots are gratuitous from security viewpoint. So, we do not want to cry wolf and undertaken replacing roots which will be a humongous waste to time and money. Signatures and hence hash used to sign these do not matter. =20 -----Original Message----- From: Timothy J. Miller [mailto:tmiller@mitre.org]=20 Sent: Wednesday, December 31, 2008 1:35 PM To: Santosh Chokhani Cc: Dr Stephen Henson; ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Santosh Chokhani wrote: > I am a bit concerned about random goo when random goo is one of the > things the attacker uses to cause collision. This may limit human or > machine's ability to discern mischief. I don't see how, if the random goo is added by the CA. It defeats=20 chosen prefix attacks as a class. -- Tim From owner-ietf-pkix@mail.imc.org Wed Dec 31 11:12:14 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6CD3A69AC for ; Wed, 31 Dec 2008 11:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjH+xCGK0MrR for ; Wed, 31 Dec 2008 11:12:10 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 84C673A6824 for ; Wed, 31 Dec 2008 11:12:09 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIBf09095597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:11:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIBfGH095594; Wed, 31 Dec 2008 11:11: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 relay10.mail.uk.clara.net (relay10.mail.uk.clara.net [80.168.70.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIBTXB095574; Wed, 31 Dec 2008 11:11:40 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49616 helo=[192.168.7.8]) by relay10.mail.uk.clara.net with esmtpa (Exim 4.69) (envelope-from ) id 1LI5XR-0000nh-An; Wed, 31 Dec 2008 18:11:26 +0000 Message-ID: <495BB5D7.7040106@drh-consultancy.demon.co.uk> Date: Wed, 31 Dec 2008 18:11:35 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ietf-pkix@imc.org CC: ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> In-Reply-To: <495BB0B9.9000807@pobox.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mike wrote: > > I sent my last message a bit too hastily. Other ideas that I was > contemplating should have been mentioned including: > > - remove any unrecognized extensions > - remove tumors > > Those could potentially cause problems if for some reason they were > actually needed. This one, though, shouldn't cause trouble: > > - add a private EKU with a random number (or two) in the OID > > That would not mess up the serial number scheme in use or modify the > subject name as has been suggested. > Or add a non-critical extension with some randomness in it... Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From owner-ietf-pkix@mail.imc.org Wed Dec 31 11:13:53 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7304428C10E for ; Wed, 31 Dec 2008 11:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfbNh1S0bUq2 for ; Wed, 31 Dec 2008 11:13:53 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E81083A69FB for ; Wed, 31 Dec 2008 11:13:52 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIuUhd098366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:56:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIuUBb098363; Wed, 31 Dec 2008 11:56: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVIuSSC098350 for ; Wed, 31 Dec 2008 11:56:29 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 4657 invoked from network); 31 Dec 2008 18:56:51 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:56:51 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:56:51 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 13:56:27 -0500 Message-ID: In-Reply-To: <495BBFC7.4070405@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclreTiLOa9qi39USCibRTE4UToJHQAABQ1A References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBB5D.40507@mitre.org> <495BBFC7.4070405@mitre.org> From: "Santosh Chokhani" To: "Timothy J. Miller" Cc: "Dr Stephen Henson" , , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: You have some time there and work with client vendors to implement SHA-256 and next generation SHA. I would support a random value extension if clients checked for it. -----Original Message----- From: Timothy J. Miller [mailto:tmiller@mitre.org]=20 Sent: Wednesday, December 31, 2008 1:54 PM To: Santosh Chokhani Cc: Dr Stephen Henson; ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Santosh Chokhani wrote: > So, if you are relying on CAs, why not ask them to switch to SHA-1 as > opposed to adding more software to the CA. SHA-1 is purely a > configuration item for the CA deployments. Because someday SHA-1 (and SHA-2, or any hash algorithm) may be subject=20 to a similar collision generation attack, and the presence of=20 unpredictable data in the cert will defeat it as well. Just trying to be proactive here. -- Tim From owner-ietf-pkix@mail.imc.org Wed Dec 31 11:22:53 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E3D3A69AC for ; Wed, 31 Dec 2008 11:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7oQS4aYVOao for ; Wed, 31 Dec 2008 11:22:52 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C02BC3A68DC for ; Wed, 31 Dec 2008 11:22:51 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJ3uTE098879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 12:03:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVJ3usf098877; Wed, 31 Dec 2008 12:03: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 smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJ3lAr098860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Dec 2008 12:03:55 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBVJ3nwQ024232 for ; Wed, 31 Dec 2008 14:03:49 -0500 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id mBVJ3W6G025792 for ; Wed, 31 Dec 2008 14:03:33 -0500 Message-ID: <495BC204.4040004@nist.gov> Date: Wed, 31 Dec 2008 14:03:32 -0500 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 To: pkix Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> In-Reply-To: <495BB0B9.9000807@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: 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: The attack (http://www.win.tue.nl/hashclash/rogue-ca) does not require the attacker to know the order in which the extensions will appear or the values that will appear in the extensions. The attacker only needs to guess those portions of the DER encoded TBSCertificate that appear before the subjectPublicKeyInfo field. Also the attack does not involve including a "tumor" or any unrecognized extensions in the certificate request. The "tumor" only appears in the rogue certificate that the CA never sees. Since the length of TBSCertificate appears at the beginning of the DER encoding of TBSCertificate, anything that made the length unpredictable would make things more difficult for the attacker. The extensions field could be used for this, but one cannot reasonably vary the length of the certificate by very much. It is much easier for the CA to prevent the attacker from guessing the DER encoding of the part of TBSCertificate that appears before the subjectPublicKeyInfo field by modifying serialNumber, validity, or subject than to do so by modifying the certificate's length. As Blake Ramsdell and I separately noted yesterday, even if there is a requirement to use sequential serial numbers, one can easily create a lot of unpredictability in an unobtrusive fashion by simply randomly setting the notBefore and notAfter times to some values that are within a few minutes of the times that would have been used otherwise. Dave P.S. I am only subscribed to PKIX, so I am assuming that I cannot send this message to the other mail lists that received the original message, but others may feel free to forward it. Mike wrote: > > I sent my last message a bit too hastily. Other ideas that I was > contemplating should have been mentioned including: > > - remove any unrecognized extensions > - remove tumors > > Those could potentially cause problems if for some reason they were > actually needed. This one, though, shouldn't cause trouble: > > - add a private EKU with a random number (or two) in the OID > > That would not mess up the serial number scheme in use or modify the > subject name as has been suggested. > > Mike > > > I wrote: >> There is a simple fix -- a CA can just reorder the extensions prior >> to issuing a certificate. >> >> Mike > > From owner-ietf-pkix@mail.imc.org Wed Dec 31 11:37:20 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB68A3A68E7 for ; Wed, 31 Dec 2008 11:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tFkHS7icG+r for ; Wed, 31 Dec 2008 11:37:20 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A41E23A688E for ; Wed, 31 Dec 2008 11:37:19 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIO1iw096255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:24:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIO1jZ096254; Wed, 31 Dec 2008 11:24: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVINoec096227 for ; Wed, 31 Dec 2008 11:24:00 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 4386 invoked from network); 31 Dec 2008 18:24:12 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:24:12 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:24:12 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 13:23:49 -0500 Message-ID: In-Reply-To: <495BB5D7.7040106@drh-consultancy.demon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrdI9/sOJPqIrSRxWmhrDCQYi/6wAADprw References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> From: "Santosh Chokhani" To: "Dr Stephen Henson" , Cc: , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am a bit concerned about random goo when random goo is one of the things the attacker uses to cause collision. This may limit human or machine's ability to discern mischief. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dr Stephen Henson Sent: Wednesday, December 31, 2008 1:12 PM To: ietf-pkix@imc.org Cc: ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Mike wrote: >=20 > I sent my last message a bit too hastily. Other ideas that I was > contemplating should have been mentioned including: >=20 > - remove any unrecognized extensions > - remove tumors >=20 > Those could potentially cause problems if for some reason they were > actually needed. This one, though, shouldn't cause trouble: >=20 > - add a private EKU with a random number (or two) in the OID >=20 > That would not mess up the serial number scheme in use or modify the > subject name as has been suggested. >=20 Or add a non-critical extension with some randomness in it... Steve. --=20 Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From owner-ietf-pkix@mail.imc.org Wed Dec 31 11:38:37 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC5B3A69F9 for ; Wed, 31 Dec 2008 11:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngzQQbk3q1-d for ; Wed, 31 Dec 2008 11:38:36 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C03153A6808 for ; Wed, 31 Dec 2008 11:38:35 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIOWGQ096306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:24:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIOWbd096304; Wed, 31 Dec 2008 11:24: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 smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIOKme096278; Wed, 31 Dec 2008 11:24:31 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIOK0d010078; Wed, 31 Dec 2008 13:24:20 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIOKfI010073; Wed, 31 Dec 2008 13:24:20 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:24:20 -0500 Message-ID: <495BB8B6.1040703@mitre.org> Date: Wed, 31 Dec 2008 12:23:50 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani CC: Mike , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010602050007000404020402" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms010602050007000404020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit How about adding an otherName to the SAN? You'd need an OID for random data though. Or the CA could insert a method 4 UUID as a URI in the SAN. That's intentionally random. This might upset anyone wanting to use UUIDs as unique names, though (and these people do exist :). Just thinking out loud. -- Tim Santosh Chokhani wrote: > Private EKU could cause problems if EKU is not otherwise present in the > certificate. > > The certificate may not be usable for intended purpose. Not all clients > may recognize "any key purpose" as intended by 5280. > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Mike > Sent: Wednesday, December 31, 2008 12:50 PM > To: ietf-pkix@imc.org > Cc: ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org > Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue > CAcertificate > > > I sent my last message a bit too hastily. Other ideas that I was > contemplating should have been mentioned including: > > - remove any unrecognized extensions > - remove tumors > > Those could potentially cause problems if for some reason they were > actually needed. This one, though, shouldn't cause trouble: > > - add a private EKU with a random number (or two) in the OID > > That would not mess up the serial number scheme in use or modify the > subject name as has been suggested. > > Mike > > > I wrote: >> There is a simple fix -- a CA can just reorder the extensions prior >> to issuing a certificate. >> >> Mike > --------------ms010602050007000404020402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODIzNTBaMCMGCSqGSIb3DQEJBDEWBBTEu3+INXFh8y7RIME+TF+hrvAoaTBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgFUNkYNyIak1Rk2H6NPqM7XEBS4j05b8blOT9+hLnMM2Lwb+t6eFS8jW88JJ MaI6+q3G3oh7PiX3BXiOI8IxlNBAi0a6kegxF9sFnt7Kzrw6Tw8OvefCiDISs8QEWbTFv49g ISeuzouWk+0O/27KhDbO0Y+JG4BzqQeu4tCJRnLnAAAAAAAA --------------ms010602050007000404020402-- From owner-ietf-pkix@mail.imc.org Wed Dec 31 11:55:02 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47FA63A69DD for ; Wed, 31 Dec 2008 11:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTMH7MgVwlO7 for ; Wed, 31 Dec 2008 11:55:01 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EC3A43A6808 for ; Wed, 31 Dec 2008 11:55:00 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIsXFm098231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:54:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIsXNW098230; Wed, 31 Dec 2008 11:54: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 smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIsWLG098215; Wed, 31 Dec 2008 11:54:32 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIsUIg021783; Wed, 31 Dec 2008 13:54:31 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIsUrK021773; Wed, 31 Dec 2008 13:54:30 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:54:30 -0500 Message-ID: <495BBFC7.4070405@mitre.org> Date: Wed, 31 Dec 2008 12:53:59 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani CC: Dr Stephen Henson , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBB5D.40507@mitre.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010106060408020209040905" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms010106060408020209040905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh Chokhani wrote: > So, if you are relying on CAs, why not ask them to switch to SHA-1 as > opposed to adding more software to the CA. SHA-1 is purely a > configuration item for the CA deployments. Because someday SHA-1 (and SHA-2, or any hash algorithm) may be subject to a similar collision generation attack, and the presence of unpredictable data in the cert will defeat it as well. Just trying to be proactive here. -- Tim --------------ms010106060408020209040905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODUzNTlaMCMGCSqGSIb3DQEJBDEWBBRvm0ZUBx2kUMXPZMdTcjy9VsI7hTBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgFfgtFy7Di89XncxZPvVvOWVa1zy05iBeqhstrmEKD0MBObvNiR0lbvnC/Xt VQOKE9jnfS6QSzzE2Iik8Y92fDAhbOWgKdlWcxV9q4+qHjf4Q9aefulpw1SObVxtCcHGhSCt i64UPYyummro3guFQumjkhIxhu8Wcy9LbvN3z1yrAAAAAAAA --------------ms010106060408020209040905-- From owner-ietf-pkix@mail.imc.org Wed Dec 31 12:10:28 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD4C3A68E7 for ; Wed, 31 Dec 2008 12:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyR7Bm5hZ9Us for ; Wed, 31 Dec 2008 12:10:27 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 72AC33A6808 for ; Wed, 31 Dec 2008 12:10:27 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJKaVC000150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 12:20:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVJKaOo000149; Wed, 31 Dec 2008 12:20:36 -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 stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJKPvX000128; Wed, 31 Dec 2008 12:20:36 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Wed, 31 Dec 2008 14:20:23 -0500 Message-ID: <200812311920.mBVJKNAQ012599@stingray.missi.ncsc.mil> In-Reply-To: <411C6DBE577BC8F60969AF29@atlantis.pc.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate Thread-Index: Aclq5IgC5ZANbzGKQ/GkJqeRHNnrQgAkuFSw References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <08bb01c96ac7$1cd5a750$5680f5f0$@com> <200812302328.mBUNSDJj019534@raisinbran.srv.cs.cmu.edu> <411C6DBE577BC8F60969AF29@atlantis.pc.cs.cmu.edu> From: "Kemp, David P." To: , , , X-OriginalArrivalTime: 31 Dec 2008 19:17:00.0562 (UTC) FILETIME=[5B1E9F20:01C96B7C] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just to be precise, past MD5 certificates should be safe as long as there are no second-preimage attacks. I have no idea* whether there are any computational shortcuts to finding a second preimage (where both the hashed data and its digest value are known) relative to finding a preimage (where only the digest value is known), but in principle second-preimage attacks might be feasible sooner. Dave * for example, http://www.springerlink.com/content/yut517362112765h/ indicates that 1 in 2^56 messages may be "weak" against a specified attack on MD4. What is needed is an attack on MD5 where many or all messages are "weak". -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Jeffrey Hutzelman Sent: Tuesday, December 30, 2008 6:46 PM To: Santosh Chokhani; Peter Hesse; RL 'Bob' Morgan; Paul Hoffman Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org; jhutz@cmu.edu Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate --On Tuesday, December 30, 2008 06:28:07 PM -0500 Santosh Chokhani=20 wrote: > Since the attack is computing pre-image, I suspect that past MD5 > certificates are safe until the attack was devised. The attack does _not_ involve computing a preimage; it involves computing a=20 colliding pair one of which has a prefix which is predictable but not=20 controllable, followed by a controllable component consisting of some=20 minimum number of bits followed by at least three aligned message blocks.=20 What makes existing certificates safe is that there are no known preimage=20 attacks against MD5, couple with limitations of the technique used to=20 construct the colliding pair. However, there is a limit to how "safe" existing certificates are, because=20 the attack does not require anything that was not known 3-4 years ago. The=20 only change is that with the latest techniques for computing collisions, it=20 is possible to do so in a short enough time to be able to predict the=20 validity and serial number that will be used by the issuer with fairly high=20 probability. -- Jeff From owner-ietf-pkix@mail.imc.org Wed Dec 31 13:25:10 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9BBD3A67EE for ; Wed, 31 Dec 2008 13:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFCDNFgXHUuL for ; Wed, 31 Dec 2008 13:25:09 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id AA5253A6819 for ; Wed, 31 Dec 2008 13:25:08 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVL1UHG007358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 14:01:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVL1U3x007357; Wed, 31 Dec 2008 14:01: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.grid.kiae.ru (mail.grid.kiae.ru [144.206.66.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVL1HVu007334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Dec 2008 14:01:30 -0700 (MST) (envelope-from rea@grid.kiae.ru) Received: from phoenix.codelabs.ru (ppp85-141-67-189.pppoe.mtu-net.ru [85.141.67.189]) by mail.grid.kiae.ru (Postfix) with ESMTPSA id 6CA4554D02C; Thu, 1 Jan 2009 00:01:16 +0300 (MSK) Date: Thu, 1 Jan 2009 00:01:15 +0300 From: Eygene Ryabinkin To: "David A. Cooper" Cc: pkix Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate Message-ID: Reply-To: rea@grid.kiae.ru References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BC204.4040004@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <495BC204.4040004@nist.gov> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David, good day. Wed, Dec 31, 2008 at 02:03:32PM -0500, David A. Cooper wrote: > The attack (http://www.win.tue.nl/hashclash/rogue-ca) does not require > the attacker to know the order in which the extensions will appear or > the values that will appear in the extensions. Really? Unless I am missing something, the hash from the A + B will be different from the hash of B + A, if '+' is some sort of concatenation. In fact, changing the single bit of input should produce greatly varying hash. > The attacker only needs to guess those portions of the DER encoded > TBSCertificate that appear before the subjectPublicKeyInfo field. No, since attackers are generating collisions prior to the signing the request at CA, they should be sure that the hash computed by CA will be the same as the hash computed by attackers. And since the whole DER-encoded TBSCertificate chunk is user for a hash generation, every bit of it matters. You're right that the attackers could vary the arbitrary bits of the two certificates during the collision search. But once collision is found, this is the end, certificates are fixed and CA is used just for the signature generation. And this is the reason why people seek the serial number and validity dates of the colliding-certificate-to-be-signed. And that's why randomization of the serial number and/or validity dates will help to avoid or at least delay the attackers. -- Eygene Ryabinkin, Russian Research Centre "Kurchatov Institute" From owner-ietf-pkix@mail.imc.org Wed Dec 31 14:08:55 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03DAD3A696C for ; Wed, 31 Dec 2008 14:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqt4-V2g3gRj for ; Wed, 31 Dec 2008 14:08:53 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 615133A67F8 for ; Wed, 31 Dec 2008 14:08:53 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVLnR0a011498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 14:49:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVLnRgZ011497; Wed, 31 Dec 2008 14:49: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 smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVLnGc0011483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Dec 2008 14:49:27 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBVLn742030982; Wed, 31 Dec 2008 16:49:07 -0500 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id mBVLn22A032518; Wed, 31 Dec 2008 16:49:03 -0500 Message-ID: <495BE8CE.7020003@nist.gov> Date: Wed, 31 Dec 2008 16:49:02 -0500 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 To: rea@grid.kiae.ru CC: pkix Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BC204.4040004@nist.gov> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: 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: Eygene, You are correct that a change anywhere in the certificate will change the hash. However, the attacker does not need to know in advance what the hash value will be, only that the hash of the real certificate and the rogue certificate will be the same. If you look at the image depicting the generation of the collision in the attack (http://www.win.tue.nl/hashclash/rogue-ca/downloads/alignment.pdf), you will see why these two statements are not the same. Hash functions such as MD5, SHA-1, SHA-256, etc. work by processing messages in blocks. In the case of MD5, the blocks are 64 bytes each. In the attacks, the attackers needed to find two certificates such that the results of hashing the first 704 bytes (11 blocks) of both the real and rogue certificates would be the same. Once they had found such a collision, it was guaranteed that the hashes of the two certificates would be the same as long as the contents of the remaining bytes in both certificates (blocks 12-15) were the same. In the diagram, it notes that blocks 12-15 are identical in both the real certificate and the rogue certificate. In the rogue certificate, unlike in the real certificate, all of these bytes are just treated as random garbage. The contents of blocks 12-15 can be changed arbitrarily, as long as the same changes are made in both the real and rogue certificates, and the result will still be two certificates with the same hash value. So, the attack works as follows: guess and/or generate the contents of the certificate that will precede the subjectPublicKeyInfo field, including the overall length of the certificate. Create a key pair for the real certificate and contents for the rogue certificate such there is a collision in the intermediate output of the hash function for the two certificates (e.g., such that the output of the hash function after processing the first 10 blocks of each certificate is the same). Submit the certificate request with the information for the real certificate and then get back the real certificate from the CA. Copy all bytes from the real certificate that appear after the point of the collision into the rogue certificate (e.g., copy blocks 11-16 from the real certificate to the rogue certificate). If the CA incorporates randomness into the extensions field (but in a way that does not make the certificate's length unpredictable), the attacker may not be able to predict the hash value of the entire certificate, but that will not keep the attacker from reliably creating a collision. To put it another way, for all of the commonly used hash functions (MD5, SHA-1, SHA-256, etc.), if H(M) = H(M') then H(M || N) = H(M' || N) [I believe that the lengths of M and M' need to be the same and an even multiple of the block size used by the hash function]. So, an attacker who wants to create two messages, M || N and M' || N, such that H(M || N) = H(M' || N) can do so by creating M and M' such that H(M) = H(M') without needing to know the value of N. Dave Eygene Ryabinkin wrote: > David, good day. > > Wed, Dec 31, 2008 at 02:03:32PM -0500, David A. Cooper wrote: > >> The attack (http://www.win.tue.nl/hashclash/rogue-ca) does not require >> the attacker to know the order in which the extensions will appear or >> the values that will appear in the extensions. >> > > Really? Unless I am missing something, the hash from the A + B will be > different from the hash of B + A, if '+' is some sort of concatenation. > In fact, changing the single bit of input should produce greatly varying > hash. > > >> The attacker only needs to guess those portions of the DER encoded >> TBSCertificate that appear before the subjectPublicKeyInfo field. >> > > No, since attackers are generating collisions prior to the signing > the request at CA, they should be sure that the hash computed by CA > will be the same as the hash computed by attackers. And since the > whole DER-encoded TBSCertificate chunk is user for a hash generation, > every bit of it matters. > > You're right that the attackers could vary the arbitrary bits of the two > certificates during the collision search. But once collision is found, > this is the end, certificates are fixed and CA is used just for the > signature generation. And this is the reason why people seek the serial > number and validity dates of the colliding-certificate-to-be-signed. > And that's why randomization of the serial number and/or validity > dates will help to avoid or at least delay the attackers. > From mary@aignerclark.com Wed Dec 31 19:47:51 2008 Return-Path: X-Original-To: ietfarch-pkix-archive@core3.amsl.com Delivered-To: ietfarch-pkix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6677F3A6A98 for ; Wed, 31 Dec 2008 19:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.116 X-Spam-Level: X-Spam-Status: No, score=-21.116 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J47hMcj7-gin for ; Wed, 31 Dec 2008 19:47:50 -0800 (PST) Received: from host46-129-dynamic.2-87-r.retail.telecomitalia.it (host46-129-dynamic.2-87-r.retail.telecomitalia.it [87.2.129.46]) by core3.amsl.com (Postfix) with SMTP id 6AECE3A67A7 for ; Wed, 31 Dec 2008 19:47:45 -0800 (PST) To: Subject: May your Dreams Come True! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090101034747.6AECE3A67A7@core3.amsl.com> Date: Wed, 31 Dec 2008 19:47:45 -0800 (PST)


Please do not reply to this email. To contact Armstrong Shank Advertising, please visit us

This email message was sent to . If you do not wish to receive further communications from Armstrong Shank Advertising, click here to unsubscribe.

If you've experience any difficulty in being removed from a Armstrong Shank Advertising email list, click here for personalized help.

Copyright © 2008 Armstrong Shank Advertising, Inc. All rights reserved.
7450 S Seneca, Haysville, KS 67060

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVLnR0a011498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 14:49:27 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVLnRgZ011497; Wed, 31 Dec 2008 14:49: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 smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVLnGc0011483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Dec 2008 14:49:27 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBVLn742030982; Wed, 31 Dec 2008 16:49:07 -0500 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id mBVLn22A032518; Wed, 31 Dec 2008 16:49:03 -0500 Message-ID: <495BE8CE.7020003@nist.gov> Date: Wed, 31 Dec 2008 16:49:02 -0500 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 To: rea@grid.kiae.ru CC: pkix Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BC204.4040004@nist.gov> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: 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: Eygene, You are correct that a change anywhere in the certificate will change the hash. However, the attacker does not need to know in advance what the hash value will be, only that the hash of the real certificate and the rogue certificate will be the same. If you look at the image depicting the generation of the collision in the attack (http://www.win.tue.nl/hashclash/rogue-ca/downloads/alignment.pdf), you will see why these two statements are not the same. Hash functions such as MD5, SHA-1, SHA-256, etc. work by processing messages in blocks. In the case of MD5, the blocks are 64 bytes each. In the attacks, the attackers needed to find two certificates such that the results of hashing the first 704 bytes (11 blocks) of both the real and rogue certificates would be the same. Once they had found such a collision, it was guaranteed that the hashes of the two certificates would be the same as long as the contents of the remaining bytes in both certificates (blocks 12-15) were the same. In the diagram, it notes that blocks 12-15 are identical in both the real certificate and the rogue certificate. In the rogue certificate, unlike in the real certificate, all of these bytes are just treated as random garbage. The contents of blocks 12-15 can be changed arbitrarily, as long as the same changes are made in both the real and rogue certificates, and the result will still be two certificates with the same hash value. So, the attack works as follows: guess and/or generate the contents of the certificate that will precede the subjectPublicKeyInfo field, including the overall length of the certificate. Create a key pair for the real certificate and contents for the rogue certificate such there is a collision in the intermediate output of the hash function for the two certificates (e.g., such that the output of the hash function after processing the first 10 blocks of each certificate is the same). Submit the certificate request with the information for the real certificate and then get back the real certificate from the CA. Copy all bytes from the real certificate that appear after the point of the collision into the rogue certificate (e.g., copy blocks 11-16 from the real certificate to the rogue certificate). If the CA incorporates randomness into the extensions field (but in a way that does not make the certificate's length unpredictable), the attacker may not be able to predict the hash value of the entire certificate, but that will not keep the attacker from reliably creating a collision. To put it another way, for all of the commonly used hash functions (MD5, SHA-1, SHA-256, etc.), if H(M) = H(M') then H(M || N) = H(M' || N) [I believe that the lengths of M and M' need to be the same and an even multiple of the block size used by the hash function]. So, an attacker who wants to create two messages, M || N and M' || N, such that H(M || N) = H(M' || N) can do so by creating M and M' such that H(M) = H(M') without needing to know the value of N. Dave Eygene Ryabinkin wrote: > David, good day. > > Wed, Dec 31, 2008 at 02:03:32PM -0500, David A. Cooper wrote: > >> The attack (http://www.win.tue.nl/hashclash/rogue-ca) does not require >> the attacker to know the order in which the extensions will appear or >> the values that will appear in the extensions. >> > > Really? Unless I am missing something, the hash from the A + B will be > different from the hash of B + A, if '+' is some sort of concatenation. > In fact, changing the single bit of input should produce greatly varying > hash. > > >> The attacker only needs to guess those portions of the DER encoded >> TBSCertificate that appear before the subjectPublicKeyInfo field. >> > > No, since attackers are generating collisions prior to the signing > the request at CA, they should be sure that the hash computed by CA > will be the same as the hash computed by attackers. And since the > whole DER-encoded TBSCertificate chunk is user for a hash generation, > every bit of it matters. > > You're right that the attackers could vary the arbitrary bits of the two > certificates during the collision search. But once collision is found, > this is the end, certificates are fixed and CA is used just for the > signature generation. And this is the reason why people seek the serial > number and validity dates of the colliding-certificate-to-be-signed. > And that's why randomization of the serial number and/or validity > dates will help to avoid or at least delay the attackers. > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVL1UHG007358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 14:01:31 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVL1U3x007357; Wed, 31 Dec 2008 14:01: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.grid.kiae.ru (mail.grid.kiae.ru [144.206.66.2]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVL1HVu007334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Dec 2008 14:01:30 -0700 (MST) (envelope-from rea@grid.kiae.ru) Received: from phoenix.codelabs.ru (ppp85-141-67-189.pppoe.mtu-net.ru [85.141.67.189]) by mail.grid.kiae.ru (Postfix) with ESMTPSA id 6CA4554D02C; Thu, 1 Jan 2009 00:01:16 +0300 (MSK) Date: Thu, 1 Jan 2009 00:01:15 +0300 From: Eygene Ryabinkin To: "David A. Cooper" Cc: pkix Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate Message-ID: Reply-To: rea@grid.kiae.ru References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BC204.4040004@nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <495BC204.4040004@nist.gov> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David, good day. Wed, Dec 31, 2008 at 02:03:32PM -0500, David A. Cooper wrote: > The attack (http://www.win.tue.nl/hashclash/rogue-ca) does not require > the attacker to know the order in which the extensions will appear or > the values that will appear in the extensions. Really? Unless I am missing something, the hash from the A + B will be different from the hash of B + A, if '+' is some sort of concatenation. In fact, changing the single bit of input should produce greatly varying hash. > The attacker only needs to guess those portions of the DER encoded > TBSCertificate that appear before the subjectPublicKeyInfo field. No, since attackers are generating collisions prior to the signing the request at CA, they should be sure that the hash computed by CA will be the same as the hash computed by attackers. And since the whole DER-encoded TBSCertificate chunk is user for a hash generation, every bit of it matters. You're right that the attackers could vary the arbitrary bits of the two certificates during the collision search. But once collision is found, this is the end, certificates are fixed and CA is used just for the signature generation. And this is the reason why people seek the serial number and validity dates of the colliding-certificate-to-be-signed. And that's why randomization of the serial number and/or validity dates will help to avoid or at least delay the attackers. -- Eygene Ryabinkin, Russian Research Centre "Kurchatov Institute" Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJKaVC000150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 12:20:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVJKaOo000149; Wed, 31 Dec 2008 12:20:36 -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 stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJKPvX000128; Wed, 31 Dec 2008 12:20:36 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Wed, 31 Dec 2008 14:20:23 -0500 Message-ID: <200812311920.mBVJKNAQ012599@stingray.missi.ncsc.mil> In-Reply-To: <411C6DBE577BC8F60969AF29@atlantis.pc.cs.cmu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate Thread-Index: Aclq5IgC5ZANbzGKQ/GkJqeRHNnrQgAkuFSw References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <08bb01c96ac7$1cd5a750$5680f5f0$@com> <200812302328.mBUNSDJj019534@raisinbran.srv.cs.cmu.edu> <411C6DBE577BC8F60969AF29@atlantis.pc.cs.cmu.edu> From: "Kemp, David P." To: , , , X-OriginalArrivalTime: 31 Dec 2008 19:17:00.0562 (UTC) FILETIME=[5B1E9F20:01C96B7C] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Just to be precise, past MD5 certificates should be safe as long as there are no second-preimage attacks. I have no idea* whether there are any computational shortcuts to finding a second preimage (where both the hashed data and its digest value are known) relative to finding a preimage (where only the digest value is known), but in principle second-preimage attacks might be feasible sooner. Dave * for example, http://www.springerlink.com/content/yut517362112765h/ indicates that 1 in 2^56 messages may be "weak" against a specified attack on MD4. What is needed is an attack on MD5 where many or all messages are "weak". -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Jeffrey Hutzelman Sent: Tuesday, December 30, 2008 6:46 PM To: Santosh Chokhani; Peter Hesse; RL 'Bob' Morgan; Paul Hoffman Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org; jhutz@cmu.edu Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate --On Tuesday, December 30, 2008 06:28:07 PM -0500 Santosh Chokhani=20 wrote: > Since the attack is computing pre-image, I suspect that past MD5 > certificates are safe until the attack was devised. The attack does _not_ involve computing a preimage; it involves computing a=20 colliding pair one of which has a prefix which is predictable but not=20 controllable, followed by a controllable component consisting of some=20 minimum number of bits followed by at least three aligned message blocks.=20 What makes existing certificates safe is that there are no known preimage=20 attacks against MD5, couple with limitations of the technique used to=20 construct the colliding pair. However, there is a limit to how "safe" existing certificates are, because=20 the attack does not require anything that was not known 3-4 years ago. The=20 only change is that with the latest techniques for computing collisions, it=20 is possible to do so in a short enough time to be able to predict the=20 validity and serial number that will be used by the issuer with fairly high=20 probability. -- Jeff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJ3uTE098879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 12:03:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVJ3usf098877; Wed, 31 Dec 2008 12:03: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 smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVJ3lAr098860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Dec 2008 12:03:55 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBVJ3nwQ024232 for ; Wed, 31 Dec 2008 14:03:49 -0500 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id mBVJ3W6G025792 for ; Wed, 31 Dec 2008 14:03:33 -0500 Message-ID: <495BC204.4040004@nist.gov> Date: Wed, 31 Dec 2008 14:03:32 -0500 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 To: pkix Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> In-Reply-To: <495BB0B9.9000807@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: 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: The attack (http://www.win.tue.nl/hashclash/rogue-ca) does not require the attacker to know the order in which the extensions will appear or the values that will appear in the extensions. The attacker only needs to guess those portions of the DER encoded TBSCertificate that appear before the subjectPublicKeyInfo field. Also the attack does not involve including a "tumor" or any unrecognized extensions in the certificate request. The "tumor" only appears in the rogue certificate that the CA never sees. Since the length of TBSCertificate appears at the beginning of the DER encoding of TBSCertificate, anything that made the length unpredictable would make things more difficult for the attacker. The extensions field could be used for this, but one cannot reasonably vary the length of the certificate by very much. It is much easier for the CA to prevent the attacker from guessing the DER encoding of the part of TBSCertificate that appears before the subjectPublicKeyInfo field by modifying serialNumber, validity, or subject than to do so by modifying the certificate's length. As Blake Ramsdell and I separately noted yesterday, even if there is a requirement to use sequential serial numbers, one can easily create a lot of unpredictability in an unobtrusive fashion by simply randomly setting the notBefore and notAfter times to some values that are within a few minutes of the times that would have been used otherwise. Dave P.S. I am only subscribed to PKIX, so I am assuming that I cannot send this message to the other mail lists that received the original message, but others may feel free to forward it. Mike wrote: > > I sent my last message a bit too hastily. Other ideas that I was > contemplating should have been mentioned including: > > - remove any unrecognized extensions > - remove tumors > > Those could potentially cause problems if for some reason they were > actually needed. This one, though, shouldn't cause trouble: > > - add a private EKU with a random number (or two) in the OID > > That would not mess up the serial number scheme in use or modify the > subject name as has been suggested. > > Mike > > > I wrote: >> There is a simple fix -- a CA can just reorder the extensions prior >> to issuing a certificate. >> >> Mike > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIuUhd098366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:56:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIuUBb098363; Wed, 31 Dec 2008 11:56: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVIuSSC098350 for ; Wed, 31 Dec 2008 11:56:29 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 4657 invoked from network); 31 Dec 2008 18:56:51 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:56:51 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:56:51 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 13:56:27 -0500 Message-ID: In-Reply-To: <495BBFC7.4070405@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclreTiLOa9qi39USCibRTE4UToJHQAABQ1A References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBB5D.40507@mitre.org> <495BBFC7.4070405@mitre.org> From: "Santosh Chokhani" To: "Timothy J. Miller" Cc: "Dr Stephen Henson" , , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: You have some time there and work with client vendors to implement SHA-256 and next generation SHA. I would support a random value extension if clients checked for it. -----Original Message----- From: Timothy J. Miller [mailto:tmiller@mitre.org]=20 Sent: Wednesday, December 31, 2008 1:54 PM To: Santosh Chokhani Cc: Dr Stephen Henson; ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Santosh Chokhani wrote: > So, if you are relying on CAs, why not ask them to switch to SHA-1 as > opposed to adding more software to the CA. SHA-1 is purely a > configuration item for the CA deployments. Because someday SHA-1 (and SHA-2, or any hash algorithm) may be subject=20 to a similar collision generation attack, and the presence of=20 unpredictable data in the cert will defeat it as well. Just trying to be proactive here. -- Tim Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIsXFm098231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:54:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIsXNW098230; Wed, 31 Dec 2008 11:54: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 smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIsWLG098215; Wed, 31 Dec 2008 11:54:32 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIsUIg021783; Wed, 31 Dec 2008 13:54:31 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIsUrK021773; Wed, 31 Dec 2008 13:54:30 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:54:30 -0500 Message-ID: <495BBFC7.4070405@mitre.org> Date: Wed, 31 Dec 2008 12:53:59 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani CC: Dr Stephen Henson , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBB5D.40507@mitre.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010106060408020209040905" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms010106060408020209040905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh Chokhani wrote: > So, if you are relying on CAs, why not ask them to switch to SHA-1 as > opposed to adding more software to the CA. SHA-1 is purely a > configuration item for the CA deployments. Because someday SHA-1 (and SHA-2, or any hash algorithm) may be subject to a similar collision generation attack, and the presence of unpredictable data in the cert will defeat it as well. Just trying to be proactive here. -- Tim --------------ms010106060408020209040905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODUzNTlaMCMGCSqGSIb3DQEJBDEWBBRvm0ZUBx2kUMXPZMdTcjy9VsI7hTBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgFfgtFy7Di89XncxZPvVvOWVa1zy05iBeqhstrmEKD0MBObvNiR0lbvnC/Xt VQOKE9jnfS6QSzzE2Iik8Y92fDAhbOWgKdlWcxV9q4+qHjf4Q9aefulpw1SObVxtCcHGhSCt i64UPYyummro3guFQumjkhIxhu8Wcy9LbvN3z1yrAAAAAAAA --------------ms010106060408020209040905-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIoGWb097941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:50:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIoGo9097940; Wed, 31 Dec 2008 11:50:16 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVIoE0c097927 for ; Wed, 31 Dec 2008 11:50:15 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 4597 invoked from network); 31 Dec 2008 18:50:37 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:50:37 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:50:37 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 13:50:13 -0500 Message-ID: In-Reply-To: <495BBB5D.40507@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrdpWRZ2DsZT93SYeylkbr3Wg+mAAAUebw References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBB5D.40507@mitre.org> From: "Santosh Chokhani" To: "Timothy J. Miller" Cc: "Dr Stephen Henson" , , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: These things need to be thought through. If all the CAs did this, it might work. But, what if the client side was looking for junk in the certificate as evidence of collision? Also, client will not enforce this. So, if you are relying on CAs, why not ask them to switch to SHA-1 as opposed to adding more software to the CA. SHA-1 is purely a configuration item for the CA deployments. I just find that all three mail lists are getting work out and real message and analysis is getting lost. For example, folks are still posting misinformation that self-signed roots have a hash problem. Signatures on self-signed roots are gratuitous from security viewpoint. So, we do not want to cry wolf and undertaken replacing roots which will be a humongous waste to time and money. Signatures and hence hash used to sign these do not matter. =20 -----Original Message----- From: Timothy J. Miller [mailto:tmiller@mitre.org]=20 Sent: Wednesday, December 31, 2008 1:35 PM To: Santosh Chokhani Cc: Dr Stephen Henson; ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Santosh Chokhani wrote: > I am a bit concerned about random goo when random goo is one of the > things the attacker uses to cause collision. This may limit human or > machine's ability to discern mischief. I don't see how, if the random goo is added by the CA. It defeats=20 chosen prefix attacks as a class. -- Tim Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIZgIw096978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:35:42 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIZgjE096977; Wed, 31 Dec 2008 11:35:42 -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-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIZesj096966; Wed, 31 Dec 2008 11:35:40 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIZdvc006788; Wed, 31 Dec 2008 13:35:40 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIZdEj006785; Wed, 31 Dec 2008 13:35:39 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:35:39 -0500 Message-ID: <495BBB5D.40507@mitre.org> Date: Wed, 31 Dec 2008 12:35:09 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani CC: Dr Stephen Henson , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010007000707070000040106" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms010007000707070000040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh Chokhani wrote: > I am a bit concerned about random goo when random goo is one of the > things the attacker uses to cause collision. This may limit human or > machine's ability to discern mischief. I don't see how, if the random goo is added by the CA. It defeats chosen prefix attacks as a class. -- Tim --------------ms010007000707070000040106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODM1MDlaMCMGCSqGSIb3DQEJBDEWBBQ7wSCe4F6a7ye+v4kS0uvOGSEZxjBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgCTIqWUo25RX2p72ZoyshHyXDNPdtnFa2cGv0bRgIZSCX0rIi5+1Nl8n3imi L3lCMkQOeE0Ai3QU62e1BzsBzXl4VavVhoeb8JHhzeTZAdrXmxQCJ48CB4R1k+TKB8mtkCCT E1FJ8rPqf9EeE4BVdvHvPSb8zf3mUy3iG4rA9D7zAAAAAAAA --------------ms010007000707070000040106-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIYbiD096921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:34:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIYbHd096920; Wed, 31 Dec 2008 11:34: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-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIYZ0D096908; Wed, 31 Dec 2008 11:34:35 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIYY60003982; Wed, 31 Dec 2008 13:34:35 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIYYd0003979; Wed, 31 Dec 2008 13:34:34 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:34:34 -0500 Message-ID: <495BBB1C.3050404@mitre.org> Date: Wed, 31 Dec 2008 12:34:04 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Dr Stephen Henson CC: "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> <495BBA35.9000404@mitre.org> In-Reply-To: <495BBA35.9000404@mitre.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070406060900010800080503" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms070406060900010800080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Timothy J. Miller wrote: > Dr Stephen Henson wrote: >> Mike wrote: >>> I sent my last message a bit too hastily. Other ideas that I was >>> contemplating should have been mentioned including: >>> >>> - remove any unrecognized extensions >>> - remove tumors >>> >>> Those could potentially cause problems if for some reason they were >>> actually needed. This one, though, shouldn't cause trouble: >>> >>> - add a private EKU with a random number (or two) in the OID >>> >>> That would not mess up the serial number scheme in use or modify the >>> subject name as has been suggested. >>> >> >> Or add a non-critical extension with some randomness in it... > > Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER ::= {id-ce > 55} or should I? :) draft-01 already: Make that id-ce-magicNumber instead. :) -- Tim --------------ms070406060900010800080503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODM0MDRaMCMGCSqGSIb3DQEJBDEWBBSSJNMK3zrvAhp1fLThyKuCS2ZbzDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgChOMbV+0oDSDKO7kDjIuxQIjRDbYZag6cll5l/fgLT0BVA+ko8npPtOmf1v ctmCWIwx3wUmGBqLvXlnZIJ17XPwuT8Pkkqwte0q7M4aY3HW0J7UICoVIi9PXBsV75NklUR9 nh8lnb3TROTWQO2G2MG/8Z7Po5Sw1wOvBlDbyElIAAAAAAAA --------------ms070406060900010800080503-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIUkZQ096660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:30:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIUk5u096659; Wed, 31 Dec 2008 11:30:46 -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-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIUiF3096646; Wed, 31 Dec 2008 11:30:44 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIUhxA026624; Wed, 31 Dec 2008 13:30:44 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIUh7u026614; Wed, 31 Dec 2008 13:30:43 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:30:43 -0500 Message-ID: <495BBA35.9000404@mitre.org> Date: Wed, 31 Dec 2008 12:30:13 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Dr Stephen Henson CC: "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> In-Reply-To: <495BB5D7.7040106@drh-consultancy.demon.co.uk> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060500070900000409080503" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms060500070900000409080503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dr Stephen Henson wrote: > Mike wrote: >> I sent my last message a bit too hastily. Other ideas that I was >> contemplating should have been mentioned including: >> >> - remove any unrecognized extensions >> - remove tumors >> >> Those could potentially cause problems if for some reason they were >> actually needed. This one, though, shouldn't cause trouble: >> >> - add a private EKU with a random number (or two) in the OID >> >> That would not mess up the serial number scheme in use or modify the >> subject name as has been suggested. >> > > Or add a non-critical extension with some randomness in it... Do you want to propose id-ce-magicCookie OBJECT IDENTIFIER ::= {id-ce 55} or should I? :) -- Tim --------------ms060500070900000409080503 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODMwMTNaMCMGCSqGSIb3DQEJBDEWBBTDOGnW2taEtjPNTda+B7sp3jwHXjBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgI4Tiunxma0T7GovwYWUekJusn0Fg6S544dlebV3nxswPVkGqdvuGRb4yaBq qYonL0ehGR+ZMi1kFYNOLd0bBOibJOtHdubkqmjHMBENsjbiaUnFwd8pN4NW0GIinVLnUTYa 1vfzSaor2vdmDWTBBGF8QAXJPFF76ZsLkkqoz8BJAAAAAAAA --------------ms060500070900000409080503-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIOWGQ096306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:24:32 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIOWbd096304; Wed, 31 Dec 2008 11:24: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 smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIOKme096278; Wed, 31 Dec 2008 11:24:31 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIOK0d010078; Wed, 31 Dec 2008 13:24:20 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVIOKfI010073; Wed, 31 Dec 2008 13:24:20 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 13:24:20 -0500 Message-ID: <495BB8B6.1040703@mitre.org> Date: Wed, 31 Dec 2008 12:23:50 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani CC: Mike , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010602050007000404020402" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms010602050007000404020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit How about adding an otherName to the SAN? You'd need an OID for random data though. Or the CA could insert a method 4 UUID as a URI in the SAN. That's intentionally random. This might upset anyone wanting to use UUIDs as unique names, though (and these people do exist :). Just thinking out loud. -- Tim Santosh Chokhani wrote: > Private EKU could cause problems if EKU is not otherwise present in the > certificate. > > The certificate may not be usable for intended purpose. Not all clients > may recognize "any key purpose" as intended by 5280. > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Mike > Sent: Wednesday, December 31, 2008 12:50 PM > To: ietf-pkix@imc.org > Cc: ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org > Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue > CAcertificate > > > I sent my last message a bit too hastily. Other ideas that I was > contemplating should have been mentioned including: > > - remove any unrecognized extensions > - remove tumors > > Those could potentially cause problems if for some reason they were > actually needed. This one, though, shouldn't cause trouble: > > - add a private EKU with a random number (or two) in the OID > > That would not mess up the serial number scheme in use or modify the > subject name as has been suggested. > > Mike > > > I wrote: >> There is a simple fix -- a CA can just reorder the extensions prior >> to issuing a certificate. >> >> Mike > --------------ms010602050007000404020402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExODIzNTBaMCMGCSqGSIb3DQEJBDEWBBTEu3+INXFh8y7RIME+TF+hrvAoaTBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgFUNkYNyIak1Rk2H6NPqM7XEBS4j05b8blOT9+hLnMM2Lwb+t6eFS8jW88JJ MaI6+q3G3oh7PiX3BXiOI8IxlNBAi0a6kegxF9sFnt7Kzrw6Tw8OvefCiDISs8QEWbTFv49g ISeuzouWk+0O/27KhDbO0Y+JG4BzqQeu4tCJRnLnAAAAAAAA --------------ms010602050007000404020402-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIO1iw096255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:24:01 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIO1jZ096254; Wed, 31 Dec 2008 11:24: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVINoec096227 for ; Wed, 31 Dec 2008 11:24:00 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 4386 invoked from network); 31 Dec 2008 18:24:12 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:24:12 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:24:12 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 13:23:49 -0500 Message-ID: In-Reply-To: <495BB5D7.7040106@drh-consultancy.demon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrdI9/sOJPqIrSRxWmhrDCQYi/6wAADprw References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> <495BB5D7.7040106@drh-consultancy.demon.co.uk> From: "Santosh Chokhani" To: "Dr Stephen Henson" , Cc: , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am a bit concerned about random goo when random goo is one of the things the attacker uses to cause collision. This may limit human or machine's ability to discern mischief. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Dr Stephen Henson Sent: Wednesday, December 31, 2008 1:12 PM To: ietf-pkix@imc.org Cc: ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Mike wrote: >=20 > I sent my last message a bit too hastily. Other ideas that I was > contemplating should have been mentioned including: >=20 > - remove any unrecognized extensions > - remove tumors >=20 > Those could potentially cause problems if for some reason they were > actually needed. This one, though, shouldn't cause trouble: >=20 > - add a private EKU with a random number (or two) in the OID >=20 > That would not mess up the serial number scheme in use or modify the > subject name as has been suggested. >=20 Or add a non-critical extension with some randomness in it... Steve. --=20 Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIBf09095597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:11:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVIBfGH095594; Wed, 31 Dec 2008 11:11: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 relay10.mail.uk.clara.net (relay10.mail.uk.clara.net [80.168.70.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVIBTXB095574; Wed, 31 Dec 2008 11:11:40 -0700 (MST) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49616 helo=[192.168.7.8]) by relay10.mail.uk.clara.net with esmtpa (Exim 4.69) (envelope-from ) id 1LI5XR-0000nh-An; Wed, 31 Dec 2008 18:11:26 +0000 Message-ID: <495BB5D7.7040106@drh-consultancy.demon.co.uk> Date: Wed, 31 Dec 2008 18:11:35 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ietf-pkix@imc.org CC: ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> In-Reply-To: <495BB0B9.9000807@pobox.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mike wrote: > > I sent my last message a bit too hastily. Other ideas that I was > contemplating should have been mentioned including: > > - remove any unrecognized extensions > - remove tumors > > Those could potentially cause problems if for some reason they were > actually needed. This one, though, shouldn't cause trouble: > > - add a private EKU with a random number (or two) in the OID > > That would not mess up the serial number scheme in use or modify the > subject name as has been suggested. > Or add a non-critical extension with some randomness in it... Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVI3Gpv095203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 11:03:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVI3GDN095201; Wed, 31 Dec 2008 11:03:16 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVI3Erg095186 for ; Wed, 31 Dec 2008 11:03:15 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 4249 invoked from network); 31 Dec 2008 18:03:37 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 18:03:37 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 18:03:37 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 13:03:13 -0500 Message-ID: In-Reply-To: <495BB0B9.9000807@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrcaZvjthE5F+NRLKwI78nj+9Z5AAACsDQ References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> <495BB0B9.9000807@pobox.com> From: "Santosh Chokhani" To: "Mike" , Cc: , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Private EKU could cause problems if EKU is not otherwise present in the certificate. The certificate may not be usable for intended purpose. Not all clients may recognize "any key purpose" as intended by 5280. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Mike Sent: Wednesday, December 31, 2008 12:50 PM To: ietf-pkix@imc.org Cc: ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate I sent my last message a bit too hastily. Other ideas that I was contemplating should have been mentioned including: - remove any unrecognized extensions - remove tumors Those could potentially cause problems if for some reason they were actually needed. This one, though, shouldn't cause trouble: - add a private EKU with a random number (or two) in the OID That would not mess up the serial number scheme in use or modify the subject name as has been suggested. Mike I wrote: > There is a simple fix -- a CA can just reorder the extensions prior > to issuing a certificate. >=20 > Mike Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVHoasA094528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 10:50:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVHoawe094525; Wed, 31 Dec 2008 10:50:36 -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 sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVHoPh7094500; Wed, 31 Dec 2008 10:50:35 -0700 (MST) (envelope-from mike-list@pobox.com) Received: from localhost.localdomain (unknown [127.0.0.1]) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 88E0F1B777; Wed, 31 Dec 2008 12:50:24 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id B7C771B787; Wed, 31 Dec 2008 12:50:19 -0500 (EST) Message-ID: <495BB0B9.9000807@pobox.com> Date: Wed, 31 Dec 2008 09:49:45 -0800 From: Mike User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ietf-pkix@imc.org CC: ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> <495BA5E9.8040305@pobox.com> In-Reply-To: <495BA5E9.8040305@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 80508BAC-D763-11DD-889F-F83E113D384A-38729857!a-sasl-quonix.pobox.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I sent my last message a bit too hastily. Other ideas that I was contemplating should have been mentioned including: - remove any unrecognized extensions - remove tumors Those could potentially cause problems if for some reason they were actually needed. This one, though, shouldn't cause trouble: - add a private EKU with a random number (or two) in the OID That would not mess up the serial number scheme in use or modify the subject name as has been suggested. Mike I wrote: > There is a simple fix -- a CA can just reorder the extensions prior > to issuing a certificate. > > Mike Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVH4LtH091875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 10:04:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVH4Lhn091873; Wed, 31 Dec 2008 10:04:21 -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 sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com [207.106.133.19]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVH4AP1091758; Wed, 31 Dec 2008 10:04:20 -0700 (MST) (envelope-from mike-list@pobox.com) Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id A7EB98CD08; Wed, 31 Dec 2008 12:04:09 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id AD05D8CCFD; Wed, 31 Dec 2008 12:04:05 -0500 (EST) Message-ID: <495BA5E9.8040305@pobox.com> Date: Wed, 31 Dec 2008 09:03:37 -0800 From: Mike User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: ietf-pkix@imc.org CC: ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 0A5CA3DC-D75D-11DD-B70C-5720C92D7133-38729857!a-sasl-fastnet.pobox.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > We are simply not vigilant enough. This issue has been on our plate > since 2004. > > SHA-1 is next and neither the client side vendors nor the big > Enterprises have pushed to move to SHA-256. There is a simple fix -- a CA can just reorder the extensions prior to issuing a certificate. Mike Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFbC6Z087821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:37:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFbCqc087819; Wed, 31 Dec 2008 08:37: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 sottccs1.entrust.com (sottccs1.entrust.com [216.191.252.13]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVFaxkC087772 for ; Wed, 31 Dec 2008 08:37:10 -0700 (MST) (envelope-from tim.moses@entrust.com) Received: (qmail 28690 invoked from network); 31 Dec 2008 15:36:57 -0000 Received: from tim.moses@entrust.com by sottccs1.entrust.com with EntrustECS-Server-8.0;31 Dec 2008 15:36:57 -0000 Received: from unknown (HELO sottexch1.corp.ad.entrust.com) (10.4.51.28) by sottccs1.entrust.com with SMTP; 31 Dec 2008 15:36:56 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="--=_NextPart_EE_103656811.38200976" Date: Wed, 31 Dec 2008 10:36:56 -0500 Message-ID: <04398A2C9F306C4690265C144089972D0D3B3B13@sottexch1.corp.ad.entrust.com> In-Reply-To: <495B8D28.6070601@mitre.org> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrXBEEqsU/Y6e/ROuPhuoyz8ZfcAAAQNmw References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> From: "Tim Moses" To: "Timothy J. Miller" Cc: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----=_NextPart_EE_103656811.38200976 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Colleagues - It has been confirmed that no EV issuer is signing certific= ates with MD5. Also, EV certificates cannot be issued by an automated p= rocess, putting another obstacle in the path of an attacker. All the be= st. Tim. Tim Moses +1 613 270 3183 -----Original Message----- From: owner-ietf-smime=40mail.imc.org =5Bmailto:owner-ietf-smime=40mail.= imc.org=5D On Behalf Of Timothy J. Miller Sent: Wednesday, December 31, 2008 10:18 AM To: Santosh Chokhani Cc: ietf-pkix=40imc.org; ietf-smime=40imc.org; cfrg=40irtf.org; saag=40i= etf.org Subject: Re: =5BCfrg=5D =5Bsaag=5D Further MD5 breaks: Creating a rogue C= Acertificate Santosh Chokhani wrote: > One would think we want to start using SHA-1 or even SHA256 (assuming=20 > client vendors implement SHA256 ASAP) and ask the CAs emanating from=20 > commercial roots to perform responsible I&A before issuing certificate= s. Speaking of I&A, I found it interesting to note that the CA/Browser foru= m guidelines for EV certs allows (but recommends against) MD5 until 2010= =2E The spot check of EV issuers I did yesterday didn't turn up anyone actua= lly using MD5, but I didn't have all of 'em available. -- Tim ----=_NextPart_EE_103656811.38200976 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCTAHBgUrDgMCGjCABgkqhkiG9w0BBwEAAKCCIIIwggKf MIICCKADAgECAgRGJ7vgMA0GCSqGSIb3DQEBBQUAMCwxCzAJBgNVBAYTAkNBMR0wGwYDVQQK ExRFbnRydXN0IFRlY2hub2xvZ2llczAeFw0wODA1MDcxMzA4MzlaFw0xMTA1MDcxMzM4Mzla MDIxCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczCB nTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEA0IBgoGWlwptmAbxopaoSELaZIvJHlWg+vqcq kQlA6mSAzTEHQl79k5aUq4cPZQTK5SnsUoY3aPN8IyTN8+SDmIJ/3qwFvxG1Xkbi1UDo6qB/ TR1zwBoxpz7iL8XH5gLWSaijFab+bMeTamSeL05l0JjF0AoAmxnwAjU7Zl4kdWkCAQOjgckw gcYwHQYDVR0OBBYEFAUkiCBOsLJRzMuh2elnJIbV+bBFME4GA1UdHwRHMEUwQ6BBoD+kPTA7 MQswCQYDVQQGEwJDQTEdMBsGA1UEChMURW50cnVzdCBUZWNobm9sb2dpZXMxDTALBgNVBAMT BENSTDEwCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFDGPKjFGWl7oabci0fgBq6xQXgF1MAwG A1UdEwQFMAMBAf8wGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCAIEwDQYJKoZIhvcNAQEFBQAD gYEAbdDF5a/A+vjthvR7ofXzM3UxI/62yW9yJPzQ7sN1AS9zKgPB9Nm4tySDwSeFvqQ1/KOv JTEeYABGRaZ1YrTXc2mFhTlcLQAZ16DsS2VxnKqhEVWq4JaUaJAe9qvKvdkvpDieKQMkfM0c WZCa9b396rZKqSd+j86yP6FauYSrw6wwggLfMIICSKADAgECAgRGS07GMA0GCSqGSIb3DQEB BQUAMC4xCzAJBgNVBAYTAmNhMRAwDgYDVQQKEwdlbnRydXN0MQ0wCwYDVQQLEwRQcm9kMB4X DTA3MDUyMjE0NTQ0N1oXDTEwMDUyMjE1MjQ0N1owLDELMAkGA1UEBhMCQ0ExHTAbBgNVBAoT FEVudHJ1c3QgVGVjaG5vbG9naWVzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5SPAE WITHCc04wRiDaJpJY8ZF7bCJ1ohhSyKRA2ouJ+sjRMqzfxXcxQTKuE4GQg1dvZjvmmZJq5KZ 71yZnvK+Kb1ixXP1y/zAy6CiiatTPrf8SNzXpSDon3VdKo8zuKQ6ELKaWP3nK4O4eOiXdmfn a2bOLzFi7TpKICfieMOdlQIDAQABo4IBCjCCAQYwHQYDVR0OBBYEFDGPKjFGWl7oabci0fgB q6xQXgF1MIGNBgNVHR8EgYUwgYIwRaBDoEGkPzA9MQswCQYDVQQGEwJjYTEQMA4GA1UEChMH ZW50cnVzdDENMAsGA1UECxMEUHJvZDENMAsGA1UEAxMEQ1JMMTA5oDegNYYzZmlsZTovL1xc U09UVFBST0RDQVxDUkxccHJvZF9lbnRydXN0X2NhX2NybGZpbGUuY3JsMAsGA1UdDwQEAwIB BjAfBgNVHSMEGDAWgBTR5DvPp2uwBfGx/my5EmQy0JQbujAMBgNVHRMEBTADAQH/MBkGCSqG SIb2fQdBAAQMMAobBFY3LjEDAgCBMA0GCSqGSIb3DQEBBQUAA4GBAEnSrabNwGiiZNjhIFce 7VctEE5uR6RaADbc6hszcn50pYoliCY5T53dUpOvznUuDX0HWFfH+YXl3Isol2p0DbSSAFNv 8OWyEAd2SoYRinBNpMOyQlrTWt5FBiCB2dglbxx/I2eyTqr5COy8u/ijLKvVn00yBf3f1kCw d+//jQluMIIC7TCCAlagAwIBAgIEMkbEozANBgkqhkiG9w0BAQUFADAyMQswCQYDVQQGEwJD QTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5lc3MwHhcNOTgwODE5MTkxMjA2 WhcNMTgwODE5MTk0MjA2WjAyMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8G A1UECxMIQnVzaW5lc3MwgZ0wDQYJKoZIhvcNAQEBBQADgYsAMIGHAoGBANCAYKBlpcKbZgG8 aKWqEhC2mSLyR5VoPr6nKpEJQOpkgM0xB0Je/ZOWlKuHD2UEyuUp7FKGN2jzfCMkzfPkg5iC f96sBb8RtV5G4tVA6Oqgf00dc8AaMac+4i/Fx+YC1kmooxWm/mzHk2pkni9OZdCYxdAKAJsZ 8AI1O2ZeJHVpAgEDo4IBEDCCAQwwEQYJYIZIAYb4QgEBBAQDAgAHMFQGA1UdHwRNMEswSaBH oEWkQzBBMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5l c3MxDTALBgNVBAMTBENSTDEwKwYDVR0QBCQwIoAPMTk5ODA4MTkxOTEyMDZagQ8yMDE4MDgx OTE5MTIwNlowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFAUkiCBOsLJRzMuh2elnJIbV+bBF MB0GA1UdDgQWBBQFJIggTrCyUczLodnpZySG1fmwRTAMBgNVHRMEBTADAQH/MBkGCSqGSIb2 fQdBAAQMMAobBFY0LjADAgSQMA0GCSqGSIb3DQEBBQUAA4GBAJg+gIo2VG7EqPRBAJ3Q6sho xP/8pMCk/3UyKbuu4En4aRn+5kAXmjhqJR98uZsR89G5S1I68pn+xhg6FK3gNgC/OLOZ6bRG ABcQGkRov8vvIoJPRRN3JYcAyJSRykY2CZhPsW99pO69qlxS4lRIfIFuflaXs7PY2LTzftsO 6o1cMIIDJTCCAo6gAwIBAgIERktOCjANBgkqhkiG9w0BAQUFADAuMQswCQYDVQQGEwJjYTEQ MA4GA1UEChMHZW50cnVzdDENMAsGA1UECxMEUHJvZDAeFw0wNzA1MTYxODAxMzhaFw0xNzA1 MTYxODMxMzhaMC4xCzAJBgNVBAYTAmNhMRAwDgYDVQQKEwdlbnRydXN0MQ0wCwYDVQQLEwRQ cm9kMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpd6zp2+OYdJe2JvS/+IlSax3c1GWf xpm/6G11szZ9iRTy0UCpcVZ7e7pEnu/ySNSDN0CLFfj2XMnC2b5YgnuL9/rDz+jVCylLJbuJ HjpYmGWQqG1vbmSUBQeH9TCdTHEqScibjV77r81cfyOpjWe0iETErEUlq5jsnuZOYKkuXQID AQABo4IBTjCCAUowEQYJYIZIAYb4QgEBBAQDAgAHMIGNBgNVHR8EgYUwgYIwRaBDoEGkPzA9 MQswCQYDVQQGEwJjYTEQMA4GA1UEChMHZW50cnVzdDENMAsGA1UECxMEUHJvZDENMAsGA1UE AxMEQ1JMMTA5oDegNYYzZmlsZTovL1xcU09UVFBST0RDQVxDUkxccHJvZF9lbnRydXN0X2Nh X2NybGZpbGUuY3JsMCsGA1UdEAQkMCKADzIwMDcwNTE2MTgwMTM4WoEPMjAxNzA1MTYxODMx MzhaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBTR5DvPp2uwBfGx/my5EmQy0JQbujAdBgNV HQ4EFgQU0eQ7z6drsAXxsf5suRJkMtCUG7owDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAE EDAOGwhWNy4xOjQuMAMCBJAwDQYJKoZIhvcNAQEFBQADgYEAWATjTT62BcA4MaxLVJTG5alA BUYnKzbtbpoZrckpmEVZfcoLooJcgRq58DeGVihhvl9lfUOE3YIQUFxDXA6svFD8Fn99y3Iy RGM+itL/rRdbSAlH2Xa6HLBhjTJff9oa6n67WW/RU0106O8jqS3bcVjWeI0WLh7LKxxHnGz3 TFUwggMwMIICmaADAgECAgQ4xeeqMA0GCSqGSIb3DQEBBQUAMDIxCzAJBgNVBAYTAkNBMRAw DgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczAeFw0wNDA5MjkxNzExNThaFw0w ODA5MjkxNzQxNThaMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQL EwdSIGFuZCBEMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvIeIjfoD5D86sD8C ehB+kVhYJTL+VuaUZiVijGevUTlnUAwy1WpOYVpFCa8VK116TJ+o99axN1jMbsVBYfRzFk9S Wl4iAH+PyJ1S6D5Yl593KjHPhBCfdD0v9KoPqXhCwRlkvupreNlFx3FFk2Uf5jG/i9SCP925 OXbz3wod2mdIu8ueNWgTmA2XAOBdHZg6HYKo50BWUIgtRwFvzbh1J57+gNdHxMYLZmvj5saS 1mDTSibkPH/AY+D+xAozRmyOYa4SY2HVfZSM2SP7MkuVtKp17pzhwicoWAGKXrKeDRWDYeZB TJjHoNP/SXKdpSzY7rV8GPrfWFoogc4350VbowIDAQABo4HPMIHMMB0GA1UdDgQWBBTz8Cwo 5jmnNBmrmpGopmZAkpzicTBUBgNVHR8ETTBLMEmgR6BFpEMwQTELMAkGA1UEBhMCQ0ExEDAO BgNVBAoTB0VudHJ1c3QxETAPBgNVBAsTCEJ1c2luZXNzMQ0wCwYDVQQDEwRDUkwxMAsGA1Ud DwQEAwIBBjAfBgNVHSMEGDAWgBQFJIggTrCyUczLodnpZySG1fmwRTAMBgNVHRMEBTADAQH/ MBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgCBMA0GCSqGSIb3DQEBBQUAA4GBAI8B1Aa8TTla mxl1BgP6ch4CZUEADT/1xNwEaPveZFajVrURlnKqMfDQ704aNc2qFnLHJDI3dS49vJEJ8LsK Hvd7sf6WqRCuGkF3D8qsIWKxBK6muWdSfKAYWLB/4wDm2CcZDyXt/A3OYFjMzQ5pVBKeAXNA k6fZ32SGLVNvVqc/MIIDMDCCApmgAwIBAgIESCCkSzANBgkqhkiG9w0BAQUFADAyMQswCQYD VQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDERMA8GA1UECxMIQnVzaW5lc3MwHhcNMDgwOTI0 MTQzNjA0WhcNMTIwOTI0MTUwNjA0WjAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVz dDEQMA4GA1UECxMHUiBhbmQgRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALyH iI36A+Q/OrA/AnoQfpFYWCUy/lbmlGYlYoxnr1E5Z1AMMtVqTmFaRQmvFStdekyfqPfWsTdY zG7FQWH0cxZPUlpeIgB/j8idUug+WJefdyoxz4QQn3Q9L/SqD6l4QsEZZL7qa3jZRcdxRZNl H+Yxv4vUgj/duTl2898KHdpnSLvLnjVoE5gNlwDgXR2YOh2CqOdAVlCILUcBb824dSee/oDX R8TGC2Zr4+bGktZg00om5Dx/wGPg/sQKM0ZsjmGuEmNh1X2UjNkj+zJLlbSqde6c4cInKFgB il6yng0Vg2HmQUyYx6DT/0lynaUs2O61fBj631haKIHON+dFW6MCAwEAAaOBzzCBzDAdBgNV HQ4EFgQU8/AsKOY5pzQZq5qRqKZmQJKc4nEwVAYDVR0fBE0wSzBJoEegRaRDMEExCzAJBgNV BAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MREwDwYDVQQLEwhCdXNpbmVzczENMAsGA1UEAxME Q1JMMTALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUBSSIIE6wslHMy6HZ6WckhtX5sEUwDAYD VR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkqhkiG9w0BAQUFAAOB gQDHUhDfQdNFmborkeOSyqtTmpiIESBES6KULodyCmdHbcoV4L1H5vpjBO0HdUx+YXlIZxUj pTKDv2mowbCAdcWihfW3LjY+3RoqoMu2iR8nSDexR+TesS8drRF9Mrmy30/ddj+sneR7KeaG KL8WGcZBDmxGIvoOaCYGuxsgrC9/LzCCA2gwggLRoAMCAQICBEZLTsUwDQYJKoZIhvcNAQEF BQAwLjELMAkGA1UEBhMCY2ExEDAOBgNVBAoTB2VudHJ1c3QxDTALBgNVBAsTBFByb2QwHhcN MDcwNTIyMTQ0MTIxWhcNMTAwNTIyMTUxMTIxWjAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMH RW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALyHiI36A+Q/OrA/AnoQfpFYWCUy/lbmlGYlYoxnr1E5Z1AMMtVqTmFaRQmvFStdekyf qPfWsTdYzG7FQWH0cxZPUlpeIgB/j8idUug+WJefdyoxz4QQn3Q9L/SqD6l4QsEZZL7qa3jZ RcdxRZNlH+Yxv4vUgj/duTl2898KHdpnSLvLnjVoE5gNlwDgXR2YOh2CqOdAVlCILUcBb824 dSee/oDXR8TGC2Zr4+bGktZg00om5Dx/wGPg/sQKM0ZsjmGuEmNh1X2UjNkj+zJLlbSqde6c 4cInKFgBil6yng0Vg2HmQUyYx6DT/0lynaUs2O61fBj631haKIHON+dFW6MCAwEAAaOCAQow ggEGMB0GA1UdDgQWBBTz8Cwo5jmnNBmrmpGopmZAkpzicTCBjQYDVR0fBIGFMIGCMEWgQ6BB pD8wPTELMAkGA1UEBhMCY2ExEDAOBgNVBAoTB2VudHJ1c3QxDTALBgNVBAsTBFByb2QxDTAL BgNVBAMTBENSTDEwOaA3oDWGM2ZpbGU6Ly9cXFNPVFRQUk9EQ0FcQ1JMXHByb2RfZW50cnVz dF9jYV9jcmxmaWxlLmNybDALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU0eQ7z6drsAXxsf5s uRJkMtCUG7owDAYDVR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAEDDAKGwRWNy4xAwIAgTANBgkq hkiG9w0BAQUFAAOBgQCQBw6L+mclwk7Z64xW4jbrS1CZpTHFGNmVuow0GbxBdFWHsDNE9H0s 4AUS59qW2T8JQRhm062vhZwpj29bCkOwDgciGq2POfOachGypOnV09x5Dcs3s+5M7c3gpbEP dcO8G7GPIcociDNPPj+Kd8ceoMvcZySp22u4MWuI1bOxyjCCA28wggJXoAMCAQICBEZD+x4w DQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNV BAsTB1IgYW5kIEQwHhcNMDgxMDIxMTMyOTM2WhcNMDkwNDIxMTM1OTM2WjBVMQswCQYDVQQG EwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEiMA4GA1UEBRMHMDUw NDA2NzAQBgNVBAMTCVRpbSBNb3NlczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0gtt TXg2dN9WsLP92LJQzIYPjdXOXewCcdviTglJfIFKO+RU3O76TPR6pKsZNgPADZL6Q0QHo5I2 ygrRBXCnMOH7xKutmI2QujgX5FW6kEFrHPRom65/XkuMXNW57BjRt+C4hXKU8fHp6WaiKhOM It2WG2jTHU8IYcYnWiiK4dMCAwEAAaOB7jCB6zALBgNVHQ8EBAMCBSAwIAYDVR0RBBkwF4EV dGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBBMQswCQYDVQQGEwJD QTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwGA1UEAxMFQ1JMNDIw HwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYEFMXxKqPWd83GEHAC aXkPSw+P2UHrMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMQMCBLAwDQYJKoZI hvcNAQEFBQADggEBAClPCYWYRjj5Q0uz74Ldr4FhH4KYkt35rgTXAWR9T2cSLbq6wssHiBS5 YGmM9lsYkQHXc9yPji03n9/Xco/0VjkZY2Fmc03f+3+6WkvvnfAbZFV0HfK1IR/i3hKC5vp9 D8DjcoSXOGwucv7L9iKARJ6jJSXIHl/fTIkt1gqtpfcSAesOhq9u/XO+zxGD8GL1tKF5k1F9 0GN5MQd7HNAZsrwEBDWAO7P3MbCBmOiArjno61cQMUU7k+tgMTt4W2Eeoc0yyzIrRtamz2q8 zbxmnKdEHt140yUXmsxuG04ZM2+iL/MtVD0F69WTAr2JNGsBeeNB8KMGDlCmM8Co2uQOSTkw ggOeMIIChqADAgECAgRGQ/sdMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNVBAYTAkNBMRAwDgYD VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTA4MTAyMTEzMjkzNloXDTA5MDQy MTEzNTkzNlowVTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1Ig YW5kIEQxIjAOBgNVBAUTBzA1MDQwNjcwEAYDVQQDEwlUaW0gTW9zZXMwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBALT3bXGkvn4caHYy/u5MXZsEw0q0/s9nj6j7wNkOkyrw394HoLN7 JY404tmf3zCa+qbCXS5eC9hmbU2Rdxo1eZhlB2sZpP/aY8KaHSzUAUcv0LmtQS25qEkSZkLn WSgczRts/EvOf7q0U4COQwI0dP/vBNk+fvJ+jkjVRZxZX32dAgMBAAGjggEcMIIBGDALBgNV HQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwODEwMjExMzI5MzZagQ8yMDA5MDIyNTIyNTkzNlow IAYDVR0RBBkwF4EVdGltLm1vc2VzQGVudHJ1c3QuY29tMFQGA1UdHwRNMEswSaBHoEWkQzBB MQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEOMAwG A1UEAxMFQ1JMNDIwHwYDVR0jBBgwFoAU8/AsKOY5pzQZq5qRqKZmQJKc4nEwHQYDVR0OBBYE FCrFDow3ATgAarWOHil+N5udd2xJMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcu MQMCBLAwDQYJKoZIhvcNAQEFBQADggEBAFGhTfDY3PVBPb1xQezRSKyd6kfj6d1Gl/rqsOk7 1skHSE89plfdYHMoNEBfSCkr+O2au7hx2DBLLK/zjfaqfpr5Scu8IsYz5LrNKsukP46qwOna 2yprT9VVyCsTuByOnG//9U2CEDIwCZ/GBw1i6MHCXssSdZIjxn5oxmO4OBDHhfBIFXT2vIKC x/yEM+BgU+qWPu5T8V3Q3XR+kCE6jQDRp9cSTJy2Otzw+k+ASXASWO4hzEOH/X8Prd/lx1iS clEK1lOXl5k4gCnQu/KcpM5CGKUhwFjcO9LJb/Xkeab4+Z8yEXSvNrjc5xLuFDW3BLaFPyNa hWsrINpm/kC1goAwggP1MIIC3aADAgECAgQySKogMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNV BAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMB4XDTAyMDQxNzAy MjAyNloXDTIyMDQxNzAyNTAyNlowMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3Qx EDAOBgNVBAsTB1IgYW5kIEQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC8h4iN +gPkPzqwPwJ6EH6RWFglMv5W5pRmJWKMZ69ROWdQDDLVak5hWkUJrxUrXXpMn6j31rE3WMxu xUFh9HMWT1JaXiIAf4/InVLoPliXn3cqMc+EEJ90PS/0qg+peELBGWS+6mt42UXHcUWTZR/m Mb+L1II/3bk5dvPfCh3aZ0i7y541aBOYDZcA4F0dmDodgqjnQFZQiC1HAW/NuHUnnv6A10fE xgtma+PmxpLWYNNKJuQ8f8Bj4P7ECjNGbI5hrhJjYdV9lIzZI/syS5W0qnXunOHCJyhYAYpe sp4NFYNh5kFMmMeg0/9Jcp2lLNjutXwY+t9YWiiBzjfnRVujAgMBAAGjggETMIIBDzARBglg hkgBhvhCAQEEBAMCAAcwUwYDVR0fBEwwSjBIoEagRKRCMEAxCzAJBgNVBAYTAkNBMRAwDgYD VQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMQ0wCwYDVQQDEwRDUkwxMCsGA1UdEAQk MCKADzIwMDIwNDE3MDIyMDI2WoEPMjAyMjA0MTcwMjUwMjZaMAsGA1UdDwQEAwIBBjAfBgNV HSMEGDAWgBTz8Cwo5jmnNBmrmpGopmZAkpzicTAdBgNVHQ4EFgQU8/AsKOY5pzQZq5qRqKZm QJKc4nEwDAYDVR0TBAUwAwEB/zAdBgkqhkiG9n0HQQAEEDAOGwhWNi4wOjQuMAMCBJAwDQYJ KoZIhvcNAQEFBQADggEBAIA+ebVGmfnJrmQEsWlyRG3D5e5j8bmbq5Af2FVeB5yGn6Lr+1eV iNDxxycnLUdw6Y9LvXwuQbh2vEF+uGM71pO52/5M0gxH2LNrLv3qGwGTutoGli3Fq84SPFvy N+n4R6XO2BxJmjvfuZjNyuv2kOPMmV2yuILM8NT83TnZH5EnhGz/QiK5bMhUfvL31L076sbX g+MQo1CEDf2BPCD2IwG1CiSwN8q7T1QJoWwTtphQLx4TTDOSLgb4OXlEoTnswZpgCH5xxybI 9HpfD+CXxijdgaE5bPepq0CFtumUAKb0tKZ24xItdDJuR7pyrklRvxz1UzOL1wiK/odt/X/E 5s8xggJoMIICZAIBATA5MDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYD VQQLEwdSIGFuZCBEAgRGQ/sdMAcGBSsOAwIaoIIBiTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wODEyMzExNTM2NTZaMCMGCSqGSIb3DQEJBDEWBBRJYJQR 3LOeOmLPQl5+lI5BWAQlBjCCASgGCSqGSIb3DQEJDzGCARkwggEVMAoGCCqGSIb3DQMHMAcG BSsOAwIaMAoGCCqGSIb3DQICMAoGCCqGSIb3DQIEMAoGCCqGSIb3DQIFMA4GCCqGSIb3DQME AgIAgDANBggqhkiG9w0DBAIBKDAHBgUrDgMCBzAOBgkqhkiG9n0HQgMCAUAwDgYJKoZIhvZ9 B0IDAgEoMA8GCSqGSIb2fQdCCgICAIAwEQYLKwYBBAGBPAcBAQICAgCAMA8GCWCGSAFlAwQB AgICAIAwDwYJYIZIAWUDBAEWAgIAwDAPBglghkgBZQMEASoCAgEAMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBODANBggqhkiG9w0DAgIBKDALBgkqhkiG 9w0BAQEEgYAZ5wG6uFoDAwofzu92qRcG76k3WrqXjHB3b6RsWMe+Jt5xlI2JRzHZbSD10yJu ETUcGMyhvZEVDEwaR3dsN6N3kjF+WpqoK6OAQNA1OO6WmXXfpDJYsucllmfv+JWA0GX4M5Ux uMCHY3dvQnet5UldSEs3dAMT6wfaMlkXHTghlwAAAAAAAA== ----=_NextPart_EE_103656811.38200976-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFLFWt087123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:21:15 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFLFvN087121; Wed, 31 Dec 2008 08:21: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVFLD34087108 for ; Wed, 31 Dec 2008 08:21:13 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 3243 invoked from network); 31 Dec 2008 15:21:36 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 15:21:36 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 15:21:36 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 10:21:12 -0500 Message-ID: In-Reply-To: <495B8D28.6070601@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclrWwxnY5KUcnr6RkKSgCgRHyNxcgAADcag References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> <495B8D28.6070601@mitre.org> From: "Santosh Chokhani" To: "Timothy J. Miller" Cc: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We are simply not vigilant enough. This issue has been on our plate since 2004. SHA-1 is next and neither the client side vendors nor the big Enterprises have pushed to move to SHA-256. -----Original Message----- From: Timothy J. Miller [mailto:tmiller@mitre.org]=20 Sent: Wednesday, December 31, 2008 10:18 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Santosh Chokhani wrote: > One would think we want to start using SHA-1 or even SHA256 (assuming > client vendors implement SHA256 ASAP) and ask the CAs emanating from > commercial roots to perform responsible I&A before issuing certificates. Speaking of I&A, I found it interesting to note that the CA/Browser=20 forum guidelines for EV certs allows (but recommends against) MD5 until=20 2010. The spot check of EV issuers I did yesterday didn't turn up anyone=20 actually using MD5, but I didn't have all of 'em available. -- Tim Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFIaeD086981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:18:36 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVFIaGL086979; Wed, 31 Dec 2008 08:18:36 -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-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVFIY1l086966; Wed, 31 Dec 2008 08:18:34 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVFIXwR002392; Wed, 31 Dec 2008 10:18:33 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVFIXZb002386; Wed, 31 Dec 2008 10:18:33 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 10:18:33 -0500 Message-ID: <495B8D28.6070601@mitre.org> Date: Wed, 31 Dec 2008 09:18:00 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Santosh Chokhani CC: "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050306030909090007020003" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms050306030909090007020003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Santosh Chokhani wrote: > One would think we want to start using SHA-1 or even SHA256 (assuming > client vendors implement SHA256 ASAP) and ask the CAs emanating from > commercial roots to perform responsible I&A before issuing certificates. Speaking of I&A, I found it interesting to note that the CA/Browser forum guidelines for EV certs allows (but recommends against) MD5 until 2010. The spot check of EV issuers I did yesterday didn't turn up anyone actually using MD5, but I didn't have all of 'em available. -- Tim --------------ms050306030909090007020003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExNTE4MDBaMCMGCSqGSIb3DQEJBDEWBBTYJibxLOyG1SEmTVXB/AhI0/Bt8jBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgAZCH6+J56WxRyI0sA7T1gbC1tsCwYnjNsqIpESy0TwpwrdIYDgtwOARQOev InbqiDYQerQmWIIH+ovlzYIUazy21FVc8ReHKFTXOrx4GLrDvGSwGfsDrc8Rz8l5dcP0rXUS J6/YQsvvbM90MY/o0TBIWI2i8PG5c5mVmkkYr+E9AAAAAAAA --------------ms050306030909090007020003-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVF4tQJ086353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 08:04:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVF4sib086351; Wed, 31 Dec 2008 08:04:54 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBVF4gaD086329 for ; Wed, 31 Dec 2008 08:04:52 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 3140 invoked from network); 31 Dec 2008 15:05:05 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 15:05:05 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 15:05:04 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Further MD5 breaks: Creating a rogue CA certificate Date: Wed, 31 Dec 2008 10:04:40 -0500 Message-ID: In-Reply-To: <495B84F0.3030506@mitre.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclrWAfbgnf2g3ujTbSdpg9MXzs4IAAANDWw References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.com> <200812302223.mBUMNqDL040943@balder-227.proper.com> <495B84F0.3030506@mitre.org> From: "Santosh Chokhani" To: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mini CRL are not a standard. That said, using implementators agreement (based on whether high order to low order bits are true serial number) one bit per certificate can be assigned and the random prefix or appendage to the serial number ignored. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Timothy J. Miller Sent: Wednesday, December 31, 2008 9:43 AM To: Russ Housley Cc: Eric Rescorla; cfrg@irtf.org; ietf-smime@imc.org; saag@ietf.org; ietf-pkix@imc.org Subject: Re: Further MD5 breaks: Creating a rogue CA certificate Russ Housley wrote: >=20 >> I'm not sure I understand the issue here, but >> they don't actually have to be totally randomized. You could use a >> PRF so they were predictable to the CA. >=20 > That works. This works too: the serial number could be composed of=20 > two parts, where the most significant bits are a counter and the=20 > least significant bits are randomly generated. How would Corestreet's miniCRL format fare under this? -- Tim Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEn07r085545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:49:00 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVEn06Z085543; Wed, 31 Dec 2008 07:49:00 -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 romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEmnk9085526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:48:59 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id BFE4650822; Wed, 31 Dec 2008 07:05:05 -0800 (PST) Date: Wed, 31 Dec 2008 07:05:05 -0800 From: Eric Rescorla To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: paul.hoffman@vpnc.org, pmhesse@geminisecurity.com, rlmorgan@washington.edu, ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081231150505.BFE4650822@romeo.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Wed, 31 Dec 2008 14:20:39 +1300, Peter Gutmann wrote: > > "Peter Hesse" writes: > > >Ceasing the issuance of certificates with MD5 used in the signature doesn't > >solve the problem of the certificates that have already been issued and are > >still out there, any number of which may be rogue. > > > >Replacing, or marking as untrusted all root certificates which have any > >current valid (i.e. non-expired, non-revoked) certificates with MD5 used in > >the signature could have tremendous undesirable impact and be an untenable > >solution. > > I hate to be the one to point to the elephant in the room (well OK, I don't > hate it, it's rather fun actually) but you need to keep this in perspective: > one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks > have no problems at all obtaining certs from commercial CAs using stolen > identities and credentials for pretty much any use they want. The current MD5 > attack is very cool but there's no need to worry about bad guys doing much > with it because it's much, much easier to get legitimate CA-issued certs the > normal way, you buy them just like everyone else does (except that you use > someone else's credit card and identity, obviously). > > In other words, if this problem is fixed, would anyone other than security > geeks even notice? I doubt the crooks will. Well, if we're going to be pointing ot the obvious, then code signing actually seems kind of off-point as well. > 50% of IE users are not running up-to-date copies of their browser.[0] In many cases this means that the browsers have remote exploits. Why worry about AuthentiCode? -Ekr [0] http://www.techzoom.net/publications/insecurity-iceberg/index.en Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEhec4085339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 07:43:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBVEhe7w085337; Wed, 31 Dec 2008 07:43: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 smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBVEhQJ1085321; Wed, 31 Dec 2008 07:43:37 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVEhO1a005883; Wed, 31 Dec 2008 09:43:24 -0500 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBVEhOWH005873; Wed, 31 Dec 2008 09:43:24 -0500 Received: from [129.83.200.3] (129.83.200.3) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 31 Dec 2008 09:43:24 -0500 Message-ID: <495B84F0.3030506@mitre.org> Date: Wed, 31 Dec 2008 08:42:56 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Russ Housley CC: Eric Rescorla , "cfrg@irtf.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "ietf-pkix@imc.org" Subject: Re: Further MD5 breaks: Creating a rogue CA certificate References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.com> <200812302223.mBUMNqDL040943@balder-227.proper.com> In-Reply-To: <200812302223.mBUMNqDL040943@balder-227.proper.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090606080405090908050504" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms090606080405090908050504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Russ Housley wrote: > >> I'm not sure I understand the issue here, but >> they don't actually have to be totally randomized. You could use a >> PRF so they were predictable to the CA. > > That works. This works too: the serial number could be composed of > two parts, where the most significant bits are a counter and the > least significant bits are randomly generated. How would Corestreet's miniCRL format fare under this? -- Tim --------------ms090606080405090908050504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzExNDQyNTZaMCMGCSqGSIb3DQEJBDEWBBTfbxF7sn3oqEN3WXpHFQsd8theZDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgBZT/e02nOU5oLHw8SlL6T03B11F/xNZ0nz2O8tH5cZlJO9MLivLWFMt7kuj +OfGq/Rbd1s8iuLaOutkrqN86npxL/gDNTA9HhiOUS7uN6rWywF/2tptx4S0l7lJRMDg/BcX 0kefE1Ivxq3RU/taMplV1KFiHkJ7LJUnlyHecbu2AAAAAAAA --------------ms090606080405090908050504-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBV87fBK065613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 01:07:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBV87fct065610; Wed, 31 Dec 2008 01:07: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBV87SWk065597 for ; Wed, 31 Dec 2008 01:07:38 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 936 invoked from network); 31 Dec 2008 08:07:51 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;31 Dec 2008 08:07:51 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 31 Dec 2008 08:07:51 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Wed, 31 Dec 2008 03:07:26 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: Aclq5ghrPG8EOOIcREilhQIvujxQYwAOEaVA References: <08bb01c96ac7$1cd5a750$5680f5f0$@com> From: "Santosh Chokhani" To: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: One would think we want to start using SHA-1 or even SHA256 (assuming client vendors implement SHA256 ASAP) and ask the CAs emanating from commercial roots to perform responsible I&A before issuing certificates. It will also help if the client side certificate policy processing became more of a norm. But, all of this is probably expecting too much. My fear is that expecting any of this is also too much. -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Peter Gutmann Sent: Tuesday, December 30, 2008 8:21 PM To: paul.hoffman@vpnc.org; pmhesse@geminisecurity.com; rlmorgan@washington.edu Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate "Peter Hesse" writes: >Ceasing the issuance of certificates with MD5 used in the signature doesn't >solve the problem of the certificates that have already been issued and are >still out there, any number of which may be rogue. > >Replacing, or marking as untrusted all root certificates which have any >current valid (i.e. non-expired, non-revoked) certificates with MD5 used in >the signature could have tremendous undesirable impact and be an untenable >solution. I hate to be the one to point to the elephant in the room (well OK, I don't hate it, it's rather fun actually) but you need to keep this in perspective: one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks have no problems at all obtaining certs from commercial CAs using stolen identities and credentials for pretty much any use they want. The current MD5 attack is very cool but there's no need to worry about bad guys doing much with it because it's much, much easier to get legitimate CA-issued certs the normal way, you buy them just like everyone else does (except that you use someone else's credit card and identity, obviously). In other words, if this problem is fixed, would anyone other than security geeks even notice? I doubt the crooks will. Peter. _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBV1Kxgu050092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:20:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBV1Kx1e050089; Tue, 30 Dec 2008 18:20: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 mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBV1KkLi050051; Tue, 30 Dec 2008 18:20:58 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C6E079D3C9; Wed, 31 Dec 2008 14:20:45 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ47zQCpU9p7; Wed, 31 Dec 2008 14:20:45 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EF5B69D3C8; Wed, 31 Dec 2008 14:20:44 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 0EEEE1BE4002; Wed, 31 Dec 2008 14:20:40 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LHplH-0006Xw-V6; Wed, 31 Dec 2008 14:20:39 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: paul.hoffman@vpnc.org, pmhesse@geminisecurity.com, rlmorgan@washington.edu Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Cc: cfrg@irtf.org, ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org In-Reply-To: <08bb01c96ac7$1cd5a750$5680f5f0$@com> Message-Id: Date: Wed, 31 Dec 2008 14:20:39 +1300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Peter Hesse" writes: >Ceasing the issuance of certificates with MD5 used in the signature doesn't >solve the problem of the certificates that have already been issued and are >still out there, any number of which may be rogue. > >Replacing, or marking as untrusted all root certificates which have any >current valid (i.e. non-expired, non-revoked) certificates with MD5 used in >the signature could have tremendous undesirable impact and be an untenable >solution. I hate to be the one to point to the elephant in the room (well OK, I don't hate it, it's rather fun actually) but you need to keep this in perspective: one in ten AuthentiCode-signed Windows binaries is malware, and cybercrooks have no problems at all obtaining certs from commercial CAs using stolen identities and credentials for pretty much any use they want. The current MD5 attack is very cool but there's no need to worry about bad guys doing much with it because it's much, much easier to get legitimate CA-issued certs the normal way, you buy them just like everyone else does (except that you use someone else's credit card and identity, obviously). In other words, if this problem is fixed, would anyone other than security geeks even notice? I doubt the crooks will. Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNjtPp045193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:45:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNjtPr045191; Tue, 30 Dec 2008 16:45:55 -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 chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNjr9K045178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 16:45:54 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUNjjIx018330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:45:46 -0500 (EST) Date: Tue, 30 Dec 2008 18:45:45 -0500 From: Jeffrey Hutzelman To: Santosh Chokhani , Peter Hesse , "RL 'Bob' Morgan" , Paul Hoffman cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate Message-ID: <411C6DBE577BC8F60969AF29@atlantis.pc.cs.cmu.edu> In-Reply-To: <200812302328.mBUNSDJj019534@raisinbran.srv.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <08bb01c96ac7$1cd5a750$5680f5f0$@com> <200812302328.mBUNSDJj019534@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, December 30, 2008 06:28:07 PM -0500 Santosh Chokhani wrote: > Since the attack is computing pre-image, I suspect that past MD5 > certificates are safe until the attack was devised. The attack does _not_ involve computing a preimage; it involves computing a colliding pair one of which has a prefix which is predictable but not controllable, followed by a controllable component consisting of some minimum number of bits followed by at least three aligned message blocks. What makes existing certificates safe is that there are no known preimage attacks against MD5, couple with limitations of the technique used to construct the colliding pair. However, there is a limit to how "safe" existing certificates are, because the attack does not require anything that was not known 3-4 years ago. The only change is that with the latest techniques for computing collisions, it is possible to do so in a short enough time to be able to predict the validity and serial number that will be used by the issuer with fairly high probability. -- Jeff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNeokg044868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:40:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNeoUw044867; Tue, 30 Dec 2008 16:40:50 -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 fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNebSX044839; Tue, 30 Dec 2008 16:40:48 -0700 (MST) (envelope-from hugokraw@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so2736323fgb.26 for ; Tue, 30 Dec 2008 15:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=DDpekhM52VkOAoRXt2PZCjhH4t1PiBNvOlzCNzEqzL4=; b=ZZz3YvRMqfdLQsd/8ahiFloECdUPBawdLeuuNZH8Cr46ZHYLNXsoZ+HMY+zLRX6zYI h+P2eWBjHI0CacQWPFxFZXccAWRnZLdIAa2ZIivutA9pgNYpKm9PZOVdbDda45599etK ntwcXzkHyb9uMG1+RTH91bwmHp47itVwiUsgY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=rIO56ncxno48IvUn931cZzc48cPja3c6sVugRkSlz07p+kL31iFVgv0xYSnUpIRGhc 9l8VIIu5uelDeSjEMvZMXmMvlH94d3yEPdueUvJdVnE1X+piIepre66GsXldcD7HYouL S1ChvvQEJXezzzv/SuiCz/3ifmbLVWzeW8SV8= Received: by 10.86.95.20 with SMTP id s20mr2438156fgb.39.1230680436423; Tue, 30 Dec 2008 15:40:36 -0800 (PST) Received: by 10.86.93.6 with HTTP; Tue, 30 Dec 2008 15:40:36 -0800 (PST) Message-ID: Date: Tue, 30 Dec 2008 18:40:36 -0500 From: "Hugo Krawczyk" To: "Eric Rescorla" Subject: Re: Further MD5 breaks: Creating a rogue CA certificate Cc: "Paul Hoffman" , ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org In-Reply-To: <20081230213934.C219450822@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_143378_5086089.1230680436411" References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> X-Google-Sender-Auth: 51d21de5a352475d Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_Part_143378_5086089.1230680436411 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Paul, Eric and everyone else, Paul said > > If the IETF feels that adding randomization to signatures is > important, we should define randomized signature functions. We could > start with NIST Draft SP 800-106 > (< http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>). However, > I think that doing so is sending the wrong message: we should > instead be encouraging the use of non-broken hash functions. and Eric responded > I certainly agree we should be encouraging the use of non-broken hash > functions. However, randomizing the SN seems like very cheap backward > compatible insurance against the fact that that's going to take a long time. I believe that the best answer to the above arguments regarding the use of randomized hashing vs. the "patch" of using random SNs is given by Sotirov et al, the cryptanalysts that carried out the remarkable MD5-certificate attack (see their website). They say: *We do note however that this use of randomness in the serial number is a workaround, made possible by lucky choices in the X.509 standard. It is not a bad idea in general to add randomness to a hash input when a possible attacker is able to choose the input. A much more reliable, since designed, solution is to use randomized hashing, see [HK]. Such a solution introduces randomization as a "mode of operation" for hash functions, which is a much more fundamental approach to the problem than relying on features that happen to be present in existing standards for non-security reasons, or for no reason at all.* In this light, I disagree with Paul's statement: > I think that doing so is sending the wrong message: we should > instead be encouraging the use of non-broken hash functions. The two things are not exclusive. We should do BOTH: Adopt a randomized hashing technique (as a mode of operation for hash functions) and continue our quest for better hash functions. We must aim at the best possible hash function, but we cannot guarantee its security in the long term. As stated in the above text by Sotirov et al, randomized hashing is a more fundamental (I would call it "infrastructural") approach. It strengthens digital signatures with any hash function and for any digital signature application, not just certificates. Let's take the example of HMAC: Its development in mid-90's was motivated to a large extent by the weaknesses found in MD5 by Dobbertin and others. If we took the approach of "let's use a better hash function" we should have adopted the key-append method MAC(K,X) = SHA1(X||K) which used SHA1 for which there was ample belief that it was a very good collision resistant hash function. However, had we done that, we would now have a broken MAC since the above design breaks with collisions on the underlying hash function. I believe that the responsible course of action for the IETF and particularly SAAG is to adopt the standardization process started by NIST with http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf and create a deployment path that could accommodate a randomized hashing approach as a mode of operation. This includes the consideration of randomized hashing in protocol changes and new protocol design that support algorithm agility. No one in the world will think that by doing that we should keep using MD5, or not pay attention to NIST's hash competition, or should stop from moving to SHA2. The just-published attack indicates that it is time that we take seriously our digital signatures, and randomized hashing is the best long-term insurance we know against future collision vulnerabilities. You can find more details on the specific randomized hashing approach behind NIST's document in http://www.ee.technion.ac.il/~hugo/rhash/ In particular, some of the documents in that site provide some guidance regarding implementation and deployment issues (it also includes a now-expired internet draft). Hugo ------=_Part_143378_5086089.1230680436411 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Paul, Eric and everyone else,

Paul said

    >
    > If the IETF feels that adding randomization to signatures is
    > important, we should define randomized signature functions. We could
    > start with NIST Draft SP 800-106
    > (<http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf>). However,
    > I think that doing so is sending the wrong message: we should
    > instead be encouraging the use of non-broken hash functions.

and Eric responded

   >  I certainly agree we should be encouraging the use of non-broken hash
   >  functions. However, randomizing the SN seems like very cheap backward
   >  compatible insurance against the fact that that's going to take a long time.


I believe that the best answer to the above arguments regarding the use of
randomized hashing vs. the "patch" of using random SNs is given by Sotirov et
al, the cryptanalysts that carried out the remarkable MD5-certificate attack
(see their website). They say:

  We do note however that this use of randomness in the serial number is a
  workaround, made possible by lucky choices in the X.509 standard. It is not a
  bad idea in general to add randomness to a hash input when a possible attacker
  is able to choose the input. A much more reliable, since designed, solution is
  to use randomized hashing, see [HK]. Such a solution introduces randomization
  as a "mode of operation" for hash functions, which is a much more fundamental
  approach to the problem than relying on features that happen to be present in
  existing standards for non-security reasons, or for no reason at all.

In this light, I disagree with Paul's statement:

> I think that doing so is sending the wrong message: we should
> instead be encouraging the use of non-broken hash functions.

The two things are not exclusive. We should do BOTH:
Adopt a randomized hashing technique (as a mode of operation for hash
functions) and continue our quest for better hash functions.

We must aim at the best possible hash function, but we cannot guarantee its
security in the long term. As stated in the above text by Sotirov et al,
randomized hashing is a more fundamental (I would call it "infrastructural")
approach. It strengthens digital signatures with any hash function and for any
digital signature application, not just certificates.

Let's take the example of HMAC: Its development in mid-90's was motivated to a
large extent by the weaknesses found in MD5 by Dobbertin and others.
If we took the approach of "let's use a better hash function" we should have
adopted the key-append method
  MAC(K,X) = SHA1(X||K)
which used SHA1 for which there was ample belief that it was a very good
collision resistant hash function.  However, had we done that, we would now
have a broken MAC since the above design breaks with collisions on the
underlying hash function.

I believe that the responsible course of action for the IETF and particularly
SAAG is to adopt the standardization process started by NIST with
http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_July2008.pdf
and create a deployment path that could accommodate a randomized hashing
approach as a mode of operation. This includes the consideration of randomized
hashing in protocol changes and new protocol design that support algorithm
agility.

No one in the world will think that by doing that we should keep using MD5,
or not pay attention to NIST's hash competition, or should stop from moving to
SHA2.

The just-published attack indicates that it is time that we take seriously our
digital signatures, and randomized hashing is the best long-term insurance
we know against future collision vulnerabilities.

You can find more details on the specific randomized hashing approach behind
NIST's document in http://www.ee.technion.ac.il/~hugo/rhash/
In particular, some of the documents in that site provide some guidance
regarding implementation and deployment issues (it also includes a now-expired
internet draft).

Hugo

------=_Part_143378_5086089.1230680436411-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNUGpd044381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:30:17 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNUGKr044380; Tue, 30 Dec 2008 16:30:16 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNUEbL044362 for ; Tue, 30 Dec 2008 16:30:15 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 29881 invoked from network); 30 Dec 2008 23:30:38 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:30:38 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:30:38 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Tue, 30 Dec 2008 18:30:13 -0500 Message-ID: In-Reply-To: <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclqylLTk2EWxsuuQ1C7rI9Jvd/JmAADAnAQ References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu><9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> From: "Santosh Chokhani" To: "Yoav Nir" , "RL 'Bob' Morgan" Cc: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Let us leave the trust anchors alone. Your challenge of protecting trust anchors does not change even if you use SHA 512 or next generation hash function yet to be determined. -----Original Message----- From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, December 30, 2008 5:02 PM To: RL 'Bob' Morgan Cc: ietf-pkix@imc.org; ietf-smime@imc.org; cfrg@irtf.org; saag@ietf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate >> Regardless of that, the authors of the MD5 paper are correct: trust =20 >> anchors signed with MD5 are highly questionable as of today (well, =20 >> actually, since they published their last paper). Hopefully, the =20 >> maintainers of the popular trust anchor repositories (Microsoft, =20 >> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and =20 >> MD2!) as soon as possible. > > This is a different claim than "CAs should stop issuing certs with =20 > MD5 signatures", which is what I as an amateur take away from a =20 > quick scan of the material. Obviously MD5 is suspect in various =20 > ways, but does this new work lead to the conclusion that MD5-signed =20 > roots are untrustworthy today? > Replacing a root is a much bigger deal then changing signing =20 > practices. > > - RL "Bob" CAs should have stopped issuing certs with MD5 signatures 4 years ago, =20 when the first practical attacks on MD5 were published. Now it would be more correct to say that "relying parties should treat =20 as invalid any certificate chain that contains an MD5 (or MD2, MD4) =20 signature" Since in the HTTPS context the relying parties are the browsers, it =20 falls to the vendors (if Microsoft leads, everyone will follow) to, as =20 Paul said, yank the trust anchors. It should be noted, though, that yanking the trust anchors is not =20 enough. You really should change the relying party to not recognize =20 this algorithm. Otherwise, it's perfectly valid for a CA whose =20 certificate is signed with SHA1 to sign an intermediate CA certificate =20 with MD5 (although they usually don't do that, I hope) Email secured by Check Point _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNSAXN044294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:28:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNSAvI044292; Tue, 30 Dec 2008 16:28: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNS8eB044271 for ; Tue, 30 Dec 2008 16:28:08 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 29840 invoked from network); 30 Dec 2008 23:28:32 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:28:32 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:28:32 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Tue, 30 Dec 2008 18:28:07 -0500 Message-ID: In-Reply-To: <08bb01c96ac7$1cd5a750$5680f5f0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclqxboXk3PuIMY0SLuDtNKXm7F2qQAAEKtAAAQJILA= References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <08bb01c96ac7$1cd5a750$5680f5f0$@com> From: "Santosh Chokhani" To: "Peter Hesse" , "RL 'Bob' Morgan" , "Paul Hoffman" Cc: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Roots need not be replaced since they need protected migration and storage. Since the attack is computing pre-image, I suspect that past MD5 certificates are safe until the attack was devised. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Peter Hesse Sent: Tuesday, December 30, 2008 4:40 PM To: 'RL 'Bob' Morgan'; 'Paul Hoffman' Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Ceasing the issuance of certificates with MD5 used in the signature doesn't solve the problem of the certificates that have already been issued and are still out there, any number of which may be rogue. Replacing, or marking as untrusted all root certificates which have any current valid (i.e. non-expired, non-revoked) certificates with MD5 used in the signature could have tremendous undesirable impact and be an untenable solution. The right tool for the job is a client-side solution to fail validation of any signature which uses MD5, especially certificate signatures. I will not hold my breath for such a solution. --Peter=20 ---------------------------------------------------------------- Peter Hesse pmhesse@geminisecurity.com http://securitymusings.com http://geminisecurity.com -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of RL 'Bob' Morgan Sent: Tuesday, December 30, 2008 4:18 PM To: Paul Hoffman Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate > Regardless of that, the authors of the MD5 paper are correct: trust=20 > anchors signed with MD5 are highly questionable as of today (well,=20 > actually, since they published their last paper). Hopefully, the=20 > maintainers of the popular trust anchor repositories (Microsoft,=20 > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and=20 > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5=20 signatures", which is what I as an amateur take away from a quick scan of=20 the material. Obviously MD5 is suspect in various ways, but does this new=20 work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNQ7DX044211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:26:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNQ7Tp044209; Tue, 30 Dec 2008 16:26:07 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNQ5kV044188 for ; Tue, 30 Dec 2008 16:26:05 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 29815 invoked from network); 30 Dec 2008 23:26:29 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:26:29 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:26:29 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Tue, 30 Dec 2008 18:26:04 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Further MD5 breaks: Creating a rogue CA certificate Thread-Index: AclqxZr3n+guWOOLTkmzRrRAnrk5JgAEETnQ References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> From: "Santosh Chokhani" To: "RL 'Bob' Morgan" , "Paul Hoffman" Cc: , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As mentioned, self-signed roots have their own problems and hash is not one of them. They need other means to protect since signatures on them are useless. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of RL 'Bob' Morgan Sent: Tuesday, December 30, 2008 4:18 PM To: Paul Hoffman Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate > Regardless of that, the authors of the MD5 paper are correct: trust=20 > anchors signed with MD5 are highly questionable as of today (well,=20 > actually, since they published their last paper). Hopefully, the=20 > maintainers of the popular trust anchor repositories (Microsoft,=20 > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and=20 > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5=20 signatures", which is what I as an amateur take away from a quick scan of=20 the material. Obviously MD5 is suspect in various ways, but does this new=20 work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNNTwV044009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:23:29 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNNT9h044005; Tue, 30 Dec 2008 16:23:29 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUNNG8c043975 for ; Tue, 30 Dec 2008 16:23:27 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 29788 invoked from network); 30 Dec 2008 23:23:40 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;30 Dec 2008 23:23:40 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 30 Dec 2008 23:23:40 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Date: Tue, 30 Dec 2008 18:23:15 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate Thread-Index: AclqwLMO5Ztz1GDZSjWorp7026VgfQAFJdBA References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu><9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> From: "Santosh Chokhani" To: "Paul Hoffman" , , , , Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul, I disagree in the matter of trust anchors, assuming you mean self-signed ones. Signatures on Trust anchors are inherently useless from security viewpoint. Thus, they could be signed using even MD4. Their security relies on protecting them from unauthorized modification. -----Original Message----- From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Paul Hoffman Sent: Tuesday, December 30, 2008 3:53 PM To: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: >This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. Your recollection may be off. I believe I was the person who brought up the serial number hack at the mic, and I'm pretty sure I said "some", not "many" (and certainly not "most"!). When I looked at a handful of popular CAs earlier this week, I only found a few who are using randomization in their serial numbers. Regardless of that, the authors of the MD5 paper are correct: trust anchors signed with MD5 are highly questionable as of today (well, actually, since they published their last paper). Hopefully, the maintainers of the popular trust anchor repositories (Microsoft, Mozilla, etc.) will yank out the trust anchors signed with MD5 (and MD2!) as soon as possible. At 3:10 PM -0500 12/30/08, Russ Housley wrote: >RFC 5280 does not include this advice. It is sound advice that was discussed in PKIX and other venues. Perhaps a BCP is in order. Man, that is really stretching the definition of "best". For one, it is only needed in signatures that use known-attackable hash functions. A "best practice" in that case is to use a better hash function in the signature. Also, it relies on the ability of the software using the random number to be sure that the result is a positive integer in ASN.1, which seems overly optimistic. If the IETF feels that adding randomization to signatures is important, we should define randomized signature functions. We could start with NIST Draft SP 800-106 (). However, I think that doing so is sending the wrong message: we should instead be encouraging the use of non-broken hash functions. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNF3jE043682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:15:03 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUNF3Ok043680; Tue, 30 Dec 2008 16:15:03 -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 chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUNF1RH043670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 16:15:02 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUNEtxp017907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 18:14:56 -0500 (EST) Date: Tue, 30 Dec 2008 18:14:55 -0500 From: Jeffrey Hutzelman To: Nicolas Williams cc: Eric Rescorla , Paul Hoffman , ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate Message-ID: <8A695EE544FEFDB0EDE3DD1A@atlantis.pc.cs.cmu.edu> In-Reply-To: <20081230223612.GN1872@Sun.COM> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> <20081230223612.GN1872@Sun.COM> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, December 30, 2008 04:36:12 PM -0600 Nicolas Williams wrote: > Applying a principle of redundancy in RTI algorithms to symmetric key > protocols is fairly simple. Applying such a principle to PKI seems > rather more difficult -- it's not just hash algorithms, but pk > algorithms too. Your example was to require not just the implementation > of multiple hash (but not pk) algorithms, but to require the *use* of > those. That makes sense to me, but it's not quite the same principle > being applied to PKI as to SSH. Correct. I'm suggesting that in the case of PKI, merely having two RTI algorithms wouldn't be sufficient; at least for long-term certificates you need to actually sign using two algorithms in order to get the interoperability benefit. Validating using both isn't necessary, though it does have a benefit, in that no code or configuration changes are required to continue to be safe as long as at least one is good enough. IMHO, one of the biggest problems in the current PKI standards is that there is no ability to future-proof certificates by generating signatures with multiple algorithms. The result is that you can't start signing with a new algorithm until everyone understands it, and you can't stop accepting an old algorithm without either reissuing lots of certificates with a new one or waiting for them to expire. This means movement is very slow and we are unable to abandon a broken algorithm in a hurry. The former is poor; the latter is a disaster waiting to happen. -- Jeff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUN7SiP043207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:07:28 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUN7SjU043206; Tue, 30 Dec 2008 16:07:28 -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.14.2/8.14.2) with ESMTP id mBUN7GLB043196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Dec 2008 16:07:27 -0700 (MST) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id mBUN7AO5030377 for ; Tue, 30 Dec 2008 18:07:10 -0500 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id mBUN6xjD020656 for ; Tue, 30 Dec 2008 18:06:59 -0500 Message-ID: <495AA992.5040504@nist.gov> Date: Tue, 30 Dec 2008 18:06:58 -0500 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.18 (X11/20081120) MIME-Version: 1.0 To: pkix Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> In-Reply-To: <495A9B44.1010201@mitre.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner-Information: 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: I have heard that using non-sequential serial numbers can cause problems for OCSP responders that pre-produce responses as well. There is an alternative, however, for CAs that do not wish to use randomized serial numbers. Randomness can be included in the validity dates. The described attack relied on the ability to guess both the serial number and validity dates of the certificate that would be issued. The authors were able to find a CA that always used validity dates of notBefore = T (where T was the time of issuance) and notAfter = T + 1 year, where T was always 6 seconds after the time that the certificate request was submitted. Suppose, however, that the CA selected two random numbers R1 and R2 and then used notBefore = T + R1 seconds and notAfter = T + R2 seconds + (normal validity period [e.g., 1 year]). If R1 and R2 were each chosen from the range [-15 ... 16] then the attacker would only have a 1 in 1024 chance of guessing the validity dates. If R1 and R2 were each chosen from the range [-511 ... 512] then the attacker would only have a 1 in 1,048,576 chance of guessing the validity dates. Since notBefore and notAfter would be modified by at most a few minutes, the randomization should not create any practical problems for users. Of course, randomizing the serial number is a more effective means of counteracting the attack since the serial number could be made a random 159-bit number and since the serial number appears earlier in the certificate, but incorporating some randomness into the validity dates would be a second best choice if the serial number cannot be randomized. Dave Timothy J. Miller wrote: > Eric Rescorla wrote: >> At Tue, 30 Dec 2008 12:53:06 -0800, >> Paul Hoffman wrote: >>> Your recollection may be off. I believe I was the person who brought >>> up the serial number hack at the mic, and I'm pretty sure I said >>> "some", not "many" (and certainly not "most"!). When I looked at a >>> handful of popular CAs earlier this week, I only found a few who are >>> using randomization in their serial numbers. >> I don't know whether many or most do it. IMO everyone should. > > Randomizing serial numbers has implications for OCSP operations, > particularly those that use presigned responses in order to optimize > performance. > > Why presign? Because for a large network with varying levels of > support, it may be easier to move around sets of pre-produced > responses to distributed keyless OCSP responders than to guarantee > connectivity to a keyed OCSP service. > > Why presign batches rather than individual responses? Because for a > large PKI the response pre-production time can exceed the CRL update > frequency. > > -- Tim Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUN0k3L042872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 16:00:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUN0kvd042870; Tue, 30 Dec 2008 16:00:46 -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 brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUN0Z99042846; Tue, 30 Dec 2008 16:00:46 -0700 (MST) (envelope-from Nicolas.Williams@sun.com) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mBUN0ZCC027191; Tue, 30 Dec 2008 23:00:35 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id mBUN0ZOK044664; Tue, 30 Dec 2008 16:00:35 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id mBUMb2LL003035; Tue, 30 Dec 2008 16:37:02 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id mBUMaCUE003034; Tue, 30 Dec 2008 16:36:12 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 30 Dec 2008 16:36:12 -0600 From: Nicolas Williams To: Jeffrey Hutzelman Cc: Eric Rescorla , Paul Hoffman , ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate Message-ID: <20081230223612.GN1872@Sun.COM> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> User-Agent: Mutt/1.5.7i Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Dec 30, 2008 at 05:01:12PM -0500, Jeffrey Hutzelman wrote: > Incidentally, the recently reported problems with CBC mode ciphers in SSH > have gotten me to thinking that in some situations, a single REQUIRED > algorithm isn't enough, because if something goes wrong and you have to > abandon that algorithm in a hurry, operators may be in a position of having > to choose between seriously compromising either security or > interoperability. +1 But note that in the case of the SSH CBC mode ciphers the vulnerable ciphers had only the cipher mode in common. The SSH vulnerability, in any case, doesn't stem from the use of CBC, but is more general, and well could have been worse, but let's ignore that for this argument. So in the SSH case one would have liked to have seen two or more REQUIRED to implement ciphers with very distinct properties. Say 3DES in CBC mode, AES in counter mode, and arcfour. Applying a principle of redundancy in RTI algorithms to symmetric key protocols is fairly simple. Applying such a principle to PKI seems rather more difficult -- it's not just hash algorithms, but pk algorithms too. Your example was to require not just the implementation of multiple hash (but not pk) algorithms, but to require the *use* of those. That makes sense to me, but it's not quite the same principle being applied to PKI as to SSH. Nico -- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMcbFf041941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:38:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMcaGr041938; Tue, 30 Dec 2008 15: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 romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMcaVV041923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:38:36 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 0E36550822; Tue, 30 Dec 2008 14:54:54 -0800 (PST) Date: Tue, 30 Dec 2008 14:54:53 -0800 From: Eric Rescorla To: "Timothy J. Miller" Cc: Eric Rescorla , Paul Hoffman , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "cfrg@irtf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: <20081230223500.48BD350822@romeo.rtfm.com> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081230225454.0E36550822@romeo.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here's Tim Callan from VEriSign posting about this: https://blogs.verisign.com/ssl-blog/2008/12/on_md5_vulnerabilities_and_mit.php -Ekr y Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMVYbx041608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:31:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMVYcL041606; Tue, 30 Dec 2008 15:31:34 -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 mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMVLtP041578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:31:32 -0700 (MST) (envelope-from Scott.Rea@Dartmouth.edu) Received: from newdasher.Dartmouth.EDU (newdasher.dartmouth.edu [129.170.208.30]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id mBULqtr9007948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 17:30:44 -0500 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from c-65-96-146-181.hsd1.nh.comcast.net [65.96.146.181] by newdasher.Dartmouth.EDU (Mac) via SMTP for id <138927721>; 30 Dec 2008 17:30:43 -0500 Message-ID: <495AA0F6.7060604@Dartmouth.edu> Date: Tue, 30 Dec 2008 17:30:14 -0500 From: Scott Rea User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Russ Housley CC: "RL 'Bob' Morgan" , Paul Hoffman , ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302217.mBUMH7XD040595@balder-227.proper.com> In-Reply-To: <200812302217.mBUMH7XD040595@balder-227.proper.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU X-MailScanner-SpamCheck: spam, SpamAssassin on mailhub2 (score=1.651, required 1, BAYES_00 -2.60, BLITZ_DISCLAIMER 0.05, HELO_DYNAMIC_IPADDR 4.20) X-MailScanner-SpamScore: s X-MailScanner-From: scott.rea@dartmouth.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley wrote: > > >>> Regardless of that, the authors of the MD5 paper are correct: trust >>> anchors signed with MD5 are highly questionable as of today (well, >>> actually, since they published their last paper). Hopefully, the >>> maintainers of the popular trust anchor repositories (Microsoft, >>> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and >>> MD2!) as soon as possible. >> >> This is a different claim than "CAs should stop issuing certs with >> MD5 signatures", which is what I as an amateur take away from a quick >> scan of the material. Obviously MD5 is suspect in various ways, but >> does this new work lead to the conclusion that MD5-signed roots are >> untrustworthy today? > > We recommended a migration (walk, don't run) away from MD2, MD4, and > SHA-1 toward SHA-256 a few years ago. MD2 and MD4 generate 128 bit > hash values; even without the attacks, these are getting to be too > small. SHA-1 has been shown to be weaker than its design goal, and > the 160 bit hash value will be getting too short in a couple of > years. We recommended SHA-256 while fully recognizing that NIST was > starting a hash competition, and that we might recommend the winner of > that competition as the successor to SHA-256. > > I still strongly encourage the migration to SHA-256. > > The use of the random bits in the serial number are insurance against > similar problems being found in other hash functions. This insurance > will hopefully provide time to migrate to another hash function when > cryptanalysis begins to show flaws in any future hash function. > > Russ But one of the things that has kept the brakes on migration has been support in clients for SHA256 - the largest vendor of client machines only just recently added SHA256 to its XP platform (if you upgrade to SP3). I keep running into folks using OpenSSL as their crypto base and they haven't updated to a distribution that supports SHA256. I think it will take a little more time before it becomes the default... -- Scott Rea Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMNsTb040975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:23:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMNsm7040974; Tue, 30 Dec 2008 15:23:54 -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 [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUMNqIJ040944 for ; Tue, 30 Dec 2008 15:23:52 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812302223.mBUMNqIJ040944@balder-227.proper.com> Received: (qmail 24294 invoked by uid 0); 30 Dec 2008 22:23:45 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:23:45 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 17:23:33 -0500 To: Eric Rescorla From: Russ Housley Subject: Re: Further MD5 breaks: Creating a rogue CA certificate Cc: cfrg@irtf.org, ietf-smime@imc.org, saag@ietf.org, ietf-pkix@imc.org In-Reply-To: <20081230223500.48BD350822@romeo.rtfm.com> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> <20081230223500.48BD350822@romeo.rtfm.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: >I'm not sure I understand the issue here, but >they don't actually have to be totally randomized. You could use a >PRF so they were predictable to the CA. That works. This works too: the serial number could be composed of two parts, where the most significant bits are a counter and the least significant bits are randomly generated. Russ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMNs7f040972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:23:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMNsLw040969; Tue, 30 Dec 2008 15:23:54 -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 rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.246]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMNgDm040924; Tue, 30 Dec 2008 15:23:53 -0700 (MST) (envelope-from blaker@gmail.com) Received: by rv-out-0708.google.com with SMTP id c5so5433808rvf.34 for ; Tue, 30 Dec 2008 14:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SOjf1T9xI3MBJb+v+mg2/Dsw2wPmsmYSixQ9iXiIRcA=; b=jLU/hS5jNIbna5Zku6U+axs1KV2KLYrQTa+hHCR/6kqe207G+tXYDsVPGgTJk0qupA RJNQu5TWWaiQBDzj6O/tCx4phcCEZunboOs+VpniRcdvoADq3XwUZ1mzr83/ud5RY47H 8qdO/4Hzhx0900vj2XpDMmQJIaimvjR/nKQhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fNUP7Tab+VzvZPlIZjRGwRfpijhSl5e12WjdlWGoMMTJAQLgGCUXaBh6fPtA/Uex4x SNJMbQy/susUqr3OwRpb03aw46n6l9v8rUN4Gu8YA/jVRFYUFah7cKKcTeg4ApodNWJq EylztJzNVq1Niy3z4I7ag/Xk1/BlZfI+34MHY= Received: by 10.140.226.14 with SMTP id y14mr7464473rvg.59.1230675822107; Tue, 30 Dec 2008 14:23:42 -0800 (PST) Received: by 10.141.169.13 with HTTP; Tue, 30 Dec 2008 14:23:42 -0800 (PST) Message-ID: <985966520812301423g7f9b5b33o9219f27216b17d18@mail.gmail.com> Date: Tue, 30 Dec 2008 14:23:42 -0800 From: "Blake Ramsdell" To: "Timothy J. Miller" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate Cc: "Eric Rescorla" , "Paul Hoffman" , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "cfrg@irtf.org" In-Reply-To: <495A9B44.1010201@mitre.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, Dec 30, 2008 at 2:05 PM, Timothy J. Miller wrote: > Randomizing serial numbers has implications for OCSP operations, > particularly those that use presigned responses in order to optimize > performance. It seems that the disruption caused by modifying serial number generation for existing CAs is pretty high. Would an easier solution be to either a) make the validity period vary slightly (in the documented attack, the notBefore was always a fixed interval from the submission time, and making this vary in a period of just a few minutes would have thwarted it, if I'm understanding correctly), or b) the CA sticks some random junk in the subject DN (not an MPEG of a cat, but maybe OU=sf9fj3 [some base64 PRNG data]). Blake -- Blake Ramsdell | http://www.blakeramsdell.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMIheK040690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:18:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMIhrR040686; Tue, 30 Dec 2008 15:18:43 -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 romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMIg9v040670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:18:42 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 48BD350822; Tue, 30 Dec 2008 14:35:00 -0800 (PST) Date: Tue, 30 Dec 2008 14:34:59 -0800 From: Eric Rescorla To: "Timothy J. Miller" Cc: Eric Rescorla , Paul Hoffman , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "cfrg@irtf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: <495A9B44.1010201@mitre.org> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> <495A9B44.1010201@mitre.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081230223500.48BD350822@romeo.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Tue, 30 Dec 2008 16:05:56 -0600, Timothy J. Miller wrote: > > [1 ] > Eric Rescorla wrote: > > At Tue, 30 Dec 2008 12:53:06 -0800, > > Paul Hoffman wrote: > > >> Your recollection may be off. I believe I was the person who brought > >> up the serial number hack at the mic, and I'm pretty sure I said > >> "some", not "many" (and certainly not "most"!). When I looked at a > >> handful of popular CAs earlier this week, I only found a few who are > >> using randomization in their serial numbers. > > > I don't know whether many or most do it. IMO everyone should. > > Randomizing serial numbers has implications for OCSP operations, > particularly those that use presigned responses in order to optimize > performance. > > Why presign? Because for a large network with varying levels of > support, it may be easier to move around sets of pre-produced responses > to distributed keyless OCSP responders than to guarantee connectivity to > a keyed OCSP service. > > Why presign batches rather than individual responses? Because for a > large PKI the response pre-production time can exceed the CRL update > frequency. I'm not sure I understand the issue here, but they don't actually have to be totally randomized. You could use a PRF so they were predictable to the CA. -Ekr Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUMH83B040617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:17:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUMH8pE040614; Tue, 30 Dec 2008 15:17:08 -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 [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUMH7XD040595 for ; Tue, 30 Dec 2008 15:17:07 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812302217.mBUMH7XD040595@balder-227.proper.com> Received: (qmail 20400 invoked by uid 0); 30 Dec 2008 22:17:00 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:17:00 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 17:12:02 -0500 To: "RL 'Bob' Morgan" , Paul Hoffman From: Russ Housley Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate Cc: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org In-Reply-To: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> 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: >>Regardless of that, the authors of the MD5 paper are correct: trust >>anchors signed with MD5 are highly questionable as of today (well, >>actually, since they published their last paper). Hopefully, the >>maintainers of the popular trust anchor repositories (Microsoft, >>Mozilla, etc.) will yank out the trust anchors signed with MD5 (and >>MD2!) as soon as possible. > >This is a different claim than "CAs should stop issuing certs with >MD5 signatures", which is what I as an amateur take away from a >quick scan of the material. Obviously MD5 is suspect in various >ways, but does this new work lead to the conclusion that MD5-signed >roots are untrustworthy today? We recommended a migration (walk, don't run) away from MD2, MD4, and SHA-1 toward SHA-256 a few years ago. MD2 and MD4 generate 128 bit hash values; even without the attacks, these are getting to be too small. SHA-1 has been shown to be weaker than its design goal, and the 160 bit hash value will be getting too short in a couple of years. We recommended SHA-256 while fully recognizing that NIST was starting a hash competition, and that we might recommend the winner of that competition as the successor to SHA-256. I still strongly encourage the migration to SHA-256. The use of the random bits in the serial number are insurance against similar problems being found in other hash functions. This insurance will hopefully provide time to migrate to another hash function when cryptanalysis begins to show flaws in any future hash function. Russ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM6bm0039982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:06:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM6bFA039981; Tue, 30 Dec 2008 15:06: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-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM6P1i039959; Tue, 30 Dec 2008 15:06:36 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBUM6OPb025827; Tue, 30 Dec 2008 17:06:25 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id mBUM6Ocb025814; Tue, 30 Dec 2008 17:06:24 -0500 Received: from [129.83.200.2] (129.83.200.2) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 30 Dec 2008 17:06:24 -0500 Message-ID: <495A9B44.1010201@mitre.org> Date: Tue, 30 Dec 2008 16:05:56 -0600 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Eric Rescorla CC: Paul Hoffman , "ietf-pkix@imc.org" , "ietf-smime@imc.org" , "saag@ietf.org" , "cfrg@irtf.org" Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <20081230213934.C219450822@romeo.rtfm.com> In-Reply-To: <20081230213934.C219450822@romeo.rtfm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000706050700070408070900" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------ms000706050700070408070900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > At Tue, 30 Dec 2008 12:53:06 -0800, > Paul Hoffman wrote: >> Your recollection may be off. I believe I was the person who brought >> up the serial number hack at the mic, and I'm pretty sure I said >> "some", not "many" (and certainly not "most"!). When I looked at a >> handful of popular CAs earlier this week, I only found a few who are >> using randomization in their serial numbers. > I don't know whether many or most do it. IMO everyone should. Randomizing serial numbers has implications for OCSP operations, particularly those that use presigned responses in order to optimize performance. Why presign? Because for a large network with varying levels of support, it may be easier to move around sets of pre-produced responses to distributed keyless OCSP responders than to guarantee connectivity to a keyed OCSP service. Why presign batches rather than individual responses? Because for a large PKI the response pre-production time can exceed the CRL update frequency. -- Tim --------------ms000706050700070408070900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICqDCC AqQCAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBmzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wODEyMzAyMjA1NTZaMCMGCSqGSIb3DQEJBDEWBBQ4RbejFRP0hZy6Vjhh795xqhnGfDBS BgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDByBgkrBgEEAYI3EAQxZTBjMF0xEjAQBgNV BAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQD Ex5NSVRSRSBDb3Jwb3JhdGlvbiBQcmltYXJ5IENBLTECAh8FMHQGCyqGSIb3DQEJEAILMWWg YzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0 eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTANBgkqhkiG 9w0BAQEFAASBgELzHlPR7X3MOFLP5ZcY1mbMXJyVuu8D6m/7NK0eZrsmu7YMbLzv7t5txCiQ 6CHlVuWg0WcLwT24dUazLur+cNII/+p5MiS42K0qScSEoWc7uJDgKtmol40n1brGU7mVvLVm oNAh3ZUvQV/gAJ3VbnN61DL/Eld+TlsdEjGJ8SirAAAAAAAA --------------ms000706050700070408070900-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM2X1N039872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:02:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM2WJQ039871; Tue, 30 Dec 2008 15:02: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 dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM2UYN039852; Tue, 30 Dec 2008 15:02:31 -0700 (MST) (envelope-from ynir@checkpoint.com) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E614A29C002; Wed, 31 Dec 2008 00:02:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7F09C29C001; Wed, 31 Dec 2008 00:02:08 +0200 (IST) X-CheckPoint: {495A98AD-10000-88241DC2-7B6} Received: from [172.31.21.158] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBUM27fE029359; Wed, 31 Dec 2008 00:02:08 +0200 (IST) Cc: Paul Hoffman , ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org Message-Id: <9D2E555A-7A24-4FA7-ABF9-33F6F55AA8F2@checkpoint.com> From: Yoav Nir To: "RL 'Bob' Morgan" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Wed, 31 Dec 2008 00:02:07 +0200 References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> Regardless of that, the authors of the MD5 paper are correct: trust >> anchors signed with MD5 are highly questionable as of today (well, >> actually, since they published their last paper). Hopefully, the >> maintainers of the popular trust anchor repositories (Microsoft, >> Mozilla, etc.) will yank out the trust anchors signed with MD5 (and >> MD2!) as soon as possible. > > This is a different claim than "CAs should stop issuing certs with > MD5 signatures", which is what I as an amateur take away from a > quick scan of the material. Obviously MD5 is suspect in various > ways, but does this new work lead to the conclusion that MD5-signed > roots are untrustworthy today? > Replacing a root is a much bigger deal then changing signing > practices. > > - RL "Bob" CAs should have stopped issuing certs with MD5 signatures 4 years ago, when the first practical attacks on MD5 were published. Now it would be more correct to say that "relying parties should treat as invalid any certificate chain that contains an MD5 (or MD2, MD4) signature" Since in the HTTPS context the relying parties are the browsers, it falls to the vendors (if Microsoft leads, everyone will follow) to, as Paul said, yank the trust anchors. It should be noted, though, that yanking the trust anchors is not enough. You really should change the relying party to not recognize this algorithm. Otherwise, it's perfectly valid for a CA whose certificate is signed with SHA1 to sign an intermediate CA certificate with MD5 (although they usually don't do that, I hope) Email secured by Check Point Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM2L0u039828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:02:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM2L1x039826; Tue, 30 Dec 2008 15:02:21 -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 [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUM2J2p039808 for ; Tue, 30 Dec 2008 15:02:20 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812302202.mBUM2J2p039808@balder-227.proper.com> Received: (qmail 12655 invoked by uid 0); 30 Dec 2008 22:02:12 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 22:02:12 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 16:33:19 -0500 To: Paul Hoffman From: Russ Housley Subject: Re: Further MD5 breaks: Creating a rogue CA certificate Cc: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org In-Reply-To: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> 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: Paul: >If the IETF feels that adding randomization to signatures is >important, we should define randomized signature functions. We could >start with NIST Draft SP 800-106 >(). >However, I think that doing so is sending the wrong message: we >should instead be encouraging the use of non-broken hash functions. This is a very different thing than a BCP that the recommends that the certificate serial number include some random bits. Russ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM1XIL039746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 15:01:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUM1Xvo039744; Tue, 30 Dec 2008 15:01: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 chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUM1Lqj039727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 15:01:32 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from atlantis-home.pc.cs.cmu.edu (173-101-98-177.pools.spcsdns.net [173.101.98.177]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUM1Cht017220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 17:01:14 -0500 (EST) Date: Tue, 30 Dec 2008 17:01:12 -0500 From: Jeffrey Hutzelman To: Eric Rescorla , Paul Hoffman cc: ietf-pkix@imc.org, ietf-smime@imc.org, cfrg@irtf.org, saag@ietf.org, jhutz@cmu.edu Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CA certificate Message-ID: <48CD499D55E1C2D95D687684@atlantis.pc.cs.cmu.edu> In-Reply-To: <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> <200812302128.mBULSOUp021688@toasties.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, December 30, 2008 01:39:34 PM -0800 Eric Rescorla wrote: > At Tue, 30 Dec 2008 12:53:06 -0800, > Paul Hoffman wrote: >> >> At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: >> > This is a practical application of an approach that I remember being >> > brought up during discussions about MD5 at a saag meeting some time >> > ago. I also recall someone mentioning at the time that many/most CA's >> > were already issuing certificates with random rather than sequential >> > serial numbers, which would have thwarted this particular attack. >> >> Your recollection may be off. I believe I was the person who brought >> up the serial number hack at the mic, and I'm pretty sure I said >> "some", not "many" (and certainly not "most"!). When I looked at a >> handful of popular CAs earlier this week, I only found a few who are >> using randomization in their serial numbers. > > So it's in my deck from SAAG at IETF 62. > > http://www.ietf.org/proceedings/05mar/slides/saag-3.pdf > > I don't know whether many or most do it. IMO everyone should. I just checked my records, and shortly after that IETF, our internal CA started issuing certificates with SHA-1 signatures and randomized serial numbers, as a direct result of that discussion. > >> > RFC 5280 does not include this advice. It is sound advice that was >> > discussed in PKIX and other venues. Perhaps a BCP is in order. >> >> Man, that is really stretching the definition of "best". >> >> For one, it is only needed in signatures that use known-attackable >> hash functions. A "best practice" in that case is to use a better >> hash function in the signature. Also, it relies on the ability of >> the software using the random number to be sure that the result is a >> positive integer in ASN.1, which seems overly optimistic. On the contrary, IMHO best practice is to take every reasonable measure to reduce the likelyhood of an attack. In my book, that means both using a better hash function _and_ using randomized serial numbers, since the latter clearly helps when the hash is broken, and hash functions may become broken over time, and before you realize it. >> If the IETF feels that adding randomization to signatures is >> important, we should define randomized signature functions. I think that's a very good idea. However... > I certainly agree we should be encouraging the use of non-broken hash > functions. However, randomizing the SN seems like very cheap backward > compatible insurance against the fact that that's going to take a long > time. "what he said". Incidentally, the recently reported problems with CBC mode ciphers in SSH have gotten me to thinking that in some situations, a single REQUIRED algorithm isn't enough, because if something goes wrong and you have to abandon that algorithm in a hurry, operators may be in a position of having to choose between seriously compromising either security or interoperability. In the case of usages like certificates where no live negotiation is possible and implementations may have to interoperate over a long period of time, I believe additional care is necessary. For example, I think it would be a good idea to define a composite signature function which uses more than one hash computed independently. This would likely make some attacks harder, but more importantly, it means that as long as at least one of the underlying hashes is strong enough, the signature is still usable. -- Jeff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULdmOx038675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:39:48 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULdmIX038674; Tue, 30 Dec 2008 14:39:48 -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 prospect.joyent.us (prospect.joyent.us [8.12.36.36]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULdaRA038639; Tue, 30 Dec 2008 14:39:46 -0700 (MST) (envelope-from pmhesse@geminisecurity.com) Received: from PeterVistaSP1 (static-68-163-72-26.res.east.verizon.net [68.163.72.26]) by prospect.joyent.us (Postfix) with ESMTPSA id 14CD01ECC7; Tue, 30 Dec 2008 21:39:34 +0000 (GMT) From: "Peter Hesse" To: "'RL 'Bob' Morgan'" , "'Paul Hoffman'" Cc: , , , References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> In-Reply-To: Subject: RE: [saag] Further MD5 breaks: Creating a rogue CA certificate Date: Tue, 30 Dec 2008 16:39:34 -0500 Message-ID: <08bb01c96ac7$1cd5a750$5680f5f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclqxboXk3PuIMY0SLuDtNKXm7F2qQAAEKtA Content-Language: en-us Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ceasing the issuance of certificates with MD5 used in the signature doesn't solve the problem of the certificates that have already been issued and are still out there, any number of which may be rogue. Replacing, or marking as untrusted all root certificates which have any current valid (i.e. non-expired, non-revoked) certificates with MD5 used in the signature could have tremendous undesirable impact and be an untenable solution. The right tool for the job is a client-side solution to fail validation of any signature which uses MD5, especially certificate signatures. I will not hold my breath for such a solution. --Peter ---------------------------------------------------------------- Peter Hesse pmhesse@geminisecurity.com http://securitymusings.com http://geminisecurity.com -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of RL 'Bob' Morgan Sent: Tuesday, December 30, 2008 4:18 PM To: Paul Hoffman Cc: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate > Regardless of that, the authors of the MD5 paper are correct: trust > anchors signed with MD5 are highly questionable as of today (well, > actually, since they published their last paper). Hopefully, the > maintainers of the popular trust anchor repositories (Microsoft, > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5 signatures", which is what I as an amateur take away from a quick scan of the material. Obviously MD5 is suspect in various ways, but does this new work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULNIAn038040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:23:18 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULNIdv038039; Tue, 30 Dec 2008 14:23:18 -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 romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULNH61038023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:23:17 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id C219450822; Tue, 30 Dec 2008 13:39:34 -0800 (PST) Date: Tue, 30 Dec 2008 13:39:34 -0800 From: Eric Rescorla To: Paul Hoffman Cc: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081230213934.C219450822@romeo.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Tue, 30 Dec 2008 12:53:06 -0800, Paul Hoffman wrote: > > At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: > >This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. > > Your recollection may be off. I believe I was the person who brought > up the serial number hack at the mic, and I'm pretty sure I said > "some", not "many" (and certainly not "most"!). When I looked at a > handful of popular CAs earlier this week, I only found a few who are > using randomization in their serial numbers. So it's in my deck from SAAG at IETF 62. http://www.ietf.org/proceedings/05mar/slides/saag-3.pdf I don't know whether many or most do it. IMO everyone should. > >RFC 5280 does not include this advice. It is sound advice that was > >discussed in PKIX and other venues. Perhaps a BCP is in order. > > Man, that is really stretching the definition of "best". > > For one, it is only needed in signatures that use known-attackable > hash functions. A "best practice" in that case is to use a better > hash function in the signature. Also, it relies on the ability of > the software using the random number to be sure that the result is a > positive integer in ASN.1, which seems overly optimistic. > > If the IETF feels that adding randomization to signatures is > important, we should define randomized signature functions. We could > start with NIST Draft SP 800-106 > (). However, > I think that doing so is sending the wrong message: we should > instead be encouraging the use of non-broken hash functions. I certainly agree we should be encouraging the use of non-broken hash functions. However, randomizing the SN seems like very cheap backward compatible insurance against the fact that that's going to take a long time. -Ekr Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULIest037910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 14:18:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBULIefq037903; Tue, 30 Dec 2008 14:18: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 mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBULIShF037889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 14:18:39 -0700 (MST) (envelope-from rlmorgan@washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.7] (may be forged)) by mxout5.cac.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id mBULIO3h014517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Dec 2008 13:18:24 -0800 X-Auth-Received: from D-140-142-21-194.dhcp4.washington.edu (D-140-142-21-194.dhcp4.washington.edu [140.142.21.194]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.14.3+UW08.09/8.14.3+UW08.11) with ESMTP id mBULIOpq023005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Dec 2008 13:18:24 -0800 Date: Tue, 30 Dec 2008 13:17:50 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: Paul Hoffman cc: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: Message-ID: References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.5.0.356843, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2008.12.30.210424 X-Uwash-Spam: Gauge=IIIIIII, Probability=8%, Report='BODY_SIZE_1000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_700_799 0, FROM_EDU_TLD 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Regardless of that, the authors of the MD5 paper are correct: trust > anchors signed with MD5 are highly questionable as of today (well, > actually, since they published their last paper). Hopefully, the > maintainers of the popular trust anchor repositories (Microsoft, > Mozilla, etc.) will yank out the trust anchors signed with MD5 (and > MD2!) as soon as possible. This is a different claim than "CAs should stop issuing certs with MD5 signatures", which is what I as an amateur take away from a quick scan of the material. Obviously MD5 is suspect in various ways, but does this new work lead to the conclusion that MD5-signed roots are untrustworthy today? Replacing a root is a much bigger deal then changing signing practices. - RL "Bob" Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUKrcEw036778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:53:38 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUKrcNS036777; Tue, 30 Dec 2008 13:53:38 -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 [10.20.30.158] ([207.62.247.66]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUKrXOU036766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:53:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> Date: Tue, 30 Dec 2008 12:53:06 -0800 To: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org From: Paul Hoffman Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote: >This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. Your recollection may be off. I believe I was the person who brought up the serial number hack at the mic, and I'm pretty sure I said "some", not "many" (and certainly not "most"!). When I looked at a handful of popular CAs earlier this week, I only found a few who are using randomization in their serial numbers. Regardless of that, the authors of the MD5 paper are correct: trust anchors signed with MD5 are highly questionable as of today (well, actually, since they published their last paper). Hopefully, the maintainers of the popular trust anchor repositories (Microsoft, Mozilla, etc.) will yank out the trust anchors signed with MD5 (and MD2!) as soon as possible. At 3:10 PM -0500 12/30/08, Russ Housley wrote: >RFC 5280 does not include this advice. It is sound advice that was discussed in PKIX and other venues. Perhaps a BCP is in order. Man, that is really stretching the definition of "best". For one, it is only needed in signatures that use known-attackable hash functions. A "best practice" in that case is to use a better hash function in the signature. Also, it relies on the ability of the software using the random number to be sure that the result is a positive integer in ASN.1, which seems overly optimistic. If the IETF feels that adding randomization to signatures is important, we should define randomized signature functions. We could start with NIST Draft SP 800-106 (). However, I think that doing so is sending the wrong message: we should instead be encouraging the use of non-broken hash functions. --Paul Hoffman, Director --VPN Consortium Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUKGsOx035034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:16:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUKGs2c035033; Tue, 30 Dec 2008 13:16:54 -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 [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUKGhdl035004 for ; Tue, 30 Dec 2008 13:16:53 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812302016.mBUKGhdl035004@balder-227.proper.com> Received: (qmail 14731 invoked by uid 0); 30 Dec 2008 20:16:37 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 20:16:37 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 15:10:45 -0500 To: Jeffrey Hutzelman From: Russ Housley Subject: Re: Further MD5 breaks: Creating a rogue CA certificate Cc: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org In-Reply-To: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> 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: Jeff: >>http://www.win.tue.nl/hashclash/rogue-ca/ >> >>MD5 considered harmful today >>Creating a rogue CA certificate >> >>December 30, 2008 >> >>Alexander Sotirov, Marc Stevens, >>Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de >>Weger >> >>We have identified a vulnerability in the Internet Public Key >>Infrastructure (PKI) used to issue digital certificates for secure >>websites. As a proof of concept we executed a practical attack scenario >>and successfully created a rogue Certification Authority (CA) certificate >>trusted by all common web browsers. This certificate allows us to >>impersonate any website on the Internet, including banking and e-commerce >>sites secured using the HTTPS protocol. >> >>Our attack takes advantage of a weakness in the MD5 cryptographic hash >>function that allows the construction of different messages with the same >>MD5 hash. This is known as an MD5 "collision". Previous work on MD5 >>collisions between 2004 and 2007 showed that the use of this hash >>function in digital signatures can lead to theoretical attack scenarios. >>Our current work proves that at least one attack scenario can be >>exploited in practice, thus exposing the security infrastructure of the >>web to realistic threats. > > >This is a practical application of an approach that I remember being >brought up during discussions about MD5 at a saag meeting some time >ago. I also recall someone mentioning at the time that many/most >CA's were already issuing certificates with random rather than >sequential serial numbers, which would have thwarted this particular attack. RFC 5280 does not include this advice. It is sound advice that was discussed in PKIX and other venues. Perhaps a BCP is in order. Russ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUK78Ju034463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:07:08 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUK78Cg034461; Tue, 30 Dec 2008 13:07:08 -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 romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUK6sZq034429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:07:08 -0700 (MST) (envelope-from ekr@networkresonance.com) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DFF4550822; Tue, 30 Dec 2008 12:23:11 -0800 (PST) Date: Tue, 30 Dec 2008 12:23:11 -0800 From: Eric Rescorla To: Jeffrey Hutzelman Cc: Russ Housley , ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate In-Reply-To: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20081230202311.DFF4550822@romeo.rtfm.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At Tue, 30 Dec 2008 13:33:46 -0500, Jeffrey Hutzelman wrote: > > --On Tuesday, December 30, 2008 11:05:28 AM -0500 Russ Housley > wrote: > > > http://www.win.tue.nl/hashclash/rogue-ca/ > > > > MD5 considered harmful today > > Creating a rogue CA certificate > > > > December 30, 2008 > > > > Alexander Sotirov, Marc Stevens, > > Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de > > Weger > > > > We have identified a vulnerability in the Internet Public Key > > Infrastructure (PKI) used to issue digital certificates for secure > > websites. As a proof of concept we executed a practical attack scenario > > and successfully created a rogue Certification Authority (CA) certificate > > trusted by all common web browsers. This certificate allows us to > > impersonate any website on the Internet, including banking and e-commerce > > sites secured using the HTTPS protocol. > > > > Our attack takes advantage of a weakness in the MD5 cryptographic hash > > function that allows the construction of different messages with the same > > MD5 hash. This is known as an MD5 "collision". Previous work on MD5 > > collisions between 2004 and 2007 showed that the use of this hash > > function in digital signatures can lead to theoretical attack scenarios. > > Our current work proves that at least one attack scenario can be > > exploited in practice, thus exposing the security infrastructure of the > > web to realistic threats. > > > This is a practical application of an approach that I remember being > brought up during discussions about MD5 at a saag meeting some time ago. I > also recall someone mentioning at the time that many/most CA's were already > issuing certificates with random rather than sequential serial numbers, > which would have thwarted this particular attack. Yep. Would that they all were. FWIW, here is my writeup of this issue, targeted towards a broader community: http://www.educatedguesswork.org/2008/12/understanding_the_sotirov_et_a.html -Ekr Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUIY5KW027105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 11:34:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUIY5K6027104; Tue, 30 Dec 2008 11:34: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 chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUIXrB8027081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2008 11:34:04 -0700 (MST) (envelope-from jhutz@cmu.edu) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id mBUIXkTS014008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 13:33:47 -0500 (EST) Date: Tue, 30 Dec 2008 13:33:46 -0500 From: Jeffrey Hutzelman To: Russ Housley , ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org cc: jhutz@cmu.edu Subject: Re: [saag] Further MD5 breaks: Creating a rogue CA certificate Message-ID: <9535147E88DA266C69B983D0@atlantis.pc.cs.cmu.edu> In-Reply-To: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> References: <200812301605.mBUG5cKU027325@raisinbran.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.185.41 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, December 30, 2008 11:05:28 AM -0500 Russ Housley wrote: > http://www.win.tue.nl/hashclash/rogue-ca/ > > MD5 considered harmful today > Creating a rogue CA certificate > > December 30, 2008 > > Alexander Sotirov, Marc Stevens, > Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de > Weger > > We have identified a vulnerability in the Internet Public Key > Infrastructure (PKI) used to issue digital certificates for secure > websites. As a proof of concept we executed a practical attack scenario > and successfully created a rogue Certification Authority (CA) certificate > trusted by all common web browsers. This certificate allows us to > impersonate any website on the Internet, including banking and e-commerce > sites secured using the HTTPS protocol. > > Our attack takes advantage of a weakness in the MD5 cryptographic hash > function that allows the construction of different messages with the same > MD5 hash. This is known as an MD5 "collision". Previous work on MD5 > collisions between 2004 and 2007 showed that the use of this hash > function in digital signatures can lead to theoretical attack scenarios. > Our current work proves that at least one attack scenario can be > exploited in practice, thus exposing the security infrastructure of the > web to realistic threats. This is a practical application of an approach that I remember being brought up during discussions about MD5 at a saag meeting some time ago. I also recall someone mentioning at the time that many/most CA's were already issuing certificates with random rather than sequential serial numbers, which would have thwarted this particular attack. -- Jeff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBUG5kww018631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2008 09:05:46 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBUG5jD9018622; Tue, 30 Dec 2008 09:05: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBUG5YRs018576 for ; Tue, 30 Dec 2008 09:05:44 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812301605.mBUG5YRs018576@balder-227.proper.com> Received: (qmail 4826 invoked by uid 0); 30 Dec 2008 16:05:29 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 30 Dec 2008 16:05:29 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Dec 2008 11:05:28 -0500 To: ietf-pkix@imc.org, ietf-smime@imc.org, saag@ietf.org, cfrg@irtf.org From: Russ Housley Subject: Further MD5 breaks: Creating a rogue CA certificate 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: http://www.win.tue.nl/hashclash/rogue-ca/ MD5 considered harmful today Creating a rogue CA certificate December 30, 2008 Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol. Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 "collision". Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDgUl0064477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 06:42:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBSDgUVJ064476; Sun, 28 Dec 2008 06:42: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 robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDgTI8064469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 28 Dec 2008 06:42:30 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id mBSDgTBV016209; Sun, 28 Dec 2008 05:42:29 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Dec 2008 05:42:29 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C968F2.1F8A2075" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: New Version Notification for draft-hallambaker-ocspagility-02 Date: Sun, 28 Dec 2008 05:42:27 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFC32@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02 Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYUAbAkkKADYA7QBQ== References: <20081202183941.5A3003A6B4C@core3.amsl.com> <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> <9F11911AED01D24BAA1C2355723C3D321AB5BBBECD@EA-EXMSG-C332.europe.corp.microsoft.com> From: "Hallam-Baker, Phillip" To: "Stefan Santesson" , X-OriginalArrivalTime: 28 Dec 2008 13:42:29.0287 (UTC) FILETIME=[2077DB70:01C968F2] 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_01C968F2.1F8A2075 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1) On the issue of algorithm strength. The problem here is that the = accepted strength of an algorithm may change during the validity period = of the cert. So RSA 1024 might be perfectly acceptable for use in = conjunction with an OCSP validity check mechanism, provided that the = OCSP check is solid. We have for many years had the luxury of being able to avoid concerns = for crypto algorithm strength by simply adding more bits. Let that = continue for as long as possible, but if it does happen there are a lot = of edge cases that are likely to be thrown up during the transition that = are ugly. Another case that I have been looking at a lot recently is one where a = device that is incapable of doing public key crypto is being used in a = PKI. This is for SCADA type applications. Believe it or not it is = entirely possible to make this situation work with very low cost, low = power micro-controller devices. There was a lot of work done on this = early on in the development of PKI but the ideas were mostly dropped as = (1) workstation class machines became ubiquitous and the CPU overhead = issue became moot and (2) these approaches decrease the CPU overhead at = the periphery by concentrating it at the server, not a winning strategy = in 1985, but one that is entirely practical today. These are devices that have too little RAM to generate an RSA 2048 bit = signature, let alone an Ethernet packet. But they can do AES and there = are serious reasons for doing so. 2) I left RFC 5019 out of consideration entirely when writing the draft. = Looking over it again I think that it already makes the decisions for = us, all we need to do is to make reference to the existing decision = here, perhaps adding an explanation of the reason why. Cache busting is = already discouraged in 5019. Use of request extensions is already a SHOULD NOT in RFC 5019, so this = would be carried over here. Applications SHOULD NOT be using the = algorithm selector extension unless there is a compatibility driven = reason not to. I think we should state this and give the reason (cache = busting) as the whole point of a SHOULD NOT is that there is a potential = balance. If an application absolutely needs to specify the extension to = function then that takes priority over cache busting. -----Original Message----- From: owner-ietf-pkix@mail.imc.org on behalf of Stefan Santesson Sent: Thu 12/11/2008 4:21 AM To: Hallam-Baker, Phillip; ietf-pkix@imc.org Subject: RE: New Version Notification for = draft-hallambaker-ocspagility-02=20 =20 Phil, =20 I have a few comments on the draft: =20 This is more a nit, but I don't think the following is a compelling = argument, strong enough to be mentioned: o An implementation may intentionally wish to guard against the possibility of a compromise resulting from a signature algorithm compromise by employing two separate encryption algorithms. =20 If an implementation is securing two co-dependent messages with two = different algorithms, where breaking one of them successfully = compromises the system, then you have increased your risk of compromise = rather than reducing it. =20 Further, I would like to see some explicit text, explaining that this = approach is not applicable, or at least should not be used in = combination with implementations of 5019. Section 4.2. do state that the server can pre-produce several responses = to the same request signed with different algorithms, but what I'm most = concerned with is that clients including the extension in the request, = in combination with RFC 5019 implementations may mess up http caching. = Http caching is an important aspect of achieving scalability for LW = OCSP.=20 =20 I would prefer to entirely discourage the use of this client extension = with RFC 5019, but at least discuss the issue in the draft to make = implementers aware of the problem. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Hallam-Baker, Phillip Sent: den 2 december 2008 20:01 To: ietf-pkix@imc.org Subject: FW: New Version Notification for = draft-hallambaker-ocspagility-02=20 =20 =20 As promised at the meeting, here is an update to the OCSP agility draft. With the WG and chair's permission I will resubmit as a WG draft. The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented. So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC. And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it. So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM To: Hallam-Baker, Phillip Subject: New Version Notification for draft-hallambaker-ocspagility-02 A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository. Filename: draft-hallambaker-ocspagility Revision: 02 Title: OCSP Algorithm Agility Creation_date: 2008-12-02 WG ID: Independent Submission Number_of_pages: 8 Abstract: The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. = =20 The IETF Secretariat. ------_=_NextPart_001_01C968F2.1F8A2075 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: New Version Notification for draft-hallambaker-ocspagility-02 =

1) On the issue of algorithm strength. The problem = here is that the accepted strength of an algorithm may change during the = validity period of the cert. So RSA 1024 might be perfectly acceptable = for use in conjunction with an OCSP validity check mechanism, provided = that the OCSP check is solid.

We have for many years had the luxury of being able to avoid concerns = for crypto algorithm strength by simply adding more bits. Let that = continue for as long as possible, but if it does happen there are a lot = of edge cases that are likely to be thrown up during the transition that = are ugly.

Another case that I have been looking at a lot recently is one where a = device that is incapable of doing public key crypto is being used in a = PKI. This is for SCADA type applications. Believe it or not it is = entirely possible to make this situation work with very low cost, low = power micro-controller devices. There was a lot of work done on this = early on in the development of PKI but the ideas were mostly dropped as = (1) workstation class machines became ubiquitous and the CPU overhead = issue became moot and (2) these approaches decrease the CPU overhead at = the periphery by concentrating it at the server, not a winning strategy = in 1985, but one that is entirely practical today.

These are devices that have too little RAM to generate an RSA 2048 bit = signature, let alone an Ethernet packet. But they can do AES and there = are serious reasons for doing so.


2) I left RFC 5019 out of consideration entirely when writing the draft. = Looking over it again I think that it already makes the decisions for = us, all we need to do is to make reference to the existing decision = here, perhaps adding an explanation of the reason why. Cache busting is = already discouraged in 5019.

Use of request extensions is already a SHOULD NOT in RFC 5019, so this = would be carried over here. Applications SHOULD NOT be using the = algorithm selector extension unless there is a compatibility driven = reason not to. I think we should state this and give the reason (cache = busting) as the whole point of a SHOULD NOT is that there is a potential = balance. If an application absolutely needs to specify the extension to = function then that takes priority over cache busting.




-----Original Message-----
From: owner-ietf-pkix@mail.imc.org on behalf of Stefan Santesson
Sent: Thu 12/11/2008 4:21 AM
To: Hallam-Baker, Phillip; ietf-pkix@imc.org
Subject: RE: New Version Notification for = draft-hallambaker-ocspagility-02

Phil,



I have a few comments on the draft:



This is more a nit, but I don't think the following is a compelling = argument, strong enough to be mentioned:

   o  An implementation may intentionally wish to guard = against the

      possibility of a compromise resulting = from a signature algorithm

      compromise by employing two separate = encryption algorithms.



If an implementation is securing two co-dependent messages with two = different algorithms, where breaking one of them successfully = compromises the system, then you have increased your risk of compromise = rather than reducing it.



Further, I would like to see some explicit text, explaining that this = approach is not applicable, or at least should not be used in = combination with implementations of 5019.

Section 4.2. do state that the server can pre-produce several responses = to the same request signed with different algorithms, but what I'm most = concerned with is that clients including the extension in the request, = in combination with RFC 5019 implementations may mess up http caching. = Http caching is an important aspect of achieving scalability for LW = OCSP.



I would prefer to entirely discourage the use of this client extension = with RFC 5019, but at least discuss the issue in the draft to make = implementers aware of the problem.





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 Hallam-Baker, Phillip
Sent: den 2 december 2008 20:01
To: ietf-pkix@imc.org
Subject: FW: New Version Notification for = draft-hallambaker-ocspagility-02





As promised at the meeting, here is an update to the OCSP agility = draft.

With the WG and chair's permission I will resubmit as a WG draft.


The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented.


So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC.

And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it.


So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in.


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for = draft-hallambaker-ocspagility-02


A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository.

Filename:        = draft-hallambaker-ocspagility
Revision:        02
Title:           OCSP = Algorithm Agility
Creation_date:   2008-12-02
WG ID:           = Independent Submission
Number_of_pages: 8

Abstract:
The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.
            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =        


The IETF Secretariat.

------_=_NextPart_001_01C968F2.1F8A2075-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDNnSx052283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 06:23:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBSDNneh052282; Sun, 28 Dec 2008 06:23:49 -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 robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSDNbc3052156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 28 Dec 2008 06:23:48 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id mBSDNTHV015723; Sun, 28 Dec 2008 05:23:29 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Dec 2008 05:23:29 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C968EF.78855DA5" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: straw poll Date: Sun, 28 Dec 2008 05:22:58 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFC31@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: straw poll Thread-Index: AclfldXoaVlJ2Y9ATQKYgYj+/Dr6oAJWZBwc References: From: "Hallam-Baker, Phillip" To: "Stephen Kent" , X-OriginalArrivalTime: 28 Dec 2008 13:23:29.0403 (UTC) FILETIME=[790B5CB0:01C968EF] 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_01C968EF.78855DA5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 1 yes 2 yes -----Original Message----- From: owner-ietf-pkix@mail.imc.org on behalf of Stephen Kent Sent: Tue 12/16/2008 9:29 AM To: ietf-pkix@imc.org Subject: straw poll =20 At a previous IETF meeting (Dublin) I agreed to conduct a straw poll=20 on adding a new WG item to address OCSP algorithm agility concerns,=20 after PHB sent a message indicating what status he envisioned for the=20 work. This action for both me and PHB fell through the cracks. At the=20 MSP IETF meeting PHB provided a briefing on the problems that he saw=20 re OCSP ambiguities re algorithm agility, and proposed a standards=20 track document to address these issues (see PHB's message of 12/2). So, we now have a concrete proposal (draft-hallambaker-ocspagility)=20 available for review. PHB would like to publish this and then merge=20 it into the OCSP document when it progresses from PROPOSED to DRAFT=20 (see his message of 12/2). Please send a message to the list by January 9th (allowing for=20 holiday outages) indicating whether 1. your support PKIX work in this area 2. you support adopting PHB's document as a starting point=20 for such work Thanks & Happy Hoplidays, Steve ------_=_NextPart_001_01C968EF.78855DA5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: straw poll

1 yes
2 yes

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org on behalf of Stephen Kent
Sent: Tue 12/16/2008 9:29 AM
To: ietf-pkix@imc.org
Subject: straw poll


At a previous IETF meeting (Dublin) I agreed to conduct a straw poll
on adding a new WG item to address OCSP algorithm agility concerns,
after PHB sent a message indicating what status he envisioned for = the
work. This action for both me and PHB fell through the cracks. At = the
MSP IETF meeting PHB provided a briefing on the problems that he saw
re OCSP ambiguities re algorithm agility, and proposed a standards
track document to address these issues (see PHB's message of 12/2).

So, we now have a concrete proposal (draft-hallambaker-ocspagility)
available for review. PHB would like to publish this and then merge
it into the OCSP document when it progresses from PROPOSED to DRAFT
(see his message of 12/2).

Please send a message to the list by January 9th (allowing for
holiday outages) indicating whether

        1. your support PKIX work in = this area
        2. you support adopting PHB's = document as a starting point
for such work

Thanks & Happy Hoplidays,

Steve

------_=_NextPart_001_01C968EF.78855DA5-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBSA6Ggv020552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Dec 2008 03:06:16 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBSA6G42020546; Sun, 28 Dec 2008 03:06:16 -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 smtp812.mail.ird.yahoo.com (smtp812.mail.ird.yahoo.com [217.146.188.72]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBSA5teu020340 for ; Sun, 28 Dec 2008 03:06:13 -0700 (MST) (envelope-from j.larmouth@btinternet.com) Received: (qmail 82718 invoked from network); 28 Dec 2008 10:05:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=H1hf/YBxnVdvsuhHfSDvf2GAbZlm4/WkF/SI/9WiPWKca7LOP0Qyhdb2VSe7i0CM4OJp3AdgsxsC0FYF/n+Q7ePDjLdeNzC7qW4kCrT0jjh6i+sLbbMq1mnrTCB+l5P40JUvYJUc29fbGiiyhWqIZJ2PUheymAhxCslw4XAe5Yo= ; Received: from unknown (HELO ?192.168.1.67?) (j.larmouth@217.44.207.2 with plain) by smtp812.mail.ird.yahoo.com with SMTP; 28 Dec 2008 10:05:54 -0000 X-YMail-OSG: kc7VFaEVM1nlVjqlZ7Cid.ujlJyL78D6T6.eF28dxzVps_NNxOT.RXIyRnxY5wmAM_6.DkCgBm_Pvkn_1G8BSprCsTk60nX6nPvOx6wiRSQUzD0oYsgjXX_6t52x1Sz3Up9mX8QW6VNrg8YtmCBFYgfa1D0mJjTsovT6FdYeYc_QdBSoKuX7ATaZ1XUzzKSXB7DhXrjCFUrH5REbVOq19eFZETY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49574F82.6010206@btinternet.com> Date: Sun, 28 Dec 2008 10:05:54 +0000 From: John Larmouth Reply-To: j.larmouth@btinternet.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Tom Gindin CC: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , ietf-pkix@imc.org, ietf-smime@imc.org, turners@ieca.com, asn1dev Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, There are several comments to be made. Forgive me for being verbose, but I think that in this area, brief replies can so easily be misunderstood. 1) First, forget the old stuff with identifiers (that is the old and correct term) for names on arcs of the OID tree. They were always (and still are) ASCII text, with an initial lower-case letter. Originally, they were expected to be unique (but were never carried in protocol, only in human value notation). Then later, it was recognised that company names changed (due to take-over, merger, etc, and that they wanted to use a different name for their arc (but not to change the numerical value). It was then (circa 1992) that they should NOT be regarded as unique, and that variants would be allowed (this brought the Standard into line with existing practice). About the same time, CCITT changed its name, and synonyms were formally assigned for some top-level arcs - but still restricted to ASCII characters, starting with a lower case letter. **Forget that stuff - it is historical! But, of course, still in use.** 2) Formally, an arc now has an always unique and unambiguous numerical value (as before); the old not-necessarily-unique-or-unambiguous identifiers (as before); but also has one or more Unicode labels (any - more-or-less - Unicode characters) that is required to be unambiguous from the superior node, but not necessarily unique (multiple Unicode labels are allowed on an arc to allow for different language variants). This was much discussed and fought over, but was eventually agreed as the best solution, but with some people still dissenting, and wanting only one (unique) Unicode label on an arc. 3) As part of this extension, it was recognised that the limitation to three top-level arcs (itu-t(0), iso(1), and joint-iso-itu-t(2)) was too limiting. Fortunately, arc 2 had already been used to provide allocations for other SDOs, and provided the x is less than 47, the OID {2, x} encodes into a single octet. We now restrict the allocation of arcs {2, x} to organisations that need the single octet encoding, but there are still quite a few x values left for future allocation. For encoding purposes, the top two levels are effectively a single set of top-level arcs, encoding into a single octet, provided x is less than 47 for arc 2, with similar restrictions on the arcs beneath arcs 0 and 1. 4) When Unicode labels were introduced, the concept of "long arcs" were included specifically for use at the top level. So it is now possible for long arcs to be allocated, with Unicode labels (but no numeric identifier) directly from the root to an arc beneath arc 2, and it is now common practice to allocate a long arc whenever an arc is allocated beneath arc 2 for any major organisation or SDO. 5) Finally, there was recognition of the problem of mapping a sequence of Unicode labels (representing a set of arcs) into a canonical list of integers for the numerical values of those arcs (in the case of a long arc, a Unicode label would map into - typically - two integers, for example 2.13). This gave rise to "work in progress" on an "OID resolution process". You will recognise that this is very much what the ubiquitous DNS service provides - a mapping from a set of names (domain names, little-endian order in the set) to a set of numbers (IP addresses, big-endian order in the set). DNS look-up is universally supported, and well-established, and the current hope/intent is to be able to do OID resolution using the DNS service, but discussions are still in progress on this. The alternative of an X.500 base for OID resolution has also been much discussed, and not abandonned. But deployment of X.500 look-up software is not as ubiquitous as DNS resolution software and databases. It may be that at the stardardisation level, we will see two resolution services documented - DNS-based and X.500-based. But it is too early to comment on that. 6) Now we come to IRI registration of the "oid" scheme, which is what the Internet Draft is concerned with. This is not essential to support these developments, but was a target from the start of the work. The sequence of Unicode labels on a path from the root to a node is undoubtedly, in plain English language terms, an internationalised resource identifier. So registration of an IRI "oid" scheme with IANA was always a target for the work. It was felt that the Standard should be in place before the registration was attempted. So we now have an Internet Draft under review with uri-review, in the hope that this can be "massaged" into a form that would allow us to proceed with the formal IANA registration of the "oid" IRI scheme in the not too distant future. I hope this has gone some way towards answering your questions. John L Tom Gindin wrote: > John: > > This draft is interesting and useful for some purposes, but I >don't see how it addresses the case where a high-level arc (beyond the >control of the development organization) is renamed. Since that's >precisely the case we are discussing here (although the change took place >quite a while ago and it's reasonable to expect people to adjust), it >doesn't actually seem to help us. Am I missing something? > Also, unless I have missed something, there are only three >top-level arcs defined for OID's and they all now have names. > > Tom Gindin > > > > >John Larmouth >Sent by: owner-ietf-pkix@mail.imc.org >12/22/2008 10:48 AM >Please respond to >j.larmouth@btinternet.com > > >To >Alfred � >cc >turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org >Subject >Re: consisten use of top-level oid branch name joint-iso-itu-t(2) > > > > > > >Alfred, > >The synonyms were introduced some time ago, and, indeed, the names are >non-normative, and may not even be unambiguous. Only the numbers matter >in an OID in an encoding. > >However, the recent introduction of Unicode labels, as normative and >unambigous names gives a new naming scheme to the (same) OID tree that >enables names (Unicode labels) to be used in machine communication if >desired. The ASN.1 type is called OID_IRI and provides for node >identification using Unicode labels. Unicode labels with names similar to >the old ASCII names have been assigned for many of the top-level arcs, and >more will be added over time. > >The OID_IRI type is related to (but not dependent on) the application for >an "oid" IRI scheme, but for consistency this is desired. See I-D >draft-larmouth-oid-iri-00. > >John L > >Alfred � wrote: >Folks / to whom it concerns, > >during recent reviews of active I-Ds containing ASN.1 related >to the X.500 framework, I found that a couple of these do not >consistently employ the revised name of the top-level OID branch > > joint-iso-itu-t(2) , > >but instead use the outdated/legacy name > > joint-iso-ccitt(2) . > >Some drafts use a mix of both names. > >I suggest that the modern version joint-iso-itu-t(2) be used >consistently within all new drafts / draft versions, unless >intentionally and explicitely for historical evidence reference >has to be made to the old name. > >Kind regards, > Alfred. > > > > > -- Prof John Larmouth Larmouth T&PDS Ltd (Training and Protocol Design Services Ltd) 1 Blueberry Road Bowdon j.larmouth@btinternet.com Altrincham Cheshire WA14 3LS England Tel: +44 161 928 1605 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBR5knsi097244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Dec 2008 22:46:50 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBR5knVg097243; Fri, 26 Dec 2008 22:46:49 -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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBR5kb3k097231 for ; Fri, 26 Dec 2008 22:46:48 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 29194 invoked from network); 27 Dec 2008 05:47:05 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;27 Dec 2008 05:47:05 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 27 Dec 2008 05:47:04 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C967E6.7A3B5275" Subject: RE: TA requirements doc - do we need it? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 27 Dec 2008 00:46:34 -0500 Message-ID: In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AF3E6206D@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TA requirements doc - do we need it? Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrAAApWoQAAk2WagAEDwEFAACsxGQA== References: <9F11911AED01D24BAA1C2355723C3D321AF3E6206D@EA-EXMSG-C332.europe.corp.microsoft.com> From: "Santosh Chokhani" To: "Stefan Santesson" , , "Kemp, David P." 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_01C967E6.7A3B5275 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 I for one do not see how your e-mail relates to the TA requirements document or Dave's post. See responses in-line. =20 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Thursday, December 18, 2008 11:47 AM To: ietf-pkix@imc.org; Kemp, David P. Subject: FW: TA requirements doc - do we need it? I'm resending this as my original mail got filtered due to exceeding pkix message size restrictions. I have now replaced the embedded picture with a URL to the screenshot. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: Stefan Santesson=20 Sent: den 17 december 2008 11:43 To: 'Kemp, David P.'; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Dave, =20 You raise valid points and I partly try to avoid them because the answer is somewhat long and complex. Long and complex answers are seldom successful in standards discussions :-) =20 Let me try to show my point through a screenshot that helped explain this issue to at least one of the original contributors to the proposed protocol. This is a screenshot of the Microsoft certificate management snap-in: =20 http://www.fiddler.nu/pkix/certmgr_mmc.jpg =20 What you see here is the certificate trust policies in my laptop. It is not one root store and it is not just about trust anchors. In my laptop I have a certificate trust management snap-in for: * Each host (local machine) * Each user account * Each service running on any host [Santosh] This is consistent with TA requirements since TA requirements deal with each TA store. In your case, the TA and TAMP will be applied to three stores. =20 In the Certificate snap-in window to the right, you see a fraction of the list of services with individual certificate trust settings for one host/machine. [Santosh] This is consistent with TA material in that constraints can be associated individually with the TAs. =20 And it is not about just TA:s. It is about: [Santosh] This is not relevant to the topic since it does not relate to TA management.=20 * My personal certificates * Trusted roots * Intermediary CAs=20 * Directly trusted or untrusted certificates * Etc, etc (See above) =20 The structure of this information is not globally agreed and generic. It is just how Microsoft have structured this in the Microsoft OS. [Santosh] This is precisely why we need TAF and TAMP. That is what requirements highlight. =20 One could call this a set of certificate trust policies that are dynamically managed and as you get closer to reality,=20 [Santosh] I would say a more accurate and complete characterization of these is the constraints on the trust anchors. =20 the border between roles, peoples and machines are getting more and more virtual and dynamic and it becomes harder and harder to reduce this into one generic, intrusive and centrally managed TA management protocol. [Santosh] One would think that as things become more virtual and dynamic, more you need the associated data with the TA and TAMP that can enforce the constraints on the TA and on the associated data. =20 Let me take a few examples from the requirements: * The assumed roles and authorization model * The assumption that there exist clearly identifiable TA stores. =20 The TA requirements are assuming a TA manager responsible for a TA store. [Santosh] While operationally this may be one manager managing the TA store, the requirements and TAMP should be oriented towards many to many. A TA manager can manage one or more TA in the TA store. A TA in a TA store can be managed by more that one manager. =20 The TA manager have authority over this TA store and have the power update it or replace it. This also assumes that each TA store is individually identifiable in the protocol itself. In my environment above, I first of all don't have any isolated identifiable TA stores. [Santosh] The TA need not be in a specific store, but it is always identifiable by some combination of name, SPKI, and SKID.=20 =20 Secondly I don't have a clearly defined TA manager that has the right to view and update this information on a local machine. [Santosh] The TA requirements and TAMP should clarify this with the constraints on the TAs.=20 =20 The applications or services that eventually are being affected by these trust policy updates will not have a clue about what information that was passed in any TA management protocol, or any IETF defined TA format file several layers and APIs below their existence.=20 [Santosh] Agree and the applications do not do this. This is part of TA management and not part of applications using the TA. =20 So any discussion about how applications should take into account specific path processing preferences provided by passing TA format information around, such as applying specific constraints rules, is just pretty theory without substance unless it is made part of standard RFC 5280 path processing and implemented in the APIs for path validation. [Santosh] The TA requirements in the area of path processing are consistent with 5280. 5280 specifically cites additional checks based on the information associated with TA. See section 6.2 of 5280. =20 In the environment I'm working with, I have no use for a transaction based TA management protocol based on the simplified relationship between a TA manager and a TA store.=20 [Santosh] That does not mean others do not need it. It also does not mean that the environment you cited above would not benefit from in-band re-key of the TA. =20 If I had one, I would not know how to use it. The only thing I would know how to use, is the TA format specification. That one I can use to pass TAs around in my existing trust policy framework. [Santosh] You as a person will need not be aware of it, just like many of nuances of PKI. The processing software will securely process the transactions and update the TAs. =20 I hope this was a useful clarification and my apology for passing graphics in a PKIX posting. I hope you can view it. [Santosh] The primary purpose of TA work is to permit in band, secure installation and rekey of TAs. Unless you propose an alternative mechanism to achieve this securely, the discourse you are having is not providing any critique of the TA work. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Kemp, David P. Sent: den 16 december 2008 18:12 To: ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Stefan, =20 Refining the requirements as a series of I-Ds until "the scope of the requirements is in harmony with problem space", then publishing as an RFC once the requirements have converged, certainly sounds like the best approach. =20 But you have not explained how "The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure." The requirements in either case are for managed devices/applications/services to receive configuration items from managers without those items being compromised in transit, yes? =20 * Are you claiming that adversaries have no access to a "common network and data sharing infrastructure" and therefore no protection is needed in the networked case? That is patently false for all networks of interest to the IETF. * Or that the protection mechanisms appropriate for managing networked platforms (Connection-oriented? MACs?) are different than those needed for managing disconnected platforms (Datagram/message-oriented? Signatures?) =20 Without understanding the nature of your objections it's hard to tell whether the scope of the requirements is already in harmony with the entire problem space or not. Your 4-quadrant slide from Minneapolis is not self-explanatory - I thought we had already disposed of the push-pull issue by determining that there is no security-relevant difference between posting to a repository from which a client may pull and pushing directly to the client. Therefore the TAM requirements already cover the left half of the space. If there is a single existing TAM requirement that precludes pull, or a single missing TAM requirement needed for pull, please provide an example. =20 And I need help understanding the difference you see between TA and TA Policy - if policy is "Host/App A will trust provider X for security critical firmware category Z", and the TA store of Host/App A has provider X's TA in the slot for firmware category Z, what is the difference, other than level of abstraction, between "determine current TAs in store" and "demonstrate compliance with policy"? Again, an example of a missing TAM requirement needed to satisfy the right half of your slide would go a long way toward understanding the scope issue. =20 Dave =20 =20 =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Tuesday, December 16, 2008 9:58 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Hi Santosh, =20 As I expect, I sense that we have a slightly different view of the generality of the proposed solution, but we seem to agree on the main issue: =20 The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols. If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc. =20 I would also prefer to see the requirements document as a living document as you suggest. I think that purpose is best served if the requirements document remains in draft form. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 15 december 2008 17:47 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Stefan, =20 See my responses in-line below.=20 =20 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Friday, December 12, 2008 7:25 AM To: ietf-pkix@imc.org Subject: TA requirements doc - do we need it? =20 After all discussions in Minneapolis and going back and looking at the current situation, I feel less and less convinced that we need to approve any TA requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may be a lot more harmful than beneficiary to us as an RFC. =20 I have two major reasons: =20 First, as I have argued and tried to explain with my slide in Minneapolis, there is no general overall approach to TA management in a complex IT environment. [Santosh] In a complex distributed environment that needs to scale across Enterprises, applying requisite security services to the payload provides a scalable, interoperable, extensible, and secure solution. =20 The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure. [Santosh] The requirements are generally the same in terms of security services. Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network. But, that solution may not be as scalable or open. =20 Secondly, the requirements didn't come first. These requirements were written with an existing protocol in mind. The lasting impression is therefore that the requirements document was written to match and support the original protocol, making it a tool to grandfather the original protocol into IETF. I'm not claiming that this is the case, but it remains to be my impression. [Santosh] If you look at many of the engineering endeavors we undertake, requirements are based on past experience, security vulnerabilities we have encountered, past systems, etc. I do not know of many successful efforts where requirements were developed in vacuum. In short, it is fair to say that the requirements and protocol benefited from each other and from past experiences with protocols and vulnerabilities. =20 The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols. If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc. =20 My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to reflect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before the scope is in harmony with the requirements. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C967E6.7A3B5275 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefan,

 

I for one do not = see how your e-mail relates to the TA requirements document or Dave’s = post.  See responses in-line.

 =

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stefan Santesson
Sent: Thursday, December = 18, 2008 11:47 AM
To: ietf-pkix@imc.org; = Kemp, David P.
Subject: FW: TA = requirements doc - do we need it?

I’m = resending this as my original mail got filtered due to exceeding pkix message size restrictions.

I have now replaced the = embedded picture with a URL to the screenshot.

 <= /p>

 <= /p>

Stefan Santesson

Senior = Program Manager

Windows Security, Standards

 <= /p>

From: = Stefan Santesson
Sent: den 17 december = 2008 11:43
To: 'Kemp, David P.'; ietf-pkix@imc.org
Subject: RE: TA = requirements doc - do we need it?

 

Dave,

 <= /p>

You raise valid points and I = partly try to avoid them because the answer is somewhat long and complex. Long and = complex answers are seldom successful in standards discussions = J

 <= /p>

Let me try to show my point = through a screenshot that helped explain this issue to at least one of the = original contributors to the proposed protocol. This is a screenshot of the = Microsoft certificate management snap-in:

 <= /p>

http://www.fiddler.nu= /pkix/certmgr_mmc.jpg

 <= /p>

What you see here is the = certificate trust policies in my laptop. It is not one root store and it is not just = about trust anchors. In my laptop I have a certificate trust management = snap-in for:

·         = Each host (local = machine)

·         = Each user = account

·         = Each service running on = any host

[Santosh] This is consistent with TA requirements = since TA requirements deal with each TA store.  In your case, the TA and = TAMP will be applied to three stores.

 <= /p>

In the Certificate snap-in = window to the right, you see a fraction of the list of services with individual = certificate trust settings for one host/machine.

[Santosh] This is consistent with TA material in that constraints can be associated individually with the = TAs.

 <= /p>

And it is not about just TA:s. = It is about:

[Santosh] This is not relevant to the topic since it = does not relate to TA management.

·         = My personal = certificates

·         = Trusted = roots

·         = Intermediary CAs =

·         = Directly trusted or = untrusted certificates

·         = Etc, etc (See = above)

 <= /p>

The structure of this = information is not globally agreed and generic. It is just how Microsoft have structured = this in the Microsoft OS.

[Santosh] This is precisely why we need TAF and TAMP. =  That is what requirements highlight.

 <= /p>

One could call this a set of = certificate trust policies that are dynamically managed and as you get closer to = reality,

[Santosh] I would say a more accurate and complete = characterization of these is the constraints on the trust = anchors.

 <= /p>

the border between roles, = peoples and machines are getting more and more virtual and dynamic and it becomes = harder and harder to reduce this into one generic, intrusive and centrally = managed TA management protocol.

[Santosh] One would think that as things become more = virtual and dynamic, more you need the associated data with the TA and TAMP that = can enforce the constraints on the TA and on the associated = data.

 <= /p>

Let me take a few examples from = the requirements:

·         = The assumed roles and = authorization model

·         = The assumption that = there exist clearly identifiable TA stores.

 <= /p>

The TA requirements are = assuming a TA manager responsible for a TA store.

[Santosh] While operationally this may be one manager managing the TA store, the requirements and TAMP should be oriented = towards many to many.  A TA manager can manage one or more TA in the TA = store.  A TA in a TA store can be managed by more that one = manager.

 <= /p>

 The TA manager have = authority over this TA store and have the power update it or replace it. This also = assumes that each TA store is individually identifiable in the protocol itself. = In my environment above, I first of all don’t have any isolated  identifiable TA stores.

[Santosh] The TA need not be in a specific store, but = it is always identifiable by some combination of name, SPKI, and SKID. =

 <= /p>

Secondly I don’t have a = clearly defined TA manager that has the right to view and update this = information on a local machine.

[Santosh] The TA requirements and TAMP should clarify = this with the constraints on the TAs.

 <= /p>

The applications or services = that eventually are being affected by these trust policy updates will not = have a clue about what information that was passed in any TA management = protocol, or any IETF defined TA format file several layers and APIs below their = existence.

[Santosh] Agree and the applications do not do this. =  This is part of TA management and not part of applications using the = TA.

 <= /p>

So any discussion about how = applications should take into account specific path processing preferences provided = by passing TA format information around, such as applying specific = constraints rules, is just pretty theory without substance unless it is made part of standard RFC 5280 path processing and implemented in the APIs for path validation.

[Santosh] The TA requirements in the area of path = processing are consistent with 5280.  5280 specifically cites additional = checks based on the  information associated with TA.  See section 6.2 of = 5280.

 <= /p>

In the environment I’m = working with, I have no use for a transaction based TA management protocol based = on the simplified relationship between a TA manager and a TA store. =

[Santosh] That does not mean others do not need it. =  It also does not mean that the environment you cited above would not = benefit from in-band re-key of the TA.

 <= /p>

If I had one, I would not know = how to use it.

The only thing I would know how = to use, is the TA format specification. That one I can use to pass TAs around in = my existing trust policy framework.

[Santosh] You as a person will need not be aware of = it, just like many of nuances of PKI.  The processing software will securely process the transactions and update the TAs.

 <= /p>

I hope this was a useful = clarification and my apology for passing graphics in a PKIX posting. I hope you can = view it.

[Santosh] The primary purpose of TA work is to permit = in band, secure installation and rekey of TAs.  Unless you propose an alternative mechanism to achieve this securely, the discourse you are = having is not providing any critique of the TA work.

 <= /p>

 <= /p>

Stefan Santesson

Senior = Program Manager

Windows Security, Standards

 <= /p>

From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Kemp, David P.
Sent: den 16 december = 2008 18:12
To: ietf-pkix@imc.org
Subject: RE: TA = requirements doc - do we need it?

 

Stefan,=

 <= /p>

Refining the requirements as a = series of I-Ds until “the scope of the requirements is in harmony with = problem space”, then publishing as an RFC once the requirements have = converged, certainly sounds like the best approach.

 <= /p>

But you have not explained how = “The requirements are radically different in a device oriented environment = with disconnected units compared with a centrally managed IT environment with = a common network and data sharing infrastructure.”  The requirements in = either case are for managed devices/applications/services to receive configuration items = from managers without those items being compromised in transit, = yes?

 <= /p>

·         = Are you claiming that = adversaries have no access to a “common network and data sharing infrastructure” and therefore no protection is needed in the = networked case?  That is patently false for all networks of interest to the = IETF.

·         = Or that the protection = mechanisms appropriate for managing networked platforms (Connection-oriented?  = MACs?) are different than those needed for managing disconnected platforms (Datagram/message-oriented? Signatures?)

 <= /p>

Without understanding the = nature of your objections it’s hard to tell whether the scope of the requirements = is already in harmony with the entire problem space or not.   = Your 4-quadrant slide from Minneapolis is not self-explanatory – I = thought we had already disposed of the push-pull issue by determining that there is = no security-relevant difference between posting to a repository from which = a client may pull and pushing directly to the client.  Therefore the = TAM requirements already cover the left half of the space.  If there is = a single existing TAM requirement that precludes pull, or a single missing = TAM requirement needed for pull, please provide an = example.

 <= /p>

And I need help understanding = the difference you see between TA and TA Policy – if policy is “Host/App A will trust provider X for security critical firmware = category Z”, and the TA store of Host/App A has provider X’s TA in = the slot for firmware category Z, what is the difference, other than level of abstraction, between “determine current TAs in store” and “demonstrate compliance with policy”?  Again, an = example of a missing TAM requirement needed to satisfy the right half of your slide = would go a long way toward understanding the scope = issue.

 <= /p>

Dave

 <= /p>

 <= /p>

 <= /p>

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stefan Santesson
Sent: Tuesday, December = 16, 2008 9:58 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: TA = requirements doc - do we need it?

 

Hi = Santosh,

 <= /p>

As I expect, I sense that we = have a slightly different view of the generality of the proposed solution, but = we seem to agree on the main issue:

 <= /p>

The question one have to ask is if these requirements, in the form of an = RFC, would serve us as a community if we encounter a problem with the proposed = protocol. I doubt that it will as it at most will strengthen the argument for those = having an interest to adopt the original protocol.

[Santosh] Having a requirements document that is a = living document, permits us to evaluate various solutions and protocols. =  If we do encounter a security problem, it should be useful to analyze where = the engineering process failed, e.g., did we not articulate some = requirement, did we not have sufficient detail for a requirement, did our analysis of = protocol meeting a requirement was flawed, etc.

 <= /p>

I would also prefer to see the requirements document as a living document as you suggest. I think that = purpose is best served if the requirements document remains in draft = form.

 <= /p>

 <= /p>

 <= /p>

Stefan Santesson

Senior = Program Manager

Windows Security, Standards

 <= /p>

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Santosh Chokhani
Sent: den 15 december = 2008 17:47
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: TA = requirements doc - do we need it?

 

Stefan,

=

 

See my responses in-line below. =

 

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Stefan Santesson
Sent: Friday, December = 12, 2008 7:25 AM
To: ietf-pkix@imc.org
Subject: TA requirements = doc - do we need it?

 

After all discussions in Minneapolis and going back and looking at the current situation, I feel less and = less convinced that we need to approve any TA requirements document as an = RFC. At least not in its current form.

I’m fine with having it around as a draft for reference, but I fear it may = be a lot more harmful than beneficiary to us as an = RFC.

 

I have two major reasons:

 

First, as I have argued and tried to explain with my slide in Minneapolis, there is no general = overall approach to TA management in a complex IT = environment.

[Santosh] In a complex distributed environment that = needs to scale across Enterprises, applying requisite security services to the = payload provides a scalable, interoperable, extensible, and secure = solution.

 

The requirements are radically different in a device oriented environment = with disconnected units compared with a centrally managed IT environment with = a common network and data sharing = infrastructure.

[Santosh] The requirements are generally the same in = terms of security services.  Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and = security services provided by the Enterprise network.  But, that solution may not be as scalable or = open.

 

Secondly, the requirements didn’t come first. These requirements were = written with an existing protocol in mind. The lasting impression is therefore that = the requirements document was written to match and support the original = protocol, making it a tool to grandfather the original protocol into IETF. = I’m not claiming that this is the case, but it remains to be my = impression.

[Santosh] If you look at many of the engineering = endeavors we undertake, requirements are based on past experience, security vulnerabilities we have encountered, past systems, etc.  I do not = know of many successful efforts where requirements were developed in vacuum. In = short, it is fair to say that the requirements and protocol benefited from each = other and from past experiences with protocols and = vulnerabilities.

 

The question one have to ask is if these requirements, in the form of an = RFC, would serve us as a community if we encounter a problem with the proposed = protocol. I doubt that it will as it at most will strengthen the argument for those = having an interest to adopt the original protocol.

[Santosh] Having a requirements document that is a = living document, permits us to evaluate various solutions and protocols. =  If we do encounter a security problem, it should be useful to analyze where = the engineering process failed, e.g., did we not articulate some = requirement, did we not have sufficient detail for a requirement, did our analysis of = protocol meeting a requirement was flawed, etc.

 

My proposal going forward is to do the = following:

-          In any case adjust the scope of the requirements document = to reflect the problem space the problem space it is designed = for.

-          Leave it as a draft, or at least not publish it as an RFC = before the scope is in harmony with the requirements.

 

 

 

Stefan Santesson

Senior = Program Manager

Windows Security, Standards

 

------_=_NextPart_001_01C967E6.7A3B5275-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBOJFZYk016887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Dec 2008 12:15:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBOJFZ9Y016884; Wed, 24 Dec 2008 12:15:35 -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 e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBOJFMd1016857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Dec 2008 12:15:33 -0700 (MST) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBOJFARG009894; Wed, 24 Dec 2008 14:15:10 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBOJFJlC197854; Wed, 24 Dec 2008 14:15:19 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id mBOJFJPr026105; Wed, 24 Dec 2008 14:15:19 -0500 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id mBOJFIoj026095; Wed, 24 Dec 2008 14:15:18 -0500 In-Reply-To: <494FB6BA.9080402@btinternet.com> To: j.larmouth@btinternet.com Cc: =?UTF-8?B?QWxmcmVkIO+/vQ==?= , ietf-pkix@imc.org, ietf-smime@imc.org, turners@ieca.com MIME-Version: 1.0 Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2) X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Tom Gindin Message-ID: Date: Wed, 24 Dec 2008 14:15:17 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.1 HF1|June 13, 2008) at 12/24/2008 14:15:18, Serialize complete at 12/24/2008 14:15:18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ICAgICAgICBKb2huOg0KDQogICAgICAgIFRoaXMgZHJhZnQgaXMgaW50ZXJlc3RpbmcgYW5kIHVz ZWZ1bCBmb3Igc29tZSBwdXJwb3NlcywgYnV0IEkgDQpkb24ndCBzZWUgaG93IGl0IGFkZHJlc3Nl cyB0aGUgY2FzZSB3aGVyZSBhIGhpZ2gtbGV2ZWwgYXJjIChiZXlvbmQgdGhlIA0KY29udHJvbCBv ZiB0aGUgZGV2ZWxvcG1lbnQgb3JnYW5pemF0aW9uKSBpcyByZW5hbWVkLiAgU2luY2UgdGhhdCdz IA0KcHJlY2lzZWx5IHRoZSBjYXNlIHdlIGFyZSBkaXNjdXNzaW5nIGhlcmUgKGFsdGhvdWdoIHRo ZSBjaGFuZ2UgdG9vayBwbGFjZSANCnF1aXRlIGEgd2hpbGUgYWdvIGFuZCBpdCdzIHJlYXNvbmFi bGUgdG8gZXhwZWN0IHBlb3BsZSB0byBhZGp1c3QpLCBpdCANCmRvZXNuJ3QgYWN0dWFsbHkgc2Vl bSB0byBoZWxwIHVzLiAgQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCiAgICAgICAgQWxzbywgdW5s ZXNzIEkgaGF2ZSBtaXNzZWQgc29tZXRoaW5nLCB0aGVyZSBhcmUgb25seSB0aHJlZSANCnRvcC1s ZXZlbCBhcmNzIGRlZmluZWQgZm9yIE9JRCdzIGFuZCB0aGV5IGFsbCBub3cgaGF2ZSBuYW1lcy4N Cg0KICAgICAgICAgICAgICAgIFRvbSBHaW5kaW4NCg0KDQoNCg0KSm9obiBMYXJtb3V0aCA8ai5s YXJtb3V0aEBidGludGVybmV0LmNvbT4gDQpTZW50IGJ5OiBvd25lci1pZXRmLXBraXhAbWFpbC5p bWMub3JnDQoxMi8yMi8yMDA4IDEwOjQ4IEFNDQpQbGVhc2UgcmVzcG9uZCB0bw0Kai5sYXJtb3V0 aEBidGludGVybmV0LmNvbQ0KDQoNClRvDQpBbGZyZWQg77+9IDxhaEB0ci1zeXMuZGU+DQpjYw0K dHVybmVyc0BpZWNhLmNvbSwgaWV0Zi1wa2l4QGltYy5vcmcsIGlldGYtc21pbWVAaW1jLm9yZw0K U3ViamVjdA0KUmU6IGNvbnNpc3RlbiB1c2Ugb2YgdG9wLWxldmVsIG9pZCBicmFuY2ggbmFtZSBq b2ludC1pc28taXR1LXQoMikNCg0KDQoNCg0KDQoNCkFsZnJlZCwNCg0KVGhlIHN5bm9ueW1zIHdl cmUgaW50cm9kdWNlZCBzb21lIHRpbWUgYWdvLCBhbmQsIGluZGVlZCwgdGhlIG5hbWVzIGFyZSAN Cm5vbi1ub3JtYXRpdmUsIGFuZCBtYXkgbm90IGV2ZW4gYmUgdW5hbWJpZ3VvdXMuICBPbmx5IHRo ZSBudW1iZXJzIG1hdHRlciANCmluIGFuIE9JRCBpbiBhbiBlbmNvZGluZy4NCg0KSG93ZXZlciwg dGhlIHJlY2VudCBpbnRyb2R1Y3Rpb24gb2YgVW5pY29kZSBsYWJlbHMsIGFzIG5vcm1hdGl2ZSBh bmQgDQp1bmFtYmlnb3VzIG5hbWVzIGdpdmVzIGEgbmV3IG5hbWluZyBzY2hlbWUgdG8gdGhlIChz YW1lKSBPSUQgdHJlZSB0aGF0IA0KZW5hYmxlcyBuYW1lcyAoVW5pY29kZSBsYWJlbHMpIHRvIGJl IHVzZWQgaW4gbWFjaGluZSBjb21tdW5pY2F0aW9uIGlmIA0KZGVzaXJlZC4gIFRoZSBBU04uMSB0 eXBlIGlzIGNhbGxlZCBPSURfSVJJIGFuZCBwcm92aWRlcyBmb3Igbm9kZSANCmlkZW50aWZpY2F0 aW9uIHVzaW5nIFVuaWNvZGUgbGFiZWxzLiAgVW5pY29kZSBsYWJlbHMgd2l0aCBuYW1lcyBzaW1p bGFyIHRvIA0KdGhlIG9sZCBBU0NJSSBuYW1lcyBoYXZlIGJlZW4gYXNzaWduZWQgZm9yIG1hbnkg b2YgdGhlIHRvcC1sZXZlbCBhcmNzLCBhbmQgDQptb3JlIHdpbGwgYmUgYWRkZWQgb3ZlciB0aW1l Lg0KDQpUaGUgT0lEX0lSSSB0eXBlICBpcyByZWxhdGVkIHRvIChidXQgbm90IGRlcGVuZGVudCBv bikgdGhlIGFwcGxpY2F0aW9uIGZvciANCmFuICJvaWQiIElSSSBzY2hlbWUsICBidXQgZm9yIGNv bnNpc3RlbmN5IHRoaXMgaXMgZGVzaXJlZC4gIFNlZSBJLUQgDQpkcmFmdC1sYXJtb3V0aC1vaWQt aXJpLTAwLg0KDQpKb2huIEwNCg0KQWxmcmVkIO+/vSB3cm90ZTogDQpGb2xrcyAvIHRvIHdob20g aXQgY29uY2VybnMsDQoNCmR1cmluZyByZWNlbnQgcmV2aWV3cyBvZiBhY3RpdmUgSS1EcyBjb250 YWluaW5nIEFTTi4xIHJlbGF0ZWQNCnRvIHRoZSBYLjUwMCBmcmFtZXdvcmssIEkgZm91bmQgdGhh dCBhIGNvdXBsZSBvZiB0aGVzZSBkbyBub3QNCmNvbnNpc3RlbnRseSBlbXBsb3kgdGhlIHJldmlz ZWQgbmFtZSBvZiB0aGUgdG9wLWxldmVsIE9JRCBicmFuY2gNCg0KICAgIGpvaW50LWlzby1pdHUt dCgyKSAsDQoNCmJ1dCBpbnN0ZWFkIHVzZSB0aGUgb3V0ZGF0ZWQvbGVnYWN5IG5hbWUNCg0KICAg IGpvaW50LWlzby1jY2l0dCgyKSAuDQoNClNvbWUgZHJhZnRzIHVzZSBhIG1peCBvZiBib3RoIG5h bWVzLg0KDQpJIHN1Z2dlc3QgdGhhdCB0aGUgbW9kZXJuIHZlcnNpb24gIGpvaW50LWlzby1pdHUt dCgyKSAgYmUgdXNlZA0KY29uc2lzdGVudGx5IHdpdGhpbiBhbGwgbmV3IGRyYWZ0cyAvIGRyYWZ0 IHZlcnNpb25zLCB1bmxlc3MNCmludGVudGlvbmFsbHkgYW5kIGV4cGxpY2l0ZWx5IGZvciBoaXN0 b3JpY2FsIGV2aWRlbmNlIHJlZmVyZW5jZQ0KaGFzIHRvIGJlIG1hZGUgdG8gdGhlIG9sZCBuYW1l Lg0KDQpLaW5kIHJlZ2FyZHMsDQogIEFsZnJlZC4NCg0KIA0KDQotLSANCiAgIFByb2YgSm9obiBM YXJtb3V0aA0KICAgTGFybW91dGggVCZQRFMgTHRkDQogICAoVHJhaW5pbmcgYW5kIFByb3RvY29s IERlc2lnbiBTZXJ2aWNlcyBMdGQpDQogICAxIEJsdWViZXJyeSBSb2FkIA0KICAgQm93ZG9uICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGoubGFybW91dGhAYnRpbnRlcm5ldC5jb20NCiAg IEFsdHJpbmNoYW0NCiAgIENoZXNoaXJlDQogICBXQTE0IDNMUyANCiAgIEVuZ2xhbmQNCiAgIFRl bDogKzQ0IDE2MSA5MjggMTYwNQ0KDQoNCg== Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBNBCPA1081225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2008 04:12:25 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBNBCP7P081221; Tue, 23 Dec 2008 04:12: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 smtp811.mail.ird.yahoo.com (smtp811.mail.ird.yahoo.com [217.146.188.71]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBNBCD5j081188 for ; Tue, 23 Dec 2008 04:12:23 -0700 (MST) (envelope-from j.larmouth@btinternet.com) Received: (qmail 19382 invoked from network); 23 Dec 2008 11:12:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=ZgjNwUWwaAPfQyogg8vHfLojoDj2f6PPl6jLyMT1LX+GOZgYVsd+zYVe1pstplrU7roUTsoWhQU7rM+hxAxtO3KVP5DSctcXkIPh3CNNymNj4/TAan4LVlRGK07rc8liEWhvwMooVHIdWKw5LD8yHCu2xqLJhg7WxlFKcO54JdA= ; Received: from unknown (HELO ?192.168.1.67?) (j.larmouth@217.44.207.2 with plain) by smtp811.mail.ird.yahoo.com with SMTP; 23 Dec 2008 11:12:12 -0000 X-YMail-OSG: vrgTfU8VM1mhkBOfr2CSHGEqUVui2P3Vnd3ljSE7EVqJa89BjIvhiI93Btn7MNC9fVMoUaSwuOrYO4OSMY882lno3YQrlrLp5P8jEjFTpTp_wFt6VP8hPxnFtyPN_Lx5ksOKw39eNumGWr57Q0Sw3cKgBLS2H37M3bNaMaCviyfwvDRRD0xxU_Y5r.Abk3_Lxf2L8VqTfMACOHM4ip3OB39LJI6k_diIJGQh X-Yahoo-Newman-Property: ymail-3 Message-ID: <4950C78C.8090306@btinternet.com> Date: Tue, 23 Dec 2008 11:12:12 +0000 From: John Larmouth Reply-To: j.larmouth@btinternet.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: Paul Hoffman CC: Alfred ? , turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2) References: <200812221256.NAA13071@TR-Sys.de> <494FB6BA.9080402@btinternet.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050009060805000700080909" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------050009060805000700080909 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please note my use of "if desired" below. This presents an opportunity, not a requirement. Nothing has been removed from the old OID capability. I agree that the use of Unicode labels has not been adopted by PKIX or S/MIME (and may well never be), nor presented to them. However, unless or until the "oid" IRI format is accepted by URI-review, it would be premature for PKIX or SMIME to even consider it. John L Paul Hoffman wrote: >At 3:48 PM +0000 12/22/08, John Larmouth wrote: > > >>However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired. >> >> > >Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups. > > > >>The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels. >> >> > >Paging Peter Gutmann.... > >--Paul Hoffman, Director >--VPN Consortium > > > -- Prof John Larmouth Larmouth T&PDS Ltd (Training and Protocol Design Services Ltd) 1 Blueberry Road Bowdon j.larmouth@btinternet.com Altrincham Cheshire WA14 3LS England Tel: +44 161 928 1605 --------------050009060805000700080909 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Please note my use of "if desired" below.  This presents an opportunity, not a requirement.

Nothing has been removed from the old OID capability.

I agree that the use of Unicode labels has not been adopted by PKIX or S/MIME (and may well never be), nor presented to them.  However, unless or until the "oid" IRI format is accepted by URI-review, it would be premature for PKIX or SMIME to even consider it.

John L

Paul Hoffman wrote:
At 3:48 PM +0000 12/22/08, John Larmouth wrote:
  
However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired. 
    

Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups.

  
The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels.
    

Paging Peter Gutmann....

--Paul Hoffman, Director
--VPN Consortium

  

-- 
   Prof John Larmouth
   Larmouth T&PDS Ltd
   (Training and Protocol Design Services Ltd)
   1 Blueberry Road                     
   Bowdon                               j.larmouth@btinternet.com
   Altrincham
   Cheshire
   WA14 3LS                 
   England
   Tel: +44 161 928 1605
--------------050009060805000700080909-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMKQ2sk044002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 13:26:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMKQ2O2044001; Mon, 22 Dec 2008 13:26: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMKPsKO043973 for ; Mon, 22 Dec 2008 13:26:01 -0700 (MST) (envelope-from wwwrun@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 30) id 2809B3A6AA0; Mon, 22 Dec 2008 12:26:02 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , pkix mailing list , pkix chair Subject: Protocol Action: 'Elliptic Curve Cryptography Subject Public Key Information' to Proposed Standard Message-Id: <20081222202602.2809B3A6AA0@core3.amsl.com> Date: Mon, 22 Dec 2008 12:26:02 -0800 (PST) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the following document: - 'Elliptic Curve Cryptography Subject Public Key Information ' as a Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Pasi Eronen and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-11.txt Technical Summary The subjectPublicKeyInfo field of an X.509 certificate carries three data items: an algorithm identifier, optional parameters, and a bit string that represents the public key. The parameters are specific to the algorithm and this field usually contains simple values needed to characterize the public key algorithm, e.g., the generator and modulus for Diffie-Hellman. However, X.509 does not constrain the scope of this parameters field. The ANSI X9.62 standards allow parameters to name the curve via an object identifier, inherit the curve from an issuer, or fully specify the curve. To fully specify the curve a complex structure is required. Further, the ANSI X9.62 standards committee elected to use this field to express potentially complex limitations on how the public key in the certificate can be used, e.g., which key derivation functions can be applied to the bit string that results from a Diffie-Hellman key exchange. After considerable debate the PKIX WG decided to limit the number of parameter choices to one: the name the curve with an object identifier (namedCurve). This decision was based on implementers desire to use well known curves from NIST and the complexity of the specifiedCurve field (not to mention the 20+ pages it saved). The WG also decided to restrict the number of algorithm identifiers to three: id-ecPublicKey, id-ecDH, and id-ECMQV. The id-ecPublicKey object identifier is when a CA does not want to limit the key for use with a particular ECC algorithm. ECDSA will use this object identifier, as it is already widely implemented. The id-ecDH and id-ecMQV object identifiers are used to restrict the key for use with ECDH and ECMQV, respectively. The SHA-224, SHA-256, SHA-384, and SHA-512 algorithms and the NIST curves were added to the ASN.1 modules. Working Group Summary This ID was discussed extensively on the PKIX WG mailing list. A poll was taken to remove the specifiedCurve option. The WG was in favor of the change. The other comments were about document quality. Document Quality This document is a fairly length update of three sections of RFC 3279 (Sections 2.3.5, 3, and 5) and includes a long ASN.1 module. The quality of the draft is comparable in quality to its predecessor Personnel The document shepherd is Stefan Santesson. The responsible area director is Pasi Eronen. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMHxrJd037374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 10:59:53 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMHxrBG037373; Mon, 22 Dec 2008 10:59:53 -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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMHxrgB037367 for ; Mon, 22 Dec 2008 10:59:53 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 44D393A6A56; Mon, 22 Dec 2008 10:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-3281update-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081222180001.44D393A6A56@core3.amsl.com> Date: Mon, 22 Dec 2008 10:00:01 -0800 (PST) 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 : An Internet Attribute Certificate Profile for Authorization Author(s) : R. Housley, S. Farrell, S. Turner Filename : draft-ietf-pkix-3281update-03.txt Pages : 45 Date : 2008-12-22 This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. This document obsoletes RFC 3281. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-3281update-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pkix-3281update-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-22095610.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMGow4d034237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 09:50:58 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMGowgI034236; Mon, 22 Dec 2008 09:50: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 [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMGon8p034216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 09:50:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <494FB6BA.9080402@btinternet.com> References: <200812221256.NAA13071@TR-Sys.de> <494FB6BA.9080402@btinternet.com> Date: Mon, 22 Dec 2008 08:50:47 -0800 To: j.larmouth@btinternet.com, Alfred ? From: Paul Hoffman Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2) Cc: turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 3:48 PM +0000 12/22/08, John Larmouth wrote: >However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired. Note that this scheme has not been adopted by PKIX nor S/MIME, nor has it even been proposed to either of the working groups. >The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels. Paging Peter Gutmann.... --Paul Hoffman, Director --VPN Consortium Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMFmORn029597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 08:48:34 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMFmO90029594; Mon, 22 Dec 2008 08:48: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 smtp816.mail.ird.yahoo.com (smtp816.mail.ird.yahoo.com [77.238.189.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBMFmBgA029575 for ; Mon, 22 Dec 2008 08:48:23 -0700 (MST) (envelope-from j.larmouth@btinternet.com) Received: (qmail 20008 invoked from network); 22 Dec 2008 15:48:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:Reply-To:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=tQkoL9owhPwHWzOzbPimY2Dt9JLv9nU5CWYe5StO2PIWznWDtp9LPE29yxgnkSh5p8FCRwMbeYsCDH0gIdW6yYtovDwrpS3BpGS1jCw403OGtrbrc9pUWokxAf3jy0SmO3OIR/qUTkI8GHgcJXuL/In61WOVFOZ+PzzhYby+X1U= ; Received: from unknown (HELO ?192.168.1.67?) (j.larmouth@217.44.207.2 with plain) by smtp816.mail.ird.yahoo.com with SMTP; 22 Dec 2008 15:48:10 -0000 X-YMail-OSG: Rhsm3igVM1nRvqWJciSouoY2o6CT9wZveZw3YFTc9fQIuZHvz7kL1MGbOApNbshcIfLe78WzVfRaVJspyziFxx2Xc10jC7vH5WxKe_96btpwxv4OEbQEtxiUo5SZVvvIcA.aMYmWsReum7fstMynnnCtCoEmr.C8ANenOiYBqSp.Hy2stujeRFiUsQ1X61Yo X-Yahoo-Newman-Property: ymail-3 Message-ID: <494FB6BA.9080402@btinternet.com> Date: Mon, 22 Dec 2008 15:48:10 +0000 From: John Larmouth Reply-To: j.larmouth@btinternet.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, en-us MIME-Version: 1.0 To: =?UTF-8?B?QWxmcmVkIO+/vQ==?= CC: turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org Subject: Re: consisten use of top-level oid branch name joint-iso-itu-t(2) References: <200812221256.NAA13071@TR-Sys.de> In-Reply-To: <200812221256.NAA13071@TR-Sys.de> Content-Type: multipart/alternative; boundary="------------060306020603010708080909" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------060306020603010708080909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Alfred, The synonyms were introduced some time ago, and, indeed, the names are non-normative, and may not even be unambiguous. Only the numbers matter in an OID in an encoding. However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired. The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels. Unicode labels with names similar to the old ASCII names have been assigned for many of the top-level arcs, and more will be added over time. The OID_IRI type is related to (but not dependent on) the application for an "oid" IRI scheme, but for consistency this is desired. See I-D draft-larmouth-oid-iri-00. John L Alfred � wrote: >Folks / to whom it concerns, > >during recent reviews of active I-Ds containing ASN.1 related >to the X.500 framework, I found that a couple of these do not >consistently employ the revised name of the top-level OID branch > > joint-iso-itu-t(2) , > >but instead use the outdated/legacy name > > joint-iso-ccitt(2) . > >Some drafts use a mix of both names. > >I suggest that the modern version joint-iso-itu-t(2) be used >consistently within all new drafts / draft versions, unless >intentionally and explicitely for historical evidence reference >has to be made to the old name. > >Kind regards, > Alfred. > > > -- Prof John Larmouth Larmouth T&PDS Ltd (Training and Protocol Design Services Ltd) 1 Blueberry Road Bowdon j.larmouth@btinternet.com Altrincham Cheshire WA14 3LS England Tel: +44 161 928 1605 --------------060306020603010708080909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Alfred,

The synonyms were introduced some time ago, and, indeed, the names are non-normative, and may not even be unambiguous.  Only the numbers matter in an OID in an encoding.

However, the recent introduction of Unicode labels, as normative and unambigous names gives a new naming scheme to the (same) OID tree that enables names (Unicode labels) to be used in machine communication if desired.  The ASN.1 type is called OID_IRI and provides for node identification using Unicode labels.  Unicode labels with names similar to the old ASCII names have been assigned for many of the top-level arcs, and more will be added over time.

The OID_IRI type  is related to (but not dependent on) the application for an "oid" IRI scheme,  but for consistency this is desired.  See I-D draft-larmouth-oid-iri-00.

John L

Alfred � wrote: 
Folks / to whom it concerns,

during recent reviews of active I-Ds containing ASN.1 related
to the X.500 framework, I found that a couple of these do not
consistently employ the revised name of the top-level OID branch

    joint-iso-itu-t(2) ,

but instead use the outdated/legacy name

    joint-iso-ccitt(2) .

Some drafts use a mix of both names.

I suggest that the modern version  joint-iso-itu-t(2)  be used
consistently within all new drafts / draft versions, unless
intentionally and explicitely for historical evidence reference
has to be made to the old name.

Kind regards,
  Alfred.

  

-- 
   Prof John Larmouth
   Larmouth T&PDS Ltd
   (Training and Protocol Design Services Ltd)
   1 Blueberry Road                     
   Bowdon                               j.larmouth@btinternet.com
   Altrincham
   Cheshire
   WA14 3LS                 
   England
   Tel: +44 161 928 1605
--------------060306020603010708080909-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMEalxR024585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 07:36:47 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMEalV8024583; Mon, 22 Dec 2008 07:36:47 -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 WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMEagXw024570; Mon, 22 Dec 2008 07:36:44 -0700 (MST) (envelope-from A.Hoenes@tr-sys.de) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA080886501; Mon, 22 Dec 2008 15:35:01 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA13232; Mon, 22 Dec 2008 15:34:56 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200812221434.PAA13232@TR-Sys.de> Subject: Re: consistent use of top-level oid branch name joint-iso-itu-t(2) To: housley@vigilsec.com Date: Mon, 22 Dec 2008 15:34:56 +0100 (MEZ) Cc: turners@ieca.com, ietf-smime@imc.org, ietf-pkix@imc.org In-Reply-To: <200812221358.AA080714339@w.> from Russ Housley at Dec "22," 2008 "08:33:51" am X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, thanks for your response. > Alfred: > > This is a result of the name change from CCITT to ITU-T. So, > different documents use different names depending on when they were > published. The bits on the wire are not impacted, so I have never > worried about it. > > Russ I am fully aware of the history, but that change is back quite a couple of years now. IIRC, that must have been more than 15 years ago; in particular, the X.680 1994 Edition (== ISO/IEC 8824-1:1995) already specified the new name(s) as the primary identifier(s). My arguments are primarily: o avoiding possible confusion; o making new documents easier to read for newcomers not aware of the history of the ITU-T; o self-consistency within new documents (a major goal of RFC Editor policy); o consistency within the set of related document revisions currently in progress; o using current terminology and names in new documents; o referring to the new name when making citations of the X.680 series of IUT-T Recommendations (and that's the way SMIME and PKIX are moving forward). Kind regards, Alfred. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBME0eMV022581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 07:00:40 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBME0eRF022579; Mon, 22 Dec 2008 07:00: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBME0S1G022564 for ; Mon, 22 Dec 2008 07:00:38 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812221400.mBME0S1G022564@balder-227.proper.com> Received: (qmail 3615 invoked from network); 22 Dec 2008 14:00:25 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 22 Dec 2008 14:00:25 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Dec 2008 08:33:51 -0500 To: Alfred =?hp-roman8?B?SM5uZXM=?= From: Russ Housley Subject: Re: consistent use of top-level oid branch name joint-iso-itu-t(2) Cc: turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org In-Reply-To: <200812221256.NAA13071@TR-Sys.de> References: <200812221256.NAA13071@TR-Sys.de> 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: Alfred: This is a result of the name change from CCITT to ITU-T. So, different documents use different names depending on when they were published. The bits on the wire are not impacted, so I have never worried about it. Russ At 07:56 AM 12/22/2008, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >Folks / to whom it concerns, > >during recent reviews of active I-Ds containing ASN.1 related >to the X.500 framework, I found that a couple of these do not >consistently employ the revised name of the top-level OID branch > > joint-iso-itu-t(2) , > >but instead use the outdated/legacy name > > joint-iso-ccitt(2) . > >Some drafts use a mix of both names. > >I suggest that the modern version joint-iso-itu-t(2) be used >consistently within all new drafts / draft versions, unless >intentionally and explicitely for historical evidence reference >has to be made to the old name. > >Kind regards, > Alfred. > >-- > >+------------------------+--------------------------------------------+ >| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | >| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | >| D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | >+------------------------+--------------------------------------------+ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCvv5i018746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 05:57:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMCvvoO018744; Mon, 22 Dec 2008 05:57: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 WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCvhUl018724; Mon, 22 Dec 2008 05:57:55 -0700 (MST) (envelope-from A.Hoenes@tr-sys.de) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA080420566; Mon, 22 Dec 2008 13:56:06 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA13071; Mon, 22 Dec 2008 13:56:05 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200812221256.NAA13071@TR-Sys.de> Subject: consisten use of top-level oid branch name joint-iso-itu-t(2) To: turners@ieca.com, ietf-pkix@imc.org, ietf-smime@imc.org Date: Mon, 22 Dec 2008 13:56:04 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks / to whom it concerns, during recent reviews of active I-Ds containing ASN.1 related to the X.500 framework, I found that a couple of these do not consistently employ the revised name of the top-level OID branch joint-iso-itu-t(2) , but instead use the outdated/legacy name joint-iso-ccitt(2) . Some drafts use a mix of both names. I suggest that the modern version joint-iso-itu-t(2) be used consistently within all new drafts / draft versions, unless intentionally and explicitely for historical evidence reference has to be made to the old name. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCtLQn018637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 05:55:21 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBMCtLTM018636; Mon, 22 Dec 2008 05:55:21 -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 mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBMCt2gN018622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Dec 2008 05:55:20 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from [192.168.1.102] (dslstat-77-ppp-125.fastq.com [65.39.77.125] (may be forged)) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id mBMCqlCQ027942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Dec 2008 05:53:43 -0700 Cc: ietf-pkix@imc.org Message-Id: <32405ED5-269D-4E6C-BBB5-1E06CCAD476A@fastq.com> From: Michael Myers To: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: straw poll Date: Mon, 22 Dec 2008 05:51:02 -0700 References: X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. yes 2. yes Mike On Dec 16, 2008, at 7:29 AM, Stephen Kent wrote: > > At a previous IETF meeting (Dublin) I agreed to conduct a straw poll > on adding a new WG item to address OCSP algorithm agility concerns, > after PHB sent a message indicating what status he envisioned for > the work. This action for both me and PHB fell through the cracks. > At the MSP IETF meeting PHB provided a briefing on the problems that > he saw re OCSP ambiguities re algorithm agility, and proposed a > standards track document to address these issues (see PHB's message > of 12/2). > > So, we now have a concrete proposal (draft-hallambaker-ocspagility) > available for review. PHB would like to publish this and then merge > it into the OCSP document when it progresses from PROPOSED to DRAFT > (see his message of 12/2). > > Please send a message to the list by January 9th (allowing for > holiday outages) indicating whether > > 1. your support PKIX work in this area > 2. you support adopting PHB's document as a starting point for such > work > > Thanks & Happy Hoplidays, > > Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBLI2bAb069859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Dec 2008 11:02:37 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBLI2bc5069858; Sun, 21 Dec 2008 11:02: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 woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBLI2QJm069851 for ; Sun, 21 Dec 2008 11:02:37 -0700 (MST) (envelope-from housley@vigilsec.com) Message-Id: <200812211802.mBLI2QJm069851@balder-227.proper.com> Received: (qmail 17156 invoked from network); 21 Dec 2008 18:02:20 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 21 Dec 2008 18:02:20 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 21 Dec 2008 12:27:36 -0500 To: From: Russ Housley Subject: RE: straw poll 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: 1. Yes 2. Yes -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Tuesday, December 16, 2008 9:29 AM To: ietf-pkix@imc.org Subject: straw poll At a previous IETF meeting (Dublin) I agreed to conduct a straw poll on adding a new WG item to address OCSP algorithm agility concerns, after PHB sent a message indicating what status he envisioned for the work. This action for both me and PHB fell through the cracks. At the MSP IETF meeting PHB provided a briefing on the problems that he saw re OCSP ambiguities re algorithm agility, and proposed a standards track document to address these issues (see PHB's message of 12/2). So, we now have a concrete proposal (draft-hallambaker-ocspagility) available for review. PHB would like to publish this and then merge it into the OCSP document when it progresses from PROPOSED to DRAFT (see his message of 12/2). Please send a message to the list by January 9th (allowing for holiday outages) indicating whether 1. your support PKIX work in this area 2. you support adopting PHB's document as a starting point for such work Thanks & Happy Holidays, Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBJIxsIK054686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2008 11:59:54 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBJIxsQF054685; Fri, 19 Dec 2008 11:59:54 -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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBJIxsUa054679 for ; Fri, 19 Dec 2008 11:59:54 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 4E1CA3A6906; Fri, 19 Dec 2008 11:00:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-tac-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081219190001.4E1CA3A6906@core3.amsl.com> Date: Fri, 19 Dec 2008 11:00:01 -0800 (PST) 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 : Traceable Anonymous Certificate Author(s) : S. Park, H. Park, Y. Won, J. Lee, S. Kent Filename : draft-ietf-pkix-tac-02.txt Pages : 34 Date : 2008-12-19 Public Key Infrastructure (PKI) provides a powerful means of authenticating individuals, organizations, and computers(e.g., web servers). However, when individuals use certificates to access resources on the public Internet, there are legitimate concerns about personal privacy, and thus there are increasing demands for privacy enhancing techniques on the Internet. In a PKI, an authorized entity such as a certification Authority (CA) or a Registration Authority (RA) may be perceived, from a privacy perspective, as a "big brother," even when a CA issues a certificate containing a Subject name that is a pseudonym. This is because such entities can always map a pseudonym in a certificate they issued to the name of the real user to whom it was issued. This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 [3], CMC[4]. The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymous Issuer). The end-entity(EE) certificates issued under this model are called Traceable Anonymous Certificates (TACs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-tac-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pkix-tac-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-19105607.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIIbvoS089248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 11:37:57 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIIbvA6089247; Thu, 18 Dec 2008 11:37: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 smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBIIbj9G089219 for ; Thu, 18 Dec 2008 11:37:56 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 99910 invoked from network); 18 Dec 2008 18:37:45 -0000 Received: from unknown (HELO Wylie) (turners@96.241.96.241 with login) by smtp106.biz.mail.re2.yahoo.com with SMTP; 18 Dec 2008 18:37:44 -0000 X-YMail-OSG: Havn4LwVM1l3S1zRHQ5eiGE0btx5mBjgb2lI3t2f0Pc53jzV7MUdQ7if48MyPzlvFjNnTHhfcNOHvpb0La7xa7MjEGFFOWoXJ8I6_5DiShFg9b_kJVJ.nv2ozzGe.731tnwCZDNHMC9d4WEUoJxBvg3q7qI78MaL2WgbdAzc9fva5Nf0DqyMaPttHW7ZjTe8.MUE3GVUQwETQeOWcHOkSddCEOc- X-Yahoo-Newman-Property: ymail-3 From: "Turner, Sean P." To: , References: <1696498986EFEC4D9153717DA325CB7202A049A8@vaebe104.NOE.Nokia.com> Subject: RE: AD review comments for draft-ietf-pkix-rfc4055-update-01 Date: Thu, 18 Dec 2008 13:37:19 -0500 Organization: IECA, Inc. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AclhOURfo6N+b0JqRwyqq4U9konBCwABkvJA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <1696498986EFEC4D9153717DA325CB7202A049A8@vaebe104.NOE.Nokia.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: These look correct to me. spt >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org >[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of >Pasi.Eronen@nokia.com >Sent: Thursday, December 18, 2008 12:52 PM >To: ietf-pkix@imc.org >Subject: AD review comments for draft-ietf-pkix-rfc4055-update-01 > > > >I've now reviewed draft-ietf-pkix-rfc4055-update-01, and it >looks good. I have only one nit: the draft doesn't touch any >of the parts related to PKCS#1 v1.5 signatures (RFC 4055 also >specified OIDs for PKCS#1 v1.5 signatures with >SHA-224/256/384/512), so I'd suggest the following edits: > >Abstract: >OLD: > It updates the conventions for using the RSA Encryption Scheme - > Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport > algorithm with the Public-Key Cryptography Standards (PKCS) >#1 version > 1.5 signature algorithm in the Internet X.509 Public Key > Infrastructure (PKI). >NEW: > It updates the conventions for using the RSA Encryption Scheme - > Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport > algorithm in the Internet X.509 Public Key Infrastructure (PKI). > >Section 1: >OLD: > RFC 4055 specifies conventions for using the RSA Encryption >Scheme - > Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport > algorithm with the Public-Key Cryptography Standards (PKCS) #1 > version 1.5 signature algorithm in the Internet X.509 Public Key > Infrastructure (PKI). >NEW: > RFC 4055 specifies conventions for using the RSA Encryption >Scheme - > Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport > algorithm in the Internet X.509 Public Key Infrastructure (PKI). > > >Sean and others, do these look correct? > >Best regards, >Pasi > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIHppEj086742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 10:51:51 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIHppon086741; Thu, 18 Dec 2008 10:51:51 -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 mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIHpcBe086726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 18 Dec 2008 10:51:50 -0700 (MST) (envelope-from Pasi.Eronen@nokia.com) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id mBIHpY8Y010772 for ; Thu, 18 Dec 2008 19:51:36 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Dec 2008 19:51:34 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Dec 2008 19:51:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AD review comments for draft-ietf-pkix-rfc4055-update-01 Date: Thu, 18 Dec 2008 19:51:34 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB7202A049A8@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review comments for draft-ietf-pkix-rfc4055-update-01 Thread-Index: AclhOURfo6N+b0JqRwyqq4U9konBCw== From: To: X-OriginalArrivalTime: 18 Dec 2008 17:51:34.0375 (UTC) FILETIME=[444DCF70:01C96139] X-Nokia-AV: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've now reviewed draft-ietf-pkix-rfc4055-update-01, and it looks good. I have only one nit: the draft doesn't touch any of the parts related to PKCS#1 v1.5 signatures (RFC 4055 also specified OIDs=20 for PKCS#1 v1.5 signatures with SHA-224/256/384/512), so I'd=20 suggest the following edits: Abstract: OLD:=20 It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm with the Public-Key Cryptography Standards (PKCS) #1 = version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). NEW: It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm in the Internet X.509 Public Key Infrastructure (PKI). Section 1: OLD: RFC 4055 specifies conventions for using the RSA Encryption Scheme -=20 Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport=20 algorithm with the Public-Key Cryptography Standards (PKCS) #1=20 version 1.5 signature algorithm in the Internet X.509 Public Key=20 Infrastructure (PKI). NEW: RFC 4055 specifies conventions for using the RSA Encryption Scheme -=20 Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport=20 algorithm in the Internet X.509 Public Key Infrastructure (PKI). Sean and others, do these look correct? Best regards, Pasi Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIGlNfP083413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 09:47:23 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBIGlNjY083412; Thu, 18 Dec 2008 09: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 smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBIGlAIx083401 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 18 Dec 2008 09:47:21 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 18 Dec 2008 16:47:09 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.2.54]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 18 Dec 2008 16:47:09 +0000 From: Stefan Santesson To: "ietf-pkix@imc.org" , "Kemp, David P." Date: Thu, 18 Dec 2008 16:47:13 +0000 Subject: FW: TA requirements doc - do we need it? Thread-Topic: TA requirements doc - do we need it? Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrAAApWoQAAk2WagAEDwEFA= Message-ID: <9F11911AED01D24BAA1C2355723C3D321AF3E6206D@EA-EXMSG-C332.europe.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AF3E6206DEAEXMSGC332eu_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_9F11911AED01D24BAA1C2355723C3D321AF3E6206DEAEXMSGC332eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm resending this as my original mail got filtered due to exceeding pkix m= essage size restrictions. I have now replaced the embedded picture with a URL to the screenshot. Stefan Santesson Senior Program Manager Windows Security, Standards From: Stefan Santesson Sent: den 17 december 2008 11:43 To: 'Kemp, David P.'; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? Dave, You raise valid points and I partly try to avoid them because the answer is= somewhat long and complex. Long and complex answers are seldom successful = in standards discussions :) Let me try to show my point through a screenshot that helped explain this i= ssue to at least one of the original contributors to the proposed protocol.= This is a screenshot of the Microsoft certificate management snap-in: http://www.fiddler.nu/pkix/certmgr_mmc.jpg What you see here is the certificate trust policies in my laptop. It is not= one root store and it is not just about trust anchors. In my laptop I have= a certificate trust management snap-in for: * Each host (local machine) * Each user account * Each service running on any host In the Certificate snap-in window to the right, you see a fraction of the l= ist of services with individual certificate trust settings for one host/mac= hine. And it is not about just TA:s. It is about: * My personal certificates * Trusted roots * Intermediary CAs * Directly trusted or untrusted certificates * Etc, etc (See above) The structure of this information is not globally agreed and generic. It is= just how Microsoft have structured this in the Microsoft OS. One could call this a set of certificate trust policies that are dynamicall= y managed and as you get closer to reality, the border between roles, peopl= es and machines are getting more and more virtual and dynamic and it become= s harder and harder to reduce this into one generic, intrusive and centrall= y managed TA management protocol. Let me take a few examples from the requirements: * The assumed roles and authorization model * The assumption that there exist clearly identifiable TA stores. The TA requirements are assuming a TA manager responsible for a TA store. T= he TA manager have authority over this TA store and have the power update i= t or replace it. This also assumes that each TA store is individually ident= ifiable in the protocol itself. In my environment above, I first of all don= 't have any isolated identifiable TA stores. Secondly I don't have a clear= ly defined TA manager that has the right to view and update this informatio= n on a local machine. The applications or services that eventually are being affected by these tr= ust policy updates will not have a clue about what information that was pas= sed in any TA management protocol, or any IETF defined TA format file sever= al layers and APIs below their existence. So any discussion about how appli= cations should take into account specific path processing preferences provi= ded by passing TA format information around, such as applying specific cons= traints rules, is just pretty theory without substance unless it is made pa= rt of standard RFC 5280 path processing and implemented in the APIs for pat= h validation. In the environment I'm working with, I have no use for a transaction based = TA management protocol based on the simplified relationship between a TA ma= nager and a TA store. If I had one, I would not know how to use it. The only thing I would know how to use, is the TA format specification. Tha= t one I can use to pass TAs around in my existing trust policy framework. I hope this was a useful clarification and my apology for passing graphics = in a PKIX posting. I hope you can view it. 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 Kemp, David P. Sent: den 16 december 2008 18:12 To: ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? Stefan, Refining the requirements as a series of I-Ds until "the scope of the requi= rements is in harmony with problem space", then publishing as an RFC once t= he requirements have converged, certainly sounds like the best approach. But you have not explained how "The requirements are radically different in= a device oriented environment with disconnected units compared with a cent= rally managed IT environment with a common network and data sharing infrast= ructure." The requirements in either case are for managed devices/applicat= ions/services to receive configuration items from managers without those it= ems being compromised in transit, yes? * Are you claiming that adversaries have no access to a "common net= work and data sharing infrastructure" and therefore no protection is needed= in the networked case? That is patently false for all networks of interes= t to the IETF. * Or that the protection mechanisms appropriate for managing networ= ked platforms (Connection-oriented? MACs?) are different than those needed= for managing disconnected platforms (Datagram/message-oriented? Signatures= ?) Without understanding the nature of your objections it's hard to tell wheth= er the scope of the requirements is already in harmony with the entire prob= lem space or not. Your 4-quadrant slide from Minneapolis is not self-expl= anatory - I thought we had already disposed of the push-pull issue by deter= mining that there is no security-relevant difference between posting to a r= epository from which a client may pull and pushing directly to the client. = Therefore the TAM requirements already cover the left half of the space. = If there is a single existing TAM requirement that precludes pull, or a sin= gle missing TAM requirement needed for pull, please provide an example. And I need help understanding the difference you see between TA and TA Poli= cy - if policy is "Host/App A will trust provider X for security critical f= irmware category Z", and the TA store of Host/App A has provider X's TA in = the slot for firmware category Z, what is the difference, other than level = of abstraction, between "determine current TAs in store" and "demonstrate c= ompliance with policy"? Again, an example of a missing TAM requirement nee= ded to satisfy the right half of your slide would go a long way toward unde= rstanding the scope issue. Dave From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On= Behalf Of Stefan Santesson Sent: Tuesday, December 16, 2008 9:58 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? Hi Santosh, As I expect, I sense that we have a slightly different view of the generali= ty of the proposed solution, but we seem to agree on the main issue: The question one have to ask is if these requirements, in the form of an RF= C, would serve us as a community if we encounter a problem with the propose= d protocol. I doubt that it will as it at most will strengthen the argument= for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits= us to evaluate various solutions and protocols. If we do encounter a secu= rity problem, it should be useful to analyze where the engineering process = failed, e.g., did we not articulate some requirement, did we not have suffi= cient detail for a requirement, did our analysis of protocol meeting a requ= irement was flawed, etc. I would also prefer to see the requirements document as a living document a= s you suggest. I think that purpose is best served if the requirements docu= ment remains in draft form. 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 15 december 2008 17:47 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? Stefan, See my responses in-line below. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On= Behalf Of Stefan Santesson Sent: Friday, December 12, 2008 7:25 AM To: ietf-pkix@imc.org Subject: TA requirements doc - do we need it? After all discussions in Minneapolis and going back and looking at the curr= ent situation, I feel less and less convinced that we need to approve any T= A requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may = be a lot more harmful than beneficiary to us as an RFC. I have two major reasons: First, as I have argued and tried to explain with my slide in Minneapolis, = there is no general overall approach to TA management in a complex IT envir= onment. [Santosh] In a complex distributed environment that needs to scale across E= nterprises, applying requisite security services to the payload provides a = scalable, interoperable, extensible, and secure solution. The requirements are radically different in a device oriented environment w= ith disconnected units compared with a centrally managed IT environment wit= h a common network and data sharing infrastructure. [Santosh] The requirements are generally the same in terms of security serv= ices. Some Enterprise IT management implementations may have implemented E= nterprise specific solutions taking advantages of existing infrastructure a= nd security services provided by the Enterprise network. But, that solutio= n may not be as scalable or open. Secondly, the requirements didn't come first. These requirements were writt= en with an existing protocol in mind. The lasting impression is therefore t= hat the requirements document was written to match and support the original= protocol, making it a tool to grandfather the original protocol into IETF.= I'm not claiming that this is the case, but it remains to be my impression= . [Santosh] If you look at many of the engineering endeavors we undertake, re= quirements are based on past experience, security vulnerabilities we have e= ncountered, past systems, etc. I do not know of many successful efforts wh= ere requirements were developed in vacuum. In short, it is fair to say that= the requirements and protocol benefited from each other and from past expe= riences with protocols and vulnerabilities. The question one have to ask is if these requirements, in the form of an RF= C, would serve us as a community if we encounter a problem with the propose= d protocol. I doubt that it will as it at most will strengthen the argument= for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits= us to evaluate various solutions and protocols. If we do encounter a secu= rity problem, it should be useful to analyze where the engineering process = failed, e.g., did we not articulate some requirement, did we not have suffi= cient detail for a requirement, did our analysis of protocol meeting a requ= irement was flawed, etc. My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to ref= lect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before= the scope is in harmony with the requirements. Stefan Santesson Senior Program Manager Windows Security, Standards --_000_9F11911AED01D24BAA1C2355723C3D321AF3E6206DEAEXMSGC332eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m resending this as my original mail got filtered due to e= xceeding pkix message size restrictions.

I have now = replaced the embedded picture with a URL to the screenshot.

 =

 =

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 =

From: Stefan Santesson
Sent: den 17 december 2008 11:43
To: 'Kemp, David P.'; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need it?<= /p>

 

Dave,<= /p>

 =

You raise v= alid points and I partly try to avoid them because the answer is somewhat long a= nd complex. Long and complex answers are seldom successful in standards discussions J

 =

Let me try = to show my point through a screenshot that helped explain this issue to at least one o= f the original contributors to the proposed protocol. This is a screenshot of= the Microsoft certificate management snap-in:

 =

http://www.fiddler.nu/p= kix/certmgr_mmc.jpg

 =

What you se= e here is the certificate trust policies in my laptop. It is not one root store and i= t is not just about trust anchors. In my laptop I have a certificate trust management snap-in for:

·      =    E= ach host (local machine)

·      =    E= ach user account

·      =    E= ach service running on any host

 =

In the Cert= ificate snap-in window to the right, you see a fraction of the list of services wit= h individual certificate trust settings for one host/machine.

 =

And it is n= ot about just TA:s. It is about:

·      =    M= y personal certificates

·      =    T= rusted roots

·      =    I= ntermediary CAs

·      =    D= irectly trusted or untrusted certificates

·      =    E= tc, etc (See above)

 =

The structu= re of this information is not globally agreed and generic. It is just how Microsoft ha= ve structured this in the Microsoft OS.

 =

One could c= all this a set of certificate trust policies that are dynamically managed and as you g= et closer to reality, the border between roles, peoples and machines are getti= ng more and more virtual and dynamic and it becomes harder and harder to reduc= e this into one generic, intrusive and centrally managed TA management protoc= ol.

 =

Let me take= a few examples from the requirements:

·      =    T= he assumed roles and authorization model

·      =    T= he assumption that there exist clearly identifiable TA stores.

 =

The TA requ= irements are assuming a TA manager responsible for a TA store. The TA manager have authority over this TA store and have the power update it or replace it. Th= is also assumes that each TA store is individually identifiable in the protoco= l itself. In my environment above, I first of all don’t have any isolat= ed  identifiable TA stores. Secondly I don’t have a clearly defined= TA manager that has the right to view and update this information on a local machine.

 =

The applica= tions or services that eventually are being affected by these trust policy updates w= ill not have a clue about what information that was passed in any TA management protocol, or any IETF defined TA format file several layers and APIs below their existence. So any discussion about how applications should take into account specific path processing preferences provided by passing TA format information around, such as applying specific constraints rules, is just pr= etty theory without substance unless it is made part of standard RFC 5280 path processing and implemented in the APIs for path validation.

 =

In the envi= ronment I’m working with, I have no use for a transaction based TA management= protocol based on the simplified relationship between a TA manager and a TA store. <= o:p>

If I had on= e, I would not know how to use it.

The only th= ing I would know how to use, is the TA format specification. That one I can use t= o pass TAs around in my existing trust policy framework.

 =

I hope this= was a useful clarification and my apology for passing graphics in a PKIX posting. I hope= you can view it.

 =

 =

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 =

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Kemp, David P. Sent: den 16 december 2008 18:12
To: ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need it?<= /p>

 

Stefan,

 =

Refining th= e requirements as a series of I-Ds until “the scope of the requirements= is in harmony with problem space”, then publishing as an RFC once the requi= rements have converged, certainly sounds like the best approach.<= /p>

 =

But you hav= e not explained how “The requirements are radical= ly different in a device oriented environment with disconnected units compared with a ce= ntrally managed IT environment with a common network and data sharing infrastructure.”  The requirements= in either case are for managed devices/applications/services to receive configuration items from managers without those items being compromised in transit, yes?<= o:p>

 =

·      =    A= re you claiming that adversaries have no access to a “common network and dat= a sharing infrastructure” and therefore no protection is needed in the networke= d case?  That is patently false for all networks of interest to the IETF= .

·      =    O= r that the protection mechanisms appropriate for managing networked platforms (Connection-oriented?  MACs?) are different than those needed for mana= ging disconnected platforms (Datagram/message-oriented? Signatures?)<= /span>

 =

Without und= erstanding the nature of your objections it’s hard to tell whether the scope of = the requirements is already in harmony with the entire problem space or not.   Your 4-quadrant slide from Minneapolis is not self-explana= tory – I thought we had already disposed of the push-pull issue by determi= ning that there is no security-relevant difference between posting to a repository fr= om which a client may pull and pushing directly to the client.  Therefore= the TAM requirements already cover the left half of the space.  If there i= s a single existing TAM requirement that precludes pull, or a single missing TA= M requirement needed for pull, please provide an example.

 =

And I need = help understanding the difference you see between TA and TA Policy – if po= licy is “Host/App A will trust provider X for security critical firmware cate= gory Z”, and the TA store of Host/App A has provider X’s TA in the slot for fi= rmware category Z, what is the difference, other than level of abstraction, betwee= n “determine current TAs in store” and “demonstrate complia= nce with policy”?  Again, an example of a missing TAM requirement needed to satisfy the right = half of your slide would go a long way toward understanding the scope issue.

 =

Dave

 =

 =

 =

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson<= br> Sent: Tuesday, December 16, 2008 9:58 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need it?<= /p>

 

Hi Santosh,

 =

As I expect= , I sense that we have a slightly different view of the generality of the proposed solution, but we seem to agree on the main issue:

 =

The question one have to ask is if = these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it = at most will strengthen the argument for those having an interest to adopt the original protocol.

[Santosh] Having a requirements document t= hat is a living document, permits us to evaluate various solutions and protocol= s.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc.<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col= or:navy'>

 =

I would als= o prefer to see the requirements document as a living document as you suggest. I thi= nk that purpose is best served if the requirements document remains in draft f= orm.

 =

 =

 =

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 =

From: owner-ietf-pkix@mail.imc.org [mailto:ow= ner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani
Sent: den 15 december 2008 17:47
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need it?<= /p>

 

Stefan,

 

See my responses in-line below.

 

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson<= br> Sent: Friday, December 12, 2008 7:25 AM
To: ietf-pkix@imc.org
Subject: TA requirements doc - do we need it?

 

After all discussions in Minneapoli= s and going back and looking at the current situation, I feel less and less convi= nced that we need to approve any TA requirements document as an RFC. At least no= t in its current form.

I’m fine with having it aroun= d as a draft for reference, but I fear it may be a lot more harmful than beneficiary to = us as an RFC.

 

I have two major reasons:

 

First, as I have argued and tried t= o explain with my slide in Minneapolis, there is no general overall approach = to TA management in a complex IT environment.

[Santosh] In a complex distributed environ= ment that needs to scale across Enterprises, applying requisite security service= s to the payload provides a scalable, interoperable, extensible, and secure solution.

 

The requirements are radically diff= erent in a device oriented environment with disconnected units compared with a centr= ally managed IT environment with a common network and data sharing infrastructur= e.

[Santosh] The requirements are generally t= he same in terms of security services.  Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network.  But, that solution may not be as scalable or open= .

 

Secondly, the requirements didnR= 17;t come first. These requirements were written with an existing protocol in mind. T= he lasting impression is therefore that the requirements document was written to match= and support the original protocol, making it a tool to grandfather the original protocol into IETF. I’m not claiming that this is the case, but it re= mains to be my impression.

[Santosh] If you look at many of the engineering endeavors we undertake, requirements are based on past experien= ce, security vulnerabilities we have encountered, past systems, etc.  I do= not know of many successful efforts where requirements were developed in vacuum= . In short, it is fair to say that the requirements and protocol benefited from = each other and from past experiences with protocols and vulnerabilities.<= /i>

 

The question one have to ask is if = these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it = at most will strengthen the argument for those having an interest to adopt the original protocol.

[Santosh] Having a requirements document t= hat is a living document, permits us to evaluate various solutions and protocol= s.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc.<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col= or:navy'>

 

My proposal going forward is to do = the following:

-          In any case adjust the sc= ope of the requirements document to reflect the problem space the problem space it= is designed for.

-          Leave it as a draft, or a= t least not publish it as an RFC before the scope is in harmony with the requirements.

 

 

 

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 

--_000_9F11911AED01D24BAA1C2355723C3D321AF3E6206DEAEXMSGC332eu_-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGHCt8I014283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 10:12:55 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGHCt4w014282; Tue, 16 Dec 2008 10:12:55 -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 stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGHCsRZ014274 for ; Tue, 16 Dec 2008 10:12:54 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95FA1.71A77FB7" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: TA requirements doc - do we need it? Date: Tue, 16 Dec 2008 12:12:15 -0500 Message-ID: <200812161712.mBGHCsVQ008014@stingray.missi.ncsc.mil> In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TA requirements doc - do we need it? Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrAAApWoQA== References: <9F11911AED01D24BAA1C2355723C3D321AB5CB52E5@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0@EA-EXMSG-C332.europe.corp.microsoft.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 16 Dec 2008 17:09:50.0062 (UTC) FILETIME=[1ACA78E0:01C95FA1] 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_01C95FA1.71A77FB7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 Refining the requirements as a series of I-Ds until "the scope of the requirements is in harmony with problem space", then publishing as an RFC once the requirements have converged, certainly sounds like the best approach. =20 But you have not explained how "The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure." The requirements in either case are for managed devices/applications/services to receive configuration items from managers without those items being compromised in transit, yes? =20 * Are you claiming that adversaries have no access to a "common network and data sharing infrastructure" and therefore no protection is needed in the networked case? That is patently false for all networks of interest to the IETF. * Or that the protection mechanisms appropriate for managing networked platforms (Connection-oriented? MACs?) are different than those needed for managing disconnected platforms (Datagram/message-oriented? Signatures?) =20 Without understanding the nature of your objections it's hard to tell whether the scope of the requirements is already in harmony with the entire problem space or not. Your 4-quadrant slide from Minneapolis is not self-explanatory - I thought we had already disposed of the push-pull issue by determining that there is no security-relevant difference between posting to a repository from which a client may pull and pushing directly to the client. Therefore the TAM requirements already cover the left half of the space. If there is a single existing TAM requirement that precludes pull, or a single missing TAM requirement needed for pull, please provide an example. =20 And I need help understanding the difference you see between TA and TA Policy - if policy is "Host/App A will trust provider X for security critical firmware category Z", and the TA store of Host/App A has provider X's TA in the slot for firmware category Z, what is the difference, other than level of abstraction, between "determine current TAs in store" and "demonstrate compliance with policy"? Again, an example of a missing TAM requirement needed to satisfy the right half of your slide would go a long way toward understanding the scope issue. =20 Dave =20 =20 =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Tuesday, December 16, 2008 9:58 AM To: Santosh Chokhani; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Hi Santosh, =20 As I expect, I sense that we have a slightly different view of the generality of the proposed solution, but we seem to agree on the main issue: =20 The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols. If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc. =20 I would also prefer to see the requirements document as a living document as you suggest. I think that purpose is best served if the requirements document remains in draft form. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani Sent: den 15 december 2008 17:47 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? =20 Stefan, =20 See my responses in-line below.=20 =20 _____ =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Friday, December 12, 2008 7:25 AM To: ietf-pkix@imc.org Subject: TA requirements doc - do we need it? =20 After all discussions in Minneapolis and going back and looking at the current situation, I feel less and less convinced that we need to approve any TA requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may be a lot more harmful than beneficiary to us as an RFC. =20 I have two major reasons: =20 First, as I have argued and tried to explain with my slide in Minneapolis, there is no general overall approach to TA management in a complex IT environment. [Santosh] In a complex distributed environment that needs to scale across Enterprises, applying requisite security services to the payload provides a scalable, interoperable, extensible, and secure solution. =20 The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure. [Santosh] The requirements are generally the same in terms of security services. Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network. But, that solution may not be as scalable or open. =20 Secondly, the requirements didn't come first. These requirements were written with an existing protocol in mind. The lasting impression is therefore that the requirements document was written to match and support the original protocol, making it a tool to grandfather the original protocol into IETF. I'm not claiming that this is the case, but it remains to be my impression. [Santosh] If you look at many of the engineering endeavors we undertake, requirements are based on past experience, security vulnerabilities we have encountered, past systems, etc. I do not know of many successful efforts where requirements were developed in vacuum. In short, it is fair to say that the requirements and protocol benefited from each other and from past experiences with protocols and vulnerabilities. =20 The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols. If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc. =20 My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to reflect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before the scope is in harmony with the requirements. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C95FA1.71A77FB7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefan,

 

Refining the = requirements as a series of I-Ds until “the scope of the requirements is in harmony = with problem space”, then publishing as an RFC once the requirements have = converged, certainly sounds like the best approach.

 

But you have not = explained how “The requirements are radically different in a device oriented environment = with disconnected units compared with a centrally managed IT environment with = a common network and data sharing infrastructure.”  The requirements in either case are for managed = devices/applications/services to receive configuration items from managers without those items being = compromised in transit, yes?

 

·         Are you = claiming that adversaries have no access to a “common network and data = sharing infrastructure” and therefore no protection is needed in the = networked case?  That is patently false for all networks of interest to the = IETF.

·         Or that the protection mechanisms appropriate for managing networked platforms = (Connection-oriented?  MACs?) are different than those needed for managing disconnected = platforms (Datagram/message-oriented? Signatures?)

 

Without understanding = the nature of your objections it’s hard to tell whether the scope of the = requirements is already in harmony with the entire problem space or not.   = Your 4-quadrant slide from Minneapolis is not self-explanatory – I thought we had = already disposed of the push-pull issue by determining that there is no = security-relevant difference between posting to a repository from which a client may pull = and pushing directly to the client.  Therefore the TAM requirements = already cover the left half of the space.  If there is a single existing TAM = requirement that precludes pull, or a single missing TAM requirement needed for pull, = please provide an example.

 

And I need help = understanding the difference you see between TA and TA Policy – if policy is = “Host/App A will trust provider X for security critical firmware category Z”, and = the TA store of Host/App A has provider X’s TA in the slot for firmware = category Z, what is the difference, other than level of abstraction, between = “determine current TAs in store” and “demonstrate compliance with = policy”?  Again, an example of a missing TAM requirement needed to satisfy the right half of your slide = would go a long way toward understanding the scope issue.

 

Dave

 

 

 

From:= owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On = Behalf Of Stefan Santesson
Sent: Tuesday, December 16, 2008 9:58 AM
To: Santosh Chokhani; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need = it?

 

Hi Santosh,

 

As I expect, I sense = that we have a slightly different view of the generality of the proposed = solution, but we seem to agree on the main issue:

 

The question one have to ask is if these = requirements, in the form of an RFC, would serve us as a community if we encounter a = problem with the proposed protocol. I doubt that it will as it at most will = strengthen the argument for those having an interest to adopt the original = protocol.

[Santosh] Having a requirements document that is a living = document, permits us to evaluate various solutions and protocols.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some = requirement, did we not have sufficient detail for a requirement, did our analysis of = protocol meeting a requirement was flawed, etc.

 

I would also prefer = to see the requirements document as a living document as you suggest. I think that = purpose is best served if the requirements document remains in draft = form.

 

 

 

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 15 december 2008 17:47
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need = it?

 

Stefan,

 

See my responses in-line below.

 

From:= owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On = Behalf Of Stefan Santesson
Sent: Friday, December 12, 2008 7:25 AM
To: ietf-pkix@imc.org
Subject: TA requirements doc - do we need it?

 

After all discussions in Minneapolis and going back = and looking at the current situation, I feel less and less convinced that we = need to approve any TA requirements document as an RFC. At least not in its = current form.

I’m fine with having it around as a draft for = reference, but I fear it may be a lot more harmful than beneficiary to us as an = RFC.

 

I have two major reasons:

 

First, as I have argued and tried to explain with = my slide in Minneapolis, there is no general overall approach to TA management in = a complex IT environment.

[Santosh] In a complex distributed environment that needs to = scale across Enterprises, applying requisite security services to the payload provides a scalable, interoperable, extensible, and secure = solution.

 

The requirements are radically different in a = device oriented environment with disconnected units compared with a centrally = managed IT environment with a common network and data sharing = infrastructure.

[Santosh] The requirements are generally the same in terms = of security services.  Some Enterprise IT management implementations = may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network.  But, that solution may not be as scalable or = open.

 

Secondly, the requirements didn’t come first. = These requirements were written with an existing protocol in mind. The lasting impression is therefore that the requirements document was written to = match and support the original protocol, making it a tool to grandfather the = original protocol into IETF. I’m not claiming that this is the case, but it = remains to be my impression.

[Santosh] If you look at many of the engineering endeavors = we undertake, requirements are based on past experience, security = vulnerabilities we have encountered, past systems, etc.  I do not know of many = successful efforts where requirements were developed in vacuum. In short, it is = fair to say that the requirements and protocol benefited from each other and = from past experiences with protocols and = vulnerabilities.

 

The question one have to ask is if these = requirements, in the form of an RFC, would serve us as a community if we encounter a = problem with the proposed protocol. I doubt that it will as it at most will = strengthen the argument for those having an interest to adopt the original = protocol.

[Santosh] Having a requirements document that is a living = document, permits us to evaluate various solutions and protocols.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some = requirement, did we not have sufficient detail for a requirement, did our analysis of = protocol meeting a requirement was flawed, etc.

 

My proposal going forward is to do the = following:

-          In any case adjust the scope of the requirements document to reflect the problem space the problem space it is designed = for.

-          Leave it as a draft, or at least not publish it = as an RFC before the scope is in harmony with the requirements.

 

 

 

Stefan Santesson

Senior Program Manager

Windows Security, = Standards

 

------_=_NextPart_001_01C95FA1.71A77FB7-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFwje2009846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 08:58:45 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGFwjED009845; Tue, 16 Dec 2008 08:58: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 stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFwYZ0009833 for ; Tue, 16 Dec 2008 08:58:45 -0700 (MST) (envelope-from DPKemp@missi.ncsc.mil) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: straw poll Date: Tue, 16 Dec 2008 10:58:20 -0500 Message-ID: <200812161558.mBGFwYhj004620@stingray.missi.ncsc.mil> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: straw poll Thread-Index: AclfkM/lPsmO8eQLRsii96PH/Om8VAABjnCw References: From: "Kemp, David P." To: X-OriginalArrivalTime: 16 Dec 2008 15:55:30.0375 (UTC) FILETIME=[B89C3D70:01C95F96] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1. yes 2. yes -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Tuesday, December 16, 2008 9:29 AM To: ietf-pkix@imc.org Subject: straw poll At a previous IETF meeting (Dublin) I agreed to conduct a straw poll=20 on adding a new WG item to address OCSP algorithm agility concerns,=20 after PHB sent a message indicating what status he envisioned for the=20 work. This action for both me and PHB fell through the cracks. At the=20 MSP IETF meeting PHB provided a briefing on the problems that he saw=20 re OCSP ambiguities re algorithm agility, and proposed a standards=20 track document to address these issues (see PHB's message of 12/2). So, we now have a concrete proposal (draft-hallambaker-ocspagility)=20 available for review. PHB would like to publish this and then merge=20 it into the OCSP document when it progresses from PROPOSED to DRAFT=20 (see his message of 12/2). Please send a message to the list by January 9th (allowing for=20 holiday outages) indicating whether 1. your support PKIX work in this area 2. you support adopting PHB's document as a starting point=20 for such work Thanks & Happy Hoplidays, Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFFnDP007171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 08:15:49 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGFFnVb007170; Tue, 16 Dec 2008 08:15:49 -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-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGFFbVn007156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 16 Dec 2008 08:15:48 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 16 Dec 2008 15:15:37 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Tue, 16 Dec 2008 15:15:37 +0000 From: Stefan Santesson To: Stephen Kent , "ietf-pkix@imc.org" Date: Tue, 16 Dec 2008 15:15:40 +0000 Subject: RE: straw poll Thread-Topic: straw poll Thread-Index: AclfkMbj9Mz4GZIQRs2Bt/jsEmq9dgAABI+A Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB5D9DE2A@EA-EXMSG-C332.europe.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 1&2 I support work in the area and I support using PHB's document as starting p= oint. 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 Stephen Kent > Sent: den 16 december 2008 15:29 > To: ietf-pkix@imc.org > Subject: straw poll > > > At a previous IETF meeting (Dublin) I agreed to conduct a straw poll > on adding a new WG item to address OCSP algorithm agility concerns, > after PHB sent a message indicating what status he envisioned for the > work. This action for both me and PHB fell through the cracks. At the > MSP IETF meeting PHB provided a briefing on the problems that he saw > re OCSP ambiguities re algorithm agility, and proposed a standards > track document to address these issues (see PHB's message of 12/2). > > So, we now have a concrete proposal (draft-hallambaker-ocspagility) > available for review. PHB would like to publish this and then merge > it into the OCSP document when it progresses from PROPOSED to DRAFT > (see his message of 12/2). > > Please send a message to the list by January 9th (allowing for > holiday outages) indicating whether > > 1. your support PKIX work in this area > 2. you support adopting PHB's document as a starting point > for such work > > Thanks & Happy Hoplidays, > > Steve > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGEw2f3005912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 07:58:02 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGEw2pO005911; Tue, 16 Dec 2008 07:58: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-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGEvotx005898 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 16 Dec 2008 07:58:01 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 16 Dec 2008 14:57:49 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Tue, 16 Dec 2008 14:57:49 +0000 From: Stefan Santesson To: Santosh Chokhani , "ietf-pkix@imc.org" Date: Tue, 16 Dec 2008 14:57:51 +0000 Subject: RE: TA requirements doc - do we need it? Thread-Topic: TA requirements doc - do we need it? Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9AAC9gTrA= Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0@EA-EXMSG-C332.europe.corp.microsoft.com> References: <9F11911AED01D24BAA1C2355723C3D321AB5CB52E5@EA-EXMSG-C332.europe.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0EAEXMSGC332eu_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0EAEXMSGC332eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Santosh, As I expect, I sense that we have a slightly different view of the generali= ty of the proposed solution, but we seem to agree on the main issue: The question one have to ask is if these requirements, in the form of an RF= C, would serve us as a community if we encounter a problem with the propose= d protocol. I doubt that it will as it at most will strengthen the argument= for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits= us to evaluate various solutions and protocols. If we do encounter a secu= rity problem, it should be useful to analyze where the engineering process = failed, e.g., did we not articulate some requirement, did we not have suffi= cient detail for a requirement, did our analysis of protocol meeting a requ= irement was flawed, etc. I would also prefer to see the requirements document as a living document a= s you suggest. I think that purpose is best served if the requirements docu= ment remains in draft form. 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 15 december 2008 17:47 To: Stefan Santesson; ietf-pkix@imc.org Subject: RE: TA requirements doc - do we need it? Stefan, See my responses in-line below. ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On= Behalf Of Stefan Santesson Sent: Friday, December 12, 2008 7:25 AM To: ietf-pkix@imc.org Subject: TA requirements doc - do we need it? After all discussions in Minneapolis and going back and looking at the curr= ent situation, I feel less and less convinced that we need to approve any T= A requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may = be a lot more harmful than beneficiary to us as an RFC. I have two major reasons: First, as I have argued and tried to explain with my slide in Minneapolis, = there is no general overall approach to TA management in a complex IT envir= onment. [Santosh] In a complex distributed environment that needs to scale across E= nterprises, applying requisite security services to the payload provides a = scalable, interoperable, extensible, and secure solution. The requirements are radically different in a device oriented environment w= ith disconnected units compared with a centrally managed IT environment wit= h a common network and data sharing infrastructure. [Santosh] The requirements are generally the same in terms of security serv= ices. Some Enterprise IT management implementations may have implemented E= nterprise specific solutions taking advantages of existing infrastructure a= nd security services provided by the Enterprise network. But, that solutio= n may not be as scalable or open. Secondly, the requirements didn't come first. These requirements were writt= en with an existing protocol in mind. The lasting impression is therefore t= hat the requirements document was written to match and support the original= protocol, making it a tool to grandfather the original protocol into IETF.= I'm not claiming that this is the case, but it remains to be my impression= . [Santosh] If you look at many of the engineering endeavors we undertake, re= quirements are based on past experience, security vulnerabilities we have e= ncountered, past systems, etc. I do not know of many successful efforts wh= ere requirements were developed in vacuum. In short, it is fair to say that= the requirements and protocol benefited from each other and from past expe= riences with protocols and vulnerabilities. The question one have to ask is if these requirements, in the form of an RF= C, would serve us as a community if we encounter a problem with the propose= d protocol. I doubt that it will as it at most will strengthen the argument= for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits= us to evaluate various solutions and protocols. If we do encounter a secu= rity problem, it should be useful to analyze where the engineering process = failed, e.g., did we not articulate some requirement, did we not have suffi= cient detail for a requirement, did our analysis of protocol meeting a requ= irement was flawed, etc. My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to ref= lect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before= the scope is in harmony with the requirements. Stefan Santesson Senior Program Manager Windows Security, Standards --_000_9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0EAEXMSGC332eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Santosh,

 =

As I expect= , I sense that we have a slightly different view of the generality of the proposed so= lution, but we seem to agree on the main issue:

 =

The question one have to ask is if = these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it = at most will strengthen the argument for those having an interest to adopt the original protocol.

[Santosh] Having a requirements document t= hat is a living document, permits us to evaluate various solutions and protocol= s.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc.<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col= or:navy'>

 =

I would als= o prefer to see the requirements document as a living document as you suggest. I thi= nk that purpose is best served if the requirements document remains in draft f= orm.

 =

 =

 =

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 =

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Santosh Chokhani<= br> Sent: den 15 december 2008 17:47
To: Stefan Santesson; ietf-pkix@imc.org
Subject: RE: TA requirements doc - do we need it?<= /p>

 

Stefan,

 

See my responses in-line below.

 

From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson<= br> Sent: Friday, December 12, 2008 7:25 AM
To: ietf-pkix@imc.org
Subject: TA requirements doc - do we need it?

 

After all discussions in Minneapoli= s and going back and looking at the current situation, I feel less and less convi= nced that we need to approve any TA requirements document as an RFC. At least no= t in its current form.

I’m fine with having it aroun= d as a draft for reference, but I fear it may be a lot more harmful than beneficia= ry to us as an RFC.

 

I have two major reasons:

 

First, as I have argued and tried t= o explain with my slide in Minneapolis, there is no general overall approach = to TA management in a complex IT environment.

[Santosh] In a complex distributed environ= ment that needs to scale across Enterprises, applying requisite security service= s to the payload provides a scalable, interoperable, extensible, and secure solution.

 

The requirements are radically diff= erent in a device oriented environment with disconnected units compared with a centr= ally managed IT environment with a common network and data sharing infrastructur= e.

[Santosh] The requirements are generally t= he same in terms of security services.  Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network.  But, that solution may not be as scalable or open= .

 

Secondly, the requirements didnR= 17;t come first. These requirements were written with an existing protocol in mi= nd. The lasting impression is therefore that the requirements document was writ= ten to match and support the original protocol, making it a tool to grandfather= the original protocol into IETF. I’m not claiming that this is the case, = but it remains to be my impression.

[Santosh] If you look at many of the engineering endeavors we undertake, requirements are based on past experien= ce, security vulnerabilities we have encountered, past systems, etc.  I do= not know of many successful efforts where requirements were developed in vacuum= . In short, it is fair to say that the requirements and protocol benefited from = each other and from past experiences with protocols and vulnerabilities.<= /i>

 

The question one have to ask is if = these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it = at most will strengthen the argument for those having an interest to adopt the original protocol.

[Santosh] Having a requirements document t= hat is a living document, permits us to evaluate various solutions and protocol= s.  If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc.<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";col= or:navy'>

 

My proposal going forward is to do = the following:

-          In any case adjust the sc= ope of the requirements document to reflect the problem space the problem space it= is designed for.

-          Leave it as a draft, or a= t least not publish it as an RFC before the scope is in harmony with the requirements.

 

 

 

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 

--_000_9F11911AED01D24BAA1C2355723C3D321AB5D9DDF0EAEXMSGC332eu_-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGETCIo004324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 07:29:12 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBGETCjO004323; Tue, 16 Dec 2008 07:29: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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBGET2Yc004313 for ; Tue, 16 Dec 2008 07:29:12 -0700 (MST) (envelope-from kent@bbn.com) Received: from ros-dhcp233-050-110.bbn.com ([192.233.50.110]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LCauz-0007p7-Cz for ietf-pkix@imc.org; Tue, 16 Dec 2008 09:29:01 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 16 Dec 2008 09:29:06 -0500 To: ietf-pkix@imc.org From: Stephen Kent Subject: straw poll Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At a previous IETF meeting (Dublin) I agreed to conduct a straw poll on adding a new WG item to address OCSP algorithm agility concerns, after PHB sent a message indicating what status he envisioned for the work. This action for both me and PHB fell through the cracks. At the MSP IETF meeting PHB provided a briefing on the problems that he saw re OCSP ambiguities re algorithm agility, and proposed a standards track document to address these issues (see PHB's message of 12/2). So, we now have a concrete proposal (draft-hallambaker-ocspagility) available for review. PHB would like to publish this and then merge it into the OCSP document when it progresses from PROPOSED to DRAFT (see his message of 12/2). Please send a message to the list by January 9th (allowing for holiday outages) indicating whether 1. your support PKIX work in this area 2. you support adopting PHB's document as a starting point for such work Thanks & Happy Hoplidays, Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFGl5Xw038899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 09:47:05 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFGl5tc038898; Mon, 15 Dec 2008 09:47: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 scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mBFGksmg038886 for ; Mon, 15 Dec 2008 09:47:04 -0700 (MST) (envelope-from SChokhani@cygnacom.com) Received: (qmail 5374 invoked from network); 15 Dec 2008 16:46:12 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;15 Dec 2008 16:46:12 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 15 Dec 2008 16:46:11 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95ED4.BB20D3C0" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: TA requirements doc - do we need it? Date: Mon, 15 Dec 2008 11:46:51 -0500 Message-ID: In-Reply-To: <9F11911AED01D24BAA1C2355723C3D321AB5CB52E5@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TA requirements doc - do we need it? thread-index: AclcVLWRik4aj2+RQzK2L6KQEtA3rgCe8f9A References: <9F11911AED01D24BAA1C2355723C3D321AB5CB52E5@EA-EXMSG-C332.europe.corp.microsoft.com> 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_01C95ED4.BB20D3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stefan, =20 See my responses in-line below.=20 =20 ________________________________ From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson Sent: Friday, December 12, 2008 7:25 AM To: ietf-pkix@imc.org Subject: TA requirements doc - do we need it? =20 After all discussions in Minneapolis and going back and looking at the current situation, I feel less and less convinced that we need to approve any TA requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may be a lot more harmful than beneficiary to us as an RFC. =20 I have two major reasons: =20 First, as I have argued and tried to explain with my slide in Minneapolis, there is no general overall approach to TA management in a complex IT environment. [Santosh] In a complex distributed environment that needs to scale across Enterprises, applying requisite security services to the payload provides a scalable, interoperable, extensible, and secure solution. =20 The requirements are radically different in a device oriented environment with disconnected units compared with a centrally managed IT environment with a common network and data sharing infrastructure. [Santosh] The requirements are generally the same in terms of security services. Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and security services provided by the Enterprise network. But, that solution may not be as scalable or open. =20 Secondly, the requirements didn't come first. These requirements were written with an existing protocol in mind. The lasting impression is therefore that the requirements document was written to match and support the original protocol, making it a tool to grandfather the original protocol into IETF. I'm not claiming that this is the case, but it remains to be my impression. [Santosh] If you look at many of the engineering endeavors we undertake, requirements are based on past experience, security vulnerabilities we have encountered, past systems, etc. I do not know of many successful efforts where requirements were developed in vacuum. In short, it is fair to say that the requirements and protocol benefited from each other and from past experiences with protocols and vulnerabilities. =20 The question one have to ask is if these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it at most will strengthen the argument for those having an interest to adopt the original protocol. [Santosh] Having a requirements document that is a living document, permits us to evaluate various solutions and protocols. If we do encounter a security problem, it should be useful to analyze where the engineering process failed, e.g., did we not articulate some requirement, did we not have sufficient detail for a requirement, did our analysis of protocol meeting a requirement was flawed, etc. =20 My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to reflect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before the scope is in harmony with the requirements. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 ------_=_NextPart_001_01C95ED4.BB20D3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stefan,

=

 

See my responses in-line below. =

 

From: = owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stefan Santesson
Sent: Friday, December = 12, 2008 7:25 AM
To: ietf-pkix@imc.org
Subject: TA requirements = doc - do we need it?

 

After all discussions in Minneapolis and going back and looking at the current situation, I feel less and = less convinced that we need to approve any TA requirements document as an = RFC. At least not in its current form.

I’m fine with having it around as a draft for reference, but I fear it may = be a lot more harmful than beneficiary to us as an = RFC.

 

I have two major reasons:

 

First, as I have argued and tried to explain with my slide in Minneapolis, there is no general = overall approach to TA management in a complex IT = environment.

[Santosh] In a complex distributed environment that = needs to scale across Enterprises, applying requisite security services to the = payload provides a scalable, interoperable, extensible, and secure = solution.

 

The requirements are radically different in a device oriented environment = with disconnected units compared with a centrally managed IT environment with = a common network and data sharing = infrastructure.

[Santosh] The requirements are generally the same in = terms of security services.  Some Enterprise IT management implementations may have implemented Enterprise specific solutions taking advantages of existing infrastructure and = security services provided by the Enterprise network.  But, that solution may not be as scalable or = open.

 

Secondly, the requirements didn’t come first. These requirements were = written with an existing protocol in mind. The lasting impression is therefore that = the requirements document was written to match and support the original = protocol, making it a tool to grandfather the original protocol into IETF. = I’m not claiming that this is the case, but it remains to be my = impression.

[Santosh] If you look at many of the engineering = endeavors we undertake, requirements are based on past experience, security = vulnerabilities we have encountered, past systems, etc.  I do not know of many = successful efforts where requirements were developed in vacuum. In short, it is fair to say = that the requirements and protocol benefited from each other and from past = experiences with protocols and vulnerabilities.

 

The question one have to ask is if these requirements, in the form of an = RFC, would serve us as a community if we encounter a problem with the proposed = protocol. I doubt that it will as it at most will strengthen the argument for those = having an interest to adopt the original protocol.

[Santosh] Having a requirements document that is a = living document, permits us to evaluate various solutions and protocols.  If we do = encounter a security problem, it should be useful to analyze where the engineering = process failed, e.g., did we not articulate some requirement, did we not have = sufficient detail for a requirement, did our analysis of protocol meeting a = requirement was flawed, etc.

 

My proposal going forward is to do the = following:

-          In any case adjust the = scope of the requirements document to reflect the problem space the problem space = it is designed for.

-          Leave it as a draft, or at = least not publish it as an RFC before the scope is in harmony with the = requirements.

 

 

 

Stefan Santesson

Senior = Program Manager

Windows Security, Standards

 

------_=_NextPart_001_01C95ED4.BB20D3C0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFEhAra032870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 07:43:10 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBFEhAxQ032869; Mon, 15 Dec 2008 07:43: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 zombie2.ncsc.mil (zombie2.ncsc.mil [144.51.88.133]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBFEgwxJ032858 for ; Mon, 15 Dec 2008 07:43:09 -0700 (MST) (envelope-from llziegl@tycho.ncsc.mil) Received: from smtp.ncsc.mil (jazzdrum.ncsc.mil [144.51.5.7]) by zombie2.ncsc.mil (8.12.10/8.12.10) with ESMTP id mBFEedEN025511; Mon, 15 Dec 2008 14:40:39 GMT Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95EC3.6BA2BC69" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: NSA SuiteB Certificate and CRL Profile Date: Mon, 15 Dec 2008 09:42:57 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NSA SuiteB Certificate and CRL Profile Thread-Index: Aclew2qfI4gj78GSRAWOB65GfvTcUw== From: "Zieglar, Lydia L." To: Cc: "Wallner, Debbie M" , 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_01C95EC3.6BA2BC69 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have recently submitted the National Security Agency's Suite B Certificate and CRL Profile to the IETF as an Internet-Draft.=20 =20 Even though this is an individual submission, we believe that you may be interested and we encourage you to review the document. Please send your comments to llziegl@tycho.ncsc.mil =20 You may reach the document at: =20 http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cert-profile-00 .txt =20 Thanks, Lydia Zieglar =20 Lydia Zieglar 301-688-1028 llziegl@tycho.ncsc.mil =20 ------_=_NextPart_001_01C95EC3.6BA2BC69 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We = have recently=20 submitted the National Security Agency's Suite B Certificate and CRL = Profile to=20 the IETF as an Internet-Draft.
 
Even = though this is=20 an individual submission, we believe that you may be interested and we = encourage=20 you to review the document. Please send your comments to llziegl@tycho.ncsc.mil<= /FONT>
 
You = may reach the=20 document at:
 
http://www.ietf.org/internet-drafts/draft-solinas-suiteb-cer= t-profile-00.txt
 
Thanks,
Lydia=20 Zieglar
 
Lydia Zieglar
301-688-1028
llziegl@tycho.ncsc.mil
 
------_=_NextPart_001_01C95EC3.6BA2BC69-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCIiuaj099003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 11:44:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBCIiuFR099001; Fri, 12 Dec 2008 11:44: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCIiuN1098989 for ; Fri, 12 Dec 2008 11:44:56 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id CAA8528C131; Fri, 12 Dec 2008 10:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-3281update-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081212184501.CAA8528C131@core3.amsl.com> Date: Fri, 12 Dec 2008 10:45:01 -0800 (PST) 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 : An Internet Attribute Certificate Profile for Authorization Author(s) : R. Housley, S. Farrell, S. Turner Filename : draft-ietf-pkix-3281update-02.txt Pages : 45 Date : 2008-12-12 This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications. This document obsoletes RFC 3281. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-3281update-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pkix-3281update-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-12104338.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCITu4H098430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 11:29:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBCITuqF098429; Fri, 12 Dec 2008 11:29: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCITt4d098423 for ; Fri, 12 Dec 2008 11:29:55 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 45BA03A6870; Fri, 12 Dec 2008 10:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-11.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081212183001.45BA03A6870@core3.amsl.com> Date: Fri, 12 Dec 2008 10:30:01 -0800 (PST) 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 : Elliptic Curve Cryptography Subject Public Key Information Author(s) : S. Turner, K. Yiu, D. Brown, R. Housley, W. Polk Filename : draft-ietf-pkix-ecc-subpubkeyinfo-11.txt Pages : 22 Date : 2008-12-12 This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3279. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pkix-ecc-subpubkeyinfo-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-12102205.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCCPf7a078467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 05:25:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBCCPf5X078466; Fri, 12 Dec 2008 05:25: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 smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBCCPTae078452 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 12 Dec 2008 05:25:40 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 12 Dec 2008 12:25:28 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 12 Dec 2008 12:25:28 +0000 From: Stefan Santesson To: "ietf-pkix@imc.org" Date: Fri, 12 Dec 2008 12:25:25 +0000 Subject: TA requirements doc - do we need it? Thread-Topic: TA requirements doc - do we need it? Thread-Index: AclcVLWRik4aj2+RQzK2L6KQEtA3rg== Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB5CB52E5@EA-EXMSG-C332.europe.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB5CB52E5EAEXMSGC332eu_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_9F11911AED01D24BAA1C2355723C3D321AB5CB52E5EAEXMSGC332eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After all discussions in Minneapolis and going back and looking at the curr= ent situation, I feel less and less convinced that we need to approve any T= A requirements document as an RFC. At least not in its current form. I'm fine with having it around as a draft for reference, but I fear it may = be a lot more harmful than beneficiary to us as an RFC. I have two major reasons: First, as I have argued and tried to explain with my slide in Minneapolis, = there is no general overall approach to TA management in a complex IT envir= onment. The requirements are radically different in a device oriented environment w= ith disconnected units compared with a centrally managed IT environment wit= h a common network and data sharing infrastructure. Secondly, the requirements didn't come first. These requirements were writt= en with an existing protocol in mind. The lasting impression is therefore t= hat the requirements document was written to match and support the original= protocol, making it a tool to grandfather the original protocol into IETF.= I'm not claiming that this is the case, but it remains to be my impression= . The question one have to ask is if these requirements, in the form of an RF= C, would serve us as a community if we encounter a problem with the propose= d protocol. I doubt that it will as it at most will strengthen the argument= for those having an interest to adopt the original protocol. My proposal going forward is to do the following: - In any case adjust the scope of the requirements document to ref= lect the problem space the problem space it is designed for. - Leave it as a draft, or at least not publish it as an RFC before= the scope is in harmony with the requirements. Stefan Santesson Senior Program Manager Windows Security, Standards --_000_9F11911AED01D24BAA1C2355723C3D321AB5CB52E5EAEXMSGC332eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After all discussions in Minneapoli= s and going back and looking at the current situation, I feel less and less convi= nced that we need to approve any TA requirements document as an RFC. At least no= t in its current form.

I’m fine with having it aroun= d as a draft for reference, but I fear it may be a lot more harmful than beneficia= ry to us as an RFC.

 

I have two major reasons:

 

First, as I have argued and tried t= o explain with my slide in Minneapolis, there is no general overall approach = to TA management in a complex IT environment.

The requirements are radically diff= erent in a device oriented environment with disconnected units compared with a centr= ally managed IT environment with a common network and data sharing infrastructur= e.

 

Secondly, the requirements didnR= 17;t come first. These requirements were written with an existing protocol in mi= nd. The lasting impression is therefore that the requirements document was writ= ten to match and support the original protocol, making it a tool to grandfather= the original protocol into IETF. I’m not claiming that this is the case, = but it remains to be my impression.

 

 

The question one have to ask is if = these requirements, in the form of an RFC, would serve us as a community if we encounter a problem with the proposed protocol. I doubt that it will as it = at most will strengthen the argument for those having an interest to adopt the original protocol.

 

My proposal going forward is to do = the following:

-          In any case adjust the sc= ope of the requirements document to reflect the problem space the problem space it= is designed for.

-          Leave it as a draft, or a= t least not publish it as an RFC before the scope is in harmony with the requ= irements.

 

 

 

Stefan Santesson

Senior Program Manager=

Windows Security, Standards<= span lang=3DEN-US style=3D'color:#1F497D'>

 

--_000_9F11911AED01D24BAA1C2355723C3D321AB5CB52E5EAEXMSGC332eu_-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBISU2N026781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 11:28:30 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBBISUwb026779; Thu, 11 Dec 2008 11:28: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 mailhost.noorhome.net (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBISJmV026763 for ; Thu, 11 Dec 2008 11:28:30 -0700 (MST) (envelope-from arshad.noor@strongauth.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.noorhome.net (Postfix) with ESMTP id 198DF3AF1C7 for ; Thu, 11 Dec 2008 13:28:19 -0500 (EST) X-Spam-Score: -4.376 X-Spam-Level: X-Spam-Status: No, score=-4.376 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.023, BAYES_00=-2.599] Received: from mailhost.noorhome.net ([127.0.0.1]) by localhost (mailhost.noorhome.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8qBjhb6hNNk for ; Thu, 11 Dec 2008 13:28:18 -0500 (EST) Received: from mailhost.noorhome.net (mailhost.noorhome.net [63.194.79.229]) by mailhost.noorhome.net (Postfix) with ESMTP id 31E413AF1A2 for ; Thu, 11 Dec 2008 13:28:18 -0500 (EST) Date: Thu, 11 Dec 2008 13:28:18 -0500 (EST) From: Arshad Noor To: ietf-pkix Message-ID: <2447964.1001229020098078.JavaMail.root@gw.noorhome.net> In-Reply-To: <49413ff7.c6c1f10a.5a88.302c@mx.google.com> Subject: Fwd: [members] Public Review of SKSML v1.0 - 15 day review MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [72.18.244.116] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI. Arshad Noor StrongAuth, Inc. ----- Forwarded Message ----- From: "Mary McRae" To: members@lists.oasis-open.org, tc-announce@lists.oasis-open.org Sent: Thursday, December 11, 2008 8:29:35 AM (GMT-0800) America/Los_Angeles Subject: [members] Public Review of SKSML v1.0 - 15 day review To OASIS members, Public Announce Lists: The OASIS Enterprise Key Management Infrastructure (EKMI) TC has recently approved the following specification as a Committee Draft and approved the package for public review: Symmetric Key Services Markup Language (SKSML) Version 1.0 The public review starts today , 11 December 2008 , and ends 26 December 2008 . This specification was previously submitted for a 60-day public review on 24 Jul 08 - 23 Sep 08 [1]; this 15-day review is limited in scope to changes made from the previous review. All changes are noted below[2]. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. More non-normative information about the specification and the technical committee may be found at the public home page of the TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ekmi ]. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked "Send A Comment" at the top of that page, or directly at http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ekmi ]. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at http://lists.oasis-open.org/archives/ekmi-comment/ . All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. The specification document and related files are available here: Editable Source: http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/SKSML-1.0-Specification.odt PDF: http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/SKSML-1.0-Specification.pdf HTML: http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/SKSML-1.0-Specification.html The schema files are available at: Schema: http://docs.oasis-open.org/ekmi/sksml/v1.0/pr02/schema/ OASIS and the EKMI TC welcome your comments. --------------------------------------------------- Mary P McRae Director, Technical Committee Administration OASIS: Advancing open standards for the information society email: mary.mcrae@oasis-open.org web: www.oasis-open.org phone: 1. 603.232.9090 [1] http://lists.oasis-open.org/archives/tc-announce/200807/msg00011.html [2] changes since last Public Review: 1) Section 3.9 - added an example of a Request for a symmetric key with an Encryption Certificate 2) Section 3.12 - added an example of a Response with a pending Request ID 3) Section 3.13 - added an example of a Request with an update of a pending Request ID 4) Section 4.4 - added definition for element 5) Section 4.5 - added definition for element 6) Section 4.6 - modified definition of to now also return a element 7) Section 4.8 - added definition for element 8) Section 4.9 - modified definition of to now also return errors related to elements 9) Section 4.30 - added definition for Use of SKMS Error Codes and Messages 10) Appendix C - added Standard Error Codes and Messages 11) Appendix D - added process definition for Vendors to apply for a reserved block of codes Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBBpELE005778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 04:51:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBBBpEC8005777; Thu, 11 Dec 2008 04:51:14 -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 robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBBp2Bq005761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 11 Dec 2008 04:51:13 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id mBBBp1pW001257; Thu, 11 Dec 2008 03:51:01 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Dec 2008 03:51:01 -0800 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_01C95B86.BC04481B" Subject: RE: New Version Notification for draft-hallambaker-ocspagility-02 Date: Thu, 11 Dec 2008 03:50:59 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFC15@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02 Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYUAbAkkKAABZs5tw== References: <20081202183941.5A3003A6B4C@core3.amsl.com> <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> <9F11911AED01D24BAA1C2355723C3D321AB5BBBECD@EA-EXMSG-C332.europe.corp.microsoft.com> From: "Hallam-Baker, Phillip" To: "Stefan Santesson" , X-OriginalArrivalTime: 11 Dec 2008 11:51:01.0435 (UTC) FILETIME=[BD2CE0B0:01C95B86] 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_01C95B86.BC04481B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On the first issue, it depends on your implementation. If two signature = algorithms are used and clients accept either then the result is to = weaken the protection. If two algorithms are required and either clients = are required to check both or there is a mechanism to disable use of a = compromised algorithm the net result is stronger. In the case of checking a cert chain and an OCSP validation chain the = second considerations apply. On the 5019 issue, happy to extend the draft, just preferred to get = something in ASAP and need to get my head around the concerns first. -----Original Message----- From: owner-ietf-pkix@mail.imc.org on behalf of Stefan Santesson Sent: Thu 12/11/2008 4:21 AM To: Hallam-Baker, Phillip; ietf-pkix@imc.org Subject: RE: New Version Notification for = draft-hallambaker-ocspagility-02=20 =20 Phil, =20 I have a few comments on the draft: =20 This is more a nit, but I don't think the following is a compelling = argument, strong enough to be mentioned: o An implementation may intentionally wish to guard against the possibility of a compromise resulting from a signature algorithm compromise by employing two separate encryption algorithms. =20 If an implementation is securing two co-dependent messages with two = different algorithms, where breaking one of them successfully = compromises the system, then you have increased your risk of compromise = rather than reducing it. =20 Further, I would like to see some explicit text, explaining that this = approach is not applicable, or at least should not be used in = combination with implementations of 5019. Section 4.2. do state that the server can pre-produce several responses = to the same request signed with different algorithms, but what I'm most = concerned with is that clients including the extension in the request, = in combination with RFC 5019 implementations may mess up http caching. = Http caching is an important aspect of achieving scalability for LW = OCSP.=20 =20 I would prefer to entirely discourage the use of this client extension = with RFC 5019, but at least discuss the issue in the draft to make = implementers aware of the problem. =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards =20 From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Hallam-Baker, Phillip Sent: den 2 december 2008 20:01 To: ietf-pkix@imc.org Subject: FW: New Version Notification for = draft-hallambaker-ocspagility-02=20 =20 =20 As promised at the meeting, here is an update to the OCSP agility draft. With the WG and chair's permission I will resubmit as a WG draft. The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented. So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC. And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it. So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM To: Hallam-Baker, Phillip Subject: New Version Notification for draft-hallambaker-ocspagility-02 A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository. Filename: draft-hallambaker-ocspagility Revision: 02 Title: OCSP Algorithm Agility Creation_date: 2008-12-02 WG ID: Independent Submission Number_of_pages: 8 Abstract: The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. = =20 The IETF Secretariat. ------_=_NextPart_001_01C95B86.BC04481B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: New Version Notification for draft-hallambaker-ocspagility-02 =

On the first issue, it depends on your implementation. = If two signature algorithms are used and clients accept either then the = result is to weaken the protection. If two algorithms are required and = either clients are required to check both or there is a mechanism to = disable use of a compromised algorithm the net result is stronger.

In the case of checking a cert chain and an OCSP validation chain the = second considerations apply.


On the 5019 issue, happy to extend the draft, just preferred to get = something in ASAP and need to get my head around the concerns first.


-----Original Message-----
From: owner-ietf-pkix@mail.imc.org on behalf of Stefan Santesson
Sent: Thu 12/11/2008 4:21 AM
To: Hallam-Baker, Phillip; ietf-pkix@imc.org
Subject: RE: New Version Notification for = draft-hallambaker-ocspagility-02

Phil,



I have a few comments on the draft:



This is more a nit, but I don't think the following is a compelling = argument, strong enough to be mentioned:

   o  An implementation may intentionally wish to guard = against the

      possibility of a compromise resulting = from a signature algorithm

      compromise by employing two separate = encryption algorithms.



If an implementation is securing two co-dependent messages with two = different algorithms, where breaking one of them successfully = compromises the system, then you have increased your risk of compromise = rather than reducing it.



Further, I would like to see some explicit text, explaining that this = approach is not applicable, or at least should not be used in = combination with implementations of 5019.

Section 4.2. do state that the server can pre-produce several responses = to the same request signed with different algorithms, but what I'm most = concerned with is that clients including the extension in the request, = in combination with RFC 5019 implementations may mess up http caching. = Http caching is an important aspect of achieving scalability for LW = OCSP.



I would prefer to entirely discourage the use of this client extension = with RFC 5019, but at least discuss the issue in the draft to make = implementers aware of the problem.





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 Hallam-Baker, Phillip
Sent: den 2 december 2008 20:01
To: ietf-pkix@imc.org
Subject: FW: New Version Notification for = draft-hallambaker-ocspagility-02





As promised at the meeting, here is an update to the OCSP agility = draft.

With the WG and chair's permission I will resubmit as a WG draft.


The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented.


So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC.

And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it.


So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in.


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for = draft-hallambaker-ocspagility-02


A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository.

Filename:        = draft-hallambaker-ocspagility
Revision:        02
Title:           OCSP = Algorithm Agility
Creation_date:   2008-12-02
WG ID:           = Independent Submission
Number_of_pages: 8

Abstract:
The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.
            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =        


The IETF Secretariat.

------_=_NextPart_001_01C95B86.BC04481B-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBAAxti001017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 03:10:59 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBBAAxqP001016; Thu, 11 Dec 2008 03:10: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 smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBBAAlNX000989 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 11 Dec 2008 03:10:58 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 11 Dec 2008 10:10:46 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 11 Dec 2008 10:10:35 +0000 From: Stefan Santesson To: "Kemp, David P." , "ietf-pkix@imc.org" Date: Thu, 11 Dec 2008 10:10:12 +0000 Subject: RE: Signing and Encrypting with the same key? Thread-Topic: Signing and Encrypting with the same key? Thread-Index: AclHM5GhiwsKjI5xQ6qgVyHzIVGcwwBiHg0QBK8KrkA= Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB5BBBF67@EA-EXMSG-C332.europe.corp.microsoft.com> References: <255B9BB34FB7D647A506DC292726F6E11140B81F89@WSMSG3153V.srv.dir.telstra.com> <51604CB892B44C39BAF60D61875EB21E@AndersPC> <491EDDDD.2080409@lockstep.com.au> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: R3V5cywNCg0KSSBqdXN0IHJlYWxpemVkIHRoYXQgd2UgYWN0dWFsbHkgbWlnaHQgaGF2ZSBldm9s dmVkIGFzIGEgY29tbXVuaXR5Lg0KDQpTb21lb25lIGFza2VkIGZvciB0aGUgdHJ1ZSBtZWFuaW5n IG9mIG5vbi1yZXB1ZGlhdGlvbi4uLi4uLiBhbmQgdGhpcyBlLW1haWwgbGlzdCBkaWRuJ3QgZXhw bG9kZS4NCg0KDQpTdGVmYW4gU2FudGVzc29uDQpTZW5pb3IgUHJvZ3JhbSBNYW5hZ2VyDQpXaW5k b3dzIFNlY3VyaXR5LCBTdGFuZGFyZHMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IG93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmcgW21haWx0bzpvd25lci1pZXRm LQ0KPiBwa2l4QG1haWwuaW1jLm9yZ10gT24gQmVoYWxmIE9mIEtlbXAsIERhdmlkIFAuDQo+IFNl bnQ6IGRlbiAxNyBub3ZlbWJlciAyMDA4IDE1OjA3DQo+IFRvOiBpZXRmLXBraXhAaW1jLm9yZw0K PiBTdWJqZWN0OiBSRTogU2lnbmluZyBhbmQgRW5jcnlwdGluZyB3aXRoIHRoZSBzYW1lIGtleT8N Cj4NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBTdGVwaGVu IFdpbHNvbg0KPiA+DQo+ID4gSSdkIGxpa2UgdG8ga25vdyB0aGUgcHJlY2lzZQ0KPiA+IGhpc3Rv cnkgb2YgdGhlIE5SIGJpdCBpbiBYLjUwOS4gIFdobyBhY3R1YWxseSB0aG91Z2h0IG9mIGl0LCB3 ZXJlDQo+IHRoZXkNCj4gPiBhbiBlbmdpbmVlciBvciBhIGxhd3llciwgYW5kIHdoYXQgaWYgYW55 IGRlYmF0ZSB3ZW50IG9uIGF0IHRoZSB0aW1lPw0KPg0KPiBUcnVzdCBtZSwgeW91IHJlYWxseSwg UkVBTExZIGRvbid0IHdhbnQgdG8ga25vdyA6LSkuDQo+DQo+IFRob3NlIG9uIG9uZSBzaWRlIG9m IHRoZSBhcmd1bWVudCB0aG91Z2h0IHRoYXQgdGhlIE5SIGJpdCBzZXQgc2hvdWxkIGJlDQo+IHVz ZWQgZm9yIHNpZ25hdHVyZXMgdGhhdCBjb3VsZCBiZSB2YWxpZGF0ZWQgaW5kZWZpbml0ZWx5IChp LmUuIGZvciB3aGF0DQo+IG9uZSBub3JtYWxseSB0aGlua3Mgb2YgYXMgInNpZ25pbmciKSwgYW5k IHNpZ25hdHVyZXMgd2l0aCB0aGUgTlIgYml0DQo+IGNsZWFyIGNvdWxkIGJlIHVzZWQgb25seSBm b3Igc2Vzc2lvbiBhdXRoZW50aWNhdGlvbi4gIFRoYXQgd2F5IGEgc2lnbmVkDQo+IG9iamVjdCBj cmVhdGVkIGFzIHBhcnQgb2YgYSBsb2dpbiBzZXNzaW9uIGNvdWxkIG5vdCBiZSBtaXNyZXByZXNl bnRlZA0KPiBhcyBhIHNpZ25lZCBkb2N1bWVudC4NCj4NCj4gVGhvc2Ugb24gdGhlIG90aGVyIHNp ZGUgdGhvdWdodCB0aGF0IHRoZSBOUiBiaXQgYWN0dWFsbHkgaGFkIHNvbWV0aGluZw0KPiB0byBk byB3aXRoICJyZXB1ZGlhdGluZyIgc2lnbmF0dXJlcywgd2hpY2ggSU1ITyBpcyBhIHJpZGljdWxv dXMgaWRlYQ0KPiBmb3IgdGhlIHJlYXNvbnMgeW91IHN1Z2dlc3QuICBUaG9zZSB3aG8gYmVsaWV2 ZSBpbiB0aGUgY3VycmVudCBYLjUwOQ0KPiBpbnRlcnByZXRhdGlvbiBtYXkgZGVmZW5kIGl0IGlm IHRoZXkgd2lzaCwgb3Igc3BhcmUgdXMgdGhlIGRpc2N1c3Npb24uDQo+DQo+IERhdmUNCg== Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBB9MEBn097238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 02:22:14 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBB9MEFo097237; Thu, 11 Dec 2008 02:22:14 -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-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBB9M2QQ097213 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 11 Dec 2008 02:22:13 -0700 (MST) (envelope-from stefans@microsoft.com) Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 11 Dec 2008 09:22:01 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([169.254.1.53]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 11 Dec 2008 09:22:01 +0000 From: Stefan Santesson To: "Hallam-Baker, Phillip" , "ietf-pkix@imc.org" Date: Thu, 11 Dec 2008 09:21:37 +0000 Subject: RE: New Version Notification for draft-hallambaker-ocspagility-02 Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02 Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYUAbAkkKA= Message-ID: <9F11911AED01D24BAA1C2355723C3D321AB5BBBECD@EA-EXMSG-C332.europe.corp.microsoft.com> References: <20081202183941.5A3003A6B4C@core3.amsl.com> <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9F11911AED01D24BAA1C2355723C3D321AB5BBBECDEAEXMSGC332eu_" MIME-Version: 1.0 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_9F11911AED01D24BAA1C2355723C3D321AB5BBBECDEAEXMSGC332eu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, I have a few comments on the draft: This is more a nit, but I don't think the following is a compelling argumen= t, strong enough to be mentioned: o An implementation may intentionally wish to guard against the possibility of a compromise resulting from a signature algorithm compromise by employing two separate encryption algorithms. If an implementation is securing two co-dependent messages with two differe= nt algorithms, where breaking one of them successfully compromises the syst= em, then you have increased your risk of compromise rather than reducing it= . Further, I would like to see some explicit text, explaining that this appro= ach is not applicable, or at least should not be used in combination with i= mplementations of 5019. Section 4.2. do state that the server can pre-produce several responses to = the same request signed with different algorithms, but what I'm most concer= ned with is that clients including the extension in the request, in combina= tion with RFC 5019 implementations may mess up http caching. Http caching i= s an important aspect of achieving scalability for LW OCSP. I would prefer to entirely discourage the use of this client extension with= RFC 5019, but at least discuss the issue in the draft to make implementers= aware of the problem. 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 Hallam-Baker, Phillip Sent: den 2 december 2008 20:01 To: ietf-pkix@imc.org Subject: FW: New Version Notification for draft-hallambaker-ocspagility-02 As promised at the meeting, here is an update to the OCSP agility draft. With the WG and chair's permission I will resubmit as a WG draft. The basic history here is that we tried to deploy an OCSP resolver that mee= ts a pretty simple set of requirements for multiple algorithm support and f= ound that the base specification does not actually say anything about how a= response signature algorithm should be chosen, except that SHA-1 can be im= plemented. So a perfectly legal OCSP responder could report the status of a public key= certificate for an RSA signature key, signed with an RSA signature key wit= h ECC. And it gets worse, if you have an ocsp responder that is managing certs sig= ned with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, etc. e= tc.) and a status request comes in for an unknown cert, there is no data fo= r the responder to choose a reasonble response alg. You are forced to choos= e a lowest common denominator alg which is a problem if you moved to ECC be= cause RSA 4096 does not cut it. So this is a pretty simple fix to sort it out. I suggest that this goes on = standards track and if we progress OCSP from PROPOSED to DRAFT we dump the = explanatory part and merge the normative text in. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM To: Hallam-Baker, Phillip Subject: New Version Notification for draft-hallambaker-ocspagility-02 A new version of I-D, draft-hallambaker-ocspagility-02.txt has been success= fuly submitted by Phillip Hallam-Baker and posted to the IETF repository. Filename: draft-hallambaker-ocspagility Revision: 02 Title: OCSP Algorithm Agility Creation_date: 2008-12-02 WG ID: Independent Submission Number_of_pages: 8 Abstract: The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. The IETF Secretariat. --_000_9F11911AED01D24BAA1C2355723C3D321AB5BBBECDEAEXMSGC332eu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: New Version Notification for draft-hallambaker-ocspagility-02 </= title> <style> <!-- /* Font Definitions */ @font-face {font-family:Wingdings; panose-1:5 0 0 0 0 0 0 0 0 0;} @font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:"\@SimSun"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0cm; mso-margin-bottom-alt:auto; margin-left:0cm; font-size:12.0pt; font-family:"Times New Roman","serif";} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Courier New";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0cm; margin-right:0cm; margin-bottom:0cm; margin-left:36.0pt; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Courier New";} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page Section1 {size:612.0pt 792.0pt; margin:70.85pt 70.85pt 70.85pt 70.85pt;} div.Section1 {page:Section1;} /* List Definitions */ @list l0 {mso-list-id:690883177; mso-list-type:hybrid; mso-list-template-ids:902045572 69009409 69009411 69009413 69009409 690094= 11 69009413 69009409 69009411 69009413;} @list l0:level1 {mso-level-number-format:bullet; mso-level-text:\F0B7; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:38.25pt; text-indent:-18.0pt; font-family:Symbol;} ol {margin-bottom:0cm;} ul {margin-bottom:0cm;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DSV link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US style= =3D'font-size: 11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Phil,<o:p></o:p></= span></a></p> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif"; color:#1F497D'>I have a few comments on the draft:<o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif"; color:#1F497D'>This is more a nit, but I don’t think the following is= a compelling argument, strong enough to be mentioned:<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN style=3D'font-family:"Courier New"'>   o  An implementation = may intentionally wish to guard against the<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN style=3D'font-family:"Courier New"'>      possibil= ity of a compromise resulting from a signature algorithm<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN style=3D'font-family:"Courier New"'>      compromi= se by employing two separate encryption algorithms.<o:p></o:p></span></p> <p class=3DMsoNormal style=3D'page-break-before:always'><span lang=3DEN style=3D'font-family:"Courier New"'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'>If an implementation is securing two co-dependent messages w= ith two different algorithms, where breaking one of them successfully compromis= es the system, then you have increased your risk of compromise rather than reducing it.<o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'>Further, I would like to see some explicit text, explaining = that this approach is not applicable, or at least should not be used in combinat= ion with implementations of 5019.<o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'>Section 4.2. do state that the server can pre-produce severa= l responses to the same request signed with different algorithms, but what I&= #8217;m most concerned with is that clients including the extension in the request,= in combination with RFC 5019 implementations may mess up http caching. Http caching is an important aspect of achieving scalability for LW OCSP. <o:p><= /o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'>I would prefer to entirely discourage the use of this client= extension with RFC 5019, but at least discuss the issue in the draft to make implemen= ters aware of the problem.<o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <p class=3DMsoNormal><span lang=3DEN style=3D'font-size:11.0pt;font-family:= "Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f= amily: "Arial","sans-serif";color:maroon'>Stefan Santesson</span></b><span lang=3D= EN-GB style=3D'color:#1F497D'><o:p></o:p></span></p> <p class=3DMsoNormal><span lang=3DEN-GB style=3D'font-size:10.0pt;font-fami= ly:"Arial","sans-serif"; color:#400040'>Senior Program Manager</span><span lang=3DEN-GB style=3D'col= or:navy'><o:p></o:p></span></p> <p class=3DMsoNormal><b><span lang=3DEN-GB style=3D'font-size:10.0pt;font-f= amily: "Arial","sans-serif";color:#400040'>Windows Security, Standards</span></b><= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p></o:p></span></p> </div> <p class=3DMsoNormal><span lang=3DEN-US style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm = 4.0pt'> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm'> <p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f= amily: "Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz= e:10.0pt; font-family:"Tahoma","sans-serif"'> owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] <b>On Behalf Of </b>Hallam-Baker, Phi= llip<br> <b>Sent:</b> den 2 december 2008 20:01<br> <b>To:</b> ietf-pkix@imc.org<br> <b>Subject:</b> FW: New Version Notification for draft-hallambaker-ocspagility-02 <o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <p class=3DMsoNormal><o:p> </o:p></p> <p style=3D'margin-bottom:12.0pt'><span style=3D'font-size:10.0pt'>As promi= sed at the meeting, here is an update to the OCSP agility draft.<br> <br> With the WG and chair's permission I will resubmit as a WG draft.<br> <br> <br> The basic history here is that we tried to deploy an OCSP resolver that mee= ts a pretty simple set of requirements for multiple algorithm support and found = that the base specification does not actually say anything about how a response signature algorithm should be chosen, except that SHA-1 can be implemented.= <br> <br> <br> So a perfectly legal OCSP responder could report the status of a public key certificate for an RSA signature key, signed with an RSA signature key with= ECC.<br> <br> And it gets worse, if you have an ocsp responder that is managing certs sig= ned with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, etc. etc.)= and a status request comes in for an unknown cert, there is no data for the responder to choose a reasonble response alg. You are forced to choose a lo= west common denominator alg which is a problem if you moved to ECC because RSA 4= 096 does not cut it.<br> <br> <br> So this is a pretty simple fix to sort it out. I suggest that this goes on standards track and if we progress OCSP from PROPOSED to DRAFT we dump the explanatory part and merge the normative text in.<br> <br> <br> -----Original Message-----<br> From: IETF I-D Submission Tool [<a href=3D"mailto:idsubmission@ietf.org">ma= ilto:idsubmission@ietf.org</a>]<br> Sent: Tue 12/2/2008 1:39 PM<br> To: Hallam-Baker, Phillip<br> Subject: New Version Notification for draft-hallambaker-ocspagility-02<br> <br> <br> A new version of I-D, draft-hallambaker-ocspagility-02.txt has been success= fuly submitted by Phillip Hallam-Baker and posted to the IETF repository.<br> <br> Filename:        draft-hallambaker-ocspagility<br> Revision:        02<br> Title:           OCSP Algorith= m Agility<br> Creation_date:   2008-12-02<br> WG ID:           Independent Submission<br> Number_of_pages: 8<br> <br> Abstract:<br> The OSCP specification defined in RFC 2560 requires server responses<br> to be signed but does not specify a mechanism for selecting the<br> signature algorithm to be used leading to possible interoperability<br> failures in contexts where multiple signature algorithms are in use.<br> This document specifies an algorithm for server signature algorithm<br> selection and an extension that allows a client to advise a server<br> that specific signature algorithms are supported.<br>             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       <br> <br> <br> The IETF Secretariat.<br> <br> <br> <br> <br> <br> </span><o:p></o:p></p> </div> </div> </body> </html> --_000_9F11911AED01D24BAA1C2355723C3D321AB5BBBECDEAEXMSGC332eu_-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBACsh4k030003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Dec 2008 05:54:44 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mBACshSo030002; Wed, 10 Dec 2008 05:54:43 -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 mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mBACsW73029992 for <ietf-pkix@imc.org>; Wed, 10 Dec 2008 05:54:43 -0700 (MST) (envelope-from kent@bbn.com) Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.173.171]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1LAOaF-000750-Fc for ietf-pkix@imc.org; Wed, 10 Dec 2008 07:54:32 -0500 Mime-Version: 1.0 Message-Id: <p06240803c5656bd359f2@[198.18.173.171]> Date: Wed, 10 Dec 2008 07:52:22 -0500 To: ietf-pkix@imc.org From: Stephen Kent <kent@bbn.com> Subject: minutes posted Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> I have received comments from 2 sources, and made the requested changes. Since over two weeks have elapsed, I am posting final meeting minutes. Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8MOXVL005036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 15:24:33 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB8MOX0k005035; Mon, 8 Dec 2008 15:24: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 mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8MOLGd005027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Mon, 8 Dec 2008 15:24:32 -0700 (MST) (envelope-from Massimiliano.Pala@Dartmouth.edu) Received: from newblitzen.Dartmouth.EDU (newblitzen.dartmouth.edu [129.170.208.36]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id mB8MC1pr019217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-pkix@imc.org>; Mon, 8 Dec 2008 17:24:11 -0500 X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system. Received: from dhcp-212-179.cs.dartmouth.edu [129.170.212.179] by newblitzen.Dartmouth.EDU (Mac) via SMTP for ietf-pkix@imc.org id <138037849>; 08 Dec 2008 17:24:10 -0500 Message-ID: <493D9E8A.7090908@Dartmouth.edu> Date: Mon, 08 Dec 2008 17:24:10 -0500 From: Massimiliano Pala <Massimiliano.Pala@Dartmouth.EDU> Organization: Dartmouth College - Computer Science Department User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: I-D Action:draft-ietf-pkix-prqp-02.txt References: <20081208213001.3A2713A6823@core3.amsl.com> In-Reply-To: <20081208213001.3A2713A6823@core3.amsl.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090101050805030202040209" X-MailScanner: Found to be clean by mailhub.Dartmouth.EDU X-MailScanner-From: massimiliano.pala@dartmouth.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a cryptographically signed message in MIME format. --------------ms090101050805030202040209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I just published the new version of the draft. The main difference is the DHCP section where we now have the definition for DHCPv4 *and* DHCPv6 options. I am waiting on the input from the DHC WG. Please let me know if any of you have further comments on this version of the I-D. Cheers, Max Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. [...] > Title : PKI Resource Query Protocol (PRQP) > Author(s) : M. Pala > Filename : draft-ietf-pkix-prqp-02.txt > Pages : 35 > Date : 2008-12-08 > > One of the most strategic problems still open in PKIX is locating > public data and services associated with a Certification Authority > (CA). This issue impacts interoperability and usability in PKIX. > > This draft describes the PKI Resource Query Protocol (PRQP), its > design, definition, and its impact in already deployed PKIX > protocols. --------------ms090101050805030202040209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJIjCC BI0wggN1oAMCAQICAhpTMA0GCSqGSIb3DQEBBQUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx GTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0 bW91dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMTAeFw0wNTExMDgy MDMzMDZaFw0wOTExMDkyMDMzMDZaMIHBMRMwEQYKCZImiZPyLGQBGRYDZWR1MRkwFwYKCZIm iZPyLGQBGRYJZGFydG1vdXRoMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRRGFydG1vdXRoIENv bGxlZ2UxGjAYBgoJkiaJk/IsZAEBEwoxMjI1NjAyOTQ3MRowGAYDVQQDExFNYXNzaW1pbGlh bm8gUGFsYTEuMCwGCSqGSIb3DQEJARYfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVk dTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsv8obBpbhPixgdyIJj7UN0GYRNhsgWHB muCE5j8v8IvCSJWRF9spKoR0NBYgOfJu8DwQuKTIgrvbp0EC3ikrneotL4KTGD1IqWz/bSXL UR/bZAsc0r9PrvCUsZOi7wbijy784gOuqQUCJ2fJwKwk5SJ3RBaPnUROQXTp+LPSK8MCAwEA AaOCAVowggFWMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwgaIGA1UdIASB mjCBlzCBlAYKKwYBBAFBAgEBATCBhTA9BggrBgEFBQcCAjAxMBgWEURhcnRtb3V0aCBDb2xs ZWdlMAMCAQEaFURhcnRtb3V0aCBDb2xsZWdlIENQUzBEBggrBgEFBQcCARY4aHR0cDovL3d3 dy5kYXJ0bW91dGguZWR1L35wa2lsYWIvRGFydG1vdXRoQ1BTXzRTZXAwMy5wZGYwKgYDVR0R BCMwIYEfTWFzc2ltaWxpYW5vLlBhbGFARGFydG1vdXRoLmVkdTAfBgNVHSMEGDAWgBQ/wNbH p08Afu8GmWdsvJYeTaN3EjA/BggrBgEFBQcBAQQzMDEwLwYIKwYBBQUHMAGGI2h0dHA6Ly9j b2xsZWdlY2EuZGFydG1vdXRoLmVkdS9vY3NwMA0GCSqGSIb3DQEBBQUAA4IBAQDEYIWmG3Ht wcgFiBbrYKp7YpI62hgAw9I3Dj9Ai+etQcMDZL8cWg3Kd7DwYHDkLxO7jl518HIJCk8Elk+Z 3Y2c0rR+c9WLuxE+EHEUmQg2AbgxzRGZAeMXj7jrv5w75IWiXBrW3SdDkjVH6MQFZVP1CBk7 PF3/+dzmiO6E5g4cVtphPSdK2qtnX7Sh0zdePzeE+e0BTnsWdN0yHgKabKx3dCiEnQXt96sA Jf5ckg7fFLcplohwWlWJCpk8WwnJM0QGw3xbrZvLk+kIQgyh0sn2va4FgA1ae29cJ1d2NurA Z+LMdei9/ZbzBeMoD9XPSYyj7zLuVXGLF/JQQoPywk5oMIIEjTCCA3WgAwIBAgICGlMwDQYJ KoZIhvcNAQEFBQAwdzETMBEGCgmSJomT8ixkARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRh cnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYD VQQDExNEYXJ0bW91dGggQ2VydEF1dGgxMB4XDTA1MTEwODIwMzMwNloXDTA5MTEwOTIwMzMw NlowgcExEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJk/IsZAEZFglkYXJ0bW91dGgx CzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29sbGVnZTEaMBgGCgmSJomT8ixk AQETCjEyMjU2MDI5NDcxGjAYBgNVBAMTEU1hc3NpbWlsaWFubyBQYWxhMS4wLAYJKoZIhvcN AQkBFh9NYXNzaW1pbGlhbm8uUGFsYUBEYXJ0bW91dGguZWR1MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQCy/yhsGluE+LGB3IgmPtQ3QZhE2GyBYcGa4ITmPy/wi8JIlZEX2ykqhHQ0 FiA58m7wPBC4pMiCu9unQQLeKSud6i0vgpMYPUipbP9tJctRH9tkCxzSv0+u8JSxk6LvBuKP LvziA66pBQInZ8nArCTlIndEFo+dRE5BdOn4s9IrwwIDAQABo4IBWjCCAVYwDgYDVR0PAQH/ BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIFoDCBogYDVR0gBIGaMIGXMIGUBgorBgEEAUECAQEB MIGFMD0GCCsGAQUFBwICMDEwGBYRRGFydG1vdXRoIENvbGxlZ2UwAwIBARoVRGFydG1vdXRo IENvbGxlZ2UgQ1BTMEQGCCsGAQUFBwIBFjhodHRwOi8vd3d3LmRhcnRtb3V0aC5lZHUvfnBr aWxhYi9EYXJ0bW91dGhDUFNfNFNlcDAzLnBkZjAqBgNVHREEIzAhgR9NYXNzaW1pbGlhbm8u UGFsYUBEYXJ0bW91dGguZWR1MB8GA1UdIwQYMBaAFD/A1senTwB+7waZZ2y8lh5No3cSMD8G CCsGAQUFBwEBBDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NvbGxlZ2VjYS5kYXJ0bW91dGgu ZWR1L29jc3AwDQYJKoZIhvcNAQEFBQADggEBAMRghaYbce3ByAWIFutgqntikjraGADD0jcO P0CL561BwwNkvxxaDcp3sPBgcOQvE7uOXnXwcgkKTwSWT5ndjZzStH5z1Yu7ET4QcRSZCDYB uDHNEZkB4xePuOu/nDvkhaJcGtbdJ0OSNUfoxAVlU/UIGTs8Xf/53OaI7oTmDhxW2mE9J0ra q2dftKHTN14/N4T57QFOexZ03TIeAppsrHd0KISdBe33qwAl/lySDt8UtymWiHBaVYkKmTxb CckzRAbDfFutm8uT6QhCDKHSyfa9rgWADVp7b1wnV3Y26sBn4sx16L39lvMF4ygP1c9JjKPv Mu5VcYsX8lBCg/LCTmgxggL4MIIC9AIBATB9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAX BgoJkiaJk/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91 dGggQ29sbGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwCQYFKw4DAhoF AKCCAdEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMjA4 MjIyNDEwWjAjBgkqhkiG9w0BCQQxFgQUNkVBxqV40yWlfZR25U3Kidyj3AowUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQBDF/MH0wdzETMBEGCgmSJomT8ixk ARkWA2VkdTEZMBcGCgmSJomT8ixkARkWCWRhcnRtb3V0aDELMAkGA1UEBhMCVVMxGjAYBgNV BAoTEURhcnRtb3V0aCBDb2xsZWdlMRwwGgYDVQQDExNEYXJ0bW91dGggQ2VydEF1dGgxAgIa UzCBjgYLKoZIhvcNAQkQAgsxf6B9MHcxEzARBgoJkiaJk/IsZAEZFgNlZHUxGTAXBgoJkiaJ k/IsZAEZFglkYXJ0bW91dGgxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFEYXJ0bW91dGggQ29s bGVnZTEcMBoGA1UEAxMTRGFydG1vdXRoIENlcnRBdXRoMQICGlMwDQYJKoZIhvcNAQEBBQAE gYALii0fWUQB48vnJh4FHbpYlUbJwaOl45jT2pce4rucCziMVNdx7Mxmwnw3EWoFzk/M4jyN ABYGdobQ3x5opC60CKWX9l43NVj5cuPbqAc67Q6OISOpN4tHnXEYyglg9dp9jdCauE591Q6R n9+H6KeuG2pXNlRPGhabf1JS+KYWmgAAAAAAAA== --------------ms090101050805030202040209-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8LTux6002072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 14:29:56 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB8LTuaN002071; Mon, 8 Dec 2008 14:29: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.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB8LTuCg002064 for <ietf-pkix@imc.org>; Mon, 8 Dec 2008 14:29:56 -0700 (MST) (envelope-from root@core3.amsl.com) Received: by core3.amsl.com (Postfix, from userid 0) id 3A2713A6823; Mon, 8 Dec 2008 13:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org Subject: I-D Action:draft-ietf-pkix-prqp-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081208213001.3A2713A6823@core3.amsl.com> Date: Mon, 8 Dec 2008 13:30:01 -0800 (PST) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : PKI Resource Query Protocol (PRQP) Author(s) : M. Pala Filename : draft-ietf-pkix-prqp-02.txt Pages : 35 Date : 2008-12-08 One of the most strategic problems still open in PKIX is locating public data and services associated with a Certification Authority (CA). This issue impacts interoperability and usability in PKIX. This draft describes the PKI Resource Query Protocol (PRQP), its design, definition, and its impact in already deployed PKIX protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-prqp-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pkix-prqp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-08132200.I-D@ietf.org> --NextPart-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB3F079A067746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2008 08:00:07 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB3F07W1067745; Wed, 3 Dec 2008 08:00:07 -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 colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB3ExtLa067684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ietf-pkix@imc.org>; Wed, 3 Dec 2008 08:00:06 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mB3EcgxD021587; Wed, 3 Dec 2008 06:38:55 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Dec 2008 06:59:46 -0800 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_01C95557.C80AEC9A" Subject: RE: OCSP Responder Status Date: Wed, 3 Dec 2008 06:59:46 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFBE1@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OCSP Responder Status Thread-Index: AclPKVyaoEzDsqQFQU2YNjZS85ShHgGLJezN References: <052601c94e56$60120f00$c700a8c0@certintra.com.br> <492C01DC.9080508@secunet.com> <BBE6D91086994FFD98961A6911B831BC@ASCUK001> <492C3342.4050501@mitre.org> From: "Hallam-Baker, Phillip" <pbaker@verisign.com> To: "Timothy J. Miller" <tmiller@mitre.org>, "Liaquat Khan" <liaquat.khan@ascertia.com> Cc: "Johannes Merkle" <johannes.merkle@secunet.com>, "Mauricio Balassiano" <mbalassiano@certisign.com.br>, <ietf-pkix@imc.org> X-OriginalArrivalTime: 03 Dec 2008 14:59:46.0856 (UTC) FILETIME=[C858FA80:01C95557] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/> List-ID: <ietf-pkix.imc.org> List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe> This is a multi-part message in MIME format. ------_=_NextPart_001_01C95557.C80AEC9A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The trusted responder model makes no sense to me unless you are = delegating the complete trust decision to an external resource as in = SCVP. Which is of course why some of us suggested SCVP be an OCSP = extension. =20 If we were going to do anything more in this area (and I don't think we = should), we should implement the only trusted responder delegation that = makes any sense to me at all and that is where the trusted responder is = responsible for verifying the key in its entirety. =20 If you are doing delegated trust with a PKI capable endpoint device the = computational task of path math is a diminishing concer. The problem of = management of the trusted certificate base and security policy is the = bigger and increasing part of the problem. =20 So if we were to address this point I would suggest doing it through a = profile on SCVP, and SCVP-Lite profile, in which the client provides no = input into the request other than describing what it wants to DO. That = means no talk of trust roots and paths and such. Just 'X wants to do Y = with Z, give me the key and the algorithm context to use' =20 =20 In other words, SCVP-Lite is XKMS but fixing the mistake we made by = making XKMS specific to public key.=20 =20 If XKMS could deliver either a symmetric key OR a public key, then you = can have a mode of communication where the XKMS server is also operating = as a kerberos key server.=20 =20 Now that I am interested in devices that cannot support ethernet, cannot = support IP and certainly cannot support public key (no not even ECC = variants), I am starting to see interesting advantages you can achieve = by using a blend of symmetric and public key techniques rather than the = traditional approach of letting PKI do al the glamorous trusty stuff and = then confining symmetric key to just a bunch of session key stuff. =20 =20 ________________________________ From: owner-ietf-pkix@mail.imc.org on behalf of Timothy J. Miller Sent: Tue 11/25/2008 12:17 PM To: Liaquat Khan Cc: 'Johannes Merkle'; 'Mauricio Balassiano'; ietf-pkix@imc.org Subject: Re: OCSP Responder Status Liaquat Khan wrote: > The problem with your option 3 is that RFC2560 doesn't explain how a = client > can check that the second responder is acting on behalf of the first = CA. > I.e. it may chain to a trust anchor, allowing you to verify the = signature on > the OCSP response, but how do you know that the original CA actually > authorised this second responder to provide status information on the = first > responder's certificate? That's what client configuration control is for. :) That's the whole point of the trusted responder model--trust in that responder is established out-of-band (i.e., not part of the OCSP protocol). > If you are happy to live without this check then this can work, = however I > have not really seen this method actual used (probably because it = introduces > more complexity than the benefit it offers).=20 The DoD OCSP service uses the trusted responder model. It's a real PITA to manage; you have to make sure all the RPs are properly configured. Key changing under this model is even worse; the hoops we had to jump through were seriously sick. We're now migrating to the CA designated model. The CA-issued OCSP signing certs will be short-lived certs with longer-lived keys (IIRC, 30 day cert life with renewal allowed for some period of time). -- Tim ------_=_NextPart_001_01C95557.C80AEC9A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML dir=3Dltr><HEAD><TITLE>Re: OCSP Responder Status=0A= =0A= =0A= =0A=
=0A=
The trusted = responder model makes no sense to me unless you are delegating the = complete trust decision to an external resource as in SCVP. Which is of = course why some of us suggested SCVP be an OCSP extension.
=0A=
 
=0A=
If we were going to do = anything more in this area (and I don't think we should), we should = implement the only trusted responder delegation that makes any sense to = me at all and that is where the trusted responder is responsible for = verifying the key in its entirety.
=0A=
 
=0A=
If you are doing delegated = trust with a PKI capable endpoint device the computational task of path = math is a diminishing concer. The problem of management of the trusted = certificate base and security policy is the bigger and increasing part = of the problem.
=0A=
 
=0A=
So if we were to address this = point I would suggest doing it through a profile on SCVP, and SCVP-Lite = profile, in which the client provides no input into the request other = than describing what it wants to DO. That means no talk of trust roots = and paths and such. Just 'X wants to do Y with Z, give me the key and = the algorithm context to use'
=0A=
 
=0A=
 
=0A=
In other words, SCVP-Lite is = XKMS but fixing the mistake we made by making XKMS specific to public = key.
=0A=
 
=0A=
If XKMS could deliver either = a symmetric key OR a public key, then you can have a mode of = communication where the XKMS server is also operating as a kerberos key = server.
=0A=
 
=0A=
Now that I am interested in = devices that cannot support ethernet, cannot support IP and certainly = cannot support public key (no not even ECC variants), I am starting to = see interesting advantages you can achieve by using a blend of symmetric = and public key techniques rather than the traditional approach of = letting PKI do al the glamorous trusty stuff and then confining = symmetric key to just a bunch of session key stuff.
=0A=
 
=0A=
 
=0A=

=0A=
=0A= From: owner-ietf-pkix@mail.imc.org = on behalf of Timothy J. Miller
Sent: Tue 11/25/2008 12:17 = PM
To: Liaquat Khan
Cc: 'Johannes Merkle'; 'Mauricio = Balassiano'; ietf-pkix@imc.org
Subject: Re: OCSP Responder = Status

=0A=
=0A=

Liaquat Khan wrote:
> The problem with your = option 3 is that RFC2560 doesn't explain how a client
> can check = that the second responder is acting on behalf of the first CA.
> = I.e. it may chain to a trust anchor, allowing you to verify the = signature on
> the OCSP response, but how do you know that the = original CA actually
> authorised this second responder to provide = status information on the first
> responder's = certificate?

That's what client configuration control is = for.  :)  That's the whole
point of the trusted responder = model--trust in that responder is
established out-of-band (i.e., not = part of the OCSP protocol).

> If you are happy to live without = this check then this can work, however I
> have not really seen = this method actual used (probably because it introduces
> more = complexity than the benefit it offers). 

The DoD OCSP = service uses the trusted responder model.  It's a real PITA
to = manage; you have to make sure all the RPs are properly = configured.
Key changing under this model is even worse; the hoops we = had to jump
through were seriously sick.

We're now migrating = to the CA designated model.  The CA-issued OCSP
signing certs = will be short-lived certs with longer-lived keys (IIRC, 30
day cert = life with renewal allowed for some period of time).

-- = Tim

------_=_NextPart_001_01C95557.C80AEC9A-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB33Qfcq031238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 20:26:41 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB33Qfbj031237; Tue, 2 Dec 2008 20:26: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 mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB33QTbu031226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Dec 2008 20:26:40 -0700 (MST) (envelope-from mmyers@fastq.com) Received: from [192.168.1.102] (dslstat-77-ppp-125.fastq.com [65.39.77.125] (may be forged)) by mailout.fastq.com (8.13.8/8.13.8-FASTQ.10210800) with ESMTP id mB33T2Hj010327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Dec 2008 20:29:03 -0700 Cc: Message-Id: From: Michael Myers To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> Content-Type: multipart/alternative; boundary=Apple-Mail-4-859484553 Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: New Version Notification for draft-hallambaker-ocspagility-02 Date: Tue, 2 Dec 2008 20:26:27 -0700 References: <20081202183941.5A3003A6B4C@core3.amsl.com> <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.912) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Apple-Mail-4-859484553 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Phil, I will give it a read and comment accordingly. Mike On Dec 2, 2008, at 12:01 PM, Hallam-Baker, Phillip wrote: > > As promised at the meeting, here is an update to the OCSP agility > draft. > > With the WG and chair's permission I will resubmit as a WG draft. > > > The basic history here is that we tried to deploy an OCSP resolver > that meets a pretty simple set of requirements for multiple > algorithm support and found that the base specification does not > actually say anything about how a response signature algorithm > should be chosen, except that SHA-1 can be implemented. > > > So a perfectly legal OCSP responder could report the status of a > public key certificate for an RSA signature key, signed with an RSA > signature key with ECC. > > And it gets worse, if you have an ocsp responder that is managing > certs signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA- > ECC, DSA, etc. etc.) and a status request comes in for an unknown > cert, there is no data for the responder to choose a reasonble > response alg. You are forced to choose a lowest common denominator > alg which is a problem if you moved to ECC because RSA 4096 does not > cut it. > > > So this is a pretty simple fix to sort it out. I suggest that this > goes on standards track and if we progress OCSP from PROPOSED to > DRAFT we dump the explanatory part and merge the normative text in. > --Apple-Mail-4-859484553 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
Phil,

I will give it a read and = comment accordingly.

Mike


On Dec 2, 2008, = at 12:01 PM, Hallam-Baker, Phillip wrote:

=

As = promised at the meeting, here is an update to the OCSP agility = draft.

With the WG and chair's permission I will resubmit as a = WG draft.


The basic history here is that we tried to = deploy an OCSP resolver that meets a pretty simple set of requirements = for multiple algorithm support and found that the base specification = does not actually say anything about how a response signature algorithm = should be chosen, except that SHA-1 can be implemented.


So = a perfectly legal OCSP responder could report the status of a public key = certificate for an RSA signature key, signed with an RSA signature key = with ECC.

And it gets worse, if you have an ocsp responder that = is managing certs signed with umpteen different algs (RSA-SHA1, = RSA-SHA256, RSA-ECC, DSA, etc. etc.) and a status request comes in for = an unknown cert, there is no data for the responder to choose a = reasonble response alg. You are forced to choose a lowest common = denominator alg which is a problem if you moved to ECC because RSA 4096 = does not cut it.


So this is a pretty simple fix to sort it = out. I suggest that this goes on standards track and if we progress OCSP = from PROPOSED to DRAFT we dump the explanatory part and merge the = normative text in.

=

= --Apple-Mail-4-859484553-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2J1ZgE002491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 12:01:35 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mB2J1Zhr002490; Tue, 2 Dec 2008 12:01:35 -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 colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mB2J1Ohh002466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 Dec 2008 12:01:34 -0700 (MST) (envelope-from pbaker@verisign.com) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mB2IeXUW018946 for ; Tue, 2 Dec 2008 10:40:33 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 11:01:23 -0800 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_01C954B0.5E07FC46" Subject: FW: New Version Notification for draft-hallambaker-ocspagility-02 Date: Tue, 2 Dec 2008 11:01:22 -0800 Message-ID: <2788466ED3E31C418E9ACC5C316615572FFBD3@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-hallambaker-ocspagility-02 Thread-Index: AclUrVTMVGC0OUj3RuOSZcazd8skDgAAWWYU References: <20081202183941.5A3003A6B4C@core3.amsl.com> From: "Hallam-Baker, Phillip" To: X-OriginalArrivalTime: 02 Dec 2008 19:01:23.0247 (UTC) FILETIME=[5E74F3F0:01C954B0] 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_01C954B0.5E07FC46 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As promised at the meeting, here is an update to the OCSP agility draft. With the WG and chair's permission I will resubmit as a WG draft. The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented. So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC.=20 And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it. So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM To: Hallam-Baker, Phillip Subject: New Version Notification for draft-hallambaker-ocspagility-02=20 =20 A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository. Filename: draft-hallambaker-ocspagility Revision: 02 Title: OCSP Algorithm Agility Creation_date: 2008-12-02 WG ID: Independent Submission Number_of_pages: 8 Abstract: The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. = =20 The IETF Secretariat. ------_=_NextPart_001_01C954B0.5E07FC46 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: New Version Notification for draft-hallambaker-ocspagility-02 =

As promised at the meeting, here is an update to the = OCSP agility draft.

With the WG and chair's permission I will resubmit as a WG draft.


The basic history here is that we tried to deploy an OCSP resolver that = meets a pretty simple set of requirements for multiple algorithm support = and found that the base specification does not actually say anything = about how a response signature algorithm should be chosen, except that = SHA-1 can be implemented.


So a perfectly legal OCSP responder could report the status of a public = key certificate for an RSA signature key, signed with an RSA signature = key with ECC.

And it gets worse, if you have an ocsp responder that is managing certs = signed with umpteen different algs (RSA-SHA1, RSA-SHA256, RSA-ECC, DSA, = etc. etc.) and a status request comes in for an unknown cert, there is = no data for the responder to choose a reasonble response alg. You are = forced to choose a lowest common denominator alg which is a problem if = you moved to ECC because RSA 4096 does not cut it.


So this is a pretty simple fix to sort it out. I suggest that this goes = on standards track and if we progress OCSP from PROPOSED to DRAFT we = dump the explanatory part and merge the normative text in.


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 12/2/2008 1:39 PM
To: Hallam-Baker, Phillip
Subject: New Version Notification for = draft-hallambaker-ocspagility-02


A new version of I-D, draft-hallambaker-ocspagility-02.txt has been = successfuly submitted by Phillip Hallam-Baker and posted to the IETF = repository.

Filename:        = draft-hallambaker-ocspagility
Revision:        02
Title:           OCSP = Algorithm Agility
Creation_date:   2008-12-02
WG ID:           = Independent Submission
Number_of_pages: 8

Abstract:
The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.
            &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =         


The IETF Secretariat.

------_=_NextPart_001_01C954B0.5E07FC46--