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

From: Carlisle Adams <[email-masked]>
Date: Tue, 6 Mar 2001 14:18:33 -0500

Hi Paul,

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
> Sent: 	Sunday, March 04, 2001 2:33 PM
> To: 	[email-masked]
> Subject: 	RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and
> rfc2511bis- 01.txt)
> 
> At 2:31 PM -0500 3/2/01, Carlisle Adams wrote:
> >If you (or anyone else reading this) would like to run the modules 
> >through a syntax checker and give me a list of the necessary 
> >changes, I'd be happy to incorporate them.  My sense, however, from 
> >what you've listed below, is that the changes required will be 
> >sufficiently minor that they can all be taken care of during the 
> >last "48 HOURS NOTICE" editing cleanup window from the RFC Editor. 
> >Therefore, I see no reason to hold up progression of either of these 
> >documents.
> 
> Carlisle: I take it from your comments that you don't think that any 
> of Phil's suggestions need to be implemented because no one tripped 
> over them. Is that correct? If so, it's fine that we don't make the 
> changes, but that is *quite* different than changing them after 
> everyone has used the current code for testing.
 
I guess I wasn't subtle enough...  :-)

Yes, that was essentially my underlying message.  I'm certainly happy to
make changes if they need to be made in order for the code to compile (and I
will humbly submit to your suggestion that this occur *before* submission to
the RFC Editor), but I do wonder how serious this can be if no one has ever
mentioned having a problem here before.

The PKIX meeting is in exactly 2 weeks.  How about if I report at that
meeting whether these drafts can be progressed as they are or whether
yet-another-revision is required?

> Phil: do you have evidence that any ASN.1 compiler other than the one 
> you listed has problems with the code as it stands now?
 
Unless I get concrete evidence that a "currently-employed" ASN.1 compiler
fails to compile this code, the drafts will remain unchanged.  (Phil may
provide evidence for a compiler of his choosing  if he wishes, but at least
one set of corrections must come from one of the implementors that have been
involved in the interop testing all this time.)  Does this seem fair enough?
After all, the implementors now have interoperable code; we shouldn't make
them re-tinker all the way back to the ASN.1 compilation stage unless there
is a good reason.

Carlisle.

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Wed, 07 Mar 2001 08:34:07 -0500

> Carlisle Adams wrote:
>      Subject:        RE: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt
>      (and rfc2511bis- 01.txt)
> 
> Yes, that was essentially my underlying message.  I'm certainly happy
> to make changes if they need to be made in order for the code to
> compile (and I will humbly submit to your suggestion that this occur
> *before* submission to the RFC Editor), but I do wonder how serious
> this can be if no one has ever mentioned having a problem here before.

I rarely find the time to thoroughly test and
report on bust ASN.1 anymore. So I try to do so
only where correct ASN.1 is desired or mandated
by policy, say for ANSI X9 or JTC 1 standards.

For example, the recent  ISO/IEC 15945 | ITU-T 
X.843 Trusted Third Party standard relied on 
IETF CRMF and OCSP ASN.1, and both contained 
significant errors. I went through the ASN.1 
for the document text, and the ASN.1 modules, 
so that the standard could meet the ITU-T 
requirements for being published. Otherwise, 
publication of the work would have been
unnecessarily delayed.

But beyond this issue, folks with tools which 
correctly implement the ASN.1 standards can
not easily implement a specification which does
not conform to the ASN.1 standards. They must
first modify the published ASN.1 by hand. That 
is the case with this work.

Once everyone is doing a hand job on the code, 
the likelihood that they they will introduce 
errors rises, and the likelihood that they will 
all implement the same specification falls. The
amount of flux of course varies with who does the
modification and how much notation they must modify
to get the specification to work. 

Sometimes this isn't such a big deal. But it is 
never necessary to publish invalid ASN.1. There 
are free syntax checkers available. 

>      you listed has problems with the code as it stands now?

Just looking at the few minor glitches that I 
reported, I am absolutely certain that these 
pieces of ASN.1 do not conform to any version
of the ASN.1 standards. Therefore, I would feel
safe in claiming that this would not pass muster
using either of the two free syntax checkers that
X9 and JTC 1 rely upon. That's not to say that 
there are no tools that might accept this code.
Who knows?

Please understand that these errors are so easy to
detect that I did not rely on tools of any kind to
find them. They're basically common edit errors.
But little imperfections tend to matter to me 
anytime security work is involved. And if the goal
is to maximize the likelihood that different tools
from folks that have never cooperatively tested 
their code inter work, then ASN.1 errors do matter 
in the sense noted above.

> Unless I get concrete evidence that a "currently-employed" ASN.1
> compiler fails to compile this code, the drafts will remain
> unchanged.  (Phil may provide evidence for a compiler of his choosing
> if he wishes, but at least one set of corrections must come from one
> of the implementors that have been involved in the interop testing all
> this time.)  Does this seem fair enough?  After all, the implementors
> now have interoperable code; we shouldn't make them re-tinker all the
> way back to the ASN.1 compilation stage unless there is a good reason.

Do as you wish. No time for this myself right now.
But I would assert that having two implementations
of broken ASN.1 is not quite as good as having two
implementations of correct ASN.1. And the problems
of relying on bust ASN.1 really only begins to become
evident when N players, not working together or with
your test group, pick up the standard and attempt to 
implement the work with compliant tools. These are
the folks that are likely to be disadvantaged or to
get it wrong. They may not have the advantage of
collaboration.

Free tools are available for syntax checking whether
this is part of your quality process or not. I wish it
were. A lot of standards bodies I work with wish to 
rely on IETF standards in their work, and frequently
can not do so without first making corrections to the 
published ASN.1. 

If I had the time I'd check this for you. But I'm out
of the country for the next two weeks.

Phil
----
Phillip H. Griffin    Griffin Consulting
http://asn-1.com      Secure ASN.1 Design & Implementation
p:  +1-919-832-7008   1625 Glenwood Avenue
f:  +1-919-832-7390   Hayes Barton at Five Points
e:  [email-masked]    Raleigh, North Carolina 27608-2319 USA
------------------------------------------------------------