Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F36128C155 for ; Sun, 1 Mar 2009 12:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sh3PmkS0YbkW for ; Sun, 1 Mar 2009 12:56:04 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C624C3A6B9E for ; Sun, 1 Mar 2009 12:56:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,285,1233532800"; d="scan'208,217";a="38785268" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2009 20:56:28 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n21KuSvk020914; Sun, 1 Mar 2009 15:56:28 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n21KuS9L022776; Sun, 1 Mar 2009 20:56:28 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Mar 2009 15:56:28 -0500 Received: from [172.16.1.3] ([10.86.240.207]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Mar 2009 15:56:27 -0500 Message-Id: <1A3BF96A-692F-4444-8C7A-8D6FD4220D95@cisco.com> From: David McGrew To: cfrg@irtf.org In-Reply-To: <3462D904-6F07-4659-993C-54AB3B6DE9DC@w3.org> Content-Type: multipart/alternative; boundary=Apple-Mail-66--64250925 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 1 Mar 2009 12:56:26 -0800 References: <52EDBA7C-232C-47FF-B906-184206F8E312@nokia.com> <3462D904-6F07-4659-993C-54AB3B6DE9DC@w3.org> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 01 Mar 2009 20:56:27.0720 (UTC) FILETIME=[309BAC80:01C99AB0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14976; t=1235940988; x=1236804988; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Request=20for=20IETF=20community=20review=20of= 20XML=20Security=20Specifications |Sender:=20 |To:=20cfrg@irtf.org; bh=nb/MeLQJ3gwTIQuoF/+TA2A5RufMog/mkUUu+dZJO7A=; b=Qmo+U9L/QwZjNT1jgRO2SoxLIKy9dY2YLrAVHEXI357Bq3G76uQ8WX6WRi dajLAAlcRXF/lDi2hM1M8QNl9P61Ppe6CnUn+6ArlgqiOI3ZMLR4MXlaWJyW VnEY1cmTsi; Authentication-Results: rtp-dkim-1; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Frederick Hirsch , Thomas Roessler Subject: [Cfrg] Request for IETF community review of XML Security Specifications X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 20:56:05 -0000 --Apple-Mail-66--64250925 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Re-posting from SAAG to CFRG. On Mar 1, 2009, at 7:47 AM, Thomas Roessler wrote: > FYI, W3C has published initial working drafts for a number of > documents related to XML Signature and Encryption: > > 1. Incremental revisions of XML Signature and Encryption. These > revisions focus on adding markup and algorithm support for EC DSA > (at the same time addressing some known issues with RFC 4050). We > would appreciate early comment from the IETF community. > > 2. Markup for derived keys. This document, too, is one that could > use review from the IETF community. > > 3. A requirements and design document for a possible version 2 of > XML Signature. This document focuses on attempting to devise a > simpler transform model for XML Signature, in order to remove some > of the complexity of the current specification. > > The full list of drafts released is in the message quoted below. > > If you have any questions, please feel free to contact Frederick or > me. > > Thanks, > -- > Thomas Roessler, W3C > > > > > > > > Begin forwarded message: > >> From: Frederick Hirsch >> Date: 26 February 2009 12:09:26 GMT-06:00 >> To: chairs@w3.org, XMLSec WG Public List >> Cc: Frederick Hirsch >> Subject: FPWD Transition Announcement - XML Security Specifications >> Archived-At: > > >> >> This is a First Public Working Draft transition announcement from >> the XML Security WG. >> >> The following seven specifications have been published as First >> Public Working Drafts and the WG requests feedback on these >> documents. Comment may be sent to the list public-xmlsec-comments@w3.org >> . If possible please indicate the document in the subject line. >> >> (1) XML Signature Syntax and Processing Version 1.1 >> http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/ >> >> (2) XML Encryption Syntax and Processing Version 1.1 >> http://www.w3.org/TR/2009/WD-xmlenc-core1-20090226/ >> >> (3) XML Signature Transform Simplification: Requirements and Design >> http://www.w3.org/TR/2009/WD-xmldsig-simplify-20090226/ >> >> (4) XML Security Use Cases and Requirements >> http://www.w3.org/TR/2009/WD-xmlsec-reqs-20090226/ >> >> (5) XML Security Derived Keys >> http://www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/ >> >> (6) XML Signature Properties >> http://www.w3.org/TR/2009/WD-xmldsig-properties-20090226/ >> >> (7) XML Security Algorithm Cross-Reference >> http://www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/ >> >> These were included in the following transition request: >> http://lists.w3.org/Archives/Member/chairs/2009JanMar/0087.html >> >> The Working Group has also published an updated working draft of >> Best Practices: >> >> (8) XML Signature Best Practices W3C Working Draft 26 February 2009 >> http://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/ >> >> The Working Group would appreciate review of these documents, with >> special attention to the algorithms listed in XML Signature 1.1 and >> XML Encryption 1.1, the proposed 2.0 changes in the Transform >> Simplification document and Use Cases and Requirements. Again, >> comment may be sent to the list public-xmlsec-comments@w3.org . >> >> Thank you >> >> regards, Frederick >> >> Frederick Hirsch, Nokia >> Chair XML Security WG >> >> >> > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-66--64250925 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Re-posting from SAAG to CFRG. =  

