RFC Errata
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!)