The to-be-signed certificate list contains the signature algorithm identifier, the CRL issuer, and the CRL issue date. It should always contain the date by which a new CRL will be issued, even though the syntax specifies the next
version signature issuer thisUpdate nextUpdate revokedCertificates crlExtensions signatureAlgorithm signatureValue SEQUENCE OF v2
ECDSA with SHA-256
080214120000Z 080221120000Z C=US; O=Hawk; CN=CA1
userCertificate
revocationDate
crlEntryExtensions
110592 071226183000Z ECDSA with SHA-256
30 2c 02 14 9e d8 6b c1 7d ... 9a b2
74 Part II ■ PKI Basics
update field as optional. Failure to include the next update field significantly complicates validation of a certificate. When there are no revoked certificates, the revoked certificates portion of the structure is absent. When one or more certificates are revoked, each entry on the revoked certificate list is defined by a structure containing the user certificate serial number, revocation date, and optional CRL entry extensions.
The to-be-signed certificate list may also contain CRL extensions. CRL entry extensions provide information about a single revoked certificate, while CRL extensions provide information about the whole list.
The fields within the signed portion of the CRL are described next:
version. The optionalversionfield describes the syntax of the CRL. When extensions are used, which is usually the case, the field speci- fies version two (v2). CRL issuers may set the version field to v2 even if extensions are absent, so very few version one (v1) CRLs are actually in use today.
signature. Thesignaturefield contains the algorithm identifier for the digital signature algorithm used by the CRL issuer to sign the to-be- signed certificate list. This field must contain the same algorithm identi- fier as the signature algorithm field in the top-level structure of the CRL. The two algorithm identifiers are redundant; however, the digital signa- ture covers one and not the other.
issuer. Theissuerfield contains the X.500 distinguished name of the CRL issuer. The Internet Certificate and CRL profile [RFC3280] requires the issuer field to contain a nonempty name. This is generally the identity of the CA; however, some CAs may choose to delegate some or all CRL functions to another authority by including a CRL Distribution Point extension in certificates. Such CRLs are called Indirect CRLs since the certificate issuer and the CRL issuer are different authorities. Additional names, or aliases, for the CRL issuer may also appear in the issuer alter- native name extension.
thisUpdate. ThethisUpdatefield indicates the issue date of this CRL. There are two forms of date supported: UTC time and generalized time. CRL issuers must encode the this-update field as UTC time for dates through the year 2049, and CRL issuers must encode the this-update field as generalized time for dates in the year 2050 and beyond. This is the same rule as described earlier for the validity period in the certificate.
nextUpdate. ThenextUpdatefield indicates the date by which the next CRL will be issued. The same two date forms are supported: UTC time and generalized time. The next CRL could be issued before the indicated date, but it must not be issued any later than the indicated date. As stated previously, CRL issuers ought to include this field, even though it is
Turner c05.tex V3 - 03/26/2008 5:28pm Page 75
Chapter 5 ■ Understanding Public Key Infrastructure 75
optional. CRL issuers should include anextUpdatetime equal to or later than all previous CRLs issued for the same distribution point. If this sim- ple rule is not followed, then clients trying to determine when to fetch an updated CRL from the repository may not check when an updated one is available.
revokedCertificates. TherevokedCertificatesstructure lists the revoked certificates. TherevokedCertificatesstructure is optional but should only be absent when none of the unexpired certificates has been revoked. When there are no unexpired revoked certificates, therevoked- Certificatesstructure is absent; otherwise, therevokedCertificates structure contains one entry for each revoked certificate. The structure contains the certificate serial numbers, time of revocation, and optional CRL entry extensions.
userCertificate. TheuserCertificatefield within therevoked- Certificatestructure specifies the serial number of the revoked cer- tificate. Certificates are uniquely identified by the combination of their certificate issuer name and their certificate serial number. Generally, the certificate issuer and the CRL issuer are the same authority, so the CRL structure is optimized for this case. That is, the issuer name is car- ried once in the issuer field, and it applies to the entire list of serial num- bers. When the CRL issuer and the certificate issuer are different, the certificate issuer must be paired with each serial number. The certificate issuer CRL entry extension provides the certificate issuer name. This CRL entry extension, as well as the others, is described later in the chapter.
revocationDate. TherevocationDatefield specifies the date on which the revocation occurred. The same two date forms are supported: UTC time and generalized time.
crlEntryExtensions. ThecrlEntryExtensionsfield is used to provide additional information about CRL entries. This field may only appear if the version is v2. The certificate issuer described previously is one example. This CRL entry extension and others are discussed later.
crlExtensions. ThecrlExtensionsfield is used to provide additional information about the whole CRL. Again, this field may only appear if the version is v2. CRL extensions are discussed in the next section.