Found 1 record.
Status: Held for Document Update (1)
RFC 4073, "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", May 2005Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec
Errata ID: 762
Status: Held for Document Update
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-05-17
Held for Document Update by: Sean Turner
In the module heading and in the IMPORTS clause of the ASN.1 module of RFC 4073 (Appendix A on page 7), the textual label for the sub-identifier 9 of the OBJECT IDENTIFIER 1.2.840.113549.1 is spelled "pkcs-9(9)". But, ALL other (#=4) appearances of this same sub-identifier in the text of RFC 4073 use the spelling "pkcs9(9)" (without the '-'). I've tried to resolve this inconsistency going "back to the roots", and unfortunately found a big mess! (see detailed list below) Basically, PKCS#9 v2.0 from RSA Labs and its ASCII-fication RFC 2985 should be considered the primary reference because this spec contains the definition of the OBJECT IDENTIFIER 1.2.840.113549.1.9 . There, the spelling consistently is "pkcs-9(9)" . This notation style is strictly followed in all PKCS publications from RSA (as far as I could verify), and in most RFCs related to PKCS/CMS/PKIX. I've found 24 RFCs of this kind. But there are two RFCs using the spelling "pkcs9(9)" (without the '-') exclusively. And finally, I found 8 RFCs - including RFC 4073 and your RFC 4049, as well - using both spellings mixed without any recognizable pattern. Here are the detailed results of my RFC scan - with shortened titles, and some content oriented grouping applied: 'pkcs-9(9)' only : ---------------- 2985 - PKCS #9 2311 - S/MIME v.2 Message Specification, 2312 - S/MIME v.2 Certificate Handling, 2633 - S/MIME v.3 Message Specification 3114 - Company Classifying Policy via S/MIME Security Label 3183 - Domain Security Services using S/MIME 3850 - S/MIME v.3.1 Certificate Handling 3855 - Transporting S/MIME Objects in X.400 2459 - PKIX Certificate and CRL Profile [ obsoleted by: 3280 ] 3280 - PKIX Certificate and CRL Profile 2511 - PKIX Certificate Request Messages 3029 - PKIX Data Validation and Certification Server Protocols 2797 - Certificate Mgmt Messages over CMS 3161 - PKIX Time-Stamp Protocol 3125 - Electronic Signature Policies 3211 - Password-based Encryption for CMS [ obsoleted by: 3369+3370 ] 3274 - Compressed Data Content for CMS 2875 - D-H Proof-of-Posession 3185 - Reuse of CMS CEKs 3217 - Triple-DES and RC2 Key Wrapping 3370 - CMS Algorithms 3537 - HMAC Key Wrapping with 3DES or AES 3560 - RSAES-OAEP Key Transport in CMS 3565 - Use of AES Encryption in CMS 'pkcs9(9)' only : --------------- 3657 - Use of Camellia Encryption in CMS 4010 - Use of SEED Encryption in CMS mixed spelling : -------------- 2630 - CMS [ obsoleted by: 3369+3370 ] 3369 - CMS [ obsoleted by: 3852 ] 3852 - CMS 2634 - Enhanced Security Services for S/MIME 3851 - S/MIME v.3.1 Message Specification 3126 - Electronic Signature Formats for lon-term signatures 4049 - BinaryTime 4073 - Multiple Content in CMS Note: I fear that there might exist similar inconsistencies for other ==== object identifiers (verification: t.b.d.) So, what should be done? It certainly would be VERY preferable to follow identifier naming literally, always and strictly, once published in a normatively referable way. At least, we should ensure a consistent use of already defined identifiers to be followed in future IETF publications. Additionally, it might be considered to post Errata Notes for some (or all non-obsoleted) RFCs in the 2nd and 3rd category above (i.e., RFCs 2634, 3126, 3657, 3851, 3852, 4010, 4049, 4073).
It should say: