| Administrator's Guide Red Hat Certificate System |
| Previous |
Contents |
Index |
Next |
Appendix G
Certificate and CRL Extensions
This appendix explains both the standard certificate extensions defined by X.509 v3 and the extensions defined by Red Hat that were used in versions of products released before X.509 v3 was finalized. It also provides recommendations for extensions to use with specific kinds of certificates, including both PKIX Part 1 recommendations and Red Hat extensions that must be supported for compatibility with early versions of Red Hat products.
This appendix contains the following sections:
- Introduction to Certificate Extensions
- Standard X.509 v3 Certificate Extensions
- Introduction to CRL Extensions
- Standard X.509 v3 CRL Extensions
- Netscape-Defined Certificate Extensions
- CA Certificates and Extension Interactions
Introduction to Certificate Extensions
An X.509 v3 certificate contains an extensions field that permits any number of additional fields to be added to the certificate. Certificate extensions provide a way of adding information such as alternative subject names and usage restrictions to certificates. Older versions of Red Hat browsers and servers that were developed before PKIX part 1 standards were defined require Red Hat-specific extensions.
The X.509 v1 certificate specification was originally designed to bind public keys to names in an X.500 directory. As certificates began to be used on the Internet and extranets, and directory lookups could not always be performed, problem areas such as the following emerged that were not foreseen in the original specification:
- Trust-The X.500 specification establishes trust by means of a strict directory hierarchy. By contrast, Internet and extranet deployments frequently involve distributed trust models that do not conform to the hierarchical X.500 approach.
- Certificate use-Some organizations may wish to restrict the use of certificates for policy reasons. For example, some certificates may be restricted to client authentication only.
- Multiple certificates-It's not uncommon for certificate users to possess multiple certificates with identical subject names but different key material. In this case, it's necessary to identify which key and certificate should be used for what purpose.
- Alternate names-For some purposes, it is useful to have alternative subject names that are also bound to the public key in the certificate.
- Additional attributes-Some organizations may find it convenient to store additional information in certificates, for example for situations in which it's not possible to look up information in a directory.
- Relationship with CA-When certificate chaining involves intermediate CAs, it is useful to have information about the relationships among CAs embedded in their certificates.
- CRL checking-Since it's not always possible to check a certificate's revocation status against a directory or with the original certificate authority, it is useful for certificates to include information about where to check CRLs.
Eventually, the X.509 v3 specification addressed many of these issues by amending the certificate format to include additional information within a certificate-the version 3 format defines a general format for certificate extensions and specifies a number of standard extensions that can be included the certificate. Thus, the extensions defined for X.509 v3 certificates enable you to associate additional attributes with users or public keys and manage the certification hierarchy. The Internet X.509 Public Key Infrastructure Certificate and CRL Profile (see http://www.ietf.org/rfc/rfc2459.txt, http://www.ietf.org/rfc/rfc3280.txt and http://www.ietf.org/rfc/rfc3279.txt) for the RFCs that describe extensions) recommends a set of extensions to be used in Internet certificates (and standard locations for certificate or CA information). These extensions are called standard extensions.
The X.509 v3 standard for certificates also suggests that you can define your own extensions and include them in certificates you issue. These extensions are called private, proprietary, or custom extensions and they carry information unique to your organization or business. Keep in mind that applications may not able to validate certificates that contain private, critical extensions, thus preventing the use of these certificates in a general context.
Before the X.509 v3 standard was finalized, Netscape and other companies had to address some of the most pressing issues listed above with their own extension definitions. For example, applications (Netscape Navigator 3.0 or higher, and Enterprise Server 2.01 or higher) support an extension known as Netscape Certificate Type Extension that specifies the type of certificate issued, such as client, server, or object signing. Therefore, to maintain compatibility with older versions of browsers that were released before the X.509 v3 specification was finalized, certain kinds of certificates should include some of the Red Hat extensions.
Note that the X.500 and X.509 specifications are controlled by the International Telecommunication Union (ITU), an international organization that primarily serves large telecom companies, government organizations, and other entities concerned with the international telecommunications network. The Internet Engineering Task Force (IETF), which controls many of the standards that underlie the Internet, is currently developing public-key infrastructure X.509 (PKIX) standards. These proposed standards further refine the X.509 v3 approach to extensions for use on the Internet. The recommendations for certificates and CRLs have reached proposed standard status and are in a document often referred to as PKIX Part 1.
Some explanations in this appendix also make reference to Abstract Syntax Notation One (ASN.1) and Distinguished Encoding Rules (DER). These are specified in the CCITT Recommendations X.208 and X.209. For a quick summary of ASN.1 and DER, see A Layman's Guide to a Subset of ASN.1, BER, and DER, which is available at RSA Laboratories' web site (http://www.rsa.com).
Structure of Certificate Extensions
In RFC 2459, an X.509 certificate extension is defined as follows:
- extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }Which means, a certificate extension consists of the following:
- The object identifier (OID) for the extension; see Appendix H, "Object Identifiers."
- This identifier uniquely identifies the extension. It also determines the ASN.1 type of value in the value field and how the value is interpreted. That is, when an extension appears in a certificate, the OID appears as the extension ID field (extnID) and the corresponding ASN.1 encoded structure appears as the value of the octet string (extnValue); see the examples in "Sample Certificate Extensions" on page 728.
- The value, which can be either true or false, assigned to this field indicates whether the extension is critical or noncritical to the certificate.
- If the extension is critical and the certificate is sent to an application that does not understand the extension (based on the extension's ID), the application must reject the certificate.
- If the extension is not critical and the certificate is sent to an application that does not understand the extension (based on the extension's ID), the application can ignore the extension and accept the certificate.
- Typically, the application receiving the certificate checks the extension ID to determine if it can recognize the ID. If it can, it uses the extension ID to determine the type of value used.
Examples of standard extensions defined in the X.509 v3 standard include the following:
- Authority Key Identifier Extension-an extension for identifying the certificate authority's public key (the key used to sign the certificate).
- Subject Key Identifier Extension-an extension for identifying the subject's public key (the key being certified).
Note that not all applications support certificates with version 3 extensions. Applications that do support these extensions may not be able to interpret some or all of these specific extensions.
Sample Certificate Extensions
The following is an example of the section of a certificate containing X.509 v3 extensions. (CS can display certificates in human-readable format, as shown here.) As shown in the example, certificate extensions appear in sequence and only one instance of a particular extension may appear in a particular certificate; for example, a certificate may contain only one subject key identifier extension. Note that certificates that support these extensions have the version 0x2 (which corresponds to version 3).
Data: Version: v3 Serial Number: 0x1 Signature Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5 Issuer: CN=Certificate Manager,OU=netscape,O=aol,L=MV,ST=CA,C=US Validity: Not Before: Friday, February 21, 2003 12:00:00 AM PST America/Los_Angeles Not After: Monday, February 21, 2005 12:00:00 AM PST America/Los_Angeles Subject: CN=Certificate Manager,OU=netscape,O=aol,L=MV,ST=CA,C=US Subject Public Key Info: Algorithm: RSA - 1.2.840.113549.1.1.1 Public Key: Exponent: 65537 Public Key Modulus: (1024 bits) : E4:71:2A:CE:E4:24:DC:C4:AB:DF:A3:2E:80:42:0B:D9: CF:90:BE:88:4A:5C:C5:B3:73:BF:49:4D:77:31:8A:88: 15:A7:56:5F:E4:93:68:83:00:BB:4F:C0:47:03:67:F1: 30:79:43:08:1C:28:A8:97:70:40:CA:64:FA:9E:42:DF: 35:3D:0E:75:C6:B9:F2:47:0B:D5:CE:24:DD:0A:F7:84: 4E:FA:16:29:3B:91:D3:EE:24:E9:AF:F6:A1:49:E1:96: 70:DE:6F:B2:BE:3A:07:1A:0B:FD:FE:2F:75:FD:F9:FC: 63:69:36:B6:5B:09:C6:84:92:17:9C:3E:64:C3:C4:C9 Extensions: Identifier: Netscape Certificate Type - 2.16.840.1.113730.1.1 Critical: no Certificate Usage: SSL CA Secure Email CA ObjectSigning CA Identifier: Basic Constraints - 2.5.29.19 Critical: yes Is CA: yes Path Length Constraint: UNLIMITED Identifier: Subject Key Identifier - 2.5.29.14 Critical: no Key Identifier: 3B:46:83:85:27:BC:F5:9D:8E:63:E3:BE:79:EF:AF:79: 9C:37:85:84 Identifier: Authority Key Identifier - 2.5.29.35 Critical: no Key Identifier: 3B:46:83:85:27:BC:F5:9D:8E:63:E3:BE:79:EF:AF:79: 9C:37:85:84 Identifier: Key Usage: - 2.5.29.15 Critical: yes Key Usage: Digital Signature Key CertSign Crl Sign Signature: Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5 Signature: AA:96:65:3D:10:FA:C7:0B:74:38:2D:93:54:32:C0:5B: 2F:18:93:E9:7C:32:E6:A4:4F:4E:38:93:61:83:3A:6A: A2:11:91:C2:D2:A3:48:07:6C:07:54:A8:B8:42:0E:B4: E4:AE:42:B4:B5:36:24:46:4F:83:61:64:13:69:03:DF: 41:88:0B:CB:39:57:8C:6B:9F:52:7E:26:F9:24:5E:E7: BC:FB:FD:93:13:AF:24:3A:8F:DB:E3:DC:C9:F9:1F:67: A8:BD:0B:95:84:9D:EB:FC:02:95:A0:49:2C:05:D4:B0: 35:EA:A6:80:30:20:FF:B1:85:C8:4B:74:D9:DC:BB:50Standard X.509 v3 Certificate Extensions
This section summarizes the extension types that are defined as part of the Internet X.509 Version 3 standard, as of September 1998, and indicates which types are recommended by the PKIX working group.
This section summarizes important information about each certificate. For complete details, see both the X.509 v3 standard (available from the ITU) and the Internet X.509 Public Key Infrastructure - Certificate and CRL Profile (RFC 2459), available at http://www.ietf.org/rfc/rfc2459.txt. The descriptions of extensions reference the RFC and section number of the standard draft that discusses the extension; the object identifier (OID) for each extensions is also provided.
Each extension in a certificate can be designated as critical or noncritical. A certificate-using system, such as browser software, must reject the certificate if it encounters a critical extension it does not recognize; however, a noncritical extension can be ignored if it is not recognized.
CS (CS) version support is listed for each extension. "Supported" means that the indicated version of CS ships with built-in support for the extension via a policy plug-in. "Not supported" means that the indicated version of CS does not ship a policy plug-in for the extension (although the extension can be used if a custom plug-in is written).
authorityInfoAccess
OID
Criticality
This extension must be noncritical.
Discussion
The Authority Information Access extension indicates how and where to access information about the issuer of the certificate. The extension contains an accessMethod and an accessLocation field. The accessMethod specifies (by an OID) the type and format of information about the issuer found at the accessLocation.
PKIX Part 1 defines one accessMethod (id-ad-caIssuers) to get a list of CAs that have issued certificates higher in the CA chain than the issuer of the certificate using the extension. The accessLocation field then typically contains a URL indicating the location and protocol (LDAP, HTTP, FTP) used to retrieve the list.
The Online Certificate Status Protocol (RFC 2560), available at http://www.ietf.org/rfc/rfc2560.txt, defines an accessMethod (id-ad-ocsp) for using OCSP to verify certificates. The accessLocation field then contains a URL indicating the location and protocol used to access an OCSP responder that can validate the certificate.
CS Version Support
Supported since version 4.2. Refer to "AuthInfoAccessExt" on page 489.
authorityKeyIdentifier
OID
Criticality
This extension is always noncritical and is always evaluated.
Discussion
The Authority Key Identifier extension identifies the public key corresponding to the private key used to sign a certificate. This extension is useful when an issuer has multiple signing keys (for example, due to CA certificate renewal).
The extension consists of either or both of the following:
- an explicit key identifier (keyIdentifier field)
- an issuer (authorityCertIssuer field) and serial number (authorityCertSerialNumber field) identifying a certificate
If the keyIdentifier field exists, then it is used to select the certificate with a matching subjectKeyIdentifier extension. If the authorityCertIssuer and authorityCertSerialNumber fields are present, then they are used to identify the correct certificate by issuer and serialNumber.
If this extension is not present, then the issuer name alone is used to identify the issuer certificate.
PKIX Part 1 requires this extension for all certificates except self-signed root CA certificates. Where a key identifier has not been previously established, PKIX recommends that the authorityCertIssuer and authorityCertSerialNumber fields be specified. These fields permit construction of a complete certificate chain by matching the SubjectName and CertificateSerialNumber fields in the issuer's certificate against the authortiyCertIssuer and authorityCertSerialNumber in the AuthorityKeyIdentifier extension of the subject certificate.
CS Version Support
Supported since CS 4.1. Refer to "AuthorityKeyIdentifierExt" on page 492.
Note that CS does not use or support the authorityCertSerialNumber field in the Authority Key Identifier extension.
basicConstraints
OID
Criticality
PKIX Part 1 requires that this extension be marked critical. This extension is evaluated regardless of its criticality.
Discussion
This extension is used during the certificate chain verification process to identify CA certificates and to apply certificate chain path length constraints. The cA component should be set to true for all CA certificates. PKIX recommends that this extension should not appear in end-entity certificates.
If the pathLenConstraint component is present, its value must be greater than the number of CA certificates that have been processed so far (starting with the end-entity certificate and moving up the chain). If pathLenConstraint is omitted, then all of the higher level CA certificates in the chain must not include this component when the extension is present.
See "CA Certificates and Extension Interactions" on page 749 regarding the interaction of the this extension with the Netscape Certificate Type extension.
CS Version Support
Supported since CS 4.1. Refer to "BasicConstraintsExt" on page 493.
certificatePolicies
OID
Criticality
This extension may be critical or noncritical.
Discussion
The Certificate Policies extension defines one or more policies, each of which consists of an OID and optional qualifiers. The extension can include a URI to the issuer's Certificate Practice Statement or can embed issuer policy information, such as a user notice in text form. This information can be used by certificate-enabled applications.
If this extension is present, PKIX Part 1 recommends that policies be identified with an OID only, or if necessary only certain recommended qualifiers.
CS Version Support
Supported since CS 4.2. Refer to "CertificatePoliciesExt" on page 494.
CRLDistributionPoints
OID
Criticality
PKIX recommends that this extension be marked noncritical and that it be supported for all certificates.
Discussion
This extension defines how CRL information for this certificate is to be obtained. It should be used if the system is configured to use CRL issuing points.
If the extension contains a DistributionPointName of type URI, the URI is assumed to be a pointer to the current CRL for the associated reasons and will be issued by the associated cRLIssuer. The expected values for the URI are those defined for the subjectAltName extension. If the distributionPoint omits reasons, the CRL must include revocations for all reasons. If the distributionPoint omits cRLIssuer, the CRL must be issued by the CA that issued the certificate.
PKIX recommends that this extension be supported by CAs and applications.
CS Version Support
Supported since CS 4.1. Refer to "CRLDistributionPointsExt" on page 501.
extKeyUsage
OID
Criticality
If this extension is marked critical, the certificate must be used for one of the indicated purposes only. If it is not marked critical, it is treated as an advisory field that may be used to identify keys but does not restrict the use of the certificate to the indicated purposes.
Discussion
The Extended Key Usage extension indicates one or more purposes for which the certified public key may be used. These purposes may be in addition to or in place of the basic purposes indicated in the key usage extension.
The Extended Key Usage extension must include OCSP Signing in an OCSP responder's certificate (unless the CA signing key that signed the certificates validated by the responder is also the OCSP signing key). The OCSP responder's certificate must be issued directly by the CA that signs certificates the responder will validate.
The Key Usage, Extended Key Usage, and Basic Constraints extensions act together to define the purposes for which the certificate is intended to be used. Applications can use these extensions to disallow the use of a certificate in inappropriate contexts.
Table G-1 lists the uses defined by PKIX for this extension, and Table G-2 lists uses privately defined by Red Hat.
* OCSP Signing is not defined in PKIX Part 1, but in RFC 2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP."
CS Version Support
Supported since CS 4.2. Refer to "ExtendedKeyUsageExt" on page 503.
issuerAltName
OID
Criticality
PKIX Part 1 recommends that this extension be marked noncritical.
Discussion
The Issuer Alternative Name extension is used to associate Internet-style identities with the certificate issuer. Names must use the forms defined for subjectAltName.
CS Version Support
Supported since CS 4.2. Refer to "IssuerAltNameExt" on page 510.
keyUsage
OID
Criticality
This extension may be critical or noncritical. PKIX Part 1 recommends that it should be marked critical if it is used.
Discussion
The Key Usage extension defines the purpose of the key contained in the certificate. The Key Usage, Extended Key Usage, Basic Constraints, and Netscape Certificate Type extensions act together to specify the purposes for which a certificate can be used. For more information on interactions between these extensions in CA certificates, see "CA Certificates and Extension Interactions" on page 749.
If this extension is included at all, set the bits as follows:
- digitalSignature (0) for SSL client certificates, S/MIME signing certificates, and object-signing certificates.
- nonRepudiation (1) for some S/MIME signing certificates and object-signing certificates. Note, however, that the use of this bit is controversial. You should carefully consider the legal consequences of its use before setting it for any certificate.
- keyEncipherment (2) for SSL server certificates and S/MIME encryption certificates.
- dataEncipherment (3) when the subjects's public key is used to encipher user data (as opposed to key material).
- keyAgreement (4) whenever the subject's public key is used for key agreement.
- keyCertSign (5) for all CA signing certificates
- cRLSign (6) for CA signing certificates that are used to sign CRLs
- encipherOnly (7) if the public key is to be used only for enciphering data. If this bit is set, keyAgreement should also be set.
- decipherOnly (8) if the public key is to be used only for deciphering data. If this bit is set, keyAgreement should also be set.
Table G-3 summarizes the above guidelines for typical certificate uses.
If the keyUsage extension is present and is marked critical, then it will be used to enforce the usage of the certificate and key. The extension is used to limit the usage of a key; if the extension is not present or not critical, all types of usage are allowed.
If the keyUsage extension is present (critical or not), it is used to select from multiple certificates for a given operation. For example, it is used to distinguish separate signing and encryption certificates for users who have separate certificates and key pairs for these operations.
CS Version Support
Supported since CS 4.1. Refer to "KeyUsageExt" on page 513.
nameConstraints
OID
Criticality
PKIX Part 1 requires that this extension be marked critical.
Discussion
This extension, which can used in CA certificates only, defines a name space within which all subject names in subsequent certificates in a certification path must be located.
CS Version Support
Supported since CS 4.2. Refer to "NameConstraintsExt" on page 519.
OCSPNocheck
OID
Criticality
This extension should be noncritical.
Discussion
The extension is meant to be included in an OCSP responder's signing certificate. The extension tells an OCSP client that the signing certificate can be trusted without querying the OCSP responder (since the reply would again be signed by the OCSP responder, and the client would again request the validity status of the signing certificate). This extension is null-valued: its meaning is determined by its presence or absence.
Since the presence of this extension in a certificate will cause OCSP clients to trust responses signed with that certificate, use of this extension should be managed carefully. If the OCSP signing key is compromised, the entire process of validating certificates in the PKI will be compromised for the duration of the validity period of the certificate. Therefore, certificates using OCSPNocheck should be issued with short lifetimes and be renewed frequently.
CS Version Support
Supported since CS 4.2. Refer to "OCSPNoCheckExt" on page 530.
policyConstraints
OID
Criticality
This extension may be critical or noncritical.
Discussion
This extension, which is for CA certificates only, constrains path validation in two ways. It can be used to prohibit policy mapping or to require that each certificate in a path contain an acceptable policy identifier.
PKIX requires that, if present, this extension must never consist of a null sequence. At least one of the two available fields must be present.
CS Version Support
Supported since CS 4.2. Refer to "PolicyConstraintsExt" on page 531.
policyMappings
OID
Criticality
This extension must be noncritical.
Discussion
The Policy Mappings extension is used in CA certificates only. It lists one or more pairs of OIDs used to indicate that the corresponding policies of one CA are equivalent to policies of another CA. It may be useful in the context of cross-certification.
This extension may be supported by CAs and/or applications.
CS Version Support
Supported since CS 4.2. Refer to "PolicyMappingsExt" on page 532.
privateKeyUsagePeriod
OID
Discussion
The Private Key Usage Period extension allows the certificate issuer to specify a different validity period for the private key than for the certificate itself. This extension is intended for use with digital signature keys.
PKIX Part 1 recommends against the use of this extension. CAs conforming to PKIX Part 1 must not generate certificates with this extension.
CS Version Support
Supported since CS 4.2. Refer to "PrivateKeyUsagePeriodExt" on page 534.
subjectAltName
OID
Criticality
If the certificate's subject field is empty, this extension must be marked critical.
Discussion
The Subject Alternative Name extension includes one or more alternative (non-X.500) names for the identity bound by the CA to the certified public key. It may be used in addition to the certificate's subject name or as a replacement for it. Defined name forms include Internet electronic mail address (SMTP, as defined in RFC-822), DNS name, IP address, and uniform resource identifier (URI).
PKIX requires this extension for entities that are identified by name forms other than the X.500 distinguished name (DN) used in the subject field. PKIX Part 1 describes additional rules for the relationship between this extension and the subject field.
Email addresses may be provided either in the Subject Alternative Name extension, the certificate subject name field, or both. If the email address is provided as part of the subject name, it must be in the form of the EmailAddress attribute defined by PKCS-9. Software that supports S/MIME must be able to read an email address from either the Subject Alternative Name extension or from the subject name field.
CS Version Support
Supported since CS 4.1. Refer to "SubjectAltNameExt" on page 535.
subjectDirectoryAttributes
OID
Criticality
PKIX Part 1 requires that this extension be marked noncritical.
Discussion
The Subject Directory Attributes extension conveys any desired directory attribute values for the subject of the certificate. It is not recommended as an essential part of the proposed PKIX standard, but may be used in local environments.
CS Version Support
Supported since CS 4.2. Refer to "SubjectDirectoryAttributesExt" on page 538.
subjectKeyIdentifier
OID
Criticality
This extension is always noncritical.
Discussion
The Subject Key Identifier extension identifies the public key certified by this certificate. This extension provides a way of distinguishing public keys if more than one is available for a given subject name, for example after the certificate has been renewed with a new key.
The value of this extension should be calculated by performing a SHA-1 hash of the certificate's DER-encoded subjectPublicKey, as recommended by PKIX. The Subject Key Identifier extension is used in conjunction with the Authority Key Identifier extension for CA certificates. If the CA certificate has a Subject Key Identifier extension, the key identifier in the Authority Key Identifier extension (of the certificate being verified) should match the key identifier of the CA's Subject Key Identifier extension. It is not necessary for the verifier to recompute the key identifier in this case.
PKIX Part 1 requires this extension for all CA certificates and recommends it for all other certificates.
CS Version Support
Supported since CS 4.1. Refer to "SubjectKeyIdentifierExt" on page 540.
Introduction to CRL Extensions
Since its initial publication, the X.509 standard for CRL formats has been amended to include additional information within a CRL. Version 2, the latest version, allows you to add information as CRL extensions.
The extensions defined by ANSI X9 and ISO/IEC/ITU for X.509 v2 CRLs [X.509] [X9.55] enable you to associate additional attributes with CRLs. The Internet X.509 Public Key Infrastructure Certificate and CRL Profile (see http://www.ietf.org/rfc/rfc2459.txt) recommends a set of extensions to be used in CRLs. These extensions are called standard CRL extensions.
The standard also suggests that you can define your own extensions and include them in CRLs you issue. These extensions are called private, proprietary, or custom CRL extensions and they carry information unique to your organization or business. Keep in mind that applications may not able to validate CRLs that contain private, critical extensions, thus preventing the use of these CRLs in a general context.
Structure of CRL Extensions
A CRL extension consists of the following:
- The object identifier (OID) for the extension; see Appendix H, "Object Identifiers."
- This identifier uniquely identifies the extension. It also determines the ASN.1 type of value in the value field and how the value is interpreted. That is, when an extension appears in a CRL, the OID appears as the extension ID field (extnID) and the corresponding ASN.1 encoded structure appears as the value of the octet string (extnValue); see the examples in "Sample Certificate Extensions" on page 728.
- The true or false value assigned to this field indicates whether the extension is critical (true) or noncritical (false) to the CRL.
- If the extension is critical and the CRL is sent to an application that does not understand the extension (based on the extension's ID), the application must reject the CRL.
- If the extension is not critical and the CRL is sent to an application that does not understand the extension (based on the extension's ID), the application can ignore the extension and accept the CRL.
- Typically, the application receiving the CRL checks the extension ID to determine if it can recognize the ID. If it can, it uses the extension ID to determine the type of value used.
Sample CRL and CRL Entry Extensions
The following is an example of the section of a CRL containing X.509 v2 extensions. (CS can display CRLs in human-readable format, as shown here.) As shown in the example, CRL extensions appear in sequence and only one instance of a particular extension may appear in a particular CRL; for example, a CRL may contain only one authority key identifier extension. However, CRL-entry extensions appear in appropriate entries in the CRL.
Certificate Revocation List: Data: Version: v2 ... Extensions: Identifier: Authority Key Identifier Critical: no Key Identifier: 2c:22:c6:ae:4e:4b:91:c7:fb:4c:cc:ae:84:e8:aa:5b:46:6a:a0:ad Revoked Certificates: Serial Number: 0x12 Revocation Date: Tuesday, December 15, 1998 5:20:42 AM Extensions: Identifier: Revocation Reason - 2.5.29.21 Critical: no Reason: Key_Compromise Serial Number: 0x11 Revocation Date: Wednesday, December 16, 1998 4:51:54 AM Extensions: Identifier: Revocation Reason - 2.5.29.21 Critical: no Reason: CA_Compromise Serial Number: 0x10 Revocation Date: Thursday, December 17, 1998 2:37:24 AM Extensions: Identifier: Revocation Reason - 2.5.29.21 Critical: no Reason: Key_Compromise Serial Number: 0xA Revocation Date: Wednesday, November 25, 1998 5:11:18 AM Extensions: Identifier: Revocation Reason - 2.5.29.21 Critical: no Reason: Affiliation_Changed ...Standard X.509 v3 CRL Extensions
In addition to certificate extensions, the X.509 v3 proposed standard defines extensions to CRLs, which provide methods for associating additional attributes with Internet CRLs. These are of two kinds: extensions to the CRL itself, and extensions to individual certificate entries in the CRL.
Extensions for CRLs
The sections that follow describe the CRL extension types that are defined as part of the Internet X.509 v3 Public Key Infrastructure proposed standard, as of September 1998.
These are the CRL extensions described in the sections that follow:
authorityKeyIdentifier
OID
Discussion
The Authority Key Identifier extension for a CRL identifies the public key corresponding to the private key used to sign the CRL. For details, see the discussion under certificate extensions at authorityKeyIdentifier.
CS Version Support
Supported since CS 4.2. Refer to "AuthorityKeyIdentifier" on page 583.
CRLNumber
OID
Criticality
This extension must not be critical.
Discussion
The CRL Number extension specifies a sequential number for each CRL issued by a CA. It allows users to easily determine when a particular CRL supersedes another CRL.
PKIX requires that all CRLs have this extension.
CS Version Support
Supported since CS 4.2. Refer to "CRLNumber" on page 584.
deltaCRLIndicator
OID
Criticality
PKIX requires that this extension be critical if it exists.
Discussion
The Delta CRL Indicator extension identifies a delta-CRL. The use of delta-CRLs allows changes to be added to the local database while ignoring unchanged information that is already in the local database. This can significantly improve processing time for applications that store revocation information in a format other than the CRL structure.
CS Version Support
Supported since CS 6.1. Refer to "DeltaCRLIndicator" on page 585.
FreshestCRL
OID
Criticality
PKIX requires that this extension must be non-critical.
Discussion
The freshest CRL extension identifies how delta CRL information is obtained. The FreshestCRL extension is placed in the full CRL to indicate where to find latest delta CRL.
CS Version Support
Supported since CS 6.1. Refer to "FreshestCRL" on page 585.
issuerAltName
OID
Discussion
The Issuer Alternative Name extension allows additional identities to be associated with the issuer of the CRL. For details, see the discussion under certificate extensions at issuerAltName.
CS Version Support
Supported since CS 4.2. Refer to "IssuerAlternativeName" on page 587.
issuingDistributionPoint
OID
Criticality
PKIX requires that this extension be critical if it exists.
Discussion
The Issuing Distribution Point CRL extension identifies the CRL distribution point for a particular CRL and indicates what kinds of revocation it covers.
PKIX Part I does not require this extension.
CS Version Support
Supported since CS 4.2. Refer to "IssuingDistributionPoint" on page 589.
CRL Entry Extensions
The sections that follow lists the CRL entry extension types that are defined as part of the Internet X.509 v3 Public Key Infrastructure proposed standard, as of September 1998. All of these extensions are noncritical.
certificateIssuer
OID
Discussion
The Certificate Issuer extension identifies the certificate issuer associated with an entry in an indirect CRL.
This extension is used only with indirect CRLs, which are not supported by CS.
holdInstructionCode
OID
Discussion
The Hold Instruction Code extension indicates the action to be taken after encountering a certificate that has been placed on hold.
CS Version Support
Supported since CS 4.2. Refer to "HoldInstruction" on page 586.
invalidityDate
OID
Discussion
The Invalidity Date extension provides the date on which the private key was compromised or that the certificate otherwise became invalid.
CS Version Support
Supported since CS 4.2. Refer to "InvalidityDate" on page 587.
reasonCode
OID
Discussion
The Reason Code extension identifies the reason for certificate revocation.
CS Version Support
Supported since CS 4.2. Refer to "CRLReason" on page 584.
Netscape-Defined Certificate Extensions
Netscape defined certain certificate extensions for use with Navigator and Communicator. Some of the extensions that have been defined are now obsolete, and others can be superseded by the extensions defined in the X.509 proposed standard. All Red Hat extensions should be tagged as noncritical, so that their presence in a certificate does not make that certificate incompatible with other clients.
The specifications for all Netscape-defined extensions are defined at http://home.netscape.com/eng/security/comm4-cert-exts.html. For most CS deployments, only netscape-cert-type and netscape-comment need to be supported to maintain compatibility with Navigator 3.x. Therefore, only these two Red Hat certificate extensions are described here.
netscape-cert-type
OID
Discussion
The Netscape Certificate Type extension can be used to limit the purposes for which a certificate can be used. It has been replaced by the X.509 v3 extensions extKeyUsage and basicConstraints, but must still be supported in deployments that include Navigator 3.x clients.
If the extension exists in a certificate, it limits the certificate to the uses specified in it. If the extension is not present, the certificate can be used for all applications except object signing.
The value is a bit-string, where the individual bit positions, when set, certify the certificate for particular uses as follows:
- bit 0: SSL Client certificate
- bit 1: SSL Server certificate
- bit 2: S/MIME certificate
- bit 3: Object-signing certificate
- bit 4: Reserved for future use
- bit 5: SSL CA certificate
- bit 6: S/MIME CA certificate
- bit 7: Object-signing CA certificate
CS Version Support
Supported since CS 4.1. Refer to "NSCertTypeExt" on page 527.
netscape-comment
OID
Discussion
The value of this extension is an IA5String. It is a comment that can be displayed to the user when the certificate is viewed.
CS Version Support
Supported since CS 4.2. Refer to "NSCCommentExt" on page 526.
CA Certificates and Extension Interactions
Red Hat recommends that all CA certificates contain the basicConstraints extension, as this is the standard way to identify a CA certificate. In addition, to ensure support for Navigator 3.x, CAs should also use redhat-cert-type. These two extensions can interact with each other. The following table describes what different combinations of the two extensions mean.
A certificate chain generally consists of an entity certificate, zero or more intermediate CA certificates, and a root CA certificate. Typically the root CA certificate is self-signed and is loaded into Communicator's certificate database as a trusted CA.
An exchange of certificates takes place when performing an SSL handshake, when sending an S/MIME message, or when sending a signed object. As part of the handshake, the sender is expected to send the subject certificate and any intermediate CA certificates needed to link the subject certificate to the trusted root. For certificate chaining to work properly the certificates should have the following properties:
- CA certificates must have either the basicConstraints extension, the netscape-cert-type extension with one or more CA bits set, or both, as described above.
- If CAs issue multiple certificates for the same identity, for example for separate signing and encryption keys, they must include the keyUsage extension in the subject certificates.
- If CAs ever intend to generate new keys for their CA, they must add the authorityKeyIdentifier extension to all subject certificates. If the key ID is anything other than the SHA-1 hash of the CA certificates subjectPublicKeyInfo field, then the CA certificate should contain the subjectKeyIdentifier extension. This will allow for a smooth transition when the new issuing certificate becomes active.
| Previous |
Contents |
Index |
Next |