From root@core3.amsl.com Tue Jun 1 12:45:02 2010 Return-Path: X-Original-To: smime@ietf.org Delivered-To: smime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 799A93A6A99; Tue, 1 Jun 2010 12:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100601194502.799A93A6A99@core3.amsl.com> Date: Tue, 1 Jun 2010 12:45:02 -0700 (PDT) Cc: smime@ietf.org Subject: [smime] I-D ACTION:draft-ietf-smime-cms-rsa-kem-13.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 19:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the RSA-KEM Key Transport Algorithm in CMS Author(s) : J. Brainard, S. Turner, J. Randall, B. Kaliski Filename : draft-ietf-smime-cms-rsa-kem-13.txt Pages : 28 Date : 2010-5-29 The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). The ASN.1 syntax is aligned with an expected forthcoming change to ANS X9.44. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-13.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-smime-cms-rsa-kem-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-6-1124005.I-D@ietf.org> --NextPart-- From nelson@bolyard.me Tue Jun 8 10:59:28 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4E43A67EA for ; Tue, 8 Jun 2010 10:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=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 EZ9l4+1uTzhr for ; Tue, 8 Jun 2010 10:59:27 -0700 (PDT) Received: from p3plsmtpa01-08.prod.phx3.secureserver.net (p3plsmtpa01-08.prod.phx3.secureserver.net [72.167.82.88]) by core3.amsl.com (Postfix) with SMTP id 881B73A679C for ; Tue, 8 Jun 2010 10:59:27 -0700 (PDT) Received: (qmail 28664 invoked from network); 8 Jun 2010 17:59:26 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-08.prod.phx3.secureserver.net (72.167.82.88) with ESMTP; 08 Jun 2010 17:59:25 -0000 Message-ID: <4C0E8491.1090109@bolyard.me> Date: Tue, 08 Jun 2010 10:57:37 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: smime@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [smime] Double base64 encoding unavoidable in enveloped messages? X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 17:59:28 -0000 Thunderbird's developers have received complaints about the relative size of enveloped messages, as compared to the same message sent in plain text. Investigation has shown that the message production - creates the entire un-enveloped message, with any binary attachments base64 encoded, then - envelopes it, then - base 64 encodes the enveloped message. As some developers read it, this is the right/only way to do it. They see the double-encoding as unavoidable. It surely is wasteful of bandwidth and storage. Is this double base64 encoding unavoidable? Or is there something being overlooked here? From housley@vigilsec.com Tue Jun 8 11:22:01 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA003A67CF for ; Tue, 8 Jun 2010 11:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.484 X-Spam-Level: X-Spam-Status: No, score=-100.484 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_40=-0.185, 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 WZAmvoM7xcN1 for ; Tue, 8 Jun 2010 11:22:00 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id B3ADC3A6829 for ; Tue, 8 Jun 2010 11:21:59 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9EF899A4740 for ; Tue, 8 Jun 2010 14:22:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id ZJW378o317dd for ; Tue, 8 Jun 2010 14:21:57 -0400 (EDT) Received: from [140.247.250.67] (unknown [140.247.250.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 16F8B9A472E for ; Tue, 8 Jun 2010 14:22:03 -0400 (EDT) Message-ID: <4C0E8A4A.8070007@vigilsec.com> Date: Tue, 08 Jun 2010 14:22:02 -0400 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: smime@ietf.org References: <4C0E8491.1090109@bolyard.me> In-Reply-To: <4C0E8491.1090109@bolyard.me> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [smime] Double base64 encoding unavoidable in enveloped messages? X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 18:22:01 -0000 This has been discussed several times over the last few years, and there is agreement that the double-encoding ought to be avoided. There is not agreement about which one out to be eliminated. The consequences are different based on your deployment environment. Russ On 6/8/2010 1:57 PM, Nelson B Bolyard wrote: > Thunderbird's developers have received complaints about the relative size of > enveloped messages, as compared to the same message sent in plain text. > Investigation has shown that the message production > > - creates the entire un-enveloped message, with any binary attachments > base64 encoded, then > - envelopes it, then > - base 64 encodes the enveloped message. > > As some developers read it, this is the right/only way to do it. > They see the double-encoding as unavoidable. > It surely is wasteful of bandwidth and storage. > Is this double base64 encoding unavoidable? > Or is there something being overlooked here? From wwwrun@rfc-editor.org Tue Jun 8 11:37:35 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844CB3A6910; Tue, 8 Jun 2010 11:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, NO_RELAYS=-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 PQ6WLSv+PaRS; Tue, 8 Jun 2010 11:37:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id BC1B53A68F3; Tue, 8 Jun 2010 11:37:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5C56CE0693; Tue, 8 Jun 2010 11:37:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100608183736.5C56CE0693@rfc-editor.org> Date: Tue, 8 Jun 2010 11:37:36 -0700 (PDT) Cc: smime@ietf.org, rfc-editor@rfc-editor.org Subject: [smime] RFC 5911 on New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 18:37:35 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5911 Title: New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME Author: P. Hoffman, J. Schaad Status: Informational Stream: IETF Date: June 2010 Mailbox: paul.hoffman@vpnc.org, jimsch@exmsft.com Pages: 59 Characters: 101576 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-smime-new-asn1-07.txt URL: http://www.rfc-editor.org/rfc/rfc5911.txt The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the S/MIME Mail Security Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ietf@augustcellars.com Wed Jun 9 16:46:01 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95BBD3A69AE for ; Wed, 9 Jun 2010 16:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 tHyy1nhAL2Yb for ; Wed, 9 Jun 2010 16:46:00 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id B1EBD3A69AC for ; Wed, 9 Jun 2010 16:46:00 -0700 (PDT) Received: from TITUS (static-66-14-119-7.bdsl.verizon.net [66.14.119.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id DAF996EF75; Wed, 9 Jun 2010 16:46:01 -0700 (PDT) From: "Jim Schaad" To: "'Nelson B Bolyard'" , References: <4C0E8491.1090109@bolyard.me> In-Reply-To: <4C0E8491.1090109@bolyard.me> Date: Wed, 9 Jun 2010 16:45:40 -0700 Message-ID: <0dd601cb082d$dffb9af0$9ff2d0d0$@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: AcsHNMeupX9GlWWFQtuvJFIQWZPp/AA+LSkw Content-Language: en-us Subject: Re: [smime] Double base64 encoding unavoidable in enveloped messages? X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 23:46:01 -0000 There are several things that you can look at. 1. Emit and look for the binary smime capability. This will allow you to not do the inner base 64 encoding step which is the most likely to save you one wrapping. I have not been looking at active smime messages recently, but most current clients should be doing this. 2. If you would not normally do the outer wrapping, then you can omit doing that. While almost all current gateways and routers can deal with 8-bit content, it is possible that some still exist that need 7-bit content and thus the base64 encoding. Jim > -----Original Message----- > From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf > Of Nelson B Bolyard > Sent: Tuesday, June 08, 2010 10:58 AM > To: smime@ietf.org > Subject: [smime] Double base64 encoding unavoidable in enveloped > messages? > > Thunderbird's developers have received complaints about the relative > size of > enveloped messages, as compared to the same message sent in plain text. > Investigation has shown that the message production > > - creates the entire un-enveloped message, with any binary attachments > base64 encoded, then > - envelopes it, then > - base 64 encodes the enveloped message. > > As some developers read it, this is the right/only way to do it. > They see the double-encoding as unavoidable. > It surely is wasteful of bandwidth and storage. > Is this double base64 encoding unavoidable? > Or is there something being overlooked here? > > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime From pgut001@cs.auckland.ac.nz Wed Jun 9 23:52:30 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC9B3A68F9 for ; Wed, 9 Jun 2010 23:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 a0TayUMEiNW0 for ; Wed, 9 Jun 2010 23:52:29 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 6A8673A68DA for ; Wed, 9 Jun 2010 23:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1276152748; x=1307688748; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20ietf@augustcellars.com,=20nelson@bolyard.me,=20smi me@ietf.org|Subject:=20Re:=20[smime]=20Double=20base64=20 encoding=20unavoidable=20in=20enveloped=20messages? |In-Reply-To:=20<0dd601cb082d$dffb9af0$9ff2d0d0$@com> |Message-Id:=20|Date:=20Thu,=2010=20Jun=202010=2018:52:11=20+120 0; bh=6IDHSWqL/8f36fGIyfv8/fIloxocazY7hDPXdfFLzR8=; b=ZgLltAKP18yxLQdcdP+rSpmGJGVtde4QQlOdWjkm74zM4lh3IEH/v5sO r0vIV/U0+wI3z2EC9KC1B4rlQQMgdHbTQdghMXqdC58310Hi0ED2/f6eh zh4uXIpA64J/oW0CrhpvDC5oVdVW4AYEUSJyBKYrG9elc3bK6dhXHuC2/ w=; X-IronPort-AV: E=Sophos;i="4.53,397,1272801600"; d="scan'208";a="10414443" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Jun 2010 18:52:12 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OMbcZ-0006YD-V5; Thu, 10 Jun 2010 18:52:11 +1200 From: Peter Gutmann To: ietf@augustcellars.com, nelson@bolyard.me, smime@ietf.org In-Reply-To: <0dd601cb082d$dffb9af0$9ff2d0d0$@com> Message-Id: Date: Thu, 10 Jun 2010 18:52:11 +1200 Subject: Re: [smime] Double base64 encoding unavoidable in enveloped messages? X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 06:52:30 -0000 "Jim Schaad" writes: >There are several things that you can look at. Also, hasn't support for binary data been a MUST for many years now? I remember this from some time ago... I haven't done a full archaeological investigation but RFC 3851 from 2004 already says (section 3.1.2): S/MIME implementations MUST be able to deal with binary MIME objects. (followed by text on not using base64). Peter. From turners@ieca.com Thu Jun 10 06:05:15 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFEA73A67C2 for ; Thu, 10 Jun 2010 06:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 jtpw0LKI9FoO for ; Thu, 10 Jun 2010 06:05:15 -0700 (PDT) Received: from smtp115.biz.mail.sp1.yahoo.com (smtp115.biz.mail.sp1.yahoo.com [69.147.92.217]) by core3.amsl.com (Postfix) with SMTP id 0910F3A6A0B for ; Thu, 10 Jun 2010 06:05:15 -0700 (PDT) Received: (qmail 44195 invoked from network); 10 Jun 2010 13:05:14 -0000 Received: from thunderfish.local (turners@96.231.125.208 with plain) by smtp115.biz.mail.sp1.yahoo.com with SMTP; 10 Jun 2010 06:05:14 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: _Rl25_EVM1ky5hwSqTWVghQEspTRP9SpAfIHtwJfAQJkrVYySJwnb3ZyedRAP2HgcVGiKQBm3y6algvCdCHEsLXOzs4ksBcT0UTcoTTCmow3ljPjjsRVpfDqeRSze2LlDt3xR8q_JOUBducu153aLom1fOJuXZZJjNifX3Ezw_nsxdSMF8MTyAYoJGyXU3d6MJ8tLhwleNzPbRh9FZt3xoHTEigygbBrsa5_kroApZ3XqXkV8UR38JDgi10FUUCvz3srliZ72SQA8rOyxqHaCSq1YpMIzor99eNMFKabh9DXzIVQ52ibfKZ_XF.df0rxVp7Tkpp6.nXDZ52aAeQkjA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C10E308.9060503@ieca.com> Date: Thu, 10 Jun 2010 09:05:12 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org, smime@ietf.org, pkix@ietf.org, cfrg@irtf.org Content-Type: multipart/mixed; boundary="------------090806050806050406010805" Subject: [smime] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:05:15 -0000 This is a multi-part message in MIME format. --------------090806050806050406010805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit (apologies if you get this multiple times) I'm looking for feedback on this draft that proposes moving MD2 to historic status. Thanks, spt --------------090806050806050406010805 Content-Type: message/rfc822; name="I-D ACTION:draft-turner-md2-to-historic-00.txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-turner-md2-to-historic-00.txt.eml" X-Account-Key: account2 X-Mozilla-Keys: X-Apparently-To: turners@ieca.com via 216.252.120.75; Wed, 09 Jun 2010 15:00:16 -0700 Received-SPF: pass (mta1000.biz.mail.sk1.yahoo.com: domain of i-d-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) X-YMailISG: 1AsMrJEcZArVP5yvMJgkYXVp8sHZm2YoT3YrnKj0jSxGLEH6Kt.NSMPZPps_P.iiql7h.XHpvTdp6uVr6_2fzTF.8rnYMfYT_4od1k4dQ42fKQ5Wu2vJ1wsZDB2z1..W2BMMNY.R2XLpnQrQqJMpThN3graI5hPpqA.8bx92CYkSvto6p8PYpzRKhWwtvYlBy64Vs1rTZUYLvmTckHI2hmcxzdah9N3KlxcUb01IwzW6NYBvbkTHCApbX02X8Mt2FToQvCD6Lgm7.ZHpL2KxjGZL.JOC32D.Mw4meiYgElJjJysXjoYUY4FbvMNygT85VfBI9fnfg8tl7fyyqiJGcroHOdq4HclfxPbpp44C5.2lr1HCIElxy66OV9cmX6ct0Jle3YRSmfD8kfp3OAde1pOdLKyVVM.bP1lhuoXXzcC2uITmhIK0eiye_LILwVtfWiD.vy_hzAU3sOTXvGOtLQ5iJK5JmU11MUHJfW8pZGqJgIl7_OzdZawe4olPURy.pVZG2oS8afOLBo8N29pBMNLEOLd1cuUPjjh2B.RBw8Bp4MOaDrdN7Pu9f6jJwVNIiIyfVTZrZ4UMdQs8HRhTuJ8_1CgDUuGoPU8upQ-- X-Originating-IP: [64.170.98.32] Authentication-Results: mta1000.biz.mail.sk1.yahoo.com from=ietf.org; domainkeys=neutral (no sig); from=ietf.org; dkim=neutral (no sig) Received: from 64.170.98.32 (EHLO mail.ietf.org) (64.170.98.32) by mta1000.biz.mail.sk1.yahoo.com with SMTP; Wed, 09 Jun 2010 15:00:16 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9AE28C11A; Wed, 9 Jun 2010 15:00:04 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2FC6E3A6872; Wed, 9 Jun 2010 15:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-turner-md2-to-historic-00.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100609220002.2FC6E3A6872@core3.amsl.com> Date: Wed, 9 Jun 2010 15:00:02 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MD2 to Historic Status Author(s) : S. Turner Filename : draft-turner-md2-to-historic-00.txt Pages : 6 Date : 2010-6-8 This document recommends the retirement of MD2 and discusses the reasons for doing so. This document recommends RFC 1319 be moved to Historic status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-md2-to-historic-00.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-turner-md2-to-historic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-6-9145328.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --------------090806050806050406010805-- From pgut001@cs.auckland.ac.nz Thu Jun 10 06:37:24 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72C13A6A28; Thu, 10 Jun 2010 06:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, 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 4lZCIPoVCjnm; Thu, 10 Jun 2010 06:37:24 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id A7B5D3A6A2A; Thu, 10 Jun 2010 06:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1276177047; x=1307713047; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20simon@josefsson.org,=20turners@ieca.com|Subject: =20Re:=20[Cfrg]=20[Fwd:=20I-D=20ACTION:draft-turner-md2-t o-historic-00.txt]|Cc:=20cfrg@irtf.org,=20pkix@ietf.org, =20saag@ietf.org,=20smime@ietf.org|In-Reply-To:=20<87bpbj ko9d.fsf@mocca.josefsson.org>|Message-Id:=20|Date:=20Fri,=2011 =20Jun=202010=2001:37:08=20+1200; bh=2NTpe579zow3qtXS4N02EkTV7jWEdeU2XdK9mjNaF+U=; b=XyR3nwkuWqPgYImyCWU89zLMEHXtzampHv+y9kB+VWugd4Qy9j3t2lcy AdPTUoElZx3G+fzKbru4fXTKPaBto9o/z88GFwk+1fh6sm9CmlQb6jOoY Mn81mBDWnDp7c+JXyNTIVDmNqLKouu1014c7Cnl4cW8Aq/keddTmO7izD k=; X-IronPort-AV: E=Sophos;i="4.53,398,1272801600"; d="scan'208";a="10440674" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jun 2010 01:37:09 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OMhwS-0001On-NR; Fri, 11 Jun 2010 01:37:08 +1200 From: Peter Gutmann To: simon@josefsson.org, turners@ieca.com In-Reply-To: <87bpbjko9d.fsf@mocca.josefsson.org> Message-Id: Date: Fri, 11 Jun 2010 01:37:08 +1200 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Cfrg] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:37:25 -0000 Simon Josefsson writes: >1) MD2 is not on the standards track, it is Informational. I agree with > wishes to move "poor" documents from the Standards Track to Historic, > but I'm not sure I see such a big difference between having a "poor" > document as Informational or Historic. Especially for a crypto > algorithm, which the IETF typically does not put on the standards > track at all. Is there some precedent for moving Informational to > Historic? It helps to have something like this formally retired so you have a document to point to when someone wants to use (or continue to use) MD2. Trying to explain to them the difference between "Informational" and "Standards Track" when their requirement is "must be specified in an RFC" isn't generally useful. (We really need an RFC equivalent of the UK's Great Repeal Bill at some point...). Peter. From simon@josefsson.org Thu Jun 10 06:45:27 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021AB3A6A0F; Thu, 10 Jun 2010 06:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=0.780, 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 0XOW6EgCdkwD; Thu, 10 Jun 2010 06:45:26 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id ADC0B3A6A1D; Thu, 10 Jun 2010 06:45:25 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5ADivii017121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 15:44:58 +0200 From: Simon Josefsson To: Peter Gutmann References: <87bpbjko9d.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:pgut001@cs.auckland.ac.nz::ChhguUKHpZjABR4a:Y+Z X-Hashcash: 1:22:100610:pkix@ietf.org::ELbKJEqBcmWb5oZ9:4lnZ X-Hashcash: 1:22:100610:smime@ietf.org::dVO8LQ41HF3zk4k0:5KdG X-Hashcash: 1:22:100610:cfrg@irtf.org::VT0eNSiMU6DLreZt:5CNU X-Hashcash: 1:22:100610:saag@ietf.org::do2o383DR/37QJrJ:NFue X-Hashcash: 1:22:100610:turners@ieca.com::GsQku9cpvxcZcY8y:kJPb Date: Thu, 10 Jun 2010 15:44:57 +0200 In-Reply-To: (Peter Gutmann's message of "Fri, 11 Jun 2010 01:37:08 +1200") Message-ID: <87eigfj92e.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:45:27 -0000 Peter Gutmann writes: > Simon Josefsson writes: > >>1) MD2 is not on the standards track, it is Informational. I agree with >> wishes to move "poor" documents from the Standards Track to Historic, >> but I'm not sure I see such a big difference between having a "poor" >> document as Informational or Historic. Especially for a crypto >> algorithm, which the IETF typically does not put on the standards >> track at all. Is there some precedent for moving Informational to >> Historic? > > It helps to have something like this formally retired so you have a document > to point to when someone wants to use (or continue to use) MD2. Trying to > explain to them the difference between "Informational" and "Standards Track" > when their requirement is "must be specified in an RFC" isn't generally > useful. Sure, but MD2 is not used in isolation, it is used in a protocol like TLS, S/MIME, etc. Isn't it sufficient, even preferable, to move uses of MD2 in these protocol to Historic? That would seem to carry much more weight -- then people cannot continue to support MD2 in these protocol and claim to be compliant with the latest specifications. Note that there are other uses of MD2 that are still fine even if MD2 is not collision resistant. Compare how rsync still uses MD4 for checksum computations, and that won't stop it being a reasonable choice. I'm mostly playing the devil's advocate here, and want to make sure we consider the consequences before giving a flippant +1. /Simon From turners@ieca.com Thu Jun 10 07:01:06 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4E63A6970 for ; Thu, 10 Jun 2010 07:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 98N3V8gOIGXo for ; Thu, 10 Jun 2010 07:01:06 -0700 (PDT) Received: from smtp113.biz.mail.sp1.yahoo.com (smtp113.biz.mail.sp1.yahoo.com [69.147.92.226]) by core3.amsl.com (Postfix) with SMTP id F25F928C0F4 for ; Thu, 10 Jun 2010 07:01:05 -0700 (PDT) Received: (qmail 8660 invoked from network); 10 Jun 2010 14:01:05 -0000 Received: from thunderfish.local (turners@96.231.125.208 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 10 Jun 2010 07:01:05 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: KPW1RO8VM1krMtzT8Yt64Os1a624dZ9jResMM6aj35MU63CcR0l2.XBG.foq4xi2ONwbe6p397H4blm99_PJOtr8zTPMBnvmV_afKuW5ihtC.znN9_tvd4IkQV5S0v4nIsJvZ4Ni_Rwo9GmWpecqXIqD6iCZ71MhbZb5glKPb3IKYVu2eTevNZNPddyiVPOJKSX7BAARIDTBZbCaRW4kvftgDwbn1FxfjCYLH43eQwH2zMblDgYHioEihGQ9OMg2U2QbdZg12lxibRHFcZtAokEVYHMpXnNFEbA3VaQ8nlhg8PUXiR8dqs0j5FGQSyqLJtOGYAeM8orCekxdVaevVw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C10F020.4000102@ieca.com> Date: Thu, 10 Jun 2010 10:01:04 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Simon Josefsson References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> In-Reply-To: <87bpbjko9d.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:01:06 -0000 Simon Josefsson wrote: > Sean Turner writes: > >> (apologies if you get this multiple times) >> >> I'm looking for feedback on this draft that proposes moving MD2 to >> historic status. > > In general I support this: MD2 should simply not be used. > > However I see two concerns: > > 1) MD2 is not on the standards track, it is Informational. I agree with > wishes to move "poor" documents from the Standards Track to Historic, > but I'm not sure I see such a big difference between having a "poor" > document as Informational or Historic. Especially for a crypto > algorithm, which the IETF typically does not put on the standards > track at all. Is there some precedent for moving Informational to > Historic? To be honest I'm not sure there's a precedent. I don't think RFC 2026 says that this can't be done; the definition of Historic is as follows: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. (Purists have suggested that the word should be "Historical"; however, at this point the use of "Historic" is historical.) I think if it was just for standards track specifications, it would have said that. But, what I was thinking was that if we've got an informational specification of an algorithm that's broken (i.e., obsolete) we should wave red flags announcing this. One way to do that is to write this document and an another flag is to put it on a different track than ones we don't think are broken. This might just be a process thing, but I think we should be doing this. > 2) MD2 is still used. In GnuTLS I recall _adding_ support for MD2 as > recently as (according to NEWS logs) in 2005. If I recall correctly, > some Verisign root certificates are MD2. Note that in GnuTLS, > verifying a certificate involving a MD2 digital signature will fail > because MD2 is insecure, but the algorithm is still implemented and > supported. > > Thus the text in your document "many TLS implementations, OpenSSL, > Network Security Services, and GNUTLS, have disabled support for MD2" > may not be the entire story. GnuTLS "supports" MD2 even though it > does not consider it secure. I can't speak for OpenSSL or NSS, but I > suspect they implement MD2 too and can verify such digital hashes, > even if they don't consider them secure. Yeah that might have been a bit strong. Maybe: Additionally, many TLS implementations, OpenSSL, Network Security Services, and GNUTLS, support MD2 but recommend it only for backwards compatibility. > Even if these concerns cannot be fully addressed, I would likely still > support this document though. So they are "soft" concerns for me. Thanks, spt From simon@josefsson.org Thu Jun 10 07:04:28 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF583A696E; Thu, 10 Jun 2010 07:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 WBcsIKMeg2Bb; Thu, 10 Jun 2010 07:04:27 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 3CB613A68B9; Thu, 10 Jun 2010 07:04:27 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5AE1qv8017520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 16:01:54 +0200 From: Simon Josefsson To: Len Sassaman References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:cfrg@irtf.org::iD7DUTilRnXEF9bP:0uQA X-Hashcash: 1:22:100610:saag@ietf.org::JRWASo4dEHey3f2U:4CiY X-Hashcash: 1:22:100610:turners@ieca.com::eeaWOgUpw/uFMsXc:9qwM X-Hashcash: 1:22:100610:smime@ietf.org::6KD93PXlax1GZNNA:IUxY X-Hashcash: 1:22:100610:pkix@ietf.org::X8Sp1IijYzCOI9it:ew1p X-Hashcash: 1:22:100610:len.sassaman@esat.kuleuven.be::wwbDvv4GIds9Al3A:LleC Date: Thu, 10 Jun 2010 16:01:52 +0200 In-Reply-To: (Len Sassaman's message of "Thu, 10 Jun 2010 15:49:17 +0200 (CEST)") Message-ID: <87sk4vhtpr.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:04:28 -0000 Len Sassaman writes: > On Thu, 10 Jun 2010, Simon Josefsson wrote: > >> 2) MD2 is still used. In GnuTLS I recall _adding_ support for MD2 as >> recently as (according to NEWS logs) in 2005. If I recall correctly, >> some Verisign root certificates are MD2. Note that in GnuTLS, >> verifying a certificate involving a MD2 digital signature will fail >> because MD2 is insecure, but the algorithm is still implemented and >> supported. > > Verisign had a root cert that was self-signed by MD2. When Dan > Kaminsky and I found that, Dan talked to Versign, and they reissued > the cert signed with SHA-1. The original cert is still valid in older > browsers, but there should no longer be any MD2 certs in use in the > public CA system. (Who knows about private enterprise deployments, > however.) > > I support deprecating MD2. We are one incremental improvement in MD2 > attack speed away from a massive break. A self-signed trust root with MD2 is not a security problem by itself: it is not the digital signature that is trusted, it is the public key in the certificate. The MD2 roots are still shipped and trusted in several modern packages (e.g., Ubuntu 10.04 LTS ca-certificates). I support deprecating MD2 for any purpose that requires a collision resistant function. The current proposal goes further and deprecates MD2 for any use. I don't see much argumentation for deprecating it for non-collision resistant use-cases. /Simon From simon@josefsson.org Thu Jun 10 07:05:51 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741CC3A697D; Thu, 10 Jun 2010 07:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 W9P4cbqgFyuu; Thu, 10 Jun 2010 07:05:49 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 7FF923A6A20; Thu, 10 Jun 2010 07:05:49 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5AE5hYl017613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 16:05:45 +0200 From: Simon Josefsson To: Sean Turner References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <4C10F020.4000102@ieca.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:turners@ieca.com::coc6vtrPHOwIeITE:8UAW X-Hashcash: 1:22:100610:saag@ietf.org::cEgqujMel70F0cZT:9L+H X-Hashcash: 1:22:100610:pkix@ietf.org::SM1iQiV0m8vqRVki:7MT8 X-Hashcash: 1:22:100610:cfrg@irtf.org::i+lSPmZjrbxnCy0z:IRZN X-Hashcash: 1:22:100610:smime@ietf.org::H0PgqDjekSGceAOS:IjQN Date: Thu, 10 Jun 2010 16:05:43 +0200 In-Reply-To: <4C10F020.4000102@ieca.com> (Sean Turner's message of "Thu, 10 Jun 2010 10:01:04 -0400") Message-ID: <87ocfjhtjc.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:05:51 -0000 Sean Turner writes: > But, what I was thinking was that if we've got an informational > specification of an algorithm that's broken (i.e., obsolete) we should > wave red flags announcing this. One way to do that is to write this > document and an another flag is to put it on a different track than > ones we don't think are broken. This might just be a process thing, > but I think we should be doing this. One alternative would be to supersede (or update) the original RFC with your document, and still have it on Informational status. That approach permits use-cases where a collision resistant function is not required, but still raises the red flags we all want to be there. /Simon From simon@josefsson.org Thu Jun 10 07:22:31 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FEF728C121; Thu, 10 Jun 2010 07:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.812 X-Spam-Level: X-Spam-Status: No, score=-1.812 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, J_CHICKENPOX_23=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 XFEef8ku-+eM; Thu, 10 Jun 2010 07:22:29 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 7FCBA28C0F8; Thu, 10 Jun 2010 07:22:28 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5AEK5pW017997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 16:20:06 +0200 From: Simon Josefsson To: Len Sassaman References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <87sk4vhtpr.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:smime@ietf.org::FOgOV3dYn050dr6M:2OlW X-Hashcash: 1:22:100610:turners@ieca.com::zR5HdSxtl2fDkAHN:2iTH X-Hashcash: 1:22:100610:cfrg@irtf.org::eaoWXvdfE9tgXqNu:56it X-Hashcash: 1:22:100610:saag@ietf.org::IJaj4s48D8Ta0siT:BESu X-Hashcash: 1:22:100610:pkix@ietf.org::yBrNonfhOfOSK3Ua:Kiv4 X-Hashcash: 1:22:100610:len.sassaman@esat.kuleuven.be::rcIcGONN4cDuMsfB:Kk1C Date: Thu, 10 Jun 2010 16:20:05 +0200 In-Reply-To: (Len Sassaman's message of "Thu, 10 Jun 2010 16:12:02 +0200 (CEST)") Message-ID: <87typbgeay.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:22:31 -0000 Len Sassaman writes: > On Thu, 10 Jun 2010, Simon Josefsson wrote: > >> A self-signed trust root with MD2 is not a security problem by itself: >> it is not the digital signature that is trusted, it is the public key in >> the certificate. The MD2 roots are still shipped and trusted in several >> modern packages (e.g., Ubuntu 10.04 LTS ca-certificates). > > No, it absolutely *is* a security problem. Should someone develop a > preimage attack on MD2, all they need do is move the (valid) MD2 > signature to an intermediate cert with BasicConstraints CA=yes, and > then they have themselves a CA. I don't see how that gains you anything: you still need to make clients place trust in the new CA, and if the attacker has that ability, all bets are off. /Simon From simon@josefsson.org Thu Jun 10 06:32:08 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C958F3A6A26; Thu, 10 Jun 2010 06:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=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 Q3AaL-1XalWT; Thu, 10 Jun 2010 06:32:02 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id C18EC3A6A1F; Thu, 10 Jun 2010 06:31:59 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5ADVQi0016714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 15:31:32 +0200 From: Simon Josefsson To: Sean Turner References: <4C10E308.9060503@ieca.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:turners@ieca.com::zz/Cg7ph4i1/aCXj:0+rs X-Hashcash: 1:22:100610:saag@ietf.org::tLcs4tEQZJMaBi7F:6Xgy X-Hashcash: 1:22:100610:cfrg@irtf.org::4E+d5Tu3VmEuePAU:FDZ6 X-Hashcash: 1:22:100610:smime@ietf.org::utMUQRE/CqAUeKvk:SLGb X-Hashcash: 1:22:100610:pkix@ietf.org::Ob8s8AzYfEuSS/kl:aSs4 Date: Thu, 10 Jun 2010 15:31:26 +0200 In-Reply-To: <4C10E308.9060503@ieca.com> (Sean Turner's message of "Thu, 10 Jun 2010 09:05:12 -0400") Message-ID: <87bpbjko9d.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean X-Mailman-Approved-At: Thu, 10 Jun 2010 10:33:27 -0700 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:32:09 -0000 Sean Turner writes: > (apologies if you get this multiple times) > > I'm looking for feedback on this draft that proposes moving MD2 to > historic status. In general I support this: MD2 should simply not be used. However I see two concerns: 1) MD2 is not on the standards track, it is Informational. I agree with wishes to move "poor" documents from the Standards Track to Historic, but I'm not sure I see such a big difference between having a "poor" document as Informational or Historic. Especially for a crypto algorithm, which the IETF typically does not put on the standards track at all. Is there some precedent for moving Informational to Historic? 2) MD2 is still used. In GnuTLS I recall _adding_ support for MD2 as recently as (according to NEWS logs) in 2005. If I recall correctly, some Verisign root certificates are MD2. Note that in GnuTLS, verifying a certificate involving a MD2 digital signature will fail because MD2 is insecure, but the algorithm is still implemented and supported. Thus the text in your document "many TLS implementations, OpenSSL, Network Security Services, and GNUTLS, have disabled support for MD2" may not be the entire story. GnuTLS "supports" MD2 even though it does not consider it secure. I can't speak for OpenSSL or NSS, but I suspect they implement MD2 too and can verify such digital hashes, even if they don't consider them secure. Even if these concerns cannot be fully addressed, I would likely still support this document though. So they are "soft" concerns for me. /Simon From len.sassaman@esat.kuleuven.be Thu Jun 10 06:49:19 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 318E93A6968; Thu, 10 Jun 2010 06:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=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 nbEivEAQNxlz; Thu, 10 Jun 2010 06:49:18 -0700 (PDT) Received: from cavuit01.kulnet.kuleuven.be (cavuit01.kulnet.kuleuven.be [134.58.240.43]) by core3.amsl.com (Postfix) with ESMTP id 4ACBF3A6970; Thu, 10 Jun 2010 06:49:18 -0700 (PDT) Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be [134.58.240.75]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id B0BC67B8050; Thu, 10 Jun 2010 15:49:17 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by smtps02.kuleuven.be (Postfix) with ESMTP id A4326F3863; Thu, 10 Jun 2010 15:49:17 +0200 (CEST) Received: from helium.esat.kuleuven.be (helium.esat.kuleuven.be [134.58.56.167]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id BFB8548002; Thu, 10 Jun 2010 15:49:17 +0200 (CEST) Received: by helium.esat.kuleuven.be (Postfix, from userid 2415) id B97A1E5E46; Thu, 10 Jun 2010 15:49:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by helium.esat.kuleuven.be (Postfix) with ESMTP id B7378E5DF4; Thu, 10 Jun 2010 15:49:17 +0200 (CEST) Date: Thu, 10 Jun 2010 15:49:17 +0200 (CEST) X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Len Sassaman To: Simon Josefsson In-Reply-To: <87bpbjko9d.fsf@mocca.josefsson.org> Message-ID: References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-KULeuven-Information: Katholieke Universiteit Leuven X-KULeuven-Scanned: Found to be clean X-KULeuven-Envelope-From: len.sassaman@esat.kuleuven.be X-Mailman-Approved-At: Thu, 10 Jun 2010 10:33:27 -0700 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Cfrg] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 13:49:19 -0000 On Thu, 10 Jun 2010, Simon Josefsson wrote: > 2) MD2 is still used. In GnuTLS I recall _adding_ support for MD2 as > recently as (according to NEWS logs) in 2005. If I recall correctly, > some Verisign root certificates are MD2. Note that in GnuTLS, > verifying a certificate involving a MD2 digital signature will fail > because MD2 is insecure, but the algorithm is still implemented and > supported. Verisign had a root cert that was self-signed by MD2. When Dan Kaminsky and I found that, Dan talked to Versign, and they reissued the cert signed with SHA-1. The original cert is still valid in older browsers, but there should no longer be any MD2 certs in use in the public CA system. (Who knows about private enterprise deployments, however.) I support deprecating MD2. We are one incremental improvement in MD2 attack speed away from a massive break. --Len. From touch@isi.edu Thu Jun 10 07:03:06 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A5A3A6970; Thu, 10 Jun 2010 07:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 TazvPLeXBlTZ; Thu, 10 Jun 2010 07:03:05 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id C1FE53A6A0C; Thu, 10 Jun 2010 07:03:05 -0700 (PDT) Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5AE0u5l025106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Jun 2010 07:01:06 -0700 (PDT) Message-ID: <4C10F018.8040401@isi.edu> Date: Thu, 10 Jun 2010 07:00:56 -0700 From: Joe Touch User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Simon Josefsson References: <87bpbjko9d.fsf@mocca.josefsson.org> <87eigfj92e.fsf@mocca.josefsson.org> In-Reply-To: <87eigfj92e.fsf@mocca.josefsson.org> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAEC8484ED9D4BD6862F18201" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Thu, 10 Jun 2010 10:33:28 -0700 Cc: pkix@ietf.org, smime@ietf.org, cfrg@irtf.org, saag@ietf.org Subject: Re: [smime] [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:03:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAEC8484ED9D4BD6862F18201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all, I agree with Simon. I don't know what it means to move a doc like the MD2= spec to historic even means. It's not standards track. It's not a protocol. AF= AICT, it's just a description of an algorithm. It might be useful to create a "security algorithms roadmap" doc, which l= ists all known alg RFCs, and describes which are useful in various ways, and w= hich are no longer typically used, but singling out MD2 (vs. MD5 except as an = HMAC) seems not particularly useful. Joe Simon Josefsson wrote: > Peter Gutmann writes: >=20 >> Simon Josefsson writes: >> >>> 1) MD2 is not on the standards track, it is Informational. I agree w= ith >>> wishes to move "poor" documents from the Standards Track to Histori= c, >>> but I'm not sure I see such a big difference between having a "poor= " >>> document as Informational or Historic. Especially for a crypto >>> algorithm, which the IETF typically does not put on the standards >>> track at all. Is there some precedent for moving Informational to >>> Historic? >> It helps to have something like this formally retired so you have a do= cument >> to point to when someone wants to use (or continue to use) MD2. Tryin= g to >> explain to them the difference between "Informational" and "Standards = Track" >> when their requirement is "must be specified in an RFC" isn't generall= y >> useful. >=20 > Sure, but MD2 is not used in isolation, it is used in a protocol like > TLS, S/MIME, etc. Isn't it sufficient, even preferable, to move uses o= f > MD2 in these protocol to Historic? That would seem to carry much more > weight -- then people cannot continue to support MD2 in these protocol > and claim to be compliant with the latest specifications. >=20 > Note that there are other uses of MD2 that are still fine even if MD2 i= s > not collision resistant. Compare how rsync still uses MD4 for checksum= > computations, and that won't stop it being a reasonable choice. >=20 > I'm mostly playing the devil's advocate here, and want to make sure we > consider the consequences before giving a flippant +1. >=20 > /Simon > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------enigAEC8484ED9D4BD6862F18201 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkwQ8BgACgkQE5f5cImnZrv2xwCeKZvycpeI5nqIBub5U7QSG1Mz kRYAnRgvfgCoXTvJBs48lZc4E+cG0pYe =ccm1 -----END PGP SIGNATURE----- --------------enigAEC8484ED9D4BD6862F18201-- From len.sassaman@esat.kuleuven.be Thu Jun 10 07:12:05 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407AC3A6976; Thu, 10 Jun 2010 07:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=0.781, BAYES_00=-2.599, J_CHICKENPOX_23=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 VLHzPGsm-DVf; Thu, 10 Jun 2010 07:12:04 -0700 (PDT) Received: from cavuit02.kulnet.kuleuven.be (cavuit02.kulnet.kuleuven.be [134.58.240.44]) by core3.amsl.com (Postfix) with ESMTP id 4083B3A6921; Thu, 10 Jun 2010 07:12:03 -0700 (PDT) Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be [134.58.240.75]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 5E5F551C008; Thu, 10 Jun 2010 16:12:03 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by smtps02.kuleuven.be (Postfix) with ESMTP id 5813BF3862; Thu, 10 Jun 2010 16:12:03 +0200 (CEST) Received: from helium.esat.kuleuven.be (helium.esat.kuleuven.be [134.58.56.167]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 543C148002; Thu, 10 Jun 2010 16:12:03 +0200 (CEST) Received: by helium.esat.kuleuven.be (Postfix, from userid 2415) id 44170E5E46; Thu, 10 Jun 2010 16:12:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by helium.esat.kuleuven.be (Postfix) with ESMTP id 3CBEEE5BF4; Thu, 10 Jun 2010 16:12:03 +0200 (CEST) Date: Thu, 10 Jun 2010 16:12:02 +0200 (CEST) X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Len Sassaman To: Simon Josefsson In-Reply-To: <87sk4vhtpr.fsf@mocca.josefsson.org> Message-ID: References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <87sk4vhtpr.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-KULeuven-Information: Katholieke Universiteit Leuven X-KULeuven-Scanned: Found to be clean X-KULeuven-Envelope-From: len.sassaman@esat.kuleuven.be X-Mailman-Approved-At: Thu, 10 Jun 2010 10:33:27 -0700 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:12:05 -0000 On Thu, 10 Jun 2010, Simon Josefsson wrote: > A self-signed trust root with MD2 is not a security problem by itself: > it is not the digital signature that is trusted, it is the public key in > the certificate. The MD2 roots are still shipped and trusted in several > modern packages (e.g., Ubuntu 10.04 LTS ca-certificates). No, it absolutely *is* a security problem. Should someone develop a preimage attack on MD2, all they need do is move the (valid) MD2 signature to an intermediate cert with BasicConstraints CA=yes, and then they have themselves a CA. --Len. From len.sassaman@esat.kuleuven.be Thu Jun 10 09:59:10 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D0A3A69FD; Thu, 10 Jun 2010 09:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.348 X-Spam-Level: X-Spam-Status: No, score=-0.348 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_50=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 SJXGjqkMzvdl; Thu, 10 Jun 2010 09:59:09 -0700 (PDT) Received: from cavuit02.kulnet.kuleuven.be (cavuit02.kulnet.kuleuven.be [134.58.240.44]) by core3.amsl.com (Postfix) with ESMTP id 885033A67D6; Thu, 10 Jun 2010 09:59:08 -0700 (PDT) Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be [134.58.240.74]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id C0B9251C003; Thu, 10 Jun 2010 18:59:08 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by smtps01.kuleuven.be (Postfix) with ESMTP id AF86A31E705; Thu, 10 Jun 2010 18:59:08 +0200 (CEST) Received: from helium.esat.kuleuven.be (helium.esat.kuleuven.be [134.58.56.167]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id D10BC48002; Thu, 10 Jun 2010 18:59:08 +0200 (CEST) Received: by helium.esat.kuleuven.be (Postfix, from userid 2415) id C5D8CE5E46; Thu, 10 Jun 2010 18:59:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by helium.esat.kuleuven.be (Postfix) with ESMTP id C319AE5BF4; Thu, 10 Jun 2010 18:59:08 +0200 (CEST) Date: Thu, 10 Jun 2010 18:59:08 +0200 (CEST) X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Len Sassaman To: Simon Josefsson In-Reply-To: <87typbgeay.fsf@mocca.josefsson.org> Message-ID: References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <87sk4vhtpr.fsf@mocca.josefsson.org> <87typbgeay.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-KULeuven-Information: Katholieke Universiteit Leuven X-KULeuven-Scanned: Found to be clean X-KULeuven-Envelope-From: len.sassaman@esat.kuleuven.be X-Mailman-Approved-At: Thu, 10 Jun 2010 10:33:27 -0700 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 16:59:10 -0000 On Thu, 10 Jun 2010, Simon Josefsson wrote: > I don't see how that gains you anything: you still need to make clients > place trust in the new CA, and if the attacker has that ability, all > bets are off. The clients trust the new CA because it is an intermediate CA chained to the original, MD2-signed top-level CA. The intermediate cert is then treated with the same validity as *any* intermediate cert generated by that top-level cert -- since the top-level cert's signature verifies correctly on the intermediate cert, of course. Do you understand the attack now? This isn't *quite* such an issue, since after we brought it to the attention of CERT and the browser vendors, they either eliminated MD2 support entirely, or restricted it so that if an intermediate CA cert signed with MD2 would be rejected. (At least, I personally verifed Chrome and FireFox. I *think* IE and Opera were patched, too -- they should be.) So now we hope that browsers released prior to mid-2009 are retired from use before MD2 is broken in practice. Given the longevity of browsers, it's going to be close. --Len. From lists@drh-consultancy.demon.co.uk Thu Jun 10 10:58:04 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206C628C0DB; Thu, 10 Jun 2010 10:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 HM7DkKeHMBiv; Thu, 10 Jun 2010 10:58:02 -0700 (PDT) Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by core3.amsl.com (Postfix) with ESMTP id 994F23A698A; Thu, 10 Jun 2010 10:58:02 -0700 (PDT) Received: from [212.183.140.42] (port=49744 helo=[10.97.34.70]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10587) with esmtpa (authdaemon_plain:drh) id 1OMm0t-0003Qp-Ec (return-path ); Thu, 10 Jun 2010 17:58:00 +0000 Message-ID: <4C1127A5.70407@drh-consultancy.demon.co.uk> Date: Thu, 10 Jun 2010 18:57:57 +0100 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: smime@ietf.org References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> In-Reply-To: <87bpbjko9d.fsf@mocca.josefsson.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org Subject: Re: [smime] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 17:58:04 -0000 On 10/06/2010 14:31, Simon Josefsson wrote: > > Thus the text in your document "many TLS implementations, OpenSSL, > Network Security Services, and GNUTLS, have disabled support for MD2" > may not be the entire story. GnuTLS "supports" MD2 even though it > does not consider it secure. I can't speak for OpenSSL or NSS, but I > suspect they implement MD2 too and can verify such digital hashes, > even if they don't consider them secure. > OpenSSL implemented MD2 but has since disabled its use in digital signatures and generally attempting to lookup a digest called "MD2" will fail. The self signed root CA issue was worked around by disabling the signature check on the root CA by default, since it is redundant. The result is that a self signed trusted root can be signed using MD2withRSA but never subordinate CAs. 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 wwwrun@core3.amsl.com Thu Jun 10 10:58:30 2010 Return-Path: X-Original-To: smime@ietf.org Delivered-To: smime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 76B4428C10D; Thu, 10 Jun 2010 10:58:30 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100610175830.76B4428C10D@core3.amsl.com> Date: Thu, 10 Jun 2010 10:58:30 -0700 (PDT) Cc: smime chair , Internet Architecture Board , smime mailing list , RFC Editor Subject: [smime] Protocol Action: 'Use of the RSA-KEM Key Transport Algorithm in CMS' to Proposed Standard X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 17:58:30 -0000 The IESG has approved the following document: - 'Use of the RSA-KEM Key Transport Algorithm in CMS ' as a Proposed Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Sean Turner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-13.txt Technical Summary The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS). Working Group Summary The draft was development in ANSI and ISO/IEC. The CMS part describes where you put the OIDs is non-controversial. Note that the algorithm in Appendix A and ASN.1 in Appendix B is aligned with ANS X9.44 and ISO/IEC 18033-2. This document was scheduled to be on an IESG telechat in 2008-12-11, but it was sent back to the S/MIME WG after comments were received from Steve Kent during his SECDIR review on the public key certificate parameters. This version addresses, Steve's comments as well as other comments raised by Jim Schaad on the S/MIME mailing list. Note that there is one remaining OID that to be registered, and this will occur immediately following IESG approval. Document Quality As noted in the draft: The RSA-KEM Key Transport Algorithm in various forms is being adopted in several draft standards as well as in ANS-X9.44 and ISO/IEC 18033-2. It has also been recommended by the NESSIE project [NESSIE]. Personnel Blake Ramsdell is the document Shepherd. Tim Polk is the responsible Security Area AD. From simon@josefsson.org Thu Jun 10 13:20:31 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A6F3A672E; Thu, 10 Jun 2010 13:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, J_CHICKENPOX_12=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 JVNPp0Oq0P00; Thu, 10 Jun 2010 13:20:29 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 8A5B33A6784; Thu, 10 Jun 2010 13:20:27 -0700 (PDT) Received: from mocca (c80-216-29-48.bredband.comhem.se [80.216.29.48]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5AKJhcs031800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 10 Jun 2010 22:19:46 +0200 From: Simon Josefsson To: Len Sassaman References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <87sk4vhtpr.fsf@mocca.josefsson.org> <87typbgeay.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100610:smime@ietf.org::utAmCPfHI9SJWL0I:0fsU X-Hashcash: 1:22:100610:cfrg@irtf.org::Pes+7/Dm6OxJlQOo:2C4C X-Hashcash: 1:22:100610:saag@ietf.org::J0jt656oVj4YfgKD:9pjc X-Hashcash: 1:22:100610:turners@ieca.com::3JRdNsWExaMzsE9f:DVC4 X-Hashcash: 1:22:100610:pkix@ietf.org::wrDtcvYMC3EU4dqQ:I1dd X-Hashcash: 1:22:100610:len.sassaman@esat.kuleuven.be::ZYiMNjpfpNPoCM7P:J4Vl Date: Thu, 10 Jun 2010 22:19:43 +0200 In-Reply-To: (Len Sassaman's message of "Thu, 10 Jun 2010 18:59:08 +0200 (CEST)") Message-ID: <8739wuej34.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 20:20:31 -0000 Len Sassaman writes: > On Thu, 10 Jun 2010, Simon Josefsson wrote: > >> I don't see how that gains you anything: you still need to make clients >> place trust in the new CA, and if the attacker has that ability, all >> bets are off. > > The clients trust the new CA because it is an intermediate CA chained > to the original, MD2-signed top-level CA. The intermediate cert is > then treated with the same validity as *any* intermediate cert > generated by that top-level cert -- since the top-level cert's > signature verifies correctly on the intermediate cert, of course. > > Do you understand the attack now? Yes, I do, but that attack is not caused by a MD2 root. The attack is caused by software trusting MD2 to verify digital signatures. I believe the latter has been resolved in most security libraries already (it certainly has been resolved in GnuTLS, since January 2009, which treats both MD2 and MD5 as insecure). The former case (a MD2 root) is not a problem by itself, as far as I can tell, which is what I originally stated. As long as MD2 roots have not been shown to be a problem, by themselves, protocols and software will need to continue implement MD2 for operational reasons. There are still several MD2 roots in recently shipping operating systems. For example, my Ubuntu 10.04 LTS system has these RSA-MD2 roots: ./mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt: Issuer: C=US,O=VeriSign\, Inc.,OU=Class 1 Public Primary Certification Authority ./mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority ./mozilla/Verisign_RSA_Secure_Server_CA.crt Issuer: C=US,O=RSA Data Security\, Inc.,OU=Secure Server Certification Authority ./mozilla/Verisign_Class_2_Public_Primary_Certification_Authority.crt Issuer: C=US,O=VeriSign\, Inc.,OU=Class 2 Public Primary Certification Authority Right now, I think my preference would be to update RFC 1319 with something like Sean's document, to alert everyone of the security issues, but let the status of the algorithm description remain Informational. /Simon From paul.hoffman@vpnc.org Thu Jun 10 13:59:39 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 175713A659A for ; Thu, 10 Jun 2010 13:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=1.628, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 4DsIr4Id3yIN for ; Thu, 10 Jun 2010 13:59:38 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DF0313A6359 for ; Thu, 10 Jun 2010 13:59:37 -0700 (PDT) Received: from [10.20.30.158] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5AKxcEL090265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Jun 2010 13:59:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 10 Jun 2010 13:58:55 -0700 To: smime@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [smime] Fwd: Protocol Action: 'Additional CMS Revocation Information Choices' to Proposed Standard X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 20:59:39 -0000 >X-Original-To: ietf-announce@ietf.org >Delivered-To: ietf-announce@core3.amsl.com >X-idtracker: yes >From: The IESG >To: IETF-Announce >Subject: Protocol Action: 'Additional CMS Revocation Information Choices' to > Proposed Standard >Date: Thu, 10 Jun 2010 09:37:56 -0700 (PDT) >Cc: Internet Architecture Board , > RFC Editor >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.9 >List-Id: "IETF announcement list. No discussions." >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >Sender: ietf-announce-bounces@ietf.org > >The IESG has approved the following document: > >- 'Additional CMS Revocation Information Choices ' > as a Proposed Standard > >This document has been reviewed in the IETF but is not the product of an >IETF Working Group. > >The IESG contact person is Tim Polk. > >A URL of this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-turner-additional-cms-ri-choices-06.txt > >Technical Summary > > >The Cryptographic Message Syntax (CMS) allows revocation information to be >conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and >AuthEnvelopedData content types. The preferred format for revocation >information is the Certificate Revocation List (CRL), but an extension >mechanism supports other revocation information choices. This document >defines two additional revocation information formats for Online >Certificate Status Protocol (OCSP) responses and Server-Based Certificate >Validation Protocol (SCVP). > >Working Group Summary > >This I-D was forwarded to the S/MIME WG, but there was not enough >interest to support adopting it as a WG item. Nevertheless, there were a >few key members who provided comments off-list on the I-D. > >The discussions on the draft centered on the handling of unsigned SCVP >mechanism; there was no controversy w.r.t. the OCSP mechanism. The >changes to SCVP mechanism include allowing the request to be optionally >included, requiring that the SCVP response be signed, and bolstering the >security considerations. > >Document Quality > >This I-D is short at 8 pages (2 pages of technical content). There are >no known implementations at this time. > >Personnel > >Carl Wallace is the document Shepherd. Tim Polk is the responsible >Security Area AD. > >RFC Editor Note > >In section 6, please make the following substitution: > >OLD > > This document makes use of object identifiers. These object > identifiers are defined in an arc delegated by IANA to the PKIX > Working Group. No further action by IANA is necessary for this > document or any anticipated updates. > >NEW > > This document makes use of object identifiers. These > object identifiers are defined in an arc delegated by > IANA to the PKIX Working Group. The current contents > of the arc are located here: > > http://www.imc.org/ietf-pkix/pkix-oid.asn > > They were obtained by sending a request to > ietf-pkix-oid-reg@imc.org. When the PKIX WG closes, > this arc and registration procedures will be transferred > to IANA. No further action by IANA is necessary for this > document or any anticipated updates. From SChokhani@cygnacom.com Thu Jun 10 18:18:35 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5D63A68C8; Thu, 10 Jun 2010 18:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, 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 ORrO3exq3QCa; Thu, 10 Jun 2010 18:18:34 -0700 (PDT) Received: from mail75.messagelabs.com (mail75.messagelabs.com [216.82.250.3]) by core3.amsl.com (Postfix) with SMTP id F3D273A68AA; Thu, 10 Jun 2010 18:18:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: SChokhani@cygnacom.com X-Msg-Ref: server-8.tower-75.messagelabs.com!1276219114!94418028!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.19] Received: (qmail 29481 invoked from network); 11 Jun 2010 01:18:35 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.19) by server-8.tower-75.messagelabs.com with SMTP; 11 Jun 2010 01:18:35 -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 Date: Thu, 10 Jun 2010 21:18:33 -0400 Message-ID: In-Reply-To: <8739wuej34.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] Thread-Index: AcsI2mXcUs38m5trTNi+CvMoiCWxBgAKKTOw References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org><87sk4vhtpr.fsf@mocca.josefsson.org><87typbgeay.fsf@mocca.josefsson.org> <8739wuej34.fsf@mocca.josefsson.org> From: "Santosh Chokhani" To: "Simon Josefsson" , "Len Sassaman" X-Mailman-Approved-At: Thu, 10 Jun 2010 18:48:46 -0700 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 01:18:35 -0000 Len, I agree with Simon. Security strength of hash in self-signed certificate is irrelevant. It is an untrusted object. You might use the world's weakest hash or not sign it at all. That said, if you process that MD2, you may end up invoking it for other certificates. But, as Open SSL folks posted in this thread, they do not verify signatures on self-signed certificates, obviating the need for MD2. > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of > Simon Josefsson > Sent: Thursday, June 10, 2010 4:20 PM > To: Len Sassaman > Cc: pkix@ietf.org; cfrg@irtf.org; saag@ietf.org; smime@ietf.org > Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic- > 00.txt] >=20 > Len Sassaman writes: >=20 > > On Thu, 10 Jun 2010, Simon Josefsson wrote: > > > >> I don't see how that gains you anything: you still need to make > clients > >> place trust in the new CA, and if the attacker has that ability, all > >> bets are off. > > > > The clients trust the new CA because it is an intermediate CA chained > > to the original, MD2-signed top-level CA. The intermediate cert is > > then treated with the same validity as *any* intermediate cert > > generated by that top-level cert -- since the top-level cert's > > signature verifies correctly on the intermediate cert, of course. > > > > Do you understand the attack now? >=20 > Yes, I do, but that attack is not caused by a MD2 root. The attack is > caused by software trusting MD2 to verify digital signatures. I > believe > the latter has been resolved in most security libraries already (it > certainly has been resolved in GnuTLS, since January 2009, which treats > both MD2 and MD5 as insecure). >=20 > The former case (a MD2 root) is not a problem by itself, as far as I > can > tell, which is what I originally stated. >=20 > As long as MD2 roots have not been shown to be a problem, by > themselves, > protocols and software will need to continue implement MD2 for > operational reasons. There are still several MD2 roots in recently > shipping operating systems. For example, my Ubuntu 10.04 LTS system > has > these RSA-MD2 roots: >=20 > ./mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt: > Issuer: C=3DUS,O=3DVeriSign\, Inc.,OU=3DClass 1 Public Primary > Certification Authority > ./mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt > Issuer: C=3DUS,O=3DVeriSign\, Inc.,OU=3DClass 3 Public Primary > Certification Authority > ./mozilla/Verisign_RSA_Secure_Server_CA.crt > Issuer: C=3DUS,O=3DRSA Data Security\, Inc.,OU=3DSecure Server > Certification Authority > ./mozilla/Verisign_Class_2_Public_Primary_Certification_Authority.crt > Issuer: C=3DUS,O=3DVeriSign\, Inc.,OU=3DClass 2 Public Primary > Certification Authority >=20 > Right now, I think my preference would be to update RFC 1319 with > something like Sean's document, to alert everyone of the security > issues, but let the status of the algorithm description remain > Informational. >=20 > /Simon > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From pgut001@cs.auckland.ac.nz Thu Jun 10 19:50:19 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F443A6940; Thu, 10 Jun 2010 19:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 IL3Kp+NtazDf; Thu, 10 Jun 2010 19:50:18 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id E6A673A679F; Thu, 10 Jun 2010 19:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1276224621; x=1307760621; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20lists@drh-consultancy.demon.co.uk,=20smime@ietf.or g|Subject:=20Re:=20[pkix]=20[smime]=20[Fwd:=20I-D=20ACTIO N:draft-turner-md2-to-historic-00.txt]|Cc:=20pkix@ietf.or g|In-Reply-To:=20<4C1127A5.70407@drh-consultancy.demon.co .uk>|Message-Id:=20|Date:=20Fri,=2011=20Jun=202010=2014:50:17=20 +1200; bh=4OGg9VkVpu7vECt447Bdin9eM42CKGLBMnYy4s4wags=; b=lnDFwiVgFFnOUdLzKYHTrU1jhKMAnKmmY5HKtn+F/aEBBvrE04Af4rRh kkq/JFhLzoAx4yVY/DicA4pELRzc87eoruMLXQGSP0NrQn+oP9+vNCPR/ aChBpvZ7HFYTuO/dAif9pqiSmxb/OoyTEC3z+tw7lXJ3TupuEepuC+UFz I=; X-IronPort-AV: E=Sophos;i="4.53,401,1272801600"; d="scan'208";a="10553451" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jun 2010 14:50:18 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OMuK1-0002QW-GT; Fri, 11 Jun 2010 14:50:17 +1200 From: Peter Gutmann To: lists@drh-consultancy.demon.co.uk, smime@ietf.org In-Reply-To: <4C1127A5.70407@drh-consultancy.demon.co.uk> Message-Id: Date: Fri, 11 Jun 2010 14:50:17 +1200 Cc: pkix@ietf.org Subject: Re: [smime] [pkix] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 02:50:19 -0000 Dr Stephen Henson writes: >The self signed root CA issue was worked around by disabling the signature >check on the root CA by default, since it is redundant. What about catching accidental data corruption? It still acts as an integrity check, even if it's not an authenticity check. (I recently ran into a situation where mangled PEM-encoding had corrupted portions of CA root certs, and in some cases only the sig check would have caught it). Peter. From pgut001@cs.auckland.ac.nz Thu Jun 10 19:58:49 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0123A69AC; Thu, 10 Jun 2010 19:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.488, 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 wfp79rxq3QMO; Thu, 10 Jun 2010 19:58:48 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id D2E783A681F; Thu, 10 Jun 2010 19:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1276225131; x=1307761131; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20Len.Sassaman@esat.kuleuven.be,=20simon@josefsson.o rg|Subject:=20Re:=20[Cfrg]=20[Fwd:=20I-D=20ACTION:draft-t urner-md2-to-historic-00.txt]|Cc:=20cfrg@irtf.org,=20pkix @ietf.org,=20saag@ietf.org,=20smime@ietf.org,=0D=0A=20=20 =20=20turners@ieca.com|In-Reply-To:=20|Message-Id:=20|Date:=20 Fri,=2011=20Jun=202010=2014:58:49=20+1200; bh=q+Y7TzdMHTtRIm2gaHbjhVyJtG4MdnAPEJbaFFGEJWA=; b=H3R/uHh2vEPdjv58qPdxo8LRwIZybXS53MQ28EzDJcxN34LKrZH1Y+gL qEZomeqR/iV2NFNp9IS/4ttZBQS+vpNyUkUV6NnaPDibh8TOQnr0mIJpd gPwoC5wf7dx+I9nY6kzIpq3LSFAvftIEewWdAPToBQAVnOvq1UDQlZ79Q U=; X-IronPort-AV: E=Sophos;i="4.53,401,1272801600"; d="scan'208";a="10555471" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jun 2010 14:58:49 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OMuSH-0002U8-7p; Fri, 11 Jun 2010 14:58:49 +1200 From: Peter Gutmann To: Len.Sassaman@esat.kuleuven.be, simon@josefsson.org In-Reply-To: Message-Id: Date: Fri, 11 Jun 2010 14:58:49 +1200 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [Cfrg] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 02:58:49 -0000 Len Sassaman writes: >(At least, I personally verifed Chrome and FireFox. I *think* IE and Opera >were patched, too -- they should be.) So now we hope that browsers released >prior to mid-2009 are retired from use before MD2 is broken in practice. >Given the longevity of browsers, it's going to be close. I assume you're thinking of IE6 there :-). Was the fix done in CryptoAPI or in the browser itself? If it was an update to CryptoAPI then even IE6 should be OK (can anyone from MS comment on this?). Peter. From denis.pinkas@bull.net Fri Jun 11 05:37:07 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE693A68E7; Fri, 11 Jun 2010 05:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.189 X-Spam-Level: ** X-Spam-Status: No, score=2.189 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_BAD_ID=2.837] 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 I2ckD-I095og; Fri, 11 Jun 2010 05:37:05 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id 6DABC3A6973; Fri, 11 Jun 2010 05:37:04 -0700 (PDT) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id C79C11803E; Fri, 11 Jun 2010 14:41:37 +0200 (CEST) Received: from FRCLS4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2010061114370404:63330 ; Fri, 11 Jun 2010 14:37:04 +0200 From: "Denis Pinkas" To: "=?iso-8859-1?B?Sm9yZ2UgTPNwZXo=?=", "liaquat.khan" Date: Fri, 11 Jun 2010 14:37:03 +0200 Message-Id: References: MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 11/06/2010 14:37:04, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 11/06/2010 14:37:05, Serialize complete at 11/06/2010 14:37:05 Content-Type: multipart/alternative; boundary="----=_NextPart_10061114370341645580440_002" Cc: smime , pkix Subject: Re: [smime] [pkix] Research question: Witnessing by digital signature X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: denis.pinkas@bull.net List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 12:37:07 -0000 ------=_NextPart_10061114370341645580440_002 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Jorge, Since it is a topic more related to S/MIME, I copy the SMIME list and I s= uggest that the next message is no more sent to the PKIX list. I agree that the current notion of signature policy should not be changed= since it applies to a single electronic signature. If you prepare a draft for an "extended policy" (the right wording still = needs to be found), then I am interrested to read the draft. The next question will then be: should this "formal" definition be done u= sing XML or/and ASN.1 ? :-) Denis ----- Message re=E7u -----=20 De : Jorge L=F3pez=20 =C0 : Liaquat Khan=20 Date : 2010-06-11, 14:24:30 Sujet : Re: [pkix] Research question: Witnessing by digital signature Hi again Liaquat, I agree with you that, in this context, generation and verification rules= should be specified in a signature policy. The problem is that, currentl= y, ETSI Signature Policy (or analog RFC 3125) cannot deal with multiple s= ignatures. There is no way of binding one signature with another, neither= when they are parallel/sequential nor embedded. =20 In addition, verification procedures for a tree of signatures is not as s= imple as you may think. Among others, tree matching issues appear, and th= ere is not simple algorithm for that, specially when nodes of the tree ke= ep so much semantic information such as the certificate used, the signatu= re policy to which they adhere, timing data, commitment type made, etc. T= he algorithm complexity is non-linear with the increase of the tree depth= or tree width.=20 IMHO, there were two possibilities: modifying/extending current definitio= n of signature policy (under my viewpoint, not recommended at all), or pr= oposing another extended policy to cope with these needs, and that could = be easily integrated with the current one. The latter was my choice. Kind regards, Jorge. 2010/6/11 Liaquat Khan Hi Jorge You are correct with regards to this stage of PEPPOL, but this doesn=92t = mean it=92s against using automated processes in future. My main point w= as that regardless of manual or automated approach, the policy for how mu= ltiple signatures should be applied seems appropriate subject for the Sig= ning Policy. Putting this in a separate =93policy=94 will just make thi= ngs more complicated IMO as its yet another policy to process for the sig= nature verification application.=20 Regards LK =20 From: Jorge L=F3pez [mailto:jlopez.ha@gmail.com]=20 Sent: 11 June 2010 14:26 To: Liaquat Khan Cc: Pope, Nick; pkix; denis.pinkas@bull.net Subject: Re: [pkix] Research question: Witnessing by digital signature Dear Liaquat, (sorry if I have missed some information) I have skim read document D1.1 = Part 3: Signature Policies, and it seems that the Project uses ETSI Signa= ture Policies, and that the "binding" between the multiple signatures (wh= en needed) is made in human-readable documents rather than by means of au= tomated processes. Am I right? Jorge. 2010/6/11 Liaquat Khan Note the large European project =93PEPPOL=94 (Pan-European Public Procure= ment On-Line) considers multiple signature options as part of the Signatu= re Policy. It seems logical place to me. =20 Regards LK From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of J= orge L=F3pez Sent: 11 June 2010 13:22 To: Pope, Nick Cc: pkix; denis.pinkas@bull.net Subject: Re: [pkix] Research question: Witnessing by digital signature Mmm, not so sure about that. Current signature policy is already transact= ion/document oriented, as it establishes the requirements to be fulfilled= for the generation and validation of the signature, but within the trans= action scope. There are fields that specifically fix the business/transac= tional context. The necessity I mentioned is what happens when more than = one signature is needed to complete the transaction. Well, you could do that at document/application level, but the cumbersome= is guaranteed. An extended signature policy, like the one proposed in th= e aforementioned paper, can fill that gap in a seamlessly manner, and not= application-dependent one. Regards, Jorge. 2010/6/11 Pope, Nick Denis, With PDF's this is handled by producing a document template with the layo= ut including the placement of signatures. I think this is an issue for t= he document standards applying signatures not for signatures standards. Nick -----Original Message----- From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of D= enis Pinkas Sent: 11 June 2010 09:54 To: Jorge L=F3pez; swilson Cc: pkix Subject: Re: [pkix] Research question: Witnessing by digital signature Hi, You are right: there is no signature policy standard or technical documen= t that helped to establish the dependences and relationships among severa= l signatures. The current concept of "signature policy" applies to a single signature.=20 If a document has multiple signatures, each one can be done under a diffe= rent signature policy. So the "missing" concept is a "document signature policy" (not to be conf= used with a "signature policy") which would tell,=20 how many electronic signatures are needed, which signature policies are a= cceptable for each one, whether they need to be parallel=20 or embedded, which commitment types must be present, etc ... This combination of criteria could be important and all these verificatio= ns are currently left to the application. It is questionnable whether this should be standardized now or left to th= e application. Denis ----- Message re=E7u -----=20 De : Jorge L=F3pez=20 =C0 : Stephen Wilson=20 Date : 2010-06-11, 10:17:44 Sujet : Re: [pkix] Research question: Witnessing by digital signature Hi,=20 Among other open issues, a technical one lies in the fact that currently = there is no signature policy standard or technical document that helped t= o establish the dependences and relationships among several signatures to= make them legally binding. It would be the scenario of a witness or nota= ry, who must countersign a former signature to make the transaction effec= tive. This limitation was pointed out by ETSI in a technical report publi= shed in 2003 [1]. To the best of my knowledge, little research has been d= one in this direction [2]. Regards, [1] ETSI TR 102 045 - Electronic Signatures and Infrastructures (ESI); Si= gnature policy for extended business model v1.1.1. European Telecommunica= tions Standards Institute (ETSI), March 2003 [2] Jorge L. Hernandez-Ardieta, Ana I. Gonzalez-Tablas, Benjamin Ramos an= d Arturo Ribagorda. Extended Electronic Signature Policies. 2nd ACM Inter= national Conference on Security of Information and Networks (SIN 2009), p= p. 268--277, ACM Press. North Cyprus. 2009. 2010/6/10 Stephen Wilson Has any work been done in PKIX or elsewhere on formal witnessing of digit= al signatures? And/or ... does anyone in the group know of real life ins= tances where a digital signature is witnesses and attested to using anoth= er dig sig?=20 Cheers, Stephen Wilson Managing Director Lockstep Group Phone +61 (0)414 488 851 www.lockstep.com.au Lockstep Consulting provides independent specialist advice and analysis on digital identity and privacy. Lockstep Technologies develops unique new smart ID solutions that enhance privacy and prevent identity theft. _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix Consider the environment before printing this mail. "Thales e-Security Limited is incorporated in England and Wales with comp= any registration number 2518805. Its registered office is located at 2 Da= shwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Su= rrey KT15 2NX. The information contained in this e-mail is confidential. It may also be = privileged. It is only intended for the stated addressee(s) and access to= it by any other person is unauthorised. If you are not an addressee or t= he intended addressee, you must not disclose, copy, circulate or in any o= ther way use or rely on the information contained in this e-mail. Such un= authorised use may be unlawful. If you have received this e-mail in error= please delete it (and all copies) from your system, please also inform u= s immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.= com. Commercial matters detailed or referred to in this e-mail are subjec= t to a written contract signed for and on behalf of Thales e-Security Lim= ited".=20 ------=_NextPart_10061114370341645580440_002 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Jorge,
 
