RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

Note: This RFC has been updated by RFC 6268

Source of RFC: smime (sec)
See Also: RFC 5911 w/ inline errata

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

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.

Report New Errata



Advanced Search