[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-pkix-rfc2510bis-03.txt (and rfc2511bis-01.txt)
> Carlisle Adams wrote:
>
> Hi Paul,
>
> ----------
> From: Paul Hoffman / IMC[SMTP:phoffman@xxxxxxx]
> Sent: Sunday, March 04, 2001 2:33 PM
> To: ietf-pkix@xxxxxxx
> 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.
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.
> 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?
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: phil@xxxxxxxxx Raleigh, North Carolina 27608-2319 USA
------------------------------------------------------------