Subject: RE: Vagueness in empty CRLs

From: Sharon Boeyen <[email-masked]>
Date: Wed, 5 Jan 2000 14:43:28 -0500

The ASN.1 in X.509 is the way it is, at least in part, for purposes 
of backward compatibility with v1 CRLs. I don't see any need to change 
that because the PKIX profile is accommodated with the current ASN.1.

On the topic of how to issue a CRL that contains zero revocation notices, 
X.509 currently allows two ways. Either the optional revokedCertificates
element
can be absent, or it can be present with an empty SEQUENCE. That also is
nothing
new, but has been allowed since the early days of v1 CRLs. 

My understanding is that the PKIX profile mandates that the issuance of a
CRL that 
contains no revocation notices be done by omiting the revokedCertificates
element. 
I have no problem with that either because it is a profile.

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. 

While this would probably be a useful thing to do, we need to remember that
PKIX is 
not the only group that is using and profiling X.509. I suppose we can check
the profiles 
and groups we are aware of (e.g. FPKI, SEIS, TC 68, ANSI, WAP etc) and if
all we know 
about uses the same method, we could raise a defect against X.509 to modify
it. I'm not saying 
I'm opposed to that, but am raising the point that PKIX is not the only
environment of concern.

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.

Sharon 

> -----Original Message-----
> From: David P. Kemp [mailto:[email-masked]]
> Sent: Tuesday, January 04, 2000 1:41 PM
> To: [email-masked]
> Subject: Re: Vagueness in empty CRLs
> 
> 
> It should also be clearer in X.509-Y2K.  Perhaps the definition of
> revokedCertificates in CertificateList could be changed from:
> 
>     revokedCertificates ::= SEQUENCE OF SEQUENCE {
>         serialNumber        CertificateSerialNumber,
>         revocationDate      Time,
>         crlEntryExtensions  Extensions OPTIONAL } OPTIONAL,
>     ...
> 
> to:
> 
>     revokedCertificates ::= SEQUENCE SIZE(1..MAX) OF CrlEntry 
> OPTIONAL,
>     ...
> 
>     CrlEntry ::= SEQUENCE {
>         serialNumber        CertificateSerialNumber,
>         revocationDate      Time,
>         crlEntryExtensions  Extensions OPTIONAL }
> 
> 
> I notice that the size constraint for Extensions is present 
> in RFC 2459
> but not in X.509, so updating X.509 is not a strict 
> prerequisite.  Still,
> it would be nice if X.509 were clarified.
> 
> Dave
> 
> 
> 
> > Date: Tue, 04 Jan 2000 11:56:00 -0500
> > To: Paul Hoffman / IMC <[email-masked]>
> > From: Russ Housley <[email-masked]>
> > Subject: Re: Vagueness in empty CRLs
> > Cc: [email-masked]
> > 
> > I wrote this sentence.  I meant (a).  If you think it is 
> necessary, we can 
> > add a few words to remove the ambiguity in the next version.
> > 
> > Russ
> > 
> > 
> > At 04:56 PM 01/03/2000 -0800, Paul Hoffman / IMC wrote:
> > >RFC 2459, section 5.1.2 says:
> > >
> > >    Optional fields include lists of revoked certificates and CRL
> > >    extensions.  The revoked certificate list is optional 
> to support the
> > >    case where a CA has not revoked any unexpired 
> certificates that it
> > >    has issued.
> > >
> > >This could be read two ways:
> > >
> > >a) If there are no revoked certs, do not include the optional field
> > >
> > >b) If there are no revoked certs, you can include and 
> empty optional field 
> > >because it is, after all, optional
> > >
> > >At least one developer has coded only for (a). Do people 
> have a strong 
> > >feeling one way or another? Either way, I think this 
> should be clearer in 
> > >2459bis.
> > >
> > >--Paul Hoffman, Director
> > >--Internet Mail Consortium
> > 
>

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Wed, 5 Jan 2000 17:44:02 -0500

> 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 admit
though that I am amazingly sensitive on this point having heard at length
the same argument in the context of XML documents. Strikes me that people
are going to want such a capability about as often as they stick $100 bills
into the office shredder and stick them back together with Scotch tape.

Regardless, we might well wish to consider that PKIX implementations should
be restrictive in what they create and persmissive in what they accept.

If there is a possible confusion we should perhaps state that
implementations
MUST issue the pukah DER form and SHOULD accept anything that is legal BER.

	Phill

---

From: Paul Koning <[email-masked]>
Date: Wed, 5 Jan 2000 17:54:35 -0500

>>>>> "Phillip" == Phillip M Hallam-Baker <[email-masked]> writes:

 Phillip> Given the choice between ASN.1 DER purity and backwards
 Phillip> compatibility, give me compatibility every time.

That makes sense.

 Phillip> Regardless, we might well wish to consider that PKIX
 Phillip> implementations should be restrictive in what they create
 Phillip> and persmissive in what they accept.

Definitely.  That's the IETF protocol design rule.

 Phillip> If there is a possible confusion we should perhaps state
 Phillip> that implementations MUST issue the pukah DER form and
 Phillip> SHOULD accept anything that is legal BER.

I'd say that's going too far.  "Permissive" doesn't mean (to me) that
you should accept a large superset of the supposed protocol at great
expense in complexity.  It means things like:

1. Don't do value checking if it serves no purpose other than to
complain about "the wrong value".
2. Assume reserved fields can be any old value, not just zero.
3. *if it is no particular effort to do so* don't assume tagged field
to be in a particular order

But it doesn't mean that you should accept the full gruesome
flexibility of BER.  Relaxing some of the DER rules (e.g., on
ordering) may be a good thing.  But a big argument for the
"permissive" rule is to make things simpler, not to make them more
complex. 

	paul

---

From: Stephen Kent <[email-masked]>
Date: Wed, 5 Jan 2000 20:45:29 -0500

Folks,

We're not debating a generic change re adherence to DER.  We're just 
debating details of CRL encoding conventions.  I agree with Sharon's 
analysis and suggest that we adopt that approach to dealing with this 
ambiguity.

Steve