From wwwrun@rfc-editor.org Mon Feb 1 14:48:02 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 A155D28C1D2 for ; Mon, 1 Feb 2010 14:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, 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 iAQrfyDCOHZ0 for ; Mon, 1 Feb 2010 14:48:01 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id C7FBF28C1C3 for ; Mon, 1 Feb 2010 14:48:01 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DE825130001; Mon, 1 Feb 2010 14:48:37 -0800 (PST) To: blaker@gmail.com, turners@ieca.com, tim.polk@nist.gov, pasi.eronen@nokia.com, turners@ieca.com, blaker@gmail.com From: RFC Errata System Message-Id: <20100201224837.DE825130001@rfc-editor.org> Date: Mon, 1 Feb 2010 14:48:37 -0800 (PST) Cc: rfc-editor@rfc-editor.org, Derek.Edson@sss.co.nz, smime@ietf.org Subject: [smime] [Technical Errata Reported] RFC5751 (10000) 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, 01 Feb 2010 22:48:02 -0000 The following errata report has been submitted for RFC5751, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5751&eid=10000 -------------------------------------- Type: Technical Reported by: Derek Edson Section: 3.4.3.2 Original Text ------------- The micalg parameter allows for one-pass processing when the signature is being verified. The value of the micalg parameter is dependent on the message digest algorithm(s) used in the calculation of the Message Integrity Check. If multiple message digest algorithms are used, they MUST be separated by commas per [MIME- SECURE]. The values to be placed in the micalg parameter SHOULD be from the following: Algorithm Value Used MD5 md5 SHA-1 sha-1 SHA-224 sha-224 SHA-256 sha-256 SHA-384 sha-384 SHA-512 sha-512 Any other (defined separately in algorithm profile or "unknown" if not defined) (Historical note: some early implementations of S/MIME emitted and expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.) Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they do not recognize. Future names for this parameter will be consistent with the IANA "Hash Function Textual Names" registry. Corrected Text -------------- Notes ----- This revision creates a backward compatibility issue with S/MIME v2, S/MIME v3 and S/MIME v3.1 agents. In each of the previous (obsoleted) standards, they all refer to the micalg for SHA-1 as "sha1" and not "sha-1". The historical note should mean that v3.2 agents will recognize "sha1" as emitted by earlier implementations, but these implementations are unlikely to recognize the micalg value of "sha-1" emitted by a v3.2 agent. All previous standards state that receiving agents SHOULD be able to handle this situation gracefully, but when these agents fail to recognize a micalg value, they can no longer perform a "one-pass processing". Given that this parameter is "required", the most likely implication is that they will fail to verify the signature. To ensure interoperability with clients supporting previous versions, the micalg for SHA-1 MUST remain as "sha1", and receiving agents SHOULD also accept "sha-1". The micalg parameters values have always been defined as "SHOULD", but for interoperability they should be declared as "MUST". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5751 (draft-ietf-smime-3851bis-11) -------------------------------------- Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Publication Date : January 2010 Author(s) : B. Ramsdell, S. Turner Category : PROPOSED STANDARD Source : S/MIME Mail Security Area : Security Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Feb 1 16:11:54 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 9AA3B3A69EE for ; Mon, 1 Feb 2010 16:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 XctrYSF+2Mf6 for ; Mon, 1 Feb 2010 16:11:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id A5E3E3A69CA for ; Mon, 1 Feb 2010 16:11:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 80101130001; Mon, 1 Feb 2010 16:12:21 -0800 (PST) To: Blake Ramsdell , Sean Turner , Tim Polk , Eronen Pasi (Nokia-NRC/Helsinki) From: rfc-editor@rfc-editor.org Message-Id: <20100202001221.80101130001@rfc-editor.org> Date: Mon, 1 Feb 2010 16:12:21 -0800 (PST) Cc: rfc-editor@rfc-editor.org, Derek.Edson@sss.co.nz, smime@ietf.org Subject: [smime] Correction: [Technical Errata Reported] RFC5751 (2031) WAS: Technical Errata Reported] RFC5751 (10000) 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, 02 Feb 2010 00:11:54 -0000 Correction: Please note that the Errata ID assigned to this report has changed. It is now 2031. You may view the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5751&eid=2031 Apologies for the inconvenience. Thank you. RFC Editor/ah On Feb 1, 2010, at 5:48 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC5751, > "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification". > [removed incorrect URL] > > -------------------------------------- > Type: Technical > Reported by: Derek Edson > > Section: 3.4.3.2 > > Original Text > ------------- > The micalg parameter allows for one-pass processing when the > signature is being verified. The value of the micalg parameter is > dependent on the message digest algorithm(s) used in the calculation > of the Message Integrity Check. If multiple message digest > algorithms are used, they MUST be separated by commas per [MIME- > SECURE]. The values to be placed in the micalg parameter SHOULD be > from the following: > > Algorithm Value Used > > MD5 md5 > SHA-1 sha-1 > SHA-224 sha-224 > SHA-256 sha-256 > SHA-384 sha-384 > SHA-512 sha-512 > Any other (defined separately in algorithm profile or "unknown" > if not defined) > > (Historical note: some early implementations of S/MIME emitted and > expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.) > Receiving agents SHOULD be able to recover gracefully from a micalg > parameter value that they do not recognize. Future names for this > parameter will be consistent with the IANA "Hash Function Textual > Names" registry. > > > Corrected Text > -------------- > > > Notes > ----- > This revision creates a backward compatibility issue with S/MIME v2, S/MIME v3 and S/MIME v3.1 agents. In each of the previous (obsoleted) standards, they all refer to the micalg for SHA-1 as "sha1" and not "sha-1". > > The historical note should mean that v3.2 agents will recognize "sha1" as emitted by earlier implementations, but these implementations are unlikely to recognize the micalg value of "sha-1" emitted by a v3.2 agent. > > All previous standards state that receiving agents SHOULD be able to handle this situation gracefully, but when these agents fail to recognize a micalg value, they can no longer perform a "one-pass processing". Given that this parameter is "required", the most likely implication is that they will fail to verify the signature. > > To ensure interoperability with clients supporting previous versions, the micalg for SHA-1 MUST remain as "sha1", and receiving agents SHOULD also accept "sha-1". > > The micalg parameters values have always been defined as "SHOULD", but for interoperability they should be declared as "MUST". > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5751 (draft-ietf-smime-3851bis-11) > -------------------------------------- > Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification > Publication Date : January 2010 > Author(s) : B. Ramsdell, S. Turner > Category : PROPOSED STANDARD > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG From root@core3.amsl.com Fri Feb 19 15:00:01 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 3B49D3A7F00; Fri, 19 Feb 2010 15:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100219230001.3B49D3A7F00@core3.amsl.com> Date: Fri, 19 Feb 2010 15:00:01 -0800 (PST) X-Mailman-Approved-At: Fri, 19 Feb 2010 15:32:45 -0800 Cc: smime@ietf.org Subject: [smime] I-D ACTION:draft-ietf-smime-cms-rsa-kem-11.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, 19 Feb 2010 23:00:01 -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-11.txt Pages : 27 Date : 2010-2-19 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 ANS X9.44 and ISO/IEC 18033-2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsa-kem-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-2-19145244.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Thu Feb 25 09:38: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 1160228C108; Thu, 25 Feb 2010 09:38:29 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100225173830.1160228C108@core3.amsl.com> Date: Thu, 25 Feb 2010 09:38:30 -0800 (PST) Cc: smime@ietf.org Subject: [smime] Second Last Call: draft-ietf-smime-cms-rsa-kem (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 Reply-To: ietf@ietf.org List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 17:38:30 -0000 The IESG has received a request from the S/MIME Mail Security WG (smime) to consider the following document: - 'Use of the RSA-KEM Key Transport Algorithm in CMS ' as a Proposed Standard This is a second Last Call, and focuses on two normative references to Informational RFCs that were not explicitly identified in the first Last Call. The draft includes normative references to: * RFC 3217, "Triple-DES and RC2 Key Wrapping", and * RFC 3394, "Advanced Encryption Standard (AES) Key Wrap Algorithm" The IESG would like to determine whether the community believes these documents are an appropriate reference for a standards track document in spit of the lower maturity level. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10322&rfc_flag=0