From: "Paul C. Clark" <paul(_at_)tis(_dot_)com>
Jeff,
After looking into it further, I too believe that it is incorrect
to represent a null constructed quantity (sequence or set) with
a primitive null. However, I also think that null quantities within
well-defined structures (i.e. the signed portion of a crl) should
be designated null and not just omitted. In the case of crls
the revoked certificate list is the last object within the tobesigned
object. This may not be true in general, so omission has the potential
to introduce ambiguity (e.g. two adjacent sequences, either of which
may be null).
Paul
Paul,
Introducing a convention that is not supported in the standards is
unacceptable.
The specifications allow that one can omit the empty OPTIONAL elements
but
warn protocol designers about introducing ambiguity. In the case where
a specification
results in ambiguous encoding, the specification is at fault and the
remedy is to
change the specification, not introduce non-standard encodings.
By the way, I really don't see the problem. The designers of PEM CRLs
are
experienced ASN.1 protocol designers and were aware of these issues.
If the inner SEQUENCE (the ToBeSigned portion) ends without the OPTIONAL
CRLEntry (you can tell this by looking at the length of the TBS) then
there
are none ! The next item the decoder should see is the SEQUENCE
for the signature. Most implementors of encoders/decoders recognize
that
this is a recursive descent parsing problem and that keeping track of
levels
is critical. Therefore note that there are not two adjacent
SEQUENCES,
one is at a "higher" level than the other.
John