[smime] [Technical Errata Reported] RFC5751 (10000)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 01 February 2010 22:48 UTC
Return-Path: <wwwrun@rfc-editor.org>
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 <smime@core3.amsl.com>; 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 <smime@core3.amsl.com>; 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 <smime@ietf.org>; 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 <rfc-editor@rfc-editor.org>
Message-Id: <20100201224837.DE825130001@rfc-editor.org>
Date: Mon, 01 Feb 2010 14:48:37 -0800
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 <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smime>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=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 <Derek.Edson@sss.co.nz> 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
- [smime] [Technical Errata Reported] RFC5751 (1000… RFC Errata System