Proponents of number 2 make two arguments in support:
Argument #1 - There is no language restraining such an interpretation.
Argument #2 - Clauses 15 and 17 of X.209. (see also 14 and 16)
An interesting thought experiment came to me while driving home - replace the
SEQUENCE with another value; an INTEGER yielding:
BarType ::= INTEGER
A) Does anyone support an argument that an INTEGER of zero length is allowed
here ?
You are comparing apples and oranges. The semantics of integers are quite
different from the semantics of sets and sequences, and as such comparing the
two does not make sense. In particular, an ASN.1 integer is defined to have a
value that corresponds to the mathematical concept of an integer. ASN.1
semantics require this. And integers are well defined and no concept
corresponding to an "empty integer" exists.
The difference at the ASN.1 level is also fundamental. An integer is a
primitive. A sequence or set is not. The rules that apply to primitives are
very different from those that apply to primitives.
You are also confusing encoding issues with ASN.1 semantics issues. Given some
set of encoding rules it is certainly possible for some integer value to be
represented as a value of zero length (zero would be the obvious choice here).
However, as far as I know both BER and DER don't represent zero this way and
don't allow integers with zero length values (if they do I for one don't know
what they mean).
If the answer is yes then I forced to examine the following assertions:
The answer is NO.
1) X.209 is defective in that it doesn't make clear the use of the keyword
OPTIONAL
and doesn't address the issue of missing v. empty encodings.
Incorrect. X.209 does not need to address the "issue" of missing versus empty
encodings of sets and sequences. There is no "issue" to address here -- both
are allowed, they are semantically distinct and useful, and they are used in
existing specifications.
2) DER is defective in that it doesn't recognize that two possible encodings
can arise from specification of an OPTIONAL element and make restriction to a
single
encoding.
Incorrect. DER provides different encodings for semantically distinct entities.
This is something it has to do; failure to do so would be a MAJOR defect.
3) Major portions of X.400, X.500, and other protocol specifications which
depend on the canonical encoding of data to support digital signatures are
defective
because they use OPTIONAL instead of OPTIONAL DEFAULT {}.
Canonical encoding issues are not directly addressed in X.400 as far as I know.
As such, it is beyond the purview of the X.400 standards to deal with
canonicalization issues, and any semantics ambiguities in the X.400
specification that lead to canonicalization problems are not, properly
speaking, defects. However, as it happens X.400-1988 is quite careful to
specify lower bounds on the length of most sequences and sets. And when lower
bounds are not specified (or are specified as 0) there's a clear semantic
justification for this usage. I have yet to find a single place in X.400-1988
that is semantically inconsistent in the sense we're talking about here.
X.509 is another story. My reading of the specification (1988 -- I don't have
the 1993 draft handy right now) shows that the elements
(1) Certificates (contains optional ForwardCertificationPath sequence).
(2) CertificateList (contains optional revokedCertificates sequence).
(3) CertificationPath (contains optional sequence of CertificatePairs).
are possibly ambiguous semantically. (The second one is what we've been
discussing.) But for all I know there's a difference between having an empty
ForwardCertificationPath (say, we're at the top and there is no place to go)
versus not having a path present (say, the path isn't known to this agent).
If the answer to question A) is no, then I assert that it should apply to all
types. This results in a single encoding for variants of OPTIONAL data and
obviates discussion of the three assertions above.
Application of the characteristics of integers to sequences and sets is
mathematically senseless unless you want to start talking about redefinition of
integers (say Surreal Numbers or Conway's Field, both of which define
number-like objects that admit various sorts of "emptiness"). They are
different sorts of objects and they have different characteristics. What
applies to one does not and should not automatically apply to the other.
Try as you might you cannot eliminate the fact that in ASN.1 an empty object
isn't the same semantically as no object at all -- as long as you're talking
about objects that permit the concept of emptiness (which integers do not).
Moreover, you cannot eliminate usage of this construct in ASN.1; making this
change would break lots of stuff, and simply isn't going to fly.
Ned