[Top] [All Lists]

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

2010-02-01 18:12:44

Please note that the Errata ID assigned to this report has changed. It is now 

You may view the report below and at:

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 

[removed incorrect URL]

Type: Technical
Reported by: Derek Edson <Derek(_dot_)Edson(_at_)sss(_dot_)co(_dot_)nz>


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

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".

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 mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [smime] Correction: [Technical Errata Reported] RFC5751 (2031) WAS: Technical Errata Reported] RFC5751 (10000), rfc-editor <=