Since it is a topic more related to S/MIME, I copy the SMIME list an= d=20 I suggest that the next message is no more sent to the PKIX=20 list.
 
I agree that the current notion of signature policy should not be ch= anged=20 since it applies to a single electronic signature.
 
If you prepare a draft for an "extended policy" (the right wording s= till=20 needs to be found), then I am interrested to read the draft.
 
The next question will then be: should this "formal" definition= be=20 done using XML or/and ASN.1 ? :-)
 
Denis
 
-----=20 Message re=E7u ----- De=20 : Jorge L=F3pez =C0=20 : Liaquat Khan Date=20 : 2010-06-11, 14:24:30 Sujet=20 : Re: [pkix] Research question: Witnessing by digital signature

Hi again Liaquat,

I agree with you that, in this context, generation and verificatio= n rules=20 should be specified in a signature policy. The problem is that, current= ly,=20 ETSI Signature Policy (or analog RFC 3125) cannot deal with multiple=20 signatures. There is no way of binding one signature with another, neit= her=20 when they are parallel/sequential nor embedded.  

In addition, verification procedures for a tree of signatures is n= ot as=20 simple as you may think. Among others, tree matching issues appear, and= there=20 is not simple algorithm for that, specially when nodes of the tree keep= so=20 much semantic information such as the certificate used, the signature p= olicy=20 to which they adhere, timing data, commitment type made, etc. The algor= ithm=20 complexity is non-linear with the increase of the tree depth or tree=20 width. 

