RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (2)

RFC 5752, "Multiple Signatures in Cryptographic Message Syntax (CMS)", January 2010

Source of RFC: smime (sec)

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

Reported By: Derek Edson
Date Reported: 2015-08-11
Verifier Name: Stephen Farrell
Date Verified: 2015-08-14

Section 3 says:

id-aa-multipleSignatures OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
        id-aa(16) 51 }

It should say:

id-aa-multipleSignatures OBJECT IDENTIFIER ::= { 
       iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 
       smime(16) id-aa(2) 51 }


Notes:

The definition in Appendix A (ASN.1 module) is also incorrect, and inconsistent with section 3, which defines

id-aa-multipleSignatures OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-aa(2) 51 }

Under 1.2.840.113549.1.9, 16 is smime, not id-aa. id-aa(2) exists under smime(16)

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

Reported By: Joël Repiquet
Date Reported: 2013-06-25
Verifier Name: Sean Turner
Date Verified: 2013-08-12

Section 4.3 says:

   The procedures for generating SignerInfo are as specified in Section
   4.4.1 of [CMS] with the following addition:

It should say:

   The procedures for generating SignerInfo are as specified in Section
   5.3 with the following addition:

Notes:

Sean Turner confirmed the error but did not mention the right section reference.

I updated this to point to s5.3. (spt)

Status: Held for Document Update (3)

RFC 5752, "Multiple Signatures in Cryptographic Message Syntax (CMS)", January 2010

Source of RFC: smime (sec)

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

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

Section 5, pg. 8 says:

   This section describes recommended processing of signatures when
|  there are more than one SignerInfo present in a message.  This may be
   due to either multiple SignerInfo objects being present in a single
|  SignedData object or multiple SignerData objects embedded in each
   other.

   [...]

   Order of operations:

   1) Evaluate each SignerInfo object independently.

   2) Combine the results of all SignerInfo objects at the same level
|     (i.e., attached to the same SignerData object).

|  3) Combine the results of the nested SignerData objects.  Note that
      this should ignore the presence of other CMS objects between the
      SignedData objects.

It should say:

   This section describes recommended processing of signatures when
|  there is more than one SignerInfo object present in a message.  This
   may be due to either multiple SignerInfo objects being present in a
|  single SignedData object or multiple SignedData objects embedded in
   each other.

   [...]

   Order of operations:

   1) Evaluate each SignerInfo object independently.

   2) Combine the results of all SignerInfo objects at the same level
|     (i.e., attached to the same SignedData object).

|  3) Combine the results of the nested SignedData objects.  Note that
      this should ignore the presence of other CMS objects between the
      SignedData objects.

Notes:

Rationale:
There's no such ASN.1 type/object "SignerData".
Based on the importance of referencing the correct type/object,
the correction to "SignedData" is classified as 'Technical'.
Also a clarification and fix is applied in the first sentence.

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

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

Section 2.1, pg. 6 says:

   The following is an example:

      SignedData
        DigestAlg=sha1,sha256
        SignerInfo1                SignerInfo2
          digestAlg=sha1             digestAlg=sha256
          signatureAlg=dsawithsha1   signatureAlg=ecdsawithsha256
          signedAttrs=               signedAttrs=
            signingTime1               signingTime1
            messageDigest1             messageDigest2
            multiSig1=                 multiSig2=
              bodyHash=sha256           bodyHash=sha1
              signAlg=ecdsawithsha256   signAlg=dsawithsha1
 |              signAttrsHash=          signAttrsHash=
 |              algID=sha1              algID=sha256
 |              hash=value1             hash=value2

It should say:

   The following is an example:

      SignedData
        DigestAlg=sha1,sha256
        SignerInfo1                SignerInfo2
          digestAlg=sha1             digestAlg=sha256
          signatureAlg=dsawithsha1   signatureAlg=ecdsawithsha256
          signedAttrs=               signedAttrs=
            signingTime1               signingTime1
            messageDigest1             messageDigest2
            multiSig1=                 multiSig2=
              bodyHash=sha256           bodyHash=sha1
              signAlg=ecdsawithsha256   signAlg=dsawithsha1
 |            signAttrsHash=            signAttrsHash=
 |              algID=sha1                algID=sha256
 |              hash=value1               hash=value2

Notes:

Rationale:
Fixed indentation for consistency and clarity
(visual indication of subordinate elements).

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

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

Section 4.1, pg. 7 says:

   - The signer MUST:

     -- Retain the existing signerInfo objects.

|    -- Include their signerInfo object(s).

It should say:

   - The signer MUST:

     -- Retain the existing signerInfo objects.

|    -- Include their own signerInfo object(s).

Notes:

Rationale: Remove possible ambiguity of language.
(Keep for update!)

Report New Errata



Advanced Search