Different semantics should be expressed in different ASN.1 definitions
instead of
using different encodings of the same ASN.1 definition. If you do the latter,
you will always have problems of that kind again. ASN.1 encoders normally
don't
know the semantic context. They get an ASN.1 statement as input, and they
produce
a code. The purpose of DER is to ensure that a particular ASN.1 definition
leads
to a unique encoding.
Correct. But we're talking about two different definitions here.
If the same ASN.1 statement can lead to two legal encodings,
the encoding is not 'distinguished' in the sense of DER.
It is not the same ASN.1 statement.
I also don't see the
difference (with respect to DER) between the DEFAULT notation which is
addressed
by DER and the OPTIONAL notation which is not.
There's a vital distinction between the two. The DEFAULT notation is
constrained to not have any semantics associated with it -- the presence of a
value that equals the default versus the value not being there so the default
applies are defined to have identical semantics. But this does not apply to an
OPTIONAL sequence. The presence of an empty sequence versus the omission of the
sequence can be semantically distinct.
Someone else posted a hypothetical example of this already that's perfectly
reasonable, so I won't bore everyone by constructing another. But contrived
examples are not necessary, really -- there are plenty of places in X.400 and
elsewhere where an optional sequence or set, if present, specifies a constraint
in the form of a list of allowed values. If the sequence or set is omitted any
value is allowed. If the sequence or set is present and empty there are no
legal values. These are quite clearly VERY different semantically. And where it
doesn't make sense for there to be no legal values the ASN.1 (in X.400 at
least) is quite careful to specify a lower bound of 1 on the sequence or set.
However, I think pem-dev is not the right place to discuss these ASN.1
matters,
and our particular CRL problem must be solved in RFC 1422 anyway, as outlined
by
Steve in a previous message. Sorry for waisting this mailing list with these
issues.
I disagree. If you are right then no change needs to be made to RFC1422. If you
are wrong then we need to fix RFC1422. This is clearly a PEM issue and is
precisely what this mailing list is for.
Ned