Search RFCs

RFC Editor

Found 1 record.

Status:Held for Document Update (1)

RFC 4073, "Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)", May 2005

Errata ID:762
Status: Held for Document Update
Type: Technical
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 moduleof RFC 4073 (Appendix A on page 7), the textual label for thesub-identifier 9 of the OBJECT IDENTIFIER 1.2.840.113549.1 isspelled "pkcs-9(9)".But, ALL other (#=4) appearances of this same sub-identifier in thetext 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 2985should be considered the primary reference because this spec containsthe 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 publicationsfrom RSA (as far as I could verify), and in most RFCs related toPKCS/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 CMSmixed 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 CMSNote: 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 namingliterally, always and strictly, once published in a normativelyreferable way.At least, we should ensure a consistent use of already definedidentifiers 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:

[see above]

Notes:

from pending

Report New Errata