On Mar 1, 2009, at 7:47 AM, Thomas Roessler = wrote:

FYI, W3C has published = initial working drafts for a number of documents related to XML = Signature and Encryption:

1. Incremental revisions of = XML Signature and Encryption.  These revisions focus on adding = markup and algorithm support for EC DSA (at the same time addressing = some known issues with RFC 4050).  We would appreciate early = comment from the IETF community.

2. Markup for = derived keys.  This document, too, is one that could use review = from the IETF community.

3. A requirements and = design document for a possible version 2 of XML Signature.  This = document focuses on attempting to devise a simpler transform model for = XML Signature, in order to remove some of the complexity of the current = specification.

The full list of drafts released = is in the message quoted below.

If you have any = questions, please feel free to contact Frederick or = me.

Thanks,
--
Thomas Roessler, W3C  <tlr@w3.org>






=

Begin forwarded message:

From: = Frederick Hirsch <frederick.hirsch@nokia.com>=
Date: 26 February 2009 12:09:26 = GMT-06:00
To: chairs@w3.org, XMLSec WG Public List = <public-xmlsec@w3.org>
Cc: Frederick = Hirsch <Frederick.Hirsch@nokia.com>=
Subject: FPWD Transition Announcement -  XML Security = Specifications

=

  
(1) XML Signature = Syntax and Processing Version 1.1

(2) XML Encryption Syntax and Processing Version = 1.1
 http://www.w3= .org/TR/2009/WD-xmlenc-core1-20090226/

=
(3) XML = Signature Transform Simplification: Requirements and = Design
http://ww= w.w3.org/TR/2009/WD-xmldsig-simplify-20090226/

(4) XML = Security Use Cases and Requirements
http://www.w3.= org/TR/2009/WD-xmlsec-reqs-20090226/

(5) XML Security = Derived Keys
http://= www.w3.org/TR/2009/WD-xmlsec-derivedkeys-20090226/
(7) XML Security Algorithm Cross-Reference

<= div>These were included in the following transition = request:

The Working Group has also published an = updated working draft of Best Practices:

(8) = XML Signature Best Practices W3C Working Draft 26 February 2009
http= ://www.w3.org/TR/2009/WD-xmldsig-bestpractices-20090226/

The Working Group would = appreciate review of these documents, with special attention to the = algorithms listed in XML Signature 1.1 and XML Encryption 1.1, the = proposed 2.0 changes in the Transform Simplification document and Use = Cases and Requirements. Again, comment may be sent to the list public-xmlsec-comments@w3.or= g .

Thank you

=
regards, Frederick

Frederick Hirsch, = Nokia
Chair XML Security WG


=


_____= __________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/ma= ilman/listinfo/saag

