Oscar Jacobsson wrote:
> Keon should probably take part of the blame for failing to set Version,
> as required by RFC 2459:
>
> 5.1.2.1 Version
>
> This optional field describes the version of the encoded CRL. When
> extensions are used, as required by this profile, this field MUST be
> present and MUST specify version 2 (the integer value is 1).
Which isn't really in line with X.509 (06/97), which states that:
"If any extensions included in a CertificateList are defined as
critical, the version element of the CertificateList shall be present.
If no extensions defined as critical are included, the version element
shall be absent. This may permit a implementation that only supports
version 1 CRLs to still use the CRL if in its examination of the
revokedCertificates sequence in the CRL, it does not encounter an
extension. An implementation that supports version 2 (or greater) CRLs
may be able to optimize its processing if it can determine early in
processing that no critical extensions are present in the CRL."
This is, I guess, the reason why the Keon CRL had the version number
absent, seeing as the AKI extension wasn't critical.
//oscar
S/MIME Cryptographic Signature
