Subject: RE: Vagueness in empty CRLs

From: "David P. Kemp" <[email-masked]>
Date: Thu, 6 Jan 2000 10:11:06 -0500 (EST)

> From: "Phillip M Hallam-Baker" <[email-masked]
>
> > [From Sharon Boeyen]
> > However, the proposal to be to make that same restriction in X.509 itself
> > does concern me a bit, primarily from the standpoint of backward
> compatibility
> > but also because we don't have a thorough way to ensure that making the
> change
> > wouldn't break some existing systems and environments outside PKIX.
> 
> Given the choice between ASN.1 DER purity and backwards compatibility, give
> me compatibility every time.
> 
> I have never accepted that the DER rules met a real need and hearing the
> argument again a fiftieth time is unlikely to convince me. 

I must have missed something, Phill -- who said anything about BER vs. DER?

The issue is the encoding of a CRL which has no entries; the choices
are 1) an empty SEQUENCE and 2) an absent SEQUENCE .  Both options are
legal in both BER and DER - there is nothing in X.690 section 10 or 11
which requires that empty optional sequences be elided.  This is appropriate
because in some cases there is a semantic difference between empty and
absent.

In the case of CRLs however, there is no semantic difference, just two
different ways of saying "here's a CRL with no entries".  You may believe
that canonical encodings have no benefit; I believe they do.
 
With regards to backwards compatibility, existing decoding software is
not an issue; the only issue is whether "new" decoders would be broken
by old encoders or old CRLs.  Paul H. asked that question in the PKIX
context; if a change were made to X.509 the question would have to be
asked in a much larger context and answered to the satisfaction of every
voting body.  I agree with Sharon that there is no way to be 100% sure,
but I would wager $0.50 that as of yesterday there was no CRL on earth
(excluding deliberately-created test vectors) which has "no entries"
represented as a zero-length SEQUENCE.

And I agree with Sharon's position that it is appropriate for the PKIX
profile to restrict X.509, as it already does by adding a SIZE
constraint to Extensions.

I disagree with Sharon's comment:

> If we do go ahead with a proposed change to 509, I'd prefer it to be a
> text clarification rather than a restructuring of the ASN.1, again
> because of backward compatibility.

There is no clarification possible; either both representations are
allowed or only one is allowed.  It doesn't matter whether the protocol
is specified in prose, in ASN.1 comments, or in ASN.1 syntax, the protocol
is as it is.  If the ASN.1 is not changed, redundant text could be
added to say that both cases are legal, but I don't believe there would
be any value in adding such text.  I do believe that adding text to
allow only the absent sequence while leaving the ASN.1 unchanged would
*not* be a clarification, it would be an obfuscation.  The text (if
present) and the syntax should agree, regardless of which outcomes are
chosen for X.509 and for the PKIX profile.

I recommend that PKIX add a SIZE constraint to revokedCertificates, but
take no position with respect to X.509.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 06 Jan 2000 07:47:55 -0800

At 10:11 AM 1/6/00 -0500, David P. Kemp wrote:
>I agree with Sharon that there is no way to be 100% sure,

You might owe me $0.50, depending on your definition of "yesterday". Oscar, 
a very capable open-source CA product (see <http://oscar.dstc.qut.edu.au/>, 
was generating empty CRLs with the zero-length SEQUENCE in version 3.1.3. 
3.1.4 was issued last night that fixed this. Oscar is produced in 
Australia, so it was "today" there when it was "last night" here...

Again, I think their reading of RFC 2459 was reasonable although not what 
the majority of people would have thought reading it. We have so many cases 
of "put a NULL in" or "must not put a NULL in" that we should be clear 
wherever we can.

--Paul Hoffman, Director
--Internet Mail Consortium