Subject: RE: Vagueness in empty CRLs

From: Sharon Boeyen <[email-masked]>
Date: Fri, 7 Jan 2000 09:27:22 -0500

David I agree with everything you said, and I'm certainly not going 
to bet against your wager and lose my $0.50 :-)  

I'm wondering if it would be useful to try to get a phrase added 
to 509 that "strongly recommends" that an empty SEQUENCE never be 
used. That might be helpful for guiding future implementations 
while still not breaking backward compatibility if David does 
lose his $0.50 wager. Do you think this 
is a "not worth the trouble" suggestion or something that would be 
good to try? I don't know how the 509 group would feel about it, since
we're now at the DAM stage, but I could see a phrase of this sort 
being proposed as a clarification. 

Sharon 

> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Thursday, January 06, 2000 10:11 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Vagueness in empty CRLs
> 
> 
> 
> > 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.
>