> >> 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.
>
I wholeheartedly agree; it is not our intent to create interoperability
problems, only to define the range of legal formats within the current
specification. This, I would hope, could be accomplished through friendly
dialogue (preferably on an 80 character screen :-)).
> 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
>
Actually, my assertion was that the structure of crls did NOT introduce
ambiguity. But, that in the general case of encoding structures, omitting
null quantities COULD introduce ambiguity. An implementation may wish
to internally manipulate incomplete structures and hence would like
a means to represent nulls for various quantities.
In my view, the definition:
revokedCertificates:= SEQUENCE OF CRLEntry OPTIONAL
does not preclude either the omission or the encoding of a
null sequence, in the event that there are no certificates
yet revoked. In fact an implementation should probably
accept both.
The question then is what should be generated. For generality
I would prefer the encoded null sequence. If the group at
large does not concur then we will modify our software accordingly.
Paul
---------------------------------
Paul Clark
Trusted Information Systems, Inc.
3060 Washington Road
Glenwood, MD 21738
E-Mail: paul(_at_)tis(_dot_)com
Phone: 301.854.6889
FAX: 301.854.5363
---------------------------------