errata logo graphic

Found 4 records.

Status: Verified (4)

RFC5911, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", June 2010

Source of RFC: smime (sec)

Errata ID: 2612

Status: Verified
Type: Technical

Reported By: Jim Schaad
Date Reported: 2010-11-06
Verifier Name: Tim Polk
Date Verified: 2010-11-30

Section 6 and others says:

ct-Data CONTENT-TYPE ::= {OCTET STRING IDENTIFIED BY id-data}

It should say:

ct-Data CONTENT-TYPE ::= {IDENTIFIED BY id-data}

Notes:

Due to a confusion in the part of the author's head that resulted from the difference the way that encapsulated content types are encoded between PKCS#7 and CMS, I put the type of OCTET STRING in this location. Since the OCTET STRING is explicitly included by the the encapulsated content type now, there should be an absence of a data type for the content type of id-data. Making this change however requires that some additional changes be made. It is not possible to just omit the type for a TYPE-IDENTIFIER type so a new class definition is required for CONTENT-TYPE. Unfortionately it is also not possible to simply omit the type from the syntax provided for the new content type as the parser is defined as being opertunistic rather than pessimistic by the ASN.1 syntax. Thus the tag IDENTIFIER would be consumed as a type and the rest of the parsing would fail. We there need to make the following changes:

1. Define a new object class of CONTENT-TYPE as
CONTENT-TYPE ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
} WITH SYNTAX {
[TYPE &Type] IDENTIFIED BY &id
}

2. We make the change to the defintion of ct-Data as above so that it no longer has an implied ASN.1 type associated with the object identifier

3. We then change all locations where a new content type is defined as follows:
ct-Foo CONTENT-TYPE ::= {Foo IDENTIFIED BY id-Foo}
becomes
ct-Foo CONTENT-TYPE ::= {TYPE Foo IDENTIFIED BY id-Foo}

Changes 1 and 2 will occur in the module for RFC 3851 (now RFC 5281)
Change 3 will occur in a number of different modules including modules that have been published independently since this document was released.


Errata ID: 2648

Status: Verified
Type: Technical

Reported By: Jim Schaad
Date Reported: 2010-11-29
Verifier Name: Tim Polk
Date Verified: 2010-11-30

Section Section 6 says:

  FROM AttributeCertificateVersion1-2009
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) modules(0) id-mod-v1AttrCert-02(49) } ;

It should say:

  FROM AttributeCertificateVersion1-2009
      { iso(1) member-body(2) dod(6) internet(1) security(5)
        mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;

Notes:

The wrong oid arc was used for the module identification. A similar changes is also being reported for RFC 5912


Errata ID: 2665

Status: Verified
Type: Technical

Reported By: Jim Schaad
Date Reported: 2010-12-09
Verifier Name: Tim Polk
Date Verified: 2011-03-26

Section Section 6 says:

FROM AttributeCertificateVersion1-2009
      { iso(1) member-body(2) dod(6) internet(1) security(5)
        mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;

It should say:

FROM AttributeCertificateVersion1-2009
      { iso(1) identified-organization(3) dod(6) internet(1) security(5)
        mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;

Notes:

One incorrect node in the arc was noted from the last errata.


Errata ID: 3128

Status: Verified
Type: Technical

Reported By: Russ Housley
Date Reported: 2012-02-18
Verifier Name: Sean Turner
Date Verified: 2012-03-05

Section 8 says:

   ContentInfo
   FROM CryptographicMessageSyntax2004
       { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) } ;

It should say:

   ContentInfo
   FROM CryptographicMessageSyntax-2009
       {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
        smime(16) modules(0) id-mod-cms-2004-02(41)};

Notes:

ContentInfo to be imported from the module that is defined elsewhere in RFC 5911.


Report New Errata