IMHO, there were two possibilities: modifying/extending current=20 definition of signature policy (under my viewpoint, not recommended at = all),=20 or proposing another extended policy to cope with these needs, and that= could=20 be easily integrated with the current one. The latter was my choice.

Kind regards,

Jorge.

2010/6/11 Liaquat Khan <liaquat.khan@ascertia.com= >

= Hi=20 Jorge

 

= You are=20 correct with regards to this stage of PEPPOL, but this doesn=92t mean= it=92s=20 against using automated processes in future.  My main point was = that=20 regardless of manual or automated approach, the policy for how multip= le=20 signatures should be applied seems appropriate subject for the Signin= g=20 Policy.   Putting this in a separate =93policy=94 will just= make=20 things more complicated IMO as its yet another policy to process for = the=20 signature verification application.

 

Regards

= LK=20  

 

 

 

From: Jorge L=F3pez [mailto:jlopez.ha@gmail.c= om]=20
Sent: 11 June 2010 14:26
To: Liaquat Khan
= Cc:=20 Pope, Nick; pkix; denis.pinkas@bull.net


Subject: Re: [pkix] Research question: Wit= nessing=20 by digital signature

 

Dear Liaquat,

 

(sorry if I have missed some information) I have= skim=20 read document D1.1 Part 3: Signature Policies, and it seems that= the=20 Project uses ETSI Signature Policies, and that the "binding" between = the=20 multiple signatures (when needed) is made in human-readable documents= rather=20 than by means of automated processes. Am I right?

 

