Subject: RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis- 01.txt)

From: "Manger, James H" <[email-masked]>
Date: Wed, 7 Mar 2001 11:04:26 +1100

Carlisle,
 
Phil's items are EDITORIAL bugs in the ASN.1.
 
A lot of PKIX (particularly ASN.1 definitions) are cut 'n pasted from X.509,
other X.500-series standards, PKCS standards, etc.  There is little
coordination of ASN.1 modules between various standard groups (PKIX don't
IMPORT definitions from X.509, they redefine them in their own modules).
You often want to use PKIX and these other standards together, but compilers
tend not to like duplicate definitions of everything.  The solution is to
rearrange the definitions, IMPORTS and modules to fit your own system.  As
part of this rearranging process it is natural that people correct any
editorial bugs they create or find: some will report these to the editor,
other assume they are too trivial to worry about.  The rfc2510bis ASN.1
module even explicitly says each implementer must adjusted the module
themselves to IMPORT the definition of CertificateRequest.
 
ASN.1 error detected by another compiler in rfc2510bis appendix F:
 
1. The IMPORT section is not terminated with a semicolon.
2. CMP1999(1) & CMP2000(2) identifiers must start with a lowercase letter
3. "SEQUENCE of CertStatus": "OF" must be capitalised.
4. Some ASN.1 definitions appear in the text but not in the module:
confirmWaitTime, confirmWaitTimeValue, implicitConfirm,
implicitConfirmValue.  All the definitions are invalid ASN.1.
5. OIDs should be:
    implicitConfirm OBJECT IDENTIFIER ::= {id-it 13}
    confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
6. Types must start with a capital letter:
    ImplicitConfirmValue ::= NULL
    ConfirmWaitTimeValue ::= GeneralizedTime - time CA will wait until

---

From: Carlisle Adams <[email-masked]>
Date: Fri, 9 Mar 2001 13:45:59 -0500

Hi Magnus and Phil,

> ----------
> From: 	Phillip H. Griffin[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Friday, March 09, 2001 8:48 AM
> To: 	[email-masked]
> Cc: 	Carlisle Adams; [email-masked]; [email-masked]'
> Subject: 	Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and
> rfc2511bis-01.txt)
> 
> Magnus and Carlisle,
> A few comments below.
 
(...some text deleted...)

> Magnus Nystrom wrote:
> > 
> >  b) PKIXCRMF imports definitions from both RFC 2459 (bis) and CMS. CMS
> >     in turn, imports definitions from ITU/ISO specifications rather
> >     than PKIX RFCs. Now this would be ok, unless it was for the fact
> >     that RFC 2459bis and RC2511bis use 1988 syntax, as does CMS, but
> >     CMS imports from modules written in 1993 syntax. This creates a
> >     mess for those using commercial compilers, since UTF8Strings (used
> >     in ISO documents but defined explicitly in PKIX documents) aren't
> 
> Actually the situation is even worse than
> described here. The use in IETF modules of
> class UNIVERSAL tags is not valid ASN.1 under
> any version of the ASN.1 standards.
> 
> It is an IETF concoction made up I believe
> to allow old X.208 and X.209 based tools to
> make use of new ASN.1 types never defined 
> in those standards, but defined for years 
> and years now in the current ASN.1 standards.
 
(...some text deleted...)

> >     supported in 1988 but are in 1993, so one cannot compile these
> >     modules with either a "1988" switch or a "1993" switch. My advice
> >     would of course be to move to 1993/1997 ASN.1 altogether, but if
> 
> Agreed. This is the best possible solution.
> Not only does it eliminate the concoction
> noted above, it allows the use of other new 
> types and encoding rules by adopters of IETF
> standards.
 
I sympathize with both your positions here, and if we were starting from
scratch I'd say that it might be worthwhile to try to create a "perfect",
up-to-date ASN.1 module.  However, this specification (begun 5 years ago)
has been actively interop tested for somewhere between 1.5 and 2 years now.
By some miracle, all ten or so independent implementations were able to take
what's listed here as a '"Compilable" ASN.1 Module Using 1988 Syntax' (note
the quotes around "Compilable" in the title of this appendix!), make
whatever tweaks were necessary to get it to compile (without a word of
complaint to the authors of the spec!), and then get their implementations
to interoperate.

Revising the ASN.1 in a significant way at this point in time necessitates
re-doing all that interop testing.  I am absolutely unwilling to initiate
that pain, especially when it appears to lead to no tangible benefit.  Small
changes (like removing the "CRMF" before "DEFINITIONS", etc.):  no problem.
But a major change (like converting the entire module to 1993/1997 syntax
and getting CMS to change at the same time, etc.), is unnecessary and
counterproductive.

Carlisle.