RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (2)

RFC 5652, "Cryptographic Message Syntax (CMS)", September 2009

Note: This RFC has been updated by RFC 8933

Source of RFC: smime (sec)

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

Reported By: Russ Housley
Date Reported: 2020-08-06
Verifier Name: Benjamin Kaduk
Date Verified: 2020-08-07

Section 9.2 says:

   If the authAttrs field is present, the content-type attribute (as
   described in Section 11.1) and the message-digest attribute (as
   described in Section 11.2) MUST be included, and the input to the MAC
   calculation process is the DER encoding of authAttrs.  A separate
   encoding of the authAttrs field is performed for message digest
   calculation.  The IMPLICIT [2] tag in the authAttrs field is not used
   for the DER encoding, rather an EXPLICIT SET OF tag is used.  That
   is, the DER encoding of the SET OF tag, rather than of the IMPLICIT
   [2] tag, is to be included in the message digest calculation along
   with the length and content octets of the authAttrs value.

It should say:

   If the authAttrs field is present, the content-type attribute (as
   described in Section 11.1) and the message-digest attribute (as
   described in Section 11.2) MUST be included, and the input to the MAC
   calculation process is the DER encoding of authAttrs.  A separate
   encoding of the authAttrs field is performed for message digest
   calculation.  The IMPLICIT [2] tag in the authAttrs field is not used
   for the DER encoding, rather an EXPLICIT SET OF tag is used.  That
   is, the DER encoding of the SET OF tag, rather than of the IMPLICIT
   [2] tag, is to be included in the MAC calculation along
   with the length and content octets of the authAttrs value.

Notes:

The paragraph is talking about the input to a MAC calculation, not the input to message digest calculation.

Errata ID: 6546
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Daniel Kahn Gillmor
Date Reported: 2021-04-15
Verifier Name: Benjamin Kaduk
Date Verified: 2021-04-15

Section 12.1 says:

  -- Imports from Appendix B of this document
           AttributeCertificateV1
              FROM AttributeCertificateVersion1

It should say:

  -- Imports from Section 12.2 of this document
           AttributeCertificateV1
              FROM AttributeCertificateVersion1

Notes:

The AttributeCertificateVersion1 is defined in section 12.2; there is no Appendix B in this document.

Status: Held for Document Update (3)

RFC 5652, "Cryptographic Message Syntax (CMS)", September 2009

Note: This RFC has been updated by RFC 8933

Source of RFC: smime (sec)

Errata ID: 7863
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: heasley
Date Reported: 2024-03-21
Held for Document Update by: Deb Cooley
Date Held: 2024-03-22

Section 5.2 says:

"... and the content
   field of the EncapsulatedContentInfo value MUST be omitted."

It should say:

"... and the eContent
   field of the EncapsulatedContentInfo value MUST be omitted."

Notes:

No 'content' field exists and I do not think this is referring to another structure.

Errata ID: 2026
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2010-01-28
Held for Document Update by: Tim Polk

Section 5.3, pg. 15 says:

[[  around the page break from page 14 to page 15: ]]

      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used by the signer.  The message digest is
      computed on either the content being signed or the content
<< page break >>
      together with the signed attributes using the process described in
      Section 5.4.  The message digest algorithm SHOULD be among those
|     listed in the digestAlgorithms field of the associated SignerData.
                                                             ^^^^^^^^^^
      Implementations MAY fail to validate signatures that use a digest
      algorithm that is not included in the SignedData digestAlgorithms
      set.

It should say:

      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used by the signer.  The message digest is
      computed on either the content being signed or the content
      together with the signed attributes using the process described in
      Section 5.4.  The message digest algorithm SHOULD be among those
|     listed in the digestAlgorithms field of the associated SignedData.
      Implementations MAY fail to validate signatures that use a digest
      algorithm that is not included in the SignedData digestAlgorithms
      set.

Notes:

Rationale:
There's no such ASN.1 type/object named "SignerData" in relevant
specifications. Text should refer to "SignedData" instead.
This is an undetected legacy flaw inherited literally from RFC 2630,
RFC 3369, and RFC 3852.

Errata ID: 3867
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jos Breek
Date Reported: 2014-01-16
Held for Document Update by: Kathleen Moriarty
Date Held: 2015-03-24

Section 5.3 says:

digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer.

It should say:

digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the signer in the signature Generation 
Process. 

Notes:

The text stated that the message digest algorithm is "used by the signer". It is unclear for what purpose the message digest algorithm is used. This recommendation is editorial and was accepted.


Additional text provided was not accepted as there is no requirement that digest used on the body is the same as the digest used in the signature operation.

The following sentence was suggested (and rejected):
"The message digest algorithm shall be equal to the message
digest algorithm used in the signatureAlgorithm field."

With the explanation in the original errata report for this additional sentence as:
There are implementations that use the message digest algorithm specified in the messageDigest field instead of the message digest algorithm specified in the signatureAlgorithm.

Is the purpose of the messageDigest field to nest the hashing algorithm used in the signing process? If so, please use the corrected text to clarify the goal of the field.

Status: Rejected (1)

RFC 5652, "Cryptographic Message Syntax (CMS)", September 2009

Note: This RFC has been updated by RFC 8933

Source of RFC: smime (sec)

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

Reported By: Thomas Stimm
Date Reported: 2018-04-23
Rejected by: Eric Rescorla
Date Rejected: 2018-04-27

Section 6.1 and 8 says:

EncryptedData ::= SEQUENCE {
   version CMSVersion,
   encryptedContentInfo EncryptedContentInfo,
   unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

EncryptedContentInfo ::= SEQUENCE {
   contentType ContentType,
   contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
   encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

It should say:

EncryptedData ::= SEQUENCE {
   version CMSVersion,
   encryptedContentInfo EncryptedContentInfo,
   encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL,
   unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }

EncryptedContentInfo ::= SEQUENCE {
   contentType ContentType,
   contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier }

Notes:

- Wrong enumeration of UnprotectedAttributes OPTIONAL [1] instead of [0].
- ‘UnprotectedAttributes OPTIONAL’ makes only sense, if ‘EncryptedContent OPTIONAL’ is available.
- It seems that OpenSSL and wolfSSL are using the suggested wrapping and are not following the RFC, here.
--VERIFIER NOTES--
Misunderstanding of the specification

Report New Errata



Advanced Search