Subject: RE: UTF-8, ASN.1, and our past sins

From: "Paul Leach" <[email-masked]>
Date: Tue, 20 Nov 2001 09:52:35 -0800

AFAIK, we never said, in London or elsewhere, that we aren't using
ASN.1. We always said that "we're using ASN.1, but"... And, that's
what's not acceptable.

So I don't think we can say it was shot down. This _is_ a language
lawywer issue. "They" can only legally be angry if we say we're doing
ASN.1, and aren't. If we invent our own language, we can do anything we
want.

I'm sorry if "perversions" and "sins" implied we actually did something
wrong -- it was meant as hyperbole, a little sarcasm directed at the
ASN.1 purists.

However, if appears to me that some parts of the latest section 5 change
or come very close to changing the semantics of ASN.1. If existing
implementations really obeyed 100% pure ASN.1, would we need all of
these?

For example, 5.1.2 -- "Option Fields in ASN.1 Sequences" says "Some
implementations behave as if certain default values are equivalent to
omission of an optional value." And 5.1.4 tells how to handle
unrecognized tag numbers in a way that implies the existing protocol as
embodied in existing implemenations is not pure ASN.1, because if they
were, the special instructions would not be needed. And tag numbers are
not encoded in pure ASN.1, because tag numbers greater than 30 do not
work. And section 5.2.4 has defines 3 integer datatypes that are
constrained to 32 bits, and says "note that it is not strictly
conformant ASN.1".

OTOH, 5.1.3 now seems to be just a warning that certain odd ASN.1
constructions are used. So, I apologize if I overgeneralized about
section 5.

Now, as it happens, none of the above prevents using commercial ASN.1
tools, as long as they are used carefully. Renaming the metalanguage
that defines the protocol just gets us of out trouble with ISO.

Finally, to quote your own message

> In recent drafts, the only non-compliant things we do with ASN.1 are
> minor violations of the extensibility model, such as adding ASN.1
> constraints on types to reflect what implementations are actually
> doing, and doing things such as replacing a type with a CHOICE
> containing the original type as one of its alternatives.

That says we're not compliant. It doesn't matter to the ISO bigots that
we're only a little non-compliant. If we do what they want and change
the protocol, then we have a huge problem with existing implementations.
For them, keeping ASN.1 unsullied is more important than that. So, I
suggest we satisfy them by ceasing to "sully" ASN.1 -- by no longer
using it.

Paul

---

From: Tom Yu <[email-masked]>
Date: 20 Nov 2001 14:12:49 -0500

>>>>> "Paul" == Paul Leach <[email-masked]> writes:

Paul> However, if appears to me that some parts of the latest section
Paul> 5 change or come very close to changing the semantics of
Paul> ASN.1. If existing implementations really obeyed 100% pure
Paul> ASN.1, would we need all of these?

Existing implementations violate ASN.1 in various ways.  We are
changing the protocol specification's use of ASN.1 in small and mostly
compatible ways to ensure that these implementations will no longer be
in violation.  We are also adding reasonable constraints on things
such as integer values so that implementations will not be required
to, for instance, handle arbitrarily large integers.

Paul> For example, 5.1.2 -- "Option Fields in ASN.1 Sequences" says "Some
Paul> implementations behave as if certain default values are equivalent to
Paul> omission of an optional value."

I fail to see how this is violationg the ASN.1 specification.  This is
a description of existing behavior, not a deviation from the ASN.1
standard.  This really is a sort of ambiguity in RFC 1510.

Paul> And 5.1.4 tells how to handle unrecognized tag numbers in a way
Paul> that implies the existing protocol as embodied in existing
Paul> implemenations is not pure ASN.1, because if they were, the
Paul> special instructions would not be needed.

No.  ASN.1 makes *no* requirements on the application's behavior with
respect to receiving unrecognized types.  I believe that is up to the
application writer or application protocol specifier to choose a
behavior.

Paul> And tag numbers are not encoded in pure ASN.1, because tag
Paul> numbers greater than 30 do not work.

Where do you see anything suggesting that?  I merely state that
certain implementations may experience difficulty with tag numbers
greater than 30.  I do not make any statements as to the nature of the
encoding of tag numbers that *should* be used by implementations,
except that there is a requirement to adhere to the DER.

Paul> And section 5.2.4 has defines 3 integer datatypes that are
Paul> constrained to 32 bits, and says "note that it is not strictly
Paul> conformant ASN.1".

It perhaps should be reworded to explain that it creates a different
type, since the original type did not contain the constraint.  It
violates the ill-specified ASN.1 extensibility model, but the
violation, if it were actually a violation, would be in the *change*
between RFC 1510 and krb-revisions.

Paul> OTOH, 5.1.3 now seems to be just a warning that certain odd
Paul> ASN.1 constructions are used. So, I apologize if I
Paul> overgeneralized about section 5.

Paul> Finally, to quote your own message

>> containing the original type as one of its alternatives.

Paul> That says we're not compliant. It doesn't matter to the ISO
Paul> bigots that we're only a little non-compliant. If we do what
Paul> they want and change the protocol, then we have a huge problem
Paul> with existing implementations.  For them, keeping ASN.1
Paul> unsullied is more important than that. So, I suggest we satisfy
Paul> them by ceasing to "sully" ASN.1 -- by no longer using it.

It is a violation of the extensibility model, which is rather
ill-specified in the ASN.1 standards, particularly with regards to
what changes constitute creation of a new type.  In fact, one of the
things we're proposing doing, replacing a type with a CHOICE
containing the original type as an alternative, is explicitly
suggested as a specific migration strategy for the EXTERNAL type in
Annex A of X.680(1997).  The use of ASN.1 in section 5 of
krb-revisions, taken by itself, does not to my knowledge violate
ASN.1.

---Tom