errata logo graphic

Found 4 records.

Status: Verified (1)

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

Source of RFC: smime (sec)

Errata ID: 3670

Status: Verified
Type: Editorial

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)

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

Source of RFC: smime (sec)

Errata ID: 2027

Status: Held for Document Update
Type: Editorial

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

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

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