[smime] Correction: [Technical Errata Reported] RFC5751 (2031) WAS: Technical Errata Reported] RFC5751 (10000)

[[e-mail]]

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 <[e-mail]>
> 
> 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