Subject: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Nov 2007 13:00:02 -0800

Greetings again. Jim Schaad and I have created a draft that contains 
revised ASN.1 modules for some of the standards-track RFCs for PKIX. 
These modules conform to ASN.1 2002. We want to see if people are 
interested in bringing the PKIX specs up to the new ASN.1 now that 
there is an open source, freeware ASN.1 compiler for ASN.1 2002, a2c 
(see <http://code.google.com/p/a2c/>).

This is definitely a first draft. There is a list of issues that we 
want to address, and we expect more issues to come up in the WG. 
Please review the draft and let us know what you think. FWIW, there 
is a parallel draft for CMS and S/MIME.

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>	Title           : New ASN.1 Modules for PKIX
>	Author(s)       : P. Hoffman, J. Schaad
>	Filename        : draft-hoffman-pkix-new-asn1-00.txt
>	Pages           : 68
>	Date            : 2007-11-08
>
>The PKIX certificate format, and many associated formats, are
>expressed using ASN.1.  The current ASN.1 modules conform to the 1988
>version of ASN.1.  This document updates those ASN.1 modules to
>conform to the 2002 version of ASN.1.  There are no bits-on-the-wire
>changes to any of the formats; this is simply a change to the syntax.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-hoffman-pkix-new-asn1-00.txt

--Paul Hoffman, Director
--VPN Consortium

---

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 8 Nov 2007 21:13:18 -0500

I am interested in moving the specs up to the later ASN.1 version.

spt 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>Sent: Thursday, November 08, 2007 4:00 PM
>To: [email-masked]
>Subject: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
>
>
>Greetings again. Jim Schaad and I have created a draft that 
>contains revised ASN.1 modules for some of the standards-track 
>RFCs for PKIX. 
>These modules conform to ASN.1 2002. We want to see if people 
>are interested in bringing the PKIX specs up to the new ASN.1 
>now that there is an open source, freeware ASN.1 compiler for 
>ASN.1 2002, a2c (see <http://code.google.com/p/a2c/>).
>
>This is definitely a first draft. There is a list of issues 
>that we want to address, and we expect more issues to come up 
>in the WG. 
>Please review the draft and let us know what you think. FWIW, 
>there is a parallel draft for CMS and S/MIME.
>
>expressed 
>>using ASN.1.  The current ASN.1 modules conform to the 1988 
>version of 
>>ASN.1.  This document updates those ASN.1 modules to conform to the 
>>2002 version of ASN.1.  There are no bits-on-the-wire changes 
>to any of 
>>the formats; this is simply a change to the syntax.
>>

---

From: Mike <[email-masked]>
Date: Fri, 09 Nov 2007 11:04:07 -0800

What is the intended status of the RFC this draft would become?  If
it is -informational- then I have no problem with it.

However, if the plan is to replace the 1988 syntax with the 2002
version, then I couldn't be more opposed.  I don't see any benefit
to making this change -- as you say there are -no- changes to the
bits on the wire.  The downside, though, is huge.  Every ASN.1
compiler that can only parse 1988 syntax will need to be upgraded,
lest they be "left behind" by the IETF whose purported goal is to
maximize interoperability between differing implementations.

The existence of one open-source compiler does not justify this
sweeping change.  And since you are one of the authors of said open-
source software, I think there is at least the possibility of a
conflict of interest.

The LDAP spec used to have close to the simplest ASN.1 syntax
possible (an exception is the use of APPLICATION tags on types), yet
those folks did something ridiculous and changed:

     Attribute ::= SEQUENCE {
         type    AttributeDescription,
         vals    SET of AttributeValue }

to:

     PartialAttribute ::= SEQUENCE {
         type    AttributeDescription,
         vals    SET OF value AttributeValue }

     Attribute ::= PartialAttribute(WITH COMPONENTS {
         ...,
         vals (SIZE(1..MAX))})

The amount of additional code required to parse this one silly
construct would be considerable.  I complained to the working group
while the specifications were still drafts and they lamented that
it was "too late" to change it back.  Isn't that why we have
*drafts*?

Yes, the ITU has deprecated the 1988 syntax, but for what reason?
It's my opinion that the 14 years of added complexity in the ASN.1
spec is simply the result of an organization trying to justify the
need for its own existence.  As long as the funding arrives, there
is work to be done!

Some developers thrive on complexity -- it is good job security, so
I can understand why they would welcome this proposal, but that has
no place in critical IETF standards.

Mike

Paul Hoffman wrote:
> interested in bringing the PKIX specs up to the new ASN.1 now that there 
> is an open source, freeware ASN.1 compiler for ASN.1 2002, a2c (see 
> <http://code.google.com/p/a2c/>).
> 
> This is definitely a first draft. There is a list of issues that we want 
> to address, and we expect more issues to come up in the WG. Please 
> review the draft and let us know what you think. FWIW, there is a 
> parallel draft for CMS and S/MIME.
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 9 Nov 2007 12:39:01 -0800

At 11:04 AM -0800 11/9/07, Mike wrote:
>What is the intended status of the RFC this draft would become?

Standards track. That is, it is updating standards-track documents.

>  If
>bits on the wire.

The code emitted by the compilers can be much more robust. For 
example, instead of 1988's "ANY", there are structures that allow 
(but not force) a compiler to do better validation checking, bounds 
checking, and so on.

>The downside, though, is huge.  Every ASN.1

Note that the compilers themselves have nothing to do with the 
interoperability of the implementations. What such a change does, of 
course, is force developers to use a compiler that can handle the new 
ASN.1.

>sweeping change.

Fully agree. There are already multiple commercial ASN.1 compilers 
that conform to the new syntax rules. Fortunately, the IETF has not 
forced developers to move to the new syntax based on the existence of 
those commercial compilers. Now that there is an open source, 
freeware compiler, we can decide if the benefits of the new syntax 
for compilers (and therefore implementers) is worth the cost of 
changing compilers.

>And since you are one of the authors of said open-

It's not clear what you mean. We make no money from people using our 
compiler. That's why we even have a web site where you can compile 
every one of these modules without even downloading the compiler.

>need for its own existence.  As long as the funding arrives, there

Regardless of their reason(s), we feel that the value of the changes 
are well worth it.

>no place in critical IETF standards.

Fully agree. However, that is not why we proposed the changes.

--Paul Hoffman, Director
--VPN Consortium

---

From: Mike <[email-masked]>
Date: Sat, 10 Nov 2007 11:30:22 -0800

> The code emitted by the compilers can be much more robust. For example, 
> instead of 1988's "ANY", there are structures that allow (but not force) 
> a compiler to do better validation checking, bounds checking, and so on.

That is a valid argument for an -informational- RFC since only compilers
that want to do the extra validation need to know how to parse such
things.  In practice, there isn't really a problem with ANY, and there
are places where things are packed into an OCTET STRING, which is the
same thing, different tag.

> course, is force developers to use a compiler that can handle the new 

Forcing developers to abandon their perfectly good tools and rewrite
their code is asking for trouble.

> compiler. That's why we even have a web site where you can compile every 
> one of these modules without even downloading the compiler.

I just found it curious that you didn't mention in your original message
that you were one of the authors of the software....

> Regardless of their reason(s), we feel that the value of the changes are 
> well worth it.

Could you list the important changes and why they are valuable, so that
an informed decision can be made?

Thanks,

Mike

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 11 Nov 2007 22:14:37 +1300

Paul Hoffman <[email-masked]> writes:
>instead of 1988's "ANY", there are structures that allow (but not force) a
>compiler to do better validation checking, bounds checking, and so on.

There's a much bigger problem with the use of 1988 ASN.1: It's not a standard
at all, since it was withdrawn more than five years ago.  Any IETF standard
that uses the 1988 form is by extension a non-standard, since what it's using
as its syntax is also a non-standard.  Technically since ASN.1:1988 doesn't
exist, you could be justified in claiming that anything at all (for example
the works of Shakespeare) are a valid interpretation of the relevant IETF
standards, since they're based on an undefined non-entity.

(The argument gets a bit philosophical at this point since the semantics of
 basing an IETF standard on something that's undefined leads to an undefined
 result.  Maybe Dr.Dan Streetmentioner could write a text on the terminology
 that's required to described this bizarre situation.  Until it's resolved, an
 implementation of PGP (or an implementation of Windows Media Audio, for that
 matter) is at least as compliant with the relevant IETF pseudo-standards as
 an implementation of CMS).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 11 Nov 2007 22:15:51 +1300

Mike <[email-masked]> writes:

>Forcing developers to abandon their perfectly good tools and rewrite their
>code is asking for trouble.

Having a bunch of supposed IETF standards that aren't really standards at all
is even worse...

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 11 Nov 2007 10:46:23 +0000

Peter Gutmann wrote:
 > Technically since ASN.1:1988 doesn't
> exist...

Ridiculous nonsense.

Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 11 Nov 2007 10:42:42 +0000

> Standards track. That is, it is updating standards-track documents.

Updating, but not obsoleting? If so, that's ok.

BTW - how certain are you that there are no differences between the
encodings allowed by rfc3280bis and this? I think it might take a
while (and some coding/testing) to be confident of that.

S.

---

From: "Turner, Sean P." <[email-masked]>
Date: Sun, 11 Nov 2007 19:35:46 -0500

It's kind of ridiculous but bean counting contracting types are sometimes
very unhappy when you have to explain to them that you're referencing a
standard that they can't go and get. Sometimes you can talk them down
sometimes not.

spt 

>[mailto:[email-masked]] On Behalf Of Stephen Farrell
>Sent: Sunday, November 11, 2007 5:46 AM
>To: Peter Gutmann
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt
>
>
>
>
>Peter Gutmann wrote:

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 12 Nov 2007 16:54:06 +1300

Stephen Farrell <[email-masked]>
>Peter Gutmann wrote:
>> Technically since ASN.1:1988 doesn't exist...
>
>Ridiculous nonsense.

Well how else do you explain requiring IETF standards to use an ISO standard
that was withdrawn five years ago?  If someone comes up to you and asks where
they can get a copy of the standard that PKIX RFCs are based on, what do you
tell them?

Seriously, what *do* you tell people when they ask where they can get the
ASN.1:1988 standard?

Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 Nov 2007 12:35:13 -0800

>Updating, but not obsoleting? If so, that's ok.

Right. It will not obsolete any of the specs. In order to do so, it 
would have to contain all of the text of the earlier specs. This is a 
straight update.

>encodings allowed by rfc3280bis and this?

Terribly certain, of course! :-)

>I think it might take a

Of course. We want extensive review by picky PKIX folks, pick ASN.1 
folks, and anyone else. We have already gotten some off-list 
corrections to our ASN.1 (one real error, some optional corrections), 
but we are hoping to get much more review.

To that end, I have made a file of all the modules from 
draft-hoffman-pkix-new-asn1-00.txt and 
draft-hoffman-cms-new-asn1-00.txt so everyone can test without having 
to cut-and-paste: <http://www.imc.org/ietf-pkix/draft-00-modules.tgz>.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Nov 2007 16:16:56 +0200

Well, I have a copy of "ASN.1 The Tutorial and Reference" lying around  
somewhere.

Also, I'm sure a 1988 specification is somewhere on the web (although  
4 minutes with google were not enough to find it)

Seriously, the fact that IETF has created IKEv2 and TLS 1.1 that  
obsoleted IKEv1 and TLS 1.0 respectively does not mean those standards  
are gone.  In fact, I would be very surprised if IKEv2 and TLS 1.1  
account for ever 0.1% of IKE and SSL/TLS traffic.

On Nov 12, 2007, at 5:54 AM, Peter Gutmann wrote:

> Scanned by Check Point VPN-1 UTM NGX R65 with Messaging Security
>