Subject: RFC 4073

From: Alfred Hönes <[email-masked]>
Date: Tue, 17 May 2005 16:13:02 +0200 (MESZ)

Hello,
having read the recent RFC 4073 authored by you I suspect a small
but perhaps technically important flaw in the text that finally
turned out to be a more general issue:

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 '-')
exlusively.

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 preferrable to follow identifier naming
literally, always and strictly, once published in a normatively
referrable 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).

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+