= --Apple-Mail-66--64250925-- From mcgrew@cisco.com Thu Mar 26 13:23:14 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A6413A68D5 for ; Thu, 26 Mar 2009 13:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5jWNbX874wr for ; Thu, 26 Mar 2009 13:23:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5EFCA3A6867 for ; Thu, 26 Mar 2009 13:22:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,428,1233532800"; d="scan'208";a="274839350" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 26 Mar 2009 20:21:27 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2QKLQ5L024035 for ; Thu, 26 Mar 2009 16:21:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2QKLQsq023557 for ; Thu, 26 Mar 2009 20:21:26 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 16:21:26 -0400 Received: from dhcp-13b3.meeting.ietf.org ([10.86.253.36]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 16:21:26 -0400 Message-Id: From: David McGrew To: cfrg@irtf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Mar 2009 13:21:25 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Mar 2009 20:21:26.0492 (UTC) FILETIME=[708179C0:01C9AE50] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=242; t=1238098886; x=1238962886; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20Standardizing=20Key=20Derivation=20Functions=20 |Sender:=20 |To:=20cfrg@irtf.org; bh=4xjlGSNDWMV5lEd7+xQ90h1FEII0thMzZ0iBMJ9U4sE=; b=qqX5D2hTz34YwP9acK6AxsW0Pe3s1vIgdkEc53/AN7cN7y+jdpC7GjFaAT nmJyzXjcV4p+xUakjA2gU4m/m7tE6sSVJ0V/z3Q6iaXtF1YpRMYShzzD29RX Wd9v4acDZZ; Authentication-Results: rtp-dkim-1; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Cfrg] Standardizing Key Derivation Functions X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 20:23:14 -0000 Hi, Hugo will be giving this presentation shortly to the IETF Security Area Advisory Group. This note is to point it out to people in CFRG that are not in SAAG. http://www3.ietf.org/proceedings/09mar/slides/saag-3.ppt David From mcgrew@cisco.com Thu Mar 26 13:26:15 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A72D13A6987 for ; Thu, 26 Mar 2009 13:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcDqV5BkwRSI for ; Thu, 26 Mar 2009 13:26:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C6A523A6867 for ; Thu, 26 Mar 2009 13:26:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,428,1233532800"; d="scan'208";a="162263040" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Mar 2009 20:26:56 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n2QKQuDF000498 for ; Thu, 26 Mar 2009 13:26:56 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n2QKQtdx005449 for ; Thu, 26 Mar 2009 20:26:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 16:26:55 -0400 Received: from dhcp-13b3.meeting.ietf.org ([10.86.253.36]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 16:26:55 -0400 Message-Id: <7948731C-C334-40FF-A952-7AFA91CBA3FD@cisco.com> From: David McGrew To: cfrg@irtf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Mar 2009 13:26:54 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Mar 2009 20:26:55.0320 (UTC) FILETIME=[3480A580:01C9AE51] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=142; t=1238099216; x=1238963216; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20David=20McGrew=20 |Subject:=20SAAG=20presentations=20at=20IETF=2074 |Sender:=20; bh=6rKlDY6lMiagFEqKmD7t/IFicI+AtI6iuYE92VFR3hQ=; b=VZAYothRpNqbby1ojSUB7+hPw9TmVK77JumpCMAlafbjeIw2GAszIS1vF3 qXsE9gp+IVePRVfxOR6HWiC2spBpzquQWQkff5TBvVNp7cJeXsoAVJi69/ny ebySiJo46r; Authentication-Results: sj-dkim-2; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Cfrg] SAAG presentations at IETF 74 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 20:26:15 -0000 FYI - other SAAG presentations may be of interest; look for "SAAG" on the left. https://datatracker.ietf.org/meeting/74/materials.html From housley@vigilsec.com Sat Mar 28 10:27:21 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6086D3A6825 for ; Sat, 28 Mar 2009 10:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, 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 4M-+fhnPRKfS for ; Sat, 28 Mar 2009 10:27:20 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id ABDA63A67B0 for ; Sat, 28 Mar 2009 10:27:20 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 7A0ED9A4739 for ; Sat, 28 Mar 2009 13:28:19 -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 ZTxPyerS9j5k for ; Sat, 28 Mar 2009 13:28:14 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (dhcp-11fc.meeting.ietf.org [130.129.17.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1F6759A47B3 for ; Sat, 28 Mar 2009 13:28:18 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 28 Mar 2009 13:28:06 -0400 To: cfrg@irtf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090328172818.1F6759A47B3@odin.smetech.net> Subject: [Cfrg] AES Key Wrap with Pad X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 17:27:21 -0000 http://www.ietf.org/internet-drafts/draft-housley-aes-key-wrap-with-pad-02.txt I want to make sure that the CFRG is aware of this document. Russ From dharkins@lounge.org Sat Mar 28 11:49:19 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8C83A69C9 for ; Sat, 28 Mar 2009 11:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 VxHHrTfLIriP for ; Sat, 28 Mar 2009 11:49:18 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id BB6053A68B8 for ; Sat, 28 Mar 2009 11:49:18 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9642C20366; Sat, 28 Mar 2009 11:50:14 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 28 Mar 2009 11:50:14 -0700 (PDT) Message-ID: In-Reply-To: <20090328172818.1F6759A47B3@odin.smetech.net> References: <20090328172818.1F6759A47B3@odin.smetech.net> Date: Sat, 28 Mar 2009 11:50:14 -0700 (PDT) From: "Dan Harkins" To: "Russ Housley" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@irtf.org Subject: Re: [Cfrg] AES Key Wrap with Pad X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 18:49:19 -0000 Hi Russ, This draft addresses a shortcoming in AES Key Wrap (RFC 3394) but I still have to ask "why?" Using this new version of AES Key Wrap will require a new code point and if that's the case why not just use AES-SIV (RFC 5297)? It allows for wrapping of arbitrarily-sized keys (which is the enhancement your new I-D adds to AES Key Wrap) but also has the ability to accept associated data. A key wrapping algorithm that accepts associated data is valuable to protocols which need to distribute wrapped keys. They can bind the message containing the key to the wrapping and/or include shared state to prevent against cut-and-paste attacks. And itt obviates the need to do an additional HMAC-foo over the entire message. While this I-D provides an improvement on AES Key Wrap, it seems to me that it's putting a turbo-charger on a Volkswagon Bug when you could drive a Ferrari instead. regards, Dan. On Sat, March 28, 2009 10:28 am, Russ Housley wrote: > http://www.ietf.org/internet-drafts/draft-housley-aes-key-wrap-with-pad-02.txt > > I want to make sure that the CFRG is aware of this document. > > Russ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > From housley@vigilsec.com Sat Mar 28 13:37:10 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C5A3A6B5D for ; Sat, 28 Mar 2009 13:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, 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 YZb0XM+8EzVh for ; Sat, 28 Mar 2009 13:37:09 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 1EB793A6B47 for ; Sat, 28 Mar 2009 13:37:09 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 5C4989A4773; Sat, 28 Mar 2009 16:38:11 -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 78t0i6tBc9En; Sat, 28 Mar 2009 16:38:03 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (dhcp-11fc.meeting.ietf.org [130.129.17.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id BD2169A4739; Sat, 28 Mar 2009 16:38:09 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 28 Mar 2009 16:31:03 -0400 To: "Dan Harkins" From: Russ Housley In-Reply-To: References: <20090328172818.1F6759A47B3@odin.smetech.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090328203809.BD2169A4739@odin.smetech.net> Cc: cfrg@irtf.org Subject: Re: [Cfrg] AES Key Wrap with Pad X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 20:37:10 -0000 Some people are interested in using AES Key Wrap when the inputs are not a multiple of 64 bits. This was previously addressed in RFC 3537 in a way that does not scale to all key types that one might want to wrap. This one does the job with very little code modification. I did the code the generate the test vectors in a few hours, including checking against code from someone else, and I have not written code as a primary aspect of my job in a very long time. Russ At 02:50 PM 3/28/2009, Dan Harkins wrote: > Hi Russ, > > This draft addresses a shortcoming in AES Key Wrap (RFC 3394) but I >still have to ask "why?" > > Using this new version of AES Key Wrap will require a new code point >and if that's the case why not just use AES-SIV (RFC 5297)? It allows >for wrapping of arbitrarily-sized keys (which is the enhancement your >new I-D adds to AES Key Wrap) but also has the ability to accept >associated data. > > A key wrapping algorithm that accepts associated data is valuable to >protocols which need to distribute wrapped keys. They can bind the >message containing the key to the wrapping and/or include shared state >to prevent against cut-and-paste attacks. And itt obviates the need to >do an additional HMAC-foo over the entire message. > > While this I-D provides an improvement on AES Key Wrap, it seems to >me that it's putting a turbo-charger on a Volkswagon Bug when you could >drive a Ferrari instead. > > regards, > > Dan. > >On Sat, March 28, 2009 10:28 am, Russ Housley wrote: > > > http://www.ietf.org/internet-drafts/draft-housley-aes-key-wrap-with-pad-02.txt > > > > I want to make sure that the CFRG is aware of this document. > > > > Russ > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > http://www.irtf.org/mailman/listinfo/cfrg > > From dharkins@lounge.org Sat Mar 28 23:02:53 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3C13A6ACF for ; Sat, 28 Mar 2009 23:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 i9c+tSBS-MXX for ; Sat, 28 Mar 2009 23:02:52 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 389413A68ED for ; Sat, 28 Mar 2009 23:02:52 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 022C02036A; Sat, 28 Mar 2009 23:03:47 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 28 Mar 2009 23:03:48 -0700 (PDT) Message-ID: <6f305b97b0c1c2e181c09b819463bdb8.squirrel@www.trepanning.net> In-Reply-To: <20090328203809.BD2169A4739@odin.smetech.net> References: <20090328172818.1F6759A47B3@odin.smetech.net> <20090328203809.BD2169A4739@odin.smetech.net> Date: Sat, 28 Mar 2009 23:03:48 -0700 (PDT) From: "Dan Harkins" To: "Russ Housley" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@irtf.org Subject: Re: [Cfrg] AES Key Wrap with Pad X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2009 06:02:53 -0000 Hi Russ, I understand the desire to wrap things that are not a multiple of 64 bits (the inability to do that is a serious shortcoming of AES Key Wrap). I'd probably expect people to also be interested in having the ability to bind associated data to the wrapped key. And I'll bet people would be interested in a provably secure key wrapping algorithm. SIV has a security proof behind it-- see "Deterministic Authenticated Encryption, A Provable-Security Treatment of the Key-Wrap Problem" by Rogaway and Shrimpton; to my knowledge, AES Key Wrap, with or without padding, does not. SIV provides for the binding of associated data to the wrapped key; AES Key Wrap does not. The fact that the modifications you're proposing to AES Key Wrap can be done by someone whose coding skills are a bit rusty does not change the fact that it is a new code point. This particular wrapping will have to be distinguished from RFC 3394 and protocol designers are going to have to go through the trouble of adding another negotiated key wrapping to their protocol. So given the choice of "wraps keys of arbitrary length, binds associated data to wrapped keys, provably secure" or "wraps keys of arbitrary length" why would you not want to go with the former? regards, Dan. On Sat, March 28, 2009 1:31 pm, Russ Housley wrote: > Some people are interested in using AES Key Wrap when the inputs are > not a multiple of 64 bits. This was previously addressed in RFC 3537 > in a way that does not scale to all key types that one might want to > wrap. This one does the job with very little code modification. I > did the code the generate the test vectors in a few hours, including > checking against code from someone else, and I have not written code > as a primary aspect of my job in a very long time. > > Russ > > At 02:50 PM 3/28/2009, Dan Harkins wrote: > >> Hi Russ, >> >> This draft addresses a shortcoming in AES Key Wrap (RFC 3394) but I >>still have to ask "why?" >> >> Using this new version of AES Key Wrap will require a new code point >>and if that's the case why not just use AES-SIV (RFC 5297)? It allows >>for wrapping of arbitrarily-sized keys (which is the enhancement your >>new I-D adds to AES Key Wrap) but also has the ability to accept >>associated data. >> >> A key wrapping algorithm that accepts associated data is valuable to >>protocols which need to distribute wrapped keys. They can bind the >>message containing the key to the wrapping and/or include shared state >>to prevent against cut-and-paste attacks. And itt obviates the need to >>do an additional HMAC-foo over the entire message. >> >> While this I-D provides an improvement on AES Key Wrap, it seems to >>me that it's putting a turbo-charger on a Volkswagon Bug when you could >>drive a Ferrari instead. >> >> regards, >> >> Dan. >> >>On Sat, March 28, 2009 10:28 am, Russ Housley wrote: >> > >> http://www.ietf.org/internet-drafts/draft-housley-aes-key-wrap-with-pad-02.txt >> > >> > I want to make sure that the CFRG is aware of this document. >> > >> > Russ >> > >> > _______________________________________________ >> > Cfrg mailing list >> > Cfrg@irtf.org >> > http://www.irtf.org/mailman/listinfo/cfrg >> > > > From housley@vigilsec.com Mon Mar 30 10:41:22 2009 Return-Path: X-Original-To: cfrg@core3.amsl.com Delivered-To: cfrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE6A3A67CF for ; Mon, 30 Mar 2009 10:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.923 X-Spam-Level: X-Spam-Status: No, score=-101.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599, 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 yWyzfjH5ne6b for ; Mon, 30 Mar 2009 10:41:21 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id B5F4D3A695C for ; Mon, 30 Mar 2009 10:41:21 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 269A99A47BC; Mon, 30 Mar 2009 13:42:33 -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 b49lhIBOeBvY; Mon, 30 Mar 2009 13:42:18 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-71-191-197-15.washdc.fios.verizon.net [71.191.197.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 7F2E29A479F; Mon, 30 Mar 2009 13:42:32 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 30 Mar 2009 13:11:56 -0400 To: "Dan Harkins" From: Russ Housley In-Reply-To: <6f305b97b0c1c2e181c09b819463bdb8.squirrel@www.trepanning.n et> References: <20090328172818.1F6759A47B3@odin.smetech.net> <20090328203809.BD2169A4739@odin.smetech.net> <6f305b97b0c1c2e181c09b819463bdb8.squirrel@www.trepanning.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090330174232.7F2E29A479F@odin.smetech.net> Cc: cfrg@irtf.org Subject: Re: [Cfrg] AES Key Wrap with Pad X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2009 17:41:22 -0000 Dan: >So given the choice of "wraps keys of arbitrary length, binds associated >data to wrapped keys, provably secure" or "wraps keys of arbitrary length" >why would you not want to go with the former? I have no objection to looking at other key wrap algorithms. This one is already FIPS-approved, and it is very unclear what the time schedule would be for another one to become FIPS-approved. Russ