Subject: Encoding for cRLNumber and invalidityDate

From: "Tammy Green" <[email-masked]>
Date: Thu, 09 Mar 2000 10:47:08 -0700

Two questions about encoding CRLs.....

1.  Is cRLNumber an INTEGER or an OCTET STRING?
In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for cRLNumber is INTEGER.  However, in the CRL examples that I've seen, it is encoded as an OCTET STRING.  Also, Internet Explorer v5 only seems to take the CRL if the cRLNumber is encoded as an OCTET STRING.

Has anyone else noticed this?

2.  Is invalidityDate encoded as GeneralizedTIme only?
In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for invalidityDate is GeneralizedTime.  Unlike other dates in the CRL (or certificates), it is not UTCTime through the year 2049 and GeneralizedTime thereafter.  However, in  examples of CRLs, indeed, even in the CRL example in Appendix D, the date is expressed in UTCTime.

Is this a typo?

Tammy Green
[email-masked]
Software Engineer
Novell, Inc.

---

From: Trevor Freeman <[email-masked]>
Date: Thu, 9 Mar 2000 16:50:01 -0800

Hi Tammy,

There seems to be a disconnect between the text in RFC2459 describing the
example of the CRL and the decode of the actual ASN.
 
In looking at the example we read the ASN as a CRL with 1 revocation entry
sn=18. The CRL entry has an extension, the reason code extension where the
revocation reason is 1 = key compromise.
 
We find no CRL extensions in the ASN which contradicts the descriptions
which states that there is a CRLnumber extension.
 
Therefore we can find no problem with the ASN, only the description does not
mach the ASN itself. Therefore we do not see that the text contradicts the
example of how the CRLnumber extension should be encoded.
 
That being said, what is not clear is what you mean when you say IE5 only
takes CRLnumber as an Octet string. IE5 does not know about the CRLnumber
extension, so it would never attempt to decode that extension. On Windows
2000 if the CRLnumber extension is present and non-critical, we process the
CRL, if the extension is marked critical, we would reject the CRL as per the
RFC because we do not process the CRLnumber extension. On down level
platforms we do not fail revocation checking on critical CRL extensions we
do not process.
 
If you are interested, we are open to doing CRL interoperability testing
with CA vendors such as yourself.
 
Trevor

-----Original Message-----
From: Tammy Green [mailto:[email-masked]]
Sent: Thursday, March 09, 2000 9:47 AM
To: [email-masked]
Cc: Nathan Coe
Subject: Encoding for cRLNumber and invalidityDate

1.  Is cRLNumber an INTEGER or an OCTET STRING?
In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for cRLNumber is
INTEGER.  However, in the CRL examples that I've seen, it is encoded as an
OCTET STRING.  Also, Internet Explorer v5 only seems to take the CRL if the
cRLNumber is encoded as an OCTET STRING.

2.  Is invalidityDate encoded as GeneralizedTIme only?
In RFC 2459 and draft-ietf-pkix-new-part1-00.txt the type for invalidityDate
is GeneralizedTime.  Unlike other dates in the CRL (or certificates), it is
not UTCTime through the year 2049 and GeneralizedTime thereafter.  However,
in  examples of CRLs, indeed, even in the CRL example in Appendix D, the
date is expressed in UTCTime.
 
Is this a typo?

Tammy Green
[email-masked] <mailto:[email-masked]> 
Software Engineer
Novell, Inc.