Jorge.

 

2010/6/11 Liaquat Khan <liaquat.khan@ascertia.com>

= Note the=20 large European project =93PEPPOL=94 (Pan-European Public Procurement = On-Line)=20 considers multiple signature options as part of the Signature Policy.=  =20  It seems logical place to me. 

 

Regards

LK

 

From: pkix-bounces@ietf.org [mailto:pkix-bounces@ie= tf.org]=20 On Behalf Of Jorge L=F3pez
Sent: 11 June 2010=20 13:22
To: Pope, Nick
Cc: pkix; denis.pinkas@bull.net


Subject: Re: [pkix] Research question= :=20 Witnessing by digital signature

 

Mmm, not so sure about that. Current signature p= olicy is=20 already transaction/document oriented, as it establishes the requirem= ents to=20 be fulfilled for the generation and validation of the signature, but = within=20 the transaction scope. There are fields that specifically fix the=20 business/transactional context. The necessity I mentioned is what hap= pens=20 when more than one signature is needed to complete the transaction.

 

Well, you could do that at document/application = level,=20 but the cumbersome is guaranteed. An extended signature policy, like = the one=20 proposed in the aforementioned paper, can fill that gap in a seamless= ly=20 manner, and not application-dependent one.

 

Regards,

 

Jorge.

 

