Subject: New modules drafts posted

From: Paul Hoffman <[email-masked]>
Date: Fri, 9 Jan 2009 08:52:21 -0800

Greetings again. This message should appear after the posting announcements for draft-ietf-pkix-new-asn1-02 and draft-ietf-smime-new-asn1-02 appear. If not, please wait a bit. :-)

Jim and I have major changes to the modules, and we think that our work is now done, modulo bug fixes. To that end, we would *really* like folks on either of these two lists who have ASN.1 compilers that handle the 2002 syntax to review the modules carefully and let both lists know if there are any errors. In addition, we are still open to comments on our choice of style for the new objects in the modules.

If you want to get copies of the modules without tedious copy-and-pasting, get the latest version of a2c from the a2c project (<http://code.google.com/p/a2c/>), specifically either <http://a2c.googlecode.com/files/a2c-v8.zip> or <http://a2c.googlecode.com/files/a2c-v8.tgz>. The modules are in the test/ directory. The makefile in that directory has all of the dependencies needed, although we are happy to have you test your own dependencie chain yourself.

At this point, we think that comments to both lists are appropriate, given the shared design between the two drafts and the heavy cross-dependencies between the modules.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 14 Jan 2009 08:55:54 -0800

Since I sent out this message below, we had one group of folks respond with a few small technical changes, but no other comments.

In the spirit of forward motion, we would like the chairs of PKIX and S/MIME to put the respective documents into WG Last Call so we can shake out any last comments and put these on standards track.

---

From: "Michael D'Errico" <[email-masked]>
Date: Wed, 14 Jan 2009 11:38:28 -0800

I would like to request that the new ASN.1 documents be given an
Informational rating rather than standard track.  The new ASN.1,
in my personal opinion, makes it more difficult for *humans* to
understand; the benefit is supposedly for ASN.1 compilers.  I
make this request so that the new ASN.1 does not eventually end
up in standard-track documents which make use of the structures,
where it is paramount that implementers understand them.  People
who have advanced ASN.1 compilers can easily grab the new ASN.1
from an Informational document and realize the benefits it is
supposed to provide.

Mike

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 14 Jan 2009 12:20:31 -0800

Mike,

I am curious as to why you think it is more difficult to understand the new
syntax as oppose to the old syntax.  I can think of any number of issues
that could contribute to this and would like to narrow them down to the ones
that you feel are detracting from your understanding. 

Possible responses could include:

1.  The introduction of the objects appears to add complexity without any
additional benefits.

2.  The addition of constraints makes things difficult to follow.

3.  The use of the macros such as SIGNED hide information that was
previously explicit

If we have a good understanding of why you believe that things are "too
complicated" then we can potentially restructure things so that they are
easier to follow.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Michael D'Errico
> Sent: Wednesday, January 14, 2009 11:38 AM
> To: [email-masked]
> Subject: Re: New modules drafts posted
> 
> 
> > Since I sent out this message below, we had one group of folks
> respond with a few small technical changes, but no other comments.
> >
> > In the spirit of forward motion, we would like the chairs of PKIX and
> S/MIME to put the respective documents into WG Last Call so we can
> shake out any last comments and put these on standards track.
> >
> >> Greetings again. This message should appear after the posting
> announcements for draft-ietf-pkix-new-asn1-02 and draft-ietf-smime-new-
> asn1-02 appear. If not, please wait a bit. :-)
> >>
> >> Jim and I have major changes to the modules, and we think that our
> work is now done, modulo bug fixes. To that end, we would *really* like
> folks on either of these two lists who have ASN.1 compilers that handle
> the 2002 syntax to review the modules carefully and let both lists know
> if there are any errors. In addition, we are still open to comments on
> our choice of style for the new objects in the modules.
> >>
> >> If you want to get copies of the modules without tedious copy-and-
> pasting, get the latest version of a2c from the a2c project
> (<http://code.google.com/p/a2c/>), specifically either
> <http://a2c.googlecode.com/files/a2c-v8.zip> or
> <http://a2c.googlecode.com/files/a2c-v8.tgz>. The modules are in the
> test/ directory. The makefile in that directory has all of the
> dependencies needed, although we are happy to have you test your own
> dependencie chain yourself.
> >>
> >> At this point, we think that comments to both lists are appropriate,
> given the shared design between the two drafts and the heavy cross-
> dependencies between the modules.
> >>
> >> --Paul Hoffman, Director
> >> --VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 14 Jan 2009 21:13:01 +0100

Being an implementer who do not always use completely ASN.1 2002
compliant tools, I agree with Michael's concern.

/Simon

---

From: "Michael D'Errico" <[email-masked]>
Date: Wed, 14 Jan 2009 16:42:52 -0800

Jim,

I am not asking you to change your document, but am asking that the
new ASN.1 remain as optional information for implementers who need/
want it.  It is my understanding that the current plan is for the new
ASN.1 to eventually replace the existing modules in all the important
security documents.  That would be a HUGE mistake, in my opinion,
since security is hard enough as it is, without making it ten times
harder with cryptic, impenetrable syntax.  I speak as someone who
understands the 1988 syntax, enough to have actually implemented an
ASN.1 parser and X.509 certificate and CRL processing and generation
software.

Mike

---

From: Sean Turner <[email-masked]>
Date: Mon, 26 Jan 2009 16:28:44 -0500

I think the modules are easier to read with the new syntax.  For 
example, it's much easier for me to figure out an algorithm's parameters 
from the proposed syntax than from having to hope that an author put 
comments in the module to link the OID and the parameters (assuming I 
don't both to read the text of the RFC).

Because there's no bits on the wire changes, parsers/decoders that 
interpret '88 DER encoded octet strings will continue to parse '02 DER 
encoded octet strings.  To go from the new ASN.1 to C, there's at least 
one free ASN.1 compiler (http://code.google.com/p/a2c/) and I've been 
told there are others that also compile these modules.  Not sure about 
encoders.

A reason to use the newer syntax, which may have been mentioned a while 
ago, is that the '88 ASN.1 specifications aren't available from ITU-T 
anymore.  If somebody is trying to be a pain they just have to ask where 
do I get those specifications from and unless you've got a copy handy 
you're sunk ... or they've got to find a developer who's got them (nice 
job security ;)

It's also easy enough (i.e., hit the delete key a lot) to convert from 
the new syntax to the old syntax.  Maybe we should have an annex that 
explains how to do that?

Obviously, I'm in favor of standards track.

spt

Michael D'Errico wrote:
>> Since I sent out this message below, we had one group of folks respond 
>> with a few small technical changes, but no other comments.
>>
>>> announcements for draft-ietf-pkix-new-asn1-02 and 
>>> draft-ietf-smime-new-asn1-02 appear. If not, please wait a bit. :-)
>>>
>>> work is now done, modulo bug fixes. To that end, we would *really* 
>>> like folks on either of these two lists who have ASN.1 compilers that 
>>> handle the 2002 syntax to review the modules carefully and let both 
>>> lists know if there are any errors. In addition, we are still open to 
>>> comments on our choice of style for the new objects in the modules.
>>>
>>> If you want to get copies of the modules without tedious 
>>> copy-and-pasting, get the latest version of a2c from the a2c project 
>>> given the shared design between the two drafts and the heavy 
>>> cross-dependencies between the modules.
>>>
>>> --Paul Hoffman, Director
>>> --VPN Consortium
> 
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Jan 2009 15:09:49 -0800

At 4:28 PM -0500 1/26/09, Sean Turner wrote:
>I think the modules are easier to read with the new syntax.  For example, it's much easier for me to figure out an algorithm's parameters from the proposed syntax than from having to hope that an author put comments in the module to link the OID and the parameters (assuming I don't both to read the text of the RFC).
>
>Because there's no bits on the wire changes, parsers/decoders that interpret '88 DER encoded octet strings will continue to parse '02 DER encoded octet strings.  To go from the new ASN.1 to C, there's at least one free ASN.1 compiler (http://code.google.com/p/a2c/) and I've been told there are others that also compile these modules.  Not sure about encoders.
>
>A reason to use the newer syntax, which may have been mentioned a while ago, is that the '88 ASN.1 specifications aren't available from ITU-T anymore.  If somebody is trying to be a pain they just have to ask where do I get those specifications from and unless you've got a copy handy you're sunk ... or they've got to find a developer who's got them (nice job security ;)

I'm with Sean on all of the above. I can see why some people think the old syntax is easier to read for parameters: all of the real stuff is in human-written comments. That doesn't make for interoperable protocols, however.

The ITU has pushed strongly on the IETF to abandon the '88 syntax, and has in fact made the specification for that unavailable. Whether you like it or not (I don't particularly...), it's their spec.

>It's also easy enough (i.e., hit the delete key a lot) to convert from the new syntax to the old syntax.  Maybe we should have an annex that explains how to do that?

We could certainly add that if that would make the spec more useful to people.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Jan 2009 00:10:27 +0000

Sean Turner wrote:
> 
> I think the modules are easier to read with the new syntax.

As someone who's not written code for this for some years,
I disagree with Sean and Paul - I find the '88 syntax easier
to understand. And that was true when I was still writing
relevant code.

It might be that there're cases where '88 syntax is under
specified all right, however, I'd guess that code for most
of the interesting ones of those is already written and
deployed.

The fact that ITU-T have withdrawn the '88 spec would be
ameliorated were that spec to be actually available
regardless. I thought that that was the case, but maybe I'm
wrong? (I.e. can I find it easily, regardless of what the
official position is?)

S.

---

From: "Michael D'Errico" <[email-masked]>
Date: Mon, 26 Jan 2009 16:40:29 -0800

> I think the modules are easier to read with the new syntax.

Then you would be someone who consults the optional '02 syntax.
Nothing wrong with that.  Let's also keep the '88 syntax and we'll
both be happy.

> Because there's no bits on the wire changes....

Precisely.  If there were changes that mandated using the newer
syntax, then there would be no choice but to adopt it.  But since
there are none, I don't see why we should throw away perfectly
understandable structures for something more cryptic (in my opinion).

> the new syntax to the old syntax.

I disagree with this -- I can't decipher many of the structures.

Mike

---

From: "Charles W. Gardiner" <[email-masked]>
Date: Tue, 27 Jan 2009 10:35:59 -0500

At 06:09 PM 1/26/2009, Paul Hoffman wrote:
><snip>

     That would help a lot.

Charlie Gardiner