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

From: [email-masked] (Peter Gutmann)
Date: Mon, 12 Nov 2007 17:21:22 +1300

[Sorry, my previous response may have been a bit unclear.  Let me rephrase
 it].

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

Attached at the end of this message is what I claim to be a PKIX-compliant
X.509 certificate encoded in ASN.1:1988.  If you would like to dispute this,
please show me where to get the ASN.1:1988 standard from the ISO to show that
it's not what I claim it is.

Peter.

-- Snip --

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 13 Nov 2007 12:04:36 -0500

The fact that X.208 1988 was withdrawn as a standard in 2002
does not mean that all paper and electronic copies have
disappeared from the face of the earth.

Get it from http://www.itu.int/rec/T-REC-X.208-198811-W/en.

The fact that copies can be had, however, does not imply
that the IETF should continue to base standards on it.
The 1992 version of X.680 says that although X.208 was
still being maintained at time of publication, continued
maintenance depends on an annual resolution by the
subcommittee and "cannot be expected to be indefinite".

Let's see - 15 years in real time is how many years in
Internet time?  NCSA Mosaic was introduced in 1992, and
Mike thinks we should still be basing RFCs on a standard
that was deprecated before the web was born?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Gutmann
Sent: Sunday, November 11, 2007 11:21 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Fwd: I-D Action:draft-hoffman-pkix-new-asn1-00.txt

[Sorry, my previous response may have been a bit unclear.  Let me
rephrase
 it].

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

Attached at the end of this message is what I claim to be a
PKIX-compliant
X.509 certificate encoded in ASN.1:1988.  If you would like to dispute
this,
please show me where to get the ASN.1:1988 standard from the ISO to show
that
it's not what I claim it is.

Peter.

---

From: Mike <[email-masked]>
Date: Wed, 14 Nov 2007 10:54:55 -0800

> that was deprecated before the web was born?

It was the creator of ASN.1 who deprecated the 1988 version.
As I said before, I believe this is a self-preservation move
more than anything else.  If they didn't add unnecessary
complexity and instead kept things simple, they would have
put the ASN.1 folks out of a job.  The specs are all about
complexity -- consider X.400 versus Internet email, and X.500
DAP versus LDAP, and how widely used those standard are.  It
was probably a mistake to even adopt ASN.1 and X.509 for the
Internet in the first place, but that ship unfortunately
sailed long ago.

Consider TCP/IP, the backbone of the Internet.  Quoting
from Wikipedia:

     TCP is a complex and evolving protocol. However,
     while significant enhancements have been made and
     proposed over the years, its most basic operation
     has not changed significantly since its first
     specification RFC 675 in 1974....

So TCP has been around for over 30 years.  It is precisely
the *simplicity* of TCP (and its relative stability) that
makes it so successful.  Back to ASN.1 1988:  even I was
able to write a parser for it, and I've had no formal
computer science education.  I've heard that you need 4
tokens of look-ahead to disambiguate some of the newer
ASN.1 constructs.  I'm sure you've heard of the K.I.S.S.
principle?  It applies here.

And again, I have no objection to the publishing of the new
ASN.1 as an Informational RFC.  An update RFC will lead to
new future versions of PKIX and CMS documents that drop the
simpler syntax, which is what I am against.

Mike

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Nov 2007 15:49:41 -0500

Mike:

There is one feature in the newer ASN.1 specification that helps 
avoid programming errors.  The use of CLASS instead of ANY DEFINED BY 
allows one to construct a table of the object identifiers and their 
associated structures.  This is very helpful.  It allows the decoder 
to automatically do the right thing.

This concept was added by BBN to their ASN.1 compiler (for the 1988 
syntax).  They added a TABLE key word to handle it.  I used this 
feature in a development many years ago, and it was better than 
having to write code for every possibility that might appear in an ANY.

I agree that the newer syntax is a bit harder to read.  But, in my 
opinion, it is worth the little bit of extra pain to get the 
automatic handling of ANY DEFINED BY.

I'm pleased to see the open source compiler that handles all of the 
ASN.1 modules in IETF specifications.

Russ

P.S.  The LDAP WG has been using the newer syntax for many years.

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 14 Nov 2007 17:32:34 -0500

I believe in KISS.  And I see plenty of examples of ASN.1-based
protocols (and was co-author of one, to my shame) which became
complex just because it is easier to get carried away in ASN.1
than in, for example, bits-in-boxes.

However, that is orthogonal to the issue of whether IETF should
make it's ASN.1-based RFCs conform to the ASN.1 standard.
The LDAP example you gave is unrelated to a switch from X.208
to X.680 - the simple definition is perfectly legal under X.680,
thus the gratuitous complexity of the second definition
was motivated by something other than the desire to be ASN.1
compliant.