2010/6/11 Pope, Nick <Nick.Pope@thales-esecurity.com>

Denis,

 

With PDF's this = is handled=20 by producing a document template with the layout including the placem= ent of=20 signatures.  I think this is an issue for the document standards= =20 applying signatures not for signatures standards.

 

Nick

<= /DIV>

-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Deni= s=20 Pinkas
Sent: 11 June 2010 09:54
To: Jorge L=F3p= ez;=20 swilson
Cc: pkix
Subject: Re: [pkix] Research=20 question: Witnessing by digital signature

Hi,

=

 <= /P>

You are right:= there is=20 no signature policy standard or technical document that helped to=20 establish the dependences and relationships among several=20 signatures.

 <= /P>

The current co= ncept of=20 "signature policy" applies to a single signature.
If a document= has=20 multiple signatures, each one can be done under a different signatu= re=20 policy.

 <= /P>

So the "missin= g" concept=20 is a "document signature policy" (not to be confused with  a=20 "signature policy") which would tell,
how many electronic signa= tures=20 are needed, which signature policies are acceptable for each one, w= hether=20 they need to be parallel
or embedded, which commitment types mu= st be=20 present, etc ...

 <= /P>

This comb= ination of=20 criteria could be important and all these verifications are current= ly left=20 to the application.

It is question= nable=20 whether this should be standardized now or left to the=20 application.

 <= /P>

Denis

 

----- Message= re=E7u -----=20

De :=20 Jorge L=F3pez

=C0 : Stephen Wilson

Date=20 : 2010-06-11,=20 10:17:44

Sujet=20 : Re: [pkix] Research q= uestion:=20 Witnessing by digital signature

 

Hi, <= /P>

 = ;

Among other = open=20 issues, a technical one lies in the fact that currently there is = no=20 signature policy standard or technical document that helped to es= tablish=20 the dependences and relationships among several signatures to mak= e them=20 legally binding. It would be the scenario of a witness or notary,= who=20 must countersign a former signature to make the transaction=20 effective. This limitation was pointed out by ETSI in a= =20 technical report published in 2003 [1]. To the best of my=20 knowledge, little research has been done in this direction=20 [2].

 = ;

Regards,

 = ;

[1] ETS= I TR 102=20 045 - Electronic Signatures and Infrastructures (ESI); Signa= ture=20 policy for extended business model v1.1.1. European=20 Telecommunications

Standards In= stitute=20 (ETSI), March 2003

[2] Jor= ge L.=20 Hernandez-Ardieta, Ana I. Gonzalez-Tablas, Benjamin Ramos and Art= uro=20 Ribagorda. Extended Electronic Signature Policies. 2nd ACM Intern= ational=20 Conference on Security of Information and Networks (SIN 2009), pp= .=20 268--277, ACM Press. North Cyprus. 2009.

 = ;

2010/6/10 St= ephen=20 Wilson <swilson@lockstep.com.au>


Has any = work been=20 done in PKIX or elsewhere on formal witnessing of digital signatu= res?=20  And/or ... does anyone in the group know of real life insta= nces=20 where a digital signature is witnesses and attested to using anot= her dig=20 sig?
Cheers,

Stephen Wilson
Managing Director
Lo= ckstep=20 Group

Phone +61 (0)414 488 851

www.lockstep.= com.au=20 <http://www.lockstep.com.au>
Lockstep Co= nsulting=20 provides independent specialist advice and analysis
on digital= =20 identity and privacy.  Lockstep Technologies develops unique=
new=20 smart ID solutions that enhance privacy and prevent identity=20 theft.



___________________________________________= ____
pkix=20 mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

 

Consider the environment = before=20 printing this mail.

"Thales e-Security Limited i= s=20 incorporated in England and Wales with company registration number 25= 18805.=20 Its registered office is located at 2 Dashwood Lang Road, The Bourne=20 Business Park, Addlestone, Nr. Weybridge, Surrey KT15=20 2NX.

The information contained in= this=20 e-mail is confidential. It may also be privileged. It is only intende= d for=20 the stated addressee(s) and access to it by any other person is=20 unauthorised. If you are not an addressee or the intended addressee, = you=20 must not disclose, copy, circulate or in any other way use or rely on= the=20 information contained in this e-mail. Such unauthorised use may be un= lawful.=20 If you have received this e-mail in error please delete it (and all c= opies)=20 from your system, please also inform us immediately on +44 (0)1844 20= 1800 or=20 email postmaster@thales-esecurity.com. Commercial matte= rs=20 detailed or referred to in this e-mail are subject to a written contr= act=20 signed for and on behalf of Thales e-Security Limited".=20

 

 

=
------=_NextPart_10061114370341645580440_002-- From jlopez.ha@gmail.com Fri Jun 11 05:47:41 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0EF13A657C for ; Fri, 11 Jun 2010 05:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yyGxyr+qgwUa for ; Fri, 11 Jun 2010 05:47:39 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 09A373A6979 for ; Fri, 11 Jun 2010 05:47:38 -0700 (PDT) Received: by wwc33 with SMTP id 33so690080wwc.31 for ; Fri, 11 Jun 2010 05:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=tokkOdrJ2vYIHn8+VvVX2XumRcMcdAMKVVVe2Nh5VrY=; b=OysAPU80gY5OiYqTJfaQ7gua6V6YxK2UD6OWSPv4o+Nso8X7y0KU5Mn/EYur6OTnyg 74Y/yhVJfOmlL9p+xCmlOdU0dnDEThkU99zXMWhdyax8fAebu/pijhHU7ZxnCv/urx8Z 9DegHxDIn7tr00SvzvQ3TbAyKGM9if0jZAmac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Jr2WAkeR6+X8HsXgZGXUaOrPrudSA82dokAS/atxuY3R4zPOqv4oft2EmDV0KoCYrK kmUfFrXzJoOIQIT61X/G9hIhfRTvHIc7LMX0xUgcJSxfCV9G7V40ZUyEbAX0Xz1dyjjE tEYR96jyEbVXs8T9copxWNQYPC/pfp7vhgkUY= MIME-Version: 1.0 Received: by 10.227.127.131 with SMTP id g3mr1792342wbs.129.1276260456560; Fri, 11 Jun 2010 05:47:36 -0700 (PDT) Received: by 10.216.20.141 with HTTP; Fri, 11 Jun 2010 05:47:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Jun 2010 14:47:36 +0200 Message-ID: From: =?ISO-8859-1?Q?Jorge_L=F3pez?= To: denis.pinkas@bull.net Content-Type: multipart/alternative; boundary=00163683306027797a0488c08be3 X-Mailman-Approved-At: Fri, 11 Jun 2010 08:08:29 -0700 Cc: "liaquat.khan" , smime Subject: Re: [smime] [pkix] Research question: Witnessing by digital signature X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 12:47:41 -0000 --00163683306027797a0488c08be3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Denis, Thanks for the interest. BTW, the paper can be a good starting point, where I define the "extended policy" using ASN.1 notation. On the contrary, in my doctoral thesis, I have carried out an implementation in XML. I think that both definitions apply, since ETSI has delivered Signature Policy definitions both in XML (ETSI 038) and ASN.1 (ETSI 272), and both "XML-based and ASN.1 based transactions" should benefit from it. However, and following IETF basis, I would suggest to prepare an I-D in ASN.1 in the first instance. Jorge. 2010/6/11 Denis Pinkas > Jorge, > > Since it is a topic more related to S/MIME, I copy the SMIME list and > I suggest that the next message is no more sent to the PKIX list. > > I agree that the current notion of signature policy should not be change= d > since it applies to a single electronic signature. > > If you prepare a draft for an "extended policy" (the right wording still > needs to be found), then I am interrested to read the draft. > > The next question will then be: should this "formal" definition be done > using XML or/and ASN.1 ? :-) > > Denis > > > ----- Message re=E7u ----- > *De :* Jorge L=F3pez > *=C0 :* Liaquat Khan > *Date :* 2010-06-11, 14:24:30 > *Sujet :* Re: [pkix] Research question: Witnessing by digital signature > > Hi again Liaquat, > > I agree with you that, in this context, generation and verification rules > should be specified in a signature policy. The problem is that, currently= , > ETSI Signature Policy (or analog RFC 3125) cannot deal with multiple > signatures. There is no way of binding one signature with another, neithe= r > when they are parallel/sequential nor embedded. > > In addition, verification procedures for a tree of signatures is not as > simple as you may think. Among others, tree matching issues appear, and > there is not simple algorithm for that, specially when nodes of the tree > keep so much semantic information such as the certificate used, the > signature policy to which they adhere, timing data, commitment type made, > etc. The algorithm complexity is non-linear with the increase of the tree > depth or tree width. > > IMHO, there were two possibilities: modifying/extending current definitio= n > of signature policy (under my viewpoint, not recommended at all), or > proposing another extended policy to cope with these needs, and that coul= d > be easily integrated with the current one. The latter was my choice. > > Kind regards, > > Jorge. > > 2010/6/11 Liaquat Khan > >> Hi Jorge >> >> >> >> You are correct with regards to this stage of PEPPOL, but this doesn=92t >> mean it=92s against using automated processes in future. My main point = was >> that regardless of manual or automated approach, the policy for how mult= iple >> signatures should be applied seems appropriate subject for the Signing >> Policy. Putting this in a separate =93policy=94 will just make things = more >> complicated IMO as its yet another policy to process for the signature >> verification application. >> >> >> >> Regards >> >> LK >> >> >> >> >> >> >> >> *From:* Jorge L=F3pez [mailto:jlopez.ha@gmail.com] >> *Sent:* 11 June 2010 14:26 >> *To:* Liaquat Khan >> *Cc:* Pope, Nick; pkix; denis.pinkas@bull.net >> >> *Subject:* Re: [pkix] Research question: Witnessing by digital signature >> >> >> >> Dear Liaquat, >> >> >> >> (sorry if I have missed some information) I have skim read document D1.1 >> Part 3: Signature Policies, and it seems that the Project uses ETSI >> Signature Policies, and that the "binding" between the multiple signatur= es >> (when needed) is made in human-readable documents rather than by means o= f >> automated processes. Am I right? >> >> >> >> Jorge. >> >> >> >> 2010/6/11 Liaquat Khan >> > >> >> Note the large European project =93PEPPOL=94 (Pan-European Public Procur= ement >> On-Line) considers multiple signature options as part of the Signature >> Policy. It seems logical place to me. >> >> >> >> Regards >> >> LK >> >> >> >> *From:* pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] *On Behalf >> Of *Jorge L=F3pez >> *Sent:* 11 June 2010 13:22 >> *To:* Pope, Nick >> *Cc:* pkix; denis.pinkas@bull.net >> >> >> *Subject:* Re: [pkix] Research question: Witnessing by digital signature >> >> >> >> Mmm, not so sure about that. Current signature policy is already >> transaction/document oriented, as it establishes the requirements to be >> fulfilled for the generation and validation of the signature, but within= the >> transaction scope. There are fields that specifically fix the >> business/transactional context. The necessity I mentioned is what happen= s >> when more than one signature is needed to complete the transaction. >> >> >> >> Well, you could do that at document/application level, but the cumbersom= e >> is guaranteed. An extended signature policy, like the one proposed in th= e >> aforementioned paper, can fill that gap in a seamlessly manner, and not >> application-dependent one. >> >> >> >> Regards, >> >> >> >> Jorge. >> >> >> >> 2010/6/11 Pope, Nick >> >> Denis, >> >> >> >> With PDF's this is handled by producing a document template with the >> layout including the placement of signatures. I think this is an issue = for >> the document standards applying signatures not for signatures standards. >> >> >> >> Nick >> >> -----Original Message----- >> *From:* pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] *On Behalf >> Of *Denis Pinkas >> *Sent:* 11 June 2010 09:54 >> *To:* Jorge L=F3pez; swilson >> *Cc:* pkix >> *Subject:* Re: [pkix] Research question: Witnessing by digital signature >> >> Hi, >> >> >> >> You are right: there is no signature policy standard or technical docume= nt >> that helped to establish the dependences and relationships among several >> signatures. >> >> >> >> The current concept of "signature policy" applies to a single signature. >> If a document has multiple signatures, each one can be done under a >> different signature policy. >> >> >> >> So the "missing" concept is a "document signature policy" (not to be >> confused with a "signature policy") which would tell, >> how many electronic signatures are needed, which signature policies are >> acceptable for each one, whether they need to be parallel >> or embedded, which commitment types must be present, etc ... >> >> >> >> This combination of criteria could be important and all these >> verifications are currently left to the application. >> >> It is questionnable whether this should be standardized now or left to t= he >> application. >> >> >> >> Denis >> >> >> >> ----- Message re=E7u ----- >> >> *De :* Jorge L=F3pez >> >> *=C0 :* Stephen Wilson >> >> *Date :* 2010-06-11, 10:17:44 >> >> *Sujet :* Re: [pkix] Research question: Witnessing by digital signature >> >> >> >> Hi, >> >> >> >> Among other open issues, a technical one lies in the fact that currently >> there is no signature policy standard or technical document that helped = to >> establish the dependences and relationships among several signatures to = make >> them legally binding. It would be the scenario of a witness or notary, w= ho >> must countersign a former signature to make the transaction >> effective. This limitation was pointed out by ETSI in a technical >> report published in 2003 [1]. To the best of my knowledge, little resear= ch >> has been done in this direction [2]. >> >> >> >> Regards, >> >> >> >> [1] ETSI TR 102 045 - Electronic Signatures and Infrastructures (ESI); >> Signature policy for extended business model v1.1.1. European >> Telecommunications >> >> Standards Institute (ETSI), March 2003 >> >> [2] Jorge L. Hernandez-Ardieta, Ana I. Gonzalez-Tablas, Benjamin Ramos a= nd >> Arturo Ribagorda. Extended Electronic Signature Policies. 2nd ACM >> International Conference on Security of Information and Networks (SIN 20= 09), >> pp. 268--277, ACM Press. North Cyprus. 2009. >> >> >> >> 2010/6/10 Stephen Wilson >> >> >> Has any work been done in PKIX or elsewhere on formal witnessing of >> digital signatures? And/or ... does anyone in the group know of real li= fe >> instances where a digital signature is witnesses and attested to using >> another dig sig? >> Cheers, >> >> Stephen Wilson >> Managing Director >> Lockstep Group >> >> Phone +61 (0)414 488 851 >> >> www.lockstep.com.au >> Lockstep Consulting provides independent specialist advice and analysis >> on digital identity and privacy. Lockstep Technologies develops unique >> new smart ID solutions that enhance privacy and prevent identity theft. >> >> >> >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix >> >> >> >> *Consider the environment before printing this mail.* >> >> *"Thales e-Security Limited is incorporated in England and Wales with >> company registration number 2518805. Its registered office is located at= 2 >> Dashwood Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, >> Surrey KT15 2NX.* >> >> *The information contained in this e-mail is confidential. It may also b= e >> privileged. It is only intended for the stated addressee(s) and access t= o it >> by any other person is unauthorised. If you are not an addressee or the >> intended addressee, you must not disclose, copy, circulate or in any oth= er >> way use or rely on the information contained in this e-mail. Such >> unauthorised use may be unlawful. If you have received this e-mail in er= ror >> please delete it (and all copies) from your system, please also inform u= s >> immediately on +44 (0)1844 201800 or email >> postmaster@thales-esecurity.com. Commercial matters detailed or referred >> to in this e-mail are subject to a written contract signed for and on be= half >> of Thales e-Security Limited".* >> >> >> >> >> > > --00163683306027797a0488c08be3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Denis,

