RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (2)

RFC 5751, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", January 2010

Note: This RFC has been obsoleted by RFC 8551

Source of RFC: smime (sec)

Errata ID: 2143
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Jim Schaad
Date Reported: 2010-04-08
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 3.2.2 says:

      Name                   CMS Type                Inner Content
      enveloped-data         EnvelopedData           id-data
      signed-data            SignedData              id-data
      certs-only             SignedData              none
      compressed-data        CompressedData          id-data

It should say:

      Name                   CMS Type                Inner Content
      enveloped-data         EnvelopedData           id-data
      signed-data            SignedData              id-data
      certs-only             SignedData              id-data
      compressed-data        CompressedData          id-data

Notes:

The inner content type is not an optional field. Some inner content type MUST be included, id-data is the correct inner content type to be specified.

The balance of the required information is in section 3.7. It is possible that the fact that id-data is used as the encapsulated content type should be added to the section Step 1 in 3.7

Errata ID: 2708
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Jim Schaad
Date Reported: 2011-02-06
Verifier Name: Tim Polk
Date Verified: 2011-03-09

Section 3.4.3.3 says:

Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42

It should say:

Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha-1; boundary=boundary42

Notes:

In this version we updated the strings associated with the micalg parameter, however the example was not updated to use the correct new value.

Status: Reported (1)

RFC 5751, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", January 2010

Note: This RFC has been obsoleted by RFC 8551

Source of RFC: smime (sec)

Errata ID: 4273
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Peter Gutmann
Date Reported: 2015-02-18

Section Global says:


Notes:

RFC 5751 contains several S/MIME sample messages, prefixed with the text "A sample message would be". These samples aren't actually valid S/MIME messages but merely contain 141 bytes of random garbage. In other words the S/MIME "sample messages" aren't actually sample messages.

Status: Rejected (1)

RFC 5751, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", January 2010

Note: This RFC has been obsoleted by RFC 8551

Source of RFC: smime (sec)

Errata ID: 2031
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Derek Edson
Date Reported: 2010-02-01
Rejected by: Tim Polk
Date Rejected: 2010-03-21

Section 3.4.3.2 says:

   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.

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".
--VERIFIER NOTES--
These changes were introduced for alignment with the names in the IANA "Hash Function Textual Names" registry. Given that the requirements is a SHOULD and the note explains the situation, I do not consider this text in error.

Report New Errata



Advanced Search