X.509 uses a relatively simple subset of ASN.1, and making the
minimal changes required to become legal under X.680 should not
require a parser with 4 tokens of lookahead.  Making more extensive
changes that explore the more esoteric features of X.680 is a
separate issue, and on that I'd come down on the side of KISS.
Some things are simpler under X.680, for example the ability to
use real UTF8STRINGs rather than a hack to produce the same bits
on the wire as X.680.

The IETF does not have a choice.  It could claim to be using its
own language (X.208) just like it defines its own language to express
the TLS protocol.  But PKIX claims to be a profile of X.509, not
an independent certificate format that sort of resembles X.509,
and so the modules contained in the normative sections of
RFC 3280bis must be written in ASN.1.  That requires updates to
the RFCs, with informative annexes to contain the pseudo-ASN.1.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Nov 2007 23:52:43 +0000

Kemp, David P. wrote:
> own language (X.208) ...

More nonsense.

S.

---

From: Steven Legg <[email-masked]>
Date: Thu, 15 Nov 2007 12:17:04 +1100

David,

> was motivated by something other than the desire to be ASN.1

In the LDAP example Mike gave, i.e.,

the change from this:

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

to this:

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

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

there are two different motivations involved. The inclusion of the
"value" identifier into SET OF AttributeValue was to make XML
encodings of the LDAP protocol messages more aesthetically pleasing
(in support of experimental extensions to LDAP). The change doesn't
affect the bits on the wire for BER and a programmer using a 1998-syntax
ASN.1 compiler can simply remove the identifiers after the SET OFs
to get the module to compile.

The addition of the WITH COMPONENTS constraint was motivated by the
desire to express formally in the ASN.1 what was previously expressed
only in the text of the RFC. This means that the revised ASN.1 is a
more complete and precise specification of the protocol than the
ASN.1 in the previous edition. A complete and precise specification
of the protocol is the main point of the RFC after all. The constraint
notation is still conformant to the 1988 syntax, so an older ASN.1
compiler should be able to parse it. If not, then the remedy is simple
- edit the constraint out of the ASN.1 before passing it to the compiler.

> use real UTF8STRINGs rather than a hack to produce the same bits

Simplicity depends on one's perspective. As a programmer, it is
easier for me to replace ANYs with open types and component
relation constraints so that my ASN.1 toolkit takes care of all
the encoding and decoding details, rather than using the ASN.1
as is. Yes, it makes the ASN.1 more complex, but for me it makes
the overall implementation trivial. Whether a specification is
written in 1998 syntax or 2002 syntax, some group of implementors
is going to be disadvantaged. The disadvantaged group always has
the option to edit the ASN.1 to suit. To that end, perhaps Paul
could consider adding to the ASN.1 (as comments) some instructions
on how to dumb it down to the 1988 level. In my opinion, moving to
the 2002 syntax is better in the long term because it allows more
precise protocol specifications and allows greater levels of
automation.

Regards,
Steven

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 15 Nov 2007 15:56:45 +0000

Stephen,

I think it would be fair to give a rationale why you think the claims presented here are "ridiculous nonsense" and "more nonsense".

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: den 15 november 2007 00:53
> To: Kemp, David P.
> Cc: [email-masked]

---

From: Mike <[email-masked]>
Date: Thu, 15 Nov 2007 07:31:48 -0800

> only in the text of the RFC.

I think this could have been achieved with:

     Attribute ::= SEQUENCE {
         type    AttributeDescription,
         vals    SET SIZE(1..MAX) OF value AttributeValue }

and my existing parser could have handled it.

But it appears that the move to ASN.1 2002 is inevitable and I
should just accept it.  I would just ask that the transition be
completed over the course of a year or so to allow people to
catch up.  I will have to rewrite my existing code, as I can
not take advantage of the a2c compiler that is now available.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 15 Nov 2007 17:18:35 +0000

Sure;-)

The IETF does have a choice.
The IETT cannot sensibly claim that X.208 was invented here.

The opposite of the above is nonsense.

Stephen.

PS: Note that I've not said that moving to asn.1 2002 is nonsense.
I just think that that's something to be done v. carefully.

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Nov 2007 13:40:18 -0500

Here is how I would see the transition:

   - publish the updates that provide the new syntax, but the 1988 
syntax remains normative

   - as each specification gets revised, the newer syntax will become 
the only one in the RFC

I believe that this transition will take many years.

Russ

---

From: Steven Legg <[email-masked]>
Date: Fri, 16 Nov 2007 10:21:31 +1100

Mike,

 >         vals    SET SIZE(1..MAX) OF value AttributeValue }

No. In the information model an attribute is required to have at
least one value, but in the protocol there are cases where the values
may be omitted. The split into PartialAttribute and Attribute
allows the two cases to be distinguished.

 > not take advantage of the a2c compiler that is now available.

You have the choice of rewriting your existing parser, rewriting
any ASN.1 that uses the 2002 syntax to suit your parser, or
continuing to use the 1988-syntax definitions.

Regards,
Steven