Thanks for the interest. BTW, the paper can be a = good starting point, where I define the "extended policy" using A= SN.1 notation. On the contrary, in my doctoral thesis, I have carried out a= n implementation in XML.=A0

I think that both definitions apply, since ETSI has del= ivered Signature Policy definitions both in XML (ETSI 038) and ASN.1 (ETSI = 272), and both "XML-based and ASN.1 based transactions" should be= nefit from it.

However, and=A0following IETF basis,=A0I would suggest = to prepare an I-D in ASN.1 in the first instance.

= Jorge.

2010/6/11 Denis Pinkas <denis.pinkas@bull.net= >
Jorge,
=A0
Since it is a topic more related to S/MIME, I copy the SMIME list and= =20 I=A0suggest that the next message is no more sent=A0to the PKIX=20 list.
=A0
I agree that the current notion of signature policy should not be chan= ged=20 since it applies to a single electronic signature.
=A0
If you prepare a draft for an "extended policy" (the right w= ording still=20 needs to be found), then I am interrested to read the draft.
=A0
The next question will then=A0be: should this "formal" defin= ition be=20 done using XML or/and ASN.1 ? :-)
=A0
Denis
=A0
-----=20 Message re=E7u -----
De=20 : Jorge L=F3pez
=C0=20 : Liaquat Khan
Date=20 : 2010-06-11, 14:24:30
Sujet=20 : Re: [pkix] Research question: Witnessing by digital signature

Hi again Liaquat,

I agree with you that, in this context, generation and verification = rules=20 should be specified in a signature policy. The problem is that, currently= ,=20 ETSI Signature Policy (or analog RFC 3125) cannot deal with multiple=20 signatures. There is no way of binding one signature with another, neithe= r=20 when they are parallel/sequential nor embedded. =A0

In addition, verification procedures for a tree of signatures is not= as=20 simple as you may think. Among others, tree matching issues appear, and t= here=20 is not simple algorithm for that, specially when nodes of the tree keep s= o=20 much semantic information such as the certificate used, the signature pol= icy=20 to which they adhere, timing data, commitment type made, etc. The algorit= hm=20 complexity is non-linear with the increase of the tree depth or tree=20 width.=A0

IMHO, there were two possibilities: modifying/extending current=20 definition of signature policy (under my viewpoint, not recommended at al= l),=20 or proposing another extended policy to cope with these needs, and that c= ould=20 be easily integrated with the current one. The latter was my choice.

Kind regards,

Jorge.

2010/6/11 Liaquat Khan <<= a href=3D"mailto:liaquat.khan@ascertia.com" target=3D"_blank">liaquat.khan@= ascertia.com>

Hi= =20 Jorge

=A0

You= are=20 correct with regards to this stage of PEPPOL, but this doesn=92t mean i= t=92s=20 against using automated processes in future.=A0 My main point was that= =20 regardless of manual or automated approach, the policy for how multiple= =20 signatures should be applied seems appropriate subject for the Signing= =20 Policy. =A0=A0Putting this in a separate =93policy=94 will just make=20 things more complicated IMO as its yet another policy to process for th= e=20 signature verification application.

=A0

Reg= ards

LK= =20 =A0

=A0

=A0

=A0

From: Jorge L=F3p= ez [mailto:jlopez.= ha@gmail.com]=20
Sent: 11 June 2010 14:26
To: Liaquat Khan
Cc= :=20 Pope, Nick; pkix; denis.pinkas@bull.net


Subject: Re: [pkix] Research question: Witnessing=20 by digital signature

=A0

Dear Liaquat,

=A0

(sorry if I have missed some information) I have= skim=20 read document=A0D1.1 Part 3: Signature Policies, and it seems that the= =20 Project uses ETSI Signature Policies, and that the "binding" = between the=20 multiple signatures (when needed) is made in human-readable documents r= ather=20 than by means of automated processes. Am I right?

=A0

Jorge.

=A0

2010/6/11 Liaquat Khan <liaquat.khan@ascertia.com>= ;

Not= e the=20 large European project =93PEPPOL=94 (Pan-European Public Procurement On= -Line)=20 considers multiple signature options as part of the Signature Policy.= =A0=20 =A0It seems logical place to me.=A0

=A0

Reg= ards

LK<= /span>

=A0

From: pkix-bounces@ietf.org [= mailto:pkix-boun= ces@ietf.org]=20 On Behalf Of Jorge L=F3pez
Sent: 11 June 2010=20 13:22
To: Pope, Nick
Cc: pkix; denis.pinkas@bull.net


Subject: Re: [pkix] Research question= :=20 Witnessing by digital signature

=A0

Mmm, not so sure about that. Current signature p= olicy is=20 already transaction/document oriented, as it establishes the requiremen= ts to=20 be fulfilled for the generation and validation of the signature, but wi= thin=20 the transaction scope. There are fields that specifically fix the=20 business/transactional context. The necessity I mentioned is what happe= ns=20 when more than one signature is needed to complete the transaction.

=A0

Well, you could do that at document/application = level,=20 but the cumbersome is guaranteed. An extended signature policy, like th= e one=20 proposed in the aforementioned paper, can fill that gap in a seamlessly= =20 manner, and not application-dependent one.

=A0

Regards,

=A0

Jorge.

=A0

2010/6/11 Pope, Nick <Nick.Pope@thales-esecurity.com= >

Denis,

=

=A0

With PDF's th= is is handled=20 by producing a document template with the layout including the placemen= t of=20 signatures.=A0 I think this is an issue for the document standards=20 applying signatures=A0not for signatures standards.

=A0

Nick

-----Original Message-----
From: pkix-bounces@ietf.o= rg [mailto:p= kix-bounces@ietf.org] On Behalf Of Denis=20 Pinkas
Sent: 11 June 2010 09:54
To: Jorge L=F3pez= ;=20 swilson
Cc: pkix
Subject: Re: [pkix] Research=20 question: Witnessing by digital signature

Hi,

<= /div>

=A0

<= /div>

You are right: = there is=20 no signature policy standard or technical document that helped to=20 establish the dependences and relationships among several=20 signatures.

=A0

<= /div>

The current con= cept of=20 "signature policy" applies to a single signature.
If a = document has=20 multiple signatures, each one can be done under a different signature= =20 policy.

=A0

<= /div>

So the "mi= ssing" concept=20 is a "document signature policy" (not to be confused with= =A0 a=20 "signature policy") which would tell,
how many electron= ic signatures=20 are needed, which signature policies are acceptable for each one, whe= ther=20 they need to be parallel
or embedded, which commitment types must= be=20 present, etc ...

=A0

<= /div>

This=A0combinat= ion of=20 criteria could be important and all these verifications are currently= left=20 to the application.

It is questionn= able=20 whether this should be standardized now or left to the=20 application.

=A0

<= /div>

Denis

=A0

<= /div>

----- Message = re=E7u -----=20

De :=20 Jorge L=F3pez

=C0 : Stephen Wilson

Date=20 : 2010-06-11,=20 10:17:44

Sujet=20 : Re: [pkix] Research ques= tion:=20 Witnessing by digital signature

=A0

Hi,

=A0

Among other o= pen=20 issues, a technical one lies in the fact that currently there is no= =20 signature policy standard or technical document that helped to esta= blish=20 the dependences and relationships among several signatures to make = them=20 legally binding. It would be the scenario of a witness or notary, w= ho=20 must countersign a former signature to make the transaction=20 effective.=A0This=A0limitation was pointed out by ETSI in a=20 technical report=A0published in 2003 [1]. To the best of my=20 knowledge, little research has been done in this direction=20 [2].

=A0

Regards,

=A0

[1]=A0ETSI TR= 102=20 045 - Electronic Signatures and=A0Infrastructures (ESI); Signature= =20 policy for extended=A0business model v1.1.1. European=20 Telecommunications

Standards Ins= titute=20 (ETSI), March 2003

[2]=A0Jorge L= .=20 Hernandez-Ardieta, Ana I. Gonzalez-Tablas, Benjamin Ramos and Artur= o=20 Ribagorda. Extended Electronic Signature Policies. 2nd ACM Internat= ional=20 Conference on Security of Information and Networks (SIN 2009), pp.= =20 268--277, ACM Press. North Cyprus. 2009.

=A0

2010/6/10 Ste= phen=20 Wilson <swilson@lockstep.com.au>


Has any w= ork been=20 done in PKIX or elsewhere on formal witnessing of digital signature= s?=20 =A0And/or ... does anyone in the group know of real life instances= =20 where a digital signature is witnesses and attested to using anothe= r dig=20 sig?
Cheers,

Stephen Wilson
Managing Director
Lock= step=20 Group

Phone +61 (0)414 488 851

www.lockstep.com.au=20 <http:/= /www.lockstep.com.au>
Lockstep Consulting=20 provides independent specialist advice and analysis
on digital= =20 identity and privacy. =A0Lockstep Technologies develops unique
n= ew=20 smart ID solutions that enhance privacy and prevent identity=20 theft.



_____________________________________________= __
pkix=20 mailing list
= pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

=A0

Consider the environment bef= ore=20 printing this mail.

"Thales e-Security Limited= is=20 incorporated in England and Wales with company registration number 2518= 805.=20 Its registered office is located at 2 Dashwood Lang Road, The Bourne=20 Business Park, Addlestone, Nr. Weybridge, Surrey KT15=20 2NX.

The information contained in th= is=20 e-mail is confidential. It may also be privileged. It is only intended = for=20 the stated addressee(s) and access to it by any other person is=20 unauthorised. If you are not an addressee or the intended addressee, yo= u=20 must not disclose, copy, circulate or in any other way use or rely on t= he=20 information contained in this e-mail. Such unauthorised use may be unla= wful.=20 If you have received this e-mail in error please delete it (and all cop= ies)=20 from your system, please also inform us immediately on +44 (0)1844 2018= 00 or=20 email postmaster@thales-esecurity.com. Commercial matters=20 detailed or referred to in this e-mail are subject to a written contrac= t=20 signed for and on behalf of Thales e-Security Limited".= =20

=A0

=A0



--00163683306027797a0488c08be3-- From len.sassaman@esat.kuleuven.be Fri Jun 11 08:54:11 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18153A6970; Fri, 11 Jun 2010 08:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.923, 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 UdeWlWrjK5lo; Fri, 11 Jun 2010 08:54:11 -0700 (PDT) Received: from cavuit01.kulnet.kuleuven.be (cavuit01.kulnet.kuleuven.be [134.58.240.43]) by core3.amsl.com (Postfix) with ESMTP id C70983A68A3; Fri, 11 Jun 2010 08:54:08 -0700 (PDT) Received: from smtps02.kuleuven.be (smtpshost02.kulnet.kuleuven.be [134.58.240.75]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 4FFE97B802A; Fri, 11 Jun 2010 17:54:06 +0200 (CEST) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by smtps02.kuleuven.be (Postfix) with ESMTP id 46071F3864; Fri, 11 Jun 2010 17:54:06 +0200 (CEST) Received: from helium.esat.kuleuven.be (helium.esat.kuleuven.be [134.58.56.167]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 42B2548002; Fri, 11 Jun 2010 17:54:06 +0200 (CEST) Received: by helium.esat.kuleuven.be (Postfix, from userid 2415) id 36AE2E5DFD; Fri, 11 Jun 2010 17:54:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by helium.esat.kuleuven.be (Postfix) with ESMTP id 338E0E57EB; Fri, 11 Jun 2010 17:54:06 +0200 (CEST) Date: Fri, 11 Jun 2010 17:54:06 +0200 (CEST) X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Len Sassaman To: Peter Gutmann In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-KULeuven-Information: Katholieke Universiteit Leuven X-KULeuven-Scanned: Found to be clean X-KULeuven-Envelope-From: len.sassaman@esat.kuleuven.be Cc: simon@josefsson.org, smime@ietf.org, cfrg@irtf.org, saag@ietf.org, pkix@ietf.org Subject: Re: [smime] [Cfrg] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 15:54:12 -0000 On Fri, 11 Jun 2010, Peter Gutmann wrote: > I assume you're thinking of IE6 there :-). Was the fix done in CryptoAPI or > in the browser itself? If it was an update to CryptoAPI then even IE6 should > be OK (can anyone from MS comment on this?). I *think* the fix was in CryptoAPI. Dan was the one who notified the vendors (OpenSSL, Mozilla, Verisign, etc.) about the MD2 signature transfer problem as well as the other flaws, so he'd be the person to ask (unless someone from MS wants to chime in.) --Len. From nelson@bolyard.me Fri Jun 11 10:43:17 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4757E28C0CF for ; Fri, 11 Jun 2010 10:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_50=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 48QiuQ1cbJHt for ; Fri, 11 Jun 2010 10:43:16 -0700 (PDT) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 39CBF3A6A26 for ; Fri, 11 Jun 2010 10:43:15 -0700 (PDT) Received: (qmail 13188 invoked from network); 11 Jun 2010 17:43:17 -0000 Received: from unknown (24.5.142.42) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 11 Jun 2010 17:43:16 -0000 Message-ID: <4C1275AD.1040807@bolyard.me> Date: Fri, 11 Jun 2010 10:43:09 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: smime@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [smime] Double base64 encoding unavoidable in enveloped messages? X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 17:43:17 -0000 On 2010-06-09 23:52 PDT, Peter Gutmann wrote: > "Jim Schaad" writes: > >> There are several things that you can look at. >> >> 1. Emit and look for the binary smime capability. This will allow you >> to not do the inner base 64 encoding step which is the most likely to >> save you one wrapping. I have not been looking at active smime >> messages recently, but most current clients should be doing this. > > Also, hasn't support for binary data been a MUST for many years now? I > remember this from some time ago... I haven't done a full archaeological > investigation but RFC 3851 from 2004 already says (section 3.1.2): > > S/MIME implementations MUST be able to deal with binary MIME objects. > > (followed by text on not using base64). Thanks, Jim & Peter. This gives me what I need. From tgindin@us.ibm.com Sun Jun 13 20:54:25 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E1A3A6823; Sun, 13 Jun 2010 20:54:24 -0700 (PDT) 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 3hrk23iGf25U; Sun, 13 Jun 2010 20:54:24 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id B11D23A67CC; Sun, 13 Jun 2010 20:54:24 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o5E3bMnu003282; Sun, 13 Jun 2010 23:37:22 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5E3sFCv137692; Sun, 13 Jun 2010 23:54:15 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5E3sFH8019042; Mon, 14 Jun 2010 00:54:15 -0300 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o5E3sFgm019037; Mon, 14 Jun 2010 00:54:15 -0300 In-Reply-To: <87eigfj92e.fsf@mocca.josefsson.org> References: <87bpbjko9d.fsf@mocca.josefsson.org> <87eigfj92e.fsf@mocca.josefsson.org> To: Simon Josefsson MIME-Version: 1.0 X-KeepSent: 37730A2F:44CD33D9-8525773E:0074B574; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Tom Gindin Message-ID: Date: Sun, 13 Jun 2010 23:54:13 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 06/13/2010 23:54:15, Serialize complete at 06/13/2010 23:54:15 Content-Type: text/plain; charset="US-ASCII" X-Mailman-Approved-At: Mon, 14 Jun 2010 20:03:42 -0700 Cc: smime@ietf.org, cfrg@irtf.org, pkix-bounces@ietf.org, saag@ietf.org, pkix@ietf.org Subject: Re: [smime] [pkix] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 03:54:25 -0000 Where in TLS (or even SSL v3) is MD2 used in a cipher suite? I realize that it's in the document list for TLS 1.0. In RFC's 2459 and 3279 (11 and 8 years old) it gives OID's and says "the use of MD2 for new applications is discouraged. It is still reasonable to use MD2 to verify existing signatures". I also can't find any current MD2 intermediate certificates. You are right that the signature of a root certificate is not a relevant exercise of trust, since one trusts either the public key of the root certificate or the content of the entire root certificate with the signature no more relevant to a trust decision than any other field in it. Tom Gindin From: Simon Josefsson To: Peter Gutmann Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Date: 06/10/2010 10:19 AM Subject: Re: [pkix] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] Sent by: pkix-bounces@ietf.org Peter Gutmann writes: > Simon Josefsson writes: > >>1) MD2 is not on the standards track, it is Informational. I agree with >> wishes to move "poor" documents from the Standards Track to Historic, >> but I'm not sure I see such a big difference between having a "poor" >> document as Informational or Historic. Especially for a crypto >> algorithm, which the IETF typically does not put on the standards >> track at all. Is there some precedent for moving Informational to >> Historic? > > It helps to have something like this formally retired so you have a document > to point to when someone wants to use (or continue to use) MD2. Trying to > explain to them the difference between "Informational" and "Standards Track" > when their requirement is "must be specified in an RFC" isn't generally > useful. Sure, but MD2 is not used in isolation, it is used in a protocol like TLS, S/MIME, etc. Isn't it sufficient, even preferable, to move uses of MD2 in these protocol to Historic? That would seem to carry much more weight -- then people cannot continue to support MD2 in these protocol and claim to be compliant with the latest specifications. Note that there are other uses of MD2 that are still fine even if MD2 is not collision resistant. Compare how rsync still uses MD4 for checksum computations, and that won't stop it being a reasonable choice. I'm mostly playing the devil's advocate here, and want to make sure we consider the consequences before giving a flippant +1. /Simon _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix From matt@mattmccutchen.net Mon Jun 14 21:15:46 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F763A6823 for ; Mon, 14 Jun 2010 21:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 j08lecl0j2N8 for ; Mon, 14 Jun 2010 21:15:46 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 1DA1C3A6813 for ; Mon, 14 Jun 2010 21:15:46 -0700 (PDT) Received: from [192.168.1.40] (pool-96-231-2-11.washdc.east.verizon.net [96.231.2.11]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id BEE9D41B09 for ; Mon, 14 Jun 2010 21:15:46 -0700 (PDT) From: Matt McCutchen To: smime In-Reply-To: <4C11448F.1040709@lockstep.com.au> References: <4C11448F.1040709@lockstep.com.au> Content-Type: text/plain; charset="UTF-8" Date: Tue, 15 Jun 2010 00:15:38 -0400 Message-ID: <1276575338.2345.38.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 15 Jun 2010 07:50:18 -0700 Subject: Re: [smime] [pkix] Research question: Witnessing by digital signature X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 04:15:46 -0000 On Fri, 2010-06-11 at 06:01 +1000, Stephen Wilson wrote: > Has any work been done in PKIX or elsewhere on formal witnessing of > digital signatures? And/or ... does anyone in the group know of real > life instances where a digital signature is witnesses and attested to > using another dig sig? How would one "witness" a digital signature? To witness a physical signature means that one has personal knowledge that the signer intentionally signed the document. Simply adding a digital signature to a document bearing someone else's digital signature is not witnessing in this sense. -- Matt From pgut001@cs.auckland.ac.nz Wed Jun 16 21:53:48 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6E03A6895 for ; Wed, 16 Jun 2010 21:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=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 xvx5nZ+3-eGY for ; Wed, 16 Jun 2010 21:53:47 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id D649A3A6A0D for ; Wed, 16 Jun 2010 21:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1276750433; x=1308286433; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20matt@mattmccutchen.net,=20smime@ietf.org|Subject: =20Re:=20[smime]=20[pkix]=20Research=20question:=20Witnes sing=20by=20digital=20signature|In-Reply-To:=20<127657533 8.2345.38.camel@mattlaptop2.local>|Message-Id:=20|Date:=20Thu, =2017=20Jun=202010=2016:53:46=20+1200; bh=8imw6y5ntEcLrEaq2VHAITSF7x500+8uq9ZE2yBBetA=; b=ifvlINUFui+wucjYYUsF9rVyeTjWPIagsA+VIo9RMos+5P9R7Zu6sZe0 cgx8/ihSj6PGxJ38NZQoNzdftIL5HjD6KUOKVUQ7trhSAM6BoUFc0vUP6 R4n8B0+sZY1xqxAFRIYS9MZj1MevdlPqcOK+ER97NyUbCP6t7iUs/LuzF g=; X-IronPort-AV: E=Sophos;i="4.53,429,1272801600"; d="scan'208";a="11522867" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Jun 2010 16:53:47 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OP76o-0001i2-M5; Thu, 17 Jun 2010 16:53:46 +1200 From: Peter Gutmann To: matt@mattmccutchen.net, smime@ietf.org In-Reply-To: <1276575338.2345.38.camel@mattlaptop2.local> Message-Id: Date: Thu, 17 Jun 2010 16:53:46 +1200 Subject: Re: [smime] [pkix] Research question: Witnessing by digital signature X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 04:53:48 -0000 Matt McCutchen writes: >On Fri, 2010-06-11 at 06:01 +1000, Stephen Wilson wrote: >> Has any work been done in PKIX or elsewhere on formal witnessing of >> digital signatures? And/or ... does anyone in the group know of real >> life instances where a digital signature is witnesses and attested to >> using another dig sig? > >How would one "witness" a digital signature? To witness a physical signature >means that one has personal knowledge that the signer intentionally signed the >document. Simply adding a digital signature to a document bearing someone >else's digital signature is not witnessing in this sense. "When I use a word it means just what I choose it to mean -- neither more nor less" -- Humpty Dumpty (and PKI). Peter. From matt@mattmccutchen.net Wed Jun 16 22:14:28 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAC603A6967 for ; Wed, 16 Jun 2010 22:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 PTmy1QPtZAD3 for ; Wed, 16 Jun 2010 22:14:23 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 280593A6938 for ; Wed, 16 Jun 2010 22:14:23 -0700 (PDT) Received: from [128.8.9.94] (vpn1-9-94.umd.edu [128.8.9.94]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id D100FD4F3D; Wed, 16 Jun 2010 22:12:34 -0700 (PDT) From: Matt McCutchen To: Peter Gutmann In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Thu, 17 Jun 2010 01:14:15 -0400 Message-ID: <1276751655.2386.325.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit Cc: smime@ietf.org Subject: Re: [smime] [pkix] Research question: Witnessing by digital signature X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 05:14:29 -0000 On Thu, 2010-06-17 at 16:53 +1200, Peter Gutmann wrote: > >How would one "witness" a digital signature? To witness a physical signature > >means that one has personal knowledge that the signer intentionally signed the > >document. Simply adding a digital signature to a document bearing someone > >else's digital signature is not witnessing in this sense. > > "When I use a word it means just what I choose it to mean -- neither more > nor less" > -- Humpty Dumpty (and PKI). And what is it chosen to mean? Maybe I can propose a better term for the concept. -- Matt From pgut001@cs.auckland.ac.nz Wed Jun 16 23:16:42 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0160B3A6848 for ; Wed, 16 Jun 2010 23:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.158 X-Spam-Level: X-Spam-Status: No, score=-1.158 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_05=-1.11] 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 OUYQlaHUwXi5 for ; Wed, 16 Jun 2010 23:16:32 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id C58F43A6967 for ; Wed, 16 Jun 2010 23:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1276755397; x=1308291397; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20matt@mattmccutchen.net,=20pgut001@cs.auckland.ac.n z|Subject:=20Re:=20[smime]=20[pkix]=20Research=20question :=20Witnessing=20by=20digital=20signature|Cc:=20smime@iet f.org|In-Reply-To:=20<1276751655.2386.325.camel@mattlapto p2.local>|Message-Id:=20|Date:=20Thu,=2017=20Jun=202010=2018:16: 14=20+1200; bh=myx4siBp0JHnRjmDK1EeEXlG/MWeamo0MCE6p3q2d6s=; b=nNkr3At5kK8HxxkMtztUjhEp6Z1NykieSPaFzrTZfTuelTUewQpxVIgJ tl04TjqEiPTJdmcs0/ZGC27dKzRmpTvlLZWniVboxyEH7Q8TRmRAhvXCt mMSoumFShbp6LY7BknIrins+tTSCYLXZPEglvE7CB/bfxZ7sovcd/HRjr I=; X-IronPort-AV: E=Sophos;i="4.53,430,1272801600"; d="scan'208";a="11534639" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Jun 2010 18:16:14 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OP8Oc-0002JV-Am; Thu, 17 Jun 2010 18:16:14 +1200 From: Peter Gutmann To: matt@mattmccutchen.net, pgut001@cs.auckland.ac.nz In-Reply-To: <1276751655.2386.325.camel@mattlaptop2.local> Message-Id: Date: Thu, 17 Jun 2010 18:16:14 +1200 Cc: smime@ietf.org Subject: Re: [smime] [pkix] Research question: Witnessing by digital signature X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 06:16:42 -0000 Matt McCutchen writes: >On Thu, 2010-06-17 at 16:53 +1200, Peter Gutmann wrote: >>>How would one "witness" a digital signature? To witness a physical signature >>>means that one has personal knowledge that the signer intentionally signed the >>>document. Simply adding a digital signature to a document bearing someone >>>else's digital signature is not witnessing in this sense. >> >> "When I use a word it means just what I choose it to mean -- neither more >> nor less" >> -- Humpty Dumpty (and PKI). > >And what is it chosen to mean? Maybe I can propose a better term for the >concept. I was commenting on the way PKI borrows standard, well-defined terms and uses them in strange ways, "nonrepudiation" being another example (and, incidentally, agreeing with your comment). So perhaps "PKI-witness" can be defined as: "A service designed to ensure PKI-nonrepudiation" and then all you need to do is come up with a definition of PKI-nonrepudiation. (My suggestion for the latter would be "A legal term misused for PKI in order to give potential buyers of PKI products and services warm fuzzies"). Peter. From sm@resistor.net Thu Jun 17 10:19:21 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B6C13A6929; Thu, 17 Jun 2010 10:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.701, 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 zLad7jyBeKYZ; Thu, 17 Jun 2010 10:19:20 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 061A03A6915; Thu, 17 Jun 2010 10:19:19 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o5HHIx1i027598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jun 2010 10:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1276795161; x=1276881561; bh=Qa6GCb9YgNm3Txw2Mne7v7P+4vvGfkxAA3kLbwi9d0s=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=USWSXUOK+jyuNtXbRW1Mkl+4vvUvYvNlKikLlt3WIS6MmsSBs1A3xazZOyyRCt4NH ugy4rk5NoxbbVV0mL2vGSwwWrwacGR3r32c4KacAcXfzc8PKTppdZ0YUyTKBPij0sE 09cDeE1jnSJjGzKG+G8ErkXayb7nkzIU8wxdD0d4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1276795161; x=1276881561; bh=Qa6GCb9YgNm3Txw2Mne7v7P+4vvGfkxAA3kLbwi9d0s=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=wvkLVgwWWz7RNAUzQiGMQtaIWufWTHatcfdIbk51WaQLBYQ+7fVIB9zUJSJnY05l3 jprXM71Hd+K/Oka6nk2gDHxvrQqI8e8+pWTI0UvACYCqVfkBFuuAK4alUNstNRknBX xlRpwZ+BtntrO9RKXISClXoBrJ/YFHHs3gNQIn28= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=LUkRcWlsMeNtQ5CDmet+pktGhjUl/aMl0Rx20x+ayvy5UYKV7yVUF/GlxWLmo3fhl cbLbxeyEBwbNahvD7jb9XxXpypvTaIXSgxT7pco6nEl5VQer5WI1RmxEG7IksaPlKjL speGrVCAYvulqKDDiMdLtWGtolB20URvdL1kQes= Message-Id: <6.2.5.6.2.20100617100201.0b7b2230@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 17 Jun 2010 10:18:38 -0700 To: Simon Josefsson From: SM In-Reply-To: <87bpbjko9d.fsf@mocca.josefsson.org> References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 17 Jun 2010 10:50:22 -0700 Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 17:19:21 -0000 Hi Simon, At 06:31 10-06-10, Simon Josefsson wrote: >1) MD2 is not on the standards track, it is Informational. I agree with > wishes to move "poor" documents from the Standards Track to Historic, > but I'm not sure I see such a big difference between having a "poor" > document as Informational or Historic. Especially for a crypto > algorithm, which the IETF typically does not put on the standards > track at all. Is there some precedent for moving Informational to > Historic? There's RFC 4223, for example, that reclassifies a non-Standards Track document to Historic. This is more about saying that MD2 should not be used and "Historic" is generally the way to say that. Regards, -sm From andrea.caccia@studiocaccia.com Thu Jun 17 10:56:17 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E9128C10E for ; Thu, 17 Jun 2010 10:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 QdkPi8hiBQmZ for ; Thu, 17 Jun 2010 10:56:16 -0700 (PDT) Received: from smtplq03.aruba.it (smtpweb21.aruba.it [62.149.158.21]) by core3.amsl.com (Postfix) with SMTP id 33B7228C100 for ; Thu, 17 Jun 2010 10:56:16 -0700 (PDT) Received: (qmail 1733 invoked by uid 89); 17 Jun 2010 17:56:11 -0000 Received: from unknown (HELO smtp5.aruba.it) (62.149.128.201) by smtplq03.aruba.it with SMTP; 17 Jun 2010 17:56:11 -0000 Received: (qmail 9705 invoked by uid 89); 17 Jun 2010 17:56:10 -0000 Received: from unknown (HELO ?192.168.10.102?) (andrea.caccia@studiocaccia.com@151.38.135.157) by smtp5.ad.aruba.it with ESMTPA; 17 Jun 2010 17:56:10 -0000 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Andrea Caccia In-Reply-To: <6.2.5.6.2.20100617100201.0b7b2230@resistor.net> Date: Thu, 17 Jun 2010 19:55:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0ED57229-EFEF-4F32-934A-8FA1E70A2947@studiocaccia.com> References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <6.2.5.6.2.20100617100201.0b7b2230@resistor.net> To: SM X-Mailer: Apple Mail (2.1078) X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N X-Mailman-Approved-At: Thu, 17 Jun 2010 11:11:03 -0700 Cc: Simon Josefsson , smime@ietf.org, cfrg@irtf.org, saag@ietf.org, pkix@ietf.org Subject: Re: [smime] [pkix] [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 17:56:17 -0000 I think it's hard to say that an algorithm is not to be used at all for = any purpose. Can MD5 be moved to Historic? I do not think so even if it has since = some time to be avoided for digital signatures but is still useful for = other purposes. The solution should be a document, regularly updated and specific for = electronic signature that list the algorithms, their correct = identification (e.g. for asn.1 and xml) and their suitability for = typical usages. Regards, Andrea Caccia Il giorno 17/giu/2010, alle ore 19.18, SM ha scritto: > Hi Simon, > At 06:31 10-06-10, Simon Josefsson wrote: >> 1) MD2 is not on the standards track, it is Informational. I agree = with >> wishes to move "poor" documents from the Standards Track to = Historic, >> but I'm not sure I see such a big difference between having a = "poor" >> document as Informational or Historic. Especially for a crypto >> algorithm, which the IETF typically does not put on the standards >> track at all. Is there some precedent for moving Informational to >> Historic? >=20 > There's RFC 4223, for example, that reclassifies a non-Standards Track = document to Historic. This is more about saying that MD2 should not be = used and "Historic" is generally the way to say that. >=20 > Regards, > -sm=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix From wwwrun@core3.amsl.com Mon Jun 21 11:03:46 2010 Return-Path: X-Original-To: smime@ietf.org Delivered-To: smime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 230F73A67D1; Mon, 21 Jun 2010 11:03:46 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100621180346.230F73A67D1@core3.amsl.com> Date: Mon, 21 Jun 2010 11:03:46 -0700 (PDT) Cc: smime chair , Internet Architecture Board , smime mailing list , RFC Editor Subject: [smime] Protocol Action: 'Cryptographic Message Syntax (CMS)' to Full Standard X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 18:03:46 -0000 The IESG has approved the following document: - 'Cryptographic Message Syntax (CMS) ' RFC 5652 as a Full Standard This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Sean Turner. A URL of this RFC is: http://www.ietf.org/rfc/rfc5652.txt Technical Summary This document specifies the Cryptographic Message Syntax (CMS), which is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. Working Group Summary RFC 5652 was a product of the smime working group. CMS is widely referenced, and is a key building block for specifications developed by the S/MIME, ltans, and keyprov working groups. Document Quality The community has accumulated significant operational experience with the Cryptographic Message Syntax in a variety of security protocols. The technical maturity and high level of confidence is clearly demonstrated by the continued use of CMS as a building block for these standards efforts. Two or more interoperable implementations were identified for all features when this specification was promoted to Draft Standard. The implementation report for RFC 3852 is available at: http://www.ietf.org/iesg/implementation/report-rfc3852.txt Personnel Tim Polk is the Responsible Area Director. RFC Editor Note In section 5.3, third paragraph in the list beginning with "The fields of type SignerInfo have the following meanings:", please make the following substitution: s/associated SignerData./associated SignedData./ From michael@stroeder.com Tue Jun 22 01:10:23 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91283A6986 for ; Tue, 22 Jun 2010 01:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.192 X-Spam-Level: X-Spam-Status: No, score=0.192 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_50=0.001, 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 WT2WDvEC1DYi for ; Tue, 22 Jun 2010 01:10:23 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id 044A53A697B for ; Tue, 22 Jun 2010 01:10:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 0CF854E123 for ; Tue, 22 Jun 2010 10:10:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1R35HqfIHp9 for ; Tue, 22 Jun 2010 10:10:22 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 2DEC64E124 for ; Tue, 22 Jun 2010 10:10:21 +0200 (CEST) Message-ID: <4C206A6B.7040205@stroeder.com> Date: Tue, 22 Jun 2010 09:46:51 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100504 Lightning/1.0b1 SeaMonkey/2.0.5 MIME-Version: 1.0 To: smime References: <4C11448F.1040709@lockstep.com.au> <1276575338.2345.38.camel@mattlaptop2.local> In-Reply-To: <1276575338.2345.38.camel@mattlaptop2.local> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [smime] [pkix] Research question: Witnessing by digital signature X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 08:10:24 -0000 Matt McCutchen wrote: > On Fri, 2010-06-11 at 06:01 +1000, Stephen Wilson wrote: >> Has any work been done in PKIX or elsewhere on formal witnessing of >> digital signatures? And/or ... does anyone in the group know of real >> life instances where a digital signature is witnesses and attested to >> using another dig sig? > > How would one "witness" a digital signature? To witness a physical > signature means that one has personal knowledge that the signer > intentionally signed the document. Simply adding a digital signature to > a document bearing someone else's digital signature is not witnessing in > this sense. Matt, you're right. That's another example of trying to solve something with PKI technology instead of examining how processes work in the real world and whether there's a technical solution at all. Just like the famous "warranty" draft. Ciao, Michael. From pgut001@cs.auckland.ac.nz Tue Jun 22 02:09:29 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1E93A697B for ; Tue, 22 Jun 2010 02:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74] 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 32Y1DhpgCJpk for ; Tue, 22 Jun 2010 02:09:28 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id EF8F13A6967 for ; Tue, 22 Jun 2010 02:09:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1277197776; x=1308733776; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20michael@stroeder.com,=20smime@ietf.org|Subject:=20 Re:=20[smime]=20[pkix]=20Research=20question:=20Witnessin g=20by=20digital=09signature|In-Reply-To:=20<4C206A6B.704 0205@stroeder.com>|Message-Id:=20|Date:=20Tue,=2022=20Jun=202010 =2021:09:26=20+1200; bh=WsjpoozEX7e94dqSJj3RkWjbd81KPMcg36FEhxWXyhw=; b=geXxf1cKppmKIFytvosgxqL1LJSzx11MJ1U69jK9Hp+6t6ArfPH4jjD3 odtQXEL99CbAm+0lrPsYX5kIpqpF0mG+d/cDDBhEB1fmx0/pQKJFZHXKk W69tX/eiVG1hoB7rj8hTu0p1QRLVYGUfqiB30JBLaFe3eY4yMQ9x1+qbl E=; X-IronPort-AV: E=Sophos;i="4.53,459,1272801600"; d="scan'208";a="12214850" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Jun 2010 21:09:26 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OQzTy-0003r6-9v; Tue, 22 Jun 2010 21:09:26 +1200 From: Peter Gutmann To: michael@stroeder.com, smime@ietf.org In-Reply-To: <4C206A6B.7040205@stroeder.com> Message-Id: Date: Tue, 22 Jun 2010 21:09:26 +1200 Subject: Re: [smime] [pkix] Research question: Witnessing by digital signature X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 09:09:29 -0000 =?ISO-8859-1?Q?Michael_Str=F6der?= writes: >That's another example of trying to solve something with PKI technology >instead of examining how processes work in the real world and whether there's >a technical solution at all. Just like the famous "warranty" draft. Hey, don't criticise that, it provided a valuable service by pointing out that the default warranty for certs is: Warranty ::= CHOICE { none NULL, -- No warranty provided ... } or more specifically (in not-quite-ASN.1): Warranty ::= DEFAULT NULL So if you don't find a warranty extensions, you know that the above is the warranty attached to your cert. Peter. From turners@ieca.com Tue Jun 22 14:50:34 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14493A6A13 for ; Tue, 22 Jun 2010 14:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_50=0.001, UNPARSEABLE_RELAY=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 oPblIquduYJq for ; Tue, 22 Jun 2010 14:50:32 -0700 (PDT) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id 9DE3A28C121 for ; Tue, 22 Jun 2010 14:50:29 -0700 (PDT) Received: (qmail 59013 invoked from network); 22 Jun 2010 21:50:33 -0000 Received: from thunderfish.local (turners@71.191.10.89 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 22 Jun 2010 14:50:33 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: HzGfjKAVM1nM2k_c64KyqVJQYZIo2fY.wEiiJo74yRwG1Kw qzMbUmjyigB19XkC1Umy0j2e8F2TprIkIz7ygkzkbl2b3eIjfa.yH1jlFGvc OsO3k._xEjLgC.Jffr9MN7VH45zBCSroVkbGMucCt6W5xL5_uhXbhtpuEKt1 Nk2Aq_P645Hy2XD7DhmY8Q1XP8lhvhqHm3w6mHD2w0Ypx7KmU73j.oiTD0CV EnkyDepaoNcqBrneN0i0b3QuurhGxcagG_7LJh47Myspf05ARuKxgEvqk8yz VMvu3063yiqXjwsv2IMDuhhyriiUdfjQMDeyd04XqwPEJtl3Vwa9ODaCft6A 3TUBTl4wf1nXETGcb1Q2zdDQuHG2T2ILxwt1pFSw.IbzU8a0nxQHUs5Rz30o L5fvmzT4RvjkE87RgTGM0roM- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C213028.4000404@ieca.com> Date: Tue, 22 Jun 2010 17:50:32 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Simon Josefsson References: <4C10E308.9060503@ieca.com> <87bpbjko9d.fsf@mocca.josefsson.org> <4C10F020.4000102@ieca.com> In-Reply-To: <4C10F020.4000102@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pkix@ietf.org, cfrg@irtf.org, saag@ietf.org, smime@ietf.org Subject: Re: [smime] [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 21:50:35 -0000 Sean Turner wrote: >> 2) MD2 is still used. In GnuTLS I recall _adding_ support for MD2 as >> recently as (according to NEWS logs) in 2005. If I recall correctly, >> some Verisign root certificates are MD2. Note that in GnuTLS, >> verifying a certificate involving a MD2 digital signature will fail >> because MD2 is insecure, but the algorithm is still implemented and >> supported. >> >> Thus the text in your document "many TLS implementations, OpenSSL, >> Network Security Services, and GNUTLS, have disabled support for MD2" >> may not be the entire story. GnuTLS "supports" MD2 even though it >> does not consider it secure. I can't speak for OpenSSL or NSS, but I >> suspect they implement MD2 too and can verify such digital hashes, >> even if they don't consider them secure. > > Yeah that might have been a bit strong. Maybe: > > Additionally, many TLS implementations, OpenSSL, Network Security > Services, and GNUTLS, support MD2 but recommend it only for backwards > compatibility. I went back and looked at this a little closer. I found that GNUTLS now turns MD2 off by default: https://rhn.redhat.com/errata/RHSA-2010-0166.html I also found that NSS does also have MD2 turned off, but it looks you can turn it back on by setting an environment variable. spt From jlopez.ha@gmail.com Wed Jun 23 04:20:26 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834F43A6860; Wed, 23 Jun 2010 04:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.348 X-Spam-Level: X-Spam-Status: No, score=-0.348 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001, 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 GtTdZOD7Bm9D; Wed, 23 Jun 2010 04:20:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 222C43A69F2; Wed, 23 Jun 2010 04:20:13 -0700 (PDT) Received: by wwi17 with SMTP id 17so439850wwi.31 for ; Wed, 23 Jun 2010 04:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QCU2+GuHMEuLFDV10W9Rq+WwVOkrTPDLADg2nM8/5XA=; b=dEmCpu1AtUgQ+v0nbUkGMVdo0+BYwCM+vyTjrwcE3IiHt55/JacIKMGvVUl2S4rf9Y 6YUOC+4SWgY3SsbYktIAOeYfcDo2fmKEprMoXV9xlfS7xDZVeKoMpTlGIsUh/zzaIzo+ mrMyfnjrZQgd6r4XrUO8RIGLwYRR97f8xrJEY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Wz6AA4p3OtK8YPE60wUIUtpn520WC/+Q+ece/m7TYR1XEgwPLyEKmnbozGb5ApKifJ 6dBDX02x2Z8mvbHFYhCWAChx8Z48McWccLmm2bMkA/v9XpHQ4os30YlHCpg+tzR74kry vQw3AHPZy/dBLDfr9XC+WAEaW2IL11YcY4bAI= MIME-Version: 1.0 Received: by 10.216.88.196 with SMTP id a46mr5787812wef.36.1277292011076; Wed, 23 Jun 2010 04:20:11 -0700 (PDT) Received: by 10.216.20.141 with HTTP; Wed, 23 Jun 2010 04:20:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Jun 2010 13:20:10 +0200 Message-ID: From: =?ISO-8859-1?Q?Jorge_L=F3pez?= To: Stefan Santesson Content-Type: multipart/alternative; boundary=0016e68fa338983e1b0489b0b89c Cc: pkix@ietf.org, Stephen Wilson , smime Subject: Re: [smime] [pkix] Research question: Witnessing by digital signature X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 11:20:26 -0000 --0016e68fa338983e1b0489b0b89c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with you Stefan. I misued the words to express that. Just to clarif= y myself, in the context I'm referring to, signatures are an instrument of evidence regarding the authenticity of the document, understood authenticit= y as a means of identifying the signatory but also indicating the signatory's approval of the signed data. But, sometimes, and in order to make some agreements and commitments made i= n a signed document binding, it is mandatory that more than one signature is present. As an example, imagine the case where some purchase order has to b= e authorised by the purchase manager. The order should not be enforced until such signature is present. IMO, currently there is no technical solution to fulfill that in a seamlessly and generalistic manner. Regards, Jorge. 2010/6/23 Stefan Santesson > A short note on this: > > On 10-06-11 10:17 AM, "Jorge L=F3pez" wrote: > > there is no signature policy standard or technical document that helped > to > > establish the dependences and relationships among several signatures to > make > > them legally binding > > It is not the signature that is legally binding, it is the AGREEMENT > supported by that signature that is legally binding. > > In most cases that agreement is legally binding regardless of whether it = is > signed or not. The signature makes it easier to prove the existence of a > legally binding agreement but it is not the component that makes the > agreement legally binding. > > This small detail is often overlooked when we are designing technical > standards. > > /Stefan > > > > --0016e68fa338983e1b0489b0b89c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with you Stefan. I misued the words to express that. Just to clarif= y myself, in the context I'm referring to, signatures are an instrument= of evidence regarding the authenticity of the document, understood authent= icity as a means of=A0identifying the signatory but also indicating the=A0s= ignatory's approval of the signed data.

But, sometimes, and in order to make some agreements and com= mitments made in a signed document binding, it is mandatory that more than = one signature is present. As an example, imagine the case where some purcha= se order has to be authorised by the purchase manager. The order should not= be enforced until such signature is present. IMO, currently there is no te= chnical solution to fulfill that in a seamlessly and generalistic manner.

Regards,

Jorge.

2010/6/23 Stefan Santesson <stefan@aaa-sec.com>
A short note on this:

On 10-06-11 10:17 AM, "Jorge L=F3pez" <jlopez.ha@gmail.com> wrote:
> there is no signature policy standard or technical document that helpe= d to
> establish the dependences and relationships among several signatures t= o make
> them legally binding

It is not the signature that is legally binding, it is the AGREEMENT<= br> supported by that signature that is legally binding.

In most cases that agreement is legally binding regardless of whether it is=
signed or not. The signature makes it easier to prove the existence of a legally binding agreement but it is not the component that makes the
agreement legally binding.

This small detail is often overlooked when we are designing technical
standards.

/Stefan




--0016e68fa338983e1b0489b0b89c-- From md@e-net.lt Wed Jun 23 05:57:20 2010 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5343A6A79; Wed, 23 Jun 2010 05:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.302 X-Spam-Level: X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, 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 so1BTIcfwTfT; Wed, 23 Jun 2010 05:57:19 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by core3.amsl.com (Postfix) with ESMTP id 8B9123A6A6D; Wed, 23 Jun 2010 05:57:18 -0700 (PDT) Received: from lan-84-240-23-130.vln.skynet.lt ([84.240.23.130] helo=[192.168.1.100]) by mail.ssc.lt with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1ORPW0-0004ay-3n; Wed, 23 Jun 2010 15:57:16 +0300 Message-ID: <4C2204AE.1000601@e-net.lt> Date: Wed, 23 Jun 2010 15:57:18 +0300 From: "Moudrick M. Dadashov" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jorge_L=F3pez?= References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040309040900050404040108" X-Mailman-Approved-At: Wed, 23 Jun 2010 08:30:15 -0700 Cc: smime , pkix@ietf.org Subject: Re: [smime] [pkix] Research question: Witnessing by digital signature X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 12:57:20 -0000 This is a multi-part message in MIME format. --------------040309040900050404040108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit yes, the signature standards talk about signatures irrelevant to other signatures that might be an essential part of a signature itself. So far it's up to application developer to provide "signature tree template" that can control the signature creation flow. Thanks, M.D. cell: +370-699-26662 On 2010.06.23 14:20, Jorge López wrote: > I agree with you Stefan. I misued the words to express that. Just to > clarify myself, in the context I'm referring to, signatures are an > instrument of evidence regarding the authenticity of the document, > understood authenticity as a means of identifying the signatory but > also indicating the signatory's approval of the signed data. > > But, sometimes, and in order to make some agreements and commitments > made in a signed document binding, it is mandatory that more than one > signature is present. As an example, imagine the case where some > purchase order has to be authorised by the purchase manager. The order > should not be enforced until such signature is present. IMO, currently > there is no technical solution to fulfill that in a seamlessly and > generalistic manner. > > Regards, > > Jorge. > > 2010/6/23 Stefan Santesson > > > A short note on this: > > On 10-06-11 10:17 AM, "Jorge López" > wrote: > > there is no signature policy standard or technical document that > helped to > > establish the dependences and relationships among several > signatures to make > > them legally binding > > It is not the signature that is legally binding, it is the AGREEMENT > supported by that signature that is legally binding. > > In most cases that agreement is legally binding regardless of > whether it is > signed or not. The signature makes it easier to prove the > existence of a > legally binding agreement but it is not the component that makes the > agreement legally binding. > > This small detail is often overlooked when we are designing technical > standards. > > /Stefan > > > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --------------040309040900050404040108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit yes, the signature standards talk about signatures irrelevant to other signatures that might be an essential part of a signature itself.

So far it's up to application developer to provide "signature tree template" that can control the signature creation flow.

Thanks,
M.D.
cell: +370-699-26662

On 2010.06.23 14:20, Jorge López wrote:
I agree with you Stefan. I misued the words to express that. Just to clarify myself, in the context I'm referring to, signatures are an instrument of evidence regarding the authenticity of the document, understood authenticity as a means of identifying the signatory but also indicating the signatory's approval of the signed data.

But, sometimes, and in order to make some agreements and commitments made in a signed document binding, it is mandatory that more than one signature is present. As an example, imagine the case where some purchase order has to be authorised by the purchase manager. The order should not be enforced until such signature is present. IMO, currently there is no technical solution to fulfill that in a seamlessly and generalistic manner.

Regards,

Jorge.

2010/6/23 Stefan Santesson <stefan@aaa-sec.com>
A short note on this:

On 10-06-11 10:17 AM, "Jorge López" <jlopez.ha@gmail.com> wrote:
> there is no signature policy standard or technical document that helped to
> establish the dependences and relationships among several signatures to make
> them legally binding

It is not the signature that is legally binding, it is the AGREEMENT
supported by that signature that is legally binding.

In most cases that agreement is legally binding regardless of whether it is
signed or not. The signature makes it easier to prove the existence of a
legally binding agreement but it is not the component that makes the
agreement legally binding.

This small detail is often overlooked when we are designing technical
standards.

/Stefan





_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--------------040309040900050404040108--