Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5280

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Pages: 151
Proposed Standard
Errata
Obsoletes:  328043254630
Updated by:  681883988399
Part 3 of 7 – Pages 43 to 71
First   Prev   Next

Top   ToC   RFC5280 - Page 43   prevText
4.2.1.11. Policy Constraints
The policy constraints extension can be used in certificates issued to CAs. The policy constraints extension constrains path validation in two ways. It can be used to prohibit policy mapping or require that each certificate in a path contain an acceptable policy identifier. If the inhibitPolicyMapping field is present, the value indicates the number of additional certificates that may appear in the path before policy mapping is no longer permitted. For example, a value of one indicates that policy mapping may be processed in certificates issued by the subject of this certificate, but not in additional certificates in the path. If the requireExplicitPolicy field is present, the value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path before an explicit policy is required for the entire path. When an explicit policy is required, it is necessary for all certificates in the path to contain an acceptable policy identifier in the certificate policies extension. An acceptable policy identifier is the identifier of a policy required by the user of the certification path or the identifier of a policy that has been declared equivalent through policy mapping. Conforming applications MUST be able to process the requireExplicitPolicy field and SHOULD be able to process the inhibitPolicyMapping field. Applications that support the inhibitPolicyMapping field MUST also implement support for the policyMappings extension. If the policyConstraints extension is marked as critical and the inhibitPolicyMapping field is present, applications that do not implement support for the inhibitPolicyMapping field MUST reject the certificate. Conforming CAs MUST NOT issue certificates where policy constraints is an empty sequence. That is, either the inhibitPolicyMapping field or the requireExplicitPolicy field MUST be present. The behavior of clients that encounter an empty policy constraints field is not addressed in this profile. Conforming CAs MUST mark this extension as critical.
Top   ToC   RFC5280 - Page 44
   id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }

   PolicyConstraints ::= SEQUENCE {
        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

   SkipCerts ::= INTEGER (0..MAX)

4.2.1.12. Extended Key Usage
This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates. This extension is defined as follows: id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER Key purposes may be defined by any organization with a need. Object identifiers used to identify key purposes MUST be assigned in accordance with IANA or ITU-T Recommendation X.660 [X.660]. This extension MAY, at the option of the certificate issuer, be either critical or non-critical. If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application. If a CA includes extended key usages to satisfy such applications, but does not wish to restrict usages of the key, the CA can include the special KeyPurposeId anyExtendedKeyUsage in addition to the particular key purposes required by the applications. Conforming CAs SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage KeyPurposeId is present. Applications that require the presence of a particular purpose MAY reject certificates that include the anyExtendedKeyUsage OID but not the particular OID expected for the application.
Top   ToC   RFC5280 - Page 45
   If a certificate contains both a key usage extension and an extended
   key usage extension, then both extensions MUST be processed
   independently and the certificate MUST only be used for a purpose
   consistent with both extensions.  If there is no purpose consistent
   with both extensions, then the certificate MUST NOT be used for any
   purpose.

   The following key usage purposes are defined:

   anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }

   id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
   -- TLS WWW client authentication
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or keyAgreement

   id-kp-codeSigning             OBJECT IDENTIFIER ::= { id-kp 3 }
   -- Signing of downloadable executable code
   -- Key usage bits that may be consistent: digitalSignature

   id-kp-emailProtection         OBJECT IDENTIFIER ::= { id-kp 4 }
   -- Email protection
   -- Key usage bits that may be consistent: digitalSignature,
   -- nonRepudiation, and/or (keyEncipherment or keyAgreement)

   id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
   -- Binding the hash of an object to a time
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or nonRepudiation

   id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
   -- Signing OCSP responses
   -- Key usage bits that may be consistent: digitalSignature
   -- and/or nonRepudiation

4.2.1.13. CRL Distribution Points
The CRL distribution points extension identifies how CRL information is obtained. The extension SHOULD be non-critical, but this profile RECOMMENDS support for this extension by CAs and applications. Further discussion of CRL management is contained in Section 5.
Top   ToC   RFC5280 - Page 46
   The cRLDistributionPoints extension is a SEQUENCE of
   DistributionPoint.  A DistributionPoint consists of three fields,
   each of which is optional: distributionPoint, reasons, and cRLIssuer.
   While each of these fields is optional, a DistributionPoint MUST NOT
   consist of only the reasons field; either distributionPoint or
   cRLIssuer MUST be present.  If the certificate issuer is not the CRL
   issuer, then the cRLIssuer field MUST be present and contain the Name
   of the CRL issuer.  If the certificate issuer is also the CRL issuer,
   then conforming CAs MUST omit the cRLIssuer field and MUST include
   the distributionPoint field.

   When the distributionPoint field is present, it contains either a
   SEQUENCE of general names or a single value, nameRelativeToCRLIssuer.
   If the DistributionPointName contains multiple values, each name
   describes a different mechanism to obtain the same CRL.  For example,
   the same CRL could be available for retrieval through both LDAP and
   HTTP.

   If the distributionPoint field contains a directoryName, the entry
   for that directoryName contains the current CRL for the associated
   reasons and the CRL is issued by the associated cRLIssuer.  The CRL
   may be stored in either the certificateRevocationList or
   authorityRevocationList attribute.  The CRL is to be obtained by the
   application from whatever directory server is locally configured.
   The protocol the application uses to access the directory (e.g., DAP
   or LDAP) is a local matter.

   If the DistributionPointName contains a general name of type URI, the
   following semantics MUST be assumed: the URI is a pointer to the
   current CRL for the associated reasons and will be issued by the
   associated cRLIssuer.  When the HTTP or FTP URI scheme is used, the
   URI MUST point to a single DER encoded CRL as specified in
   [RFC2585].  HTTP server implementations accessed via the URI SHOULD
   specify the media type application/pkix-crl in the content-type
   header field of the response.  When the LDAP URI scheme [RFC4516] is
   used, the URI MUST include a <dn> field containing the distinguished
   name of the entry holding the CRL, MUST include a single <attrdesc>
   that contains an appropriate attribute description for the attribute
   that holds the CRL [RFC4523], and SHOULD include a <host>
   (e.g., <ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?
   certificateRevocationList;binary>).  Omitting the <host> (e.g.,
   <ldap:///cn=CA,dc=example,dc=com?authorityRevocationList;binary>) has
   the effect of relying on whatever a priori knowledge the client might
   have to contact an appropriate server.  When present,
   DistributionPointName SHOULD include at least one LDAP or HTTP URI.

   If the DistributionPointName contains the single value
   nameRelativeToCRLIssuer, the value provides a distinguished name
Top   ToC   RFC5280 - Page 47
   fragment.  The fragment is appended to the X.500 distinguished name
   of the CRL issuer to obtain the distribution point name.  If the
   cRLIssuer field in the DistributionPoint is present, then the name
   fragment is appended to the distinguished name that it contains;
   otherwise, the name fragment is appended to the certificate issuer
   distinguished name.  Conforming CAs SHOULD NOT use
   nameRelativeToCRLIssuer to specify distribution point names.  The
   DistributionPointName MUST NOT use the nameRelativeToCRLIssuer
   alternative when cRLIssuer contains more than one distinguished name.

   If the DistributionPoint omits the reasons field, the CRL MUST
   include revocation information for all reasons.  This profile
   RECOMMENDS against segmenting CRLs by reason code.  When a conforming
   CA includes a cRLDistributionPoints extension in a certificate, it
   MUST include at least one DistributionPoint that points to a CRL that
   covers the certificate for all reasons.

   The cRLIssuer identifies the entity that signs and issues the CRL.
   If present, the cRLIssuer MUST only contain the distinguished name
   (DN) from the issuer field of the CRL to which the DistributionPoint
   is pointing.  The encoding of the name in the cRLIssuer field MUST be
   exactly the same as the encoding in issuer field of the CRL.  If the
   cRLIssuer field is included and the DN in that field does not
   correspond to an X.500 or LDAP directory entry where CRL is located,
   then conforming CAs MUST include the distributionPoint field.

   id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::=  { id-ce 31 }

   CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

   DistributionPoint ::= SEQUENCE {
        distributionPoint       [0]     DistributionPointName OPTIONAL,
        reasons                 [1]     ReasonFlags OPTIONAL,
        cRLIssuer               [2]     GeneralNames OPTIONAL }

   DistributionPointName ::= CHOICE {
        fullName                [0]     GeneralNames,
        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
Top   ToC   RFC5280 - Page 48
   ReasonFlags ::= BIT STRING {
        unused                  (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
        privilegeWithdrawn      (7),
        aACompromise            (8) }

4.2.1.14. Inhibit anyPolicy
The inhibit anyPolicy extension can be used in certificates issued to CAs. The inhibit anyPolicy extension indicates that the special anyPolicy OID, with the value { 2 5 29 32 0 }, is not considered an explicit match for other certificate policies except when it appears in an intermediate self-issued CA certificate. The value indicates the number of additional non-self-issued certificates that may appear in the path before anyPolicy is no longer permitted. For example, a value of one indicates that anyPolicy may be processed in certificates issued by the subject of this certificate, but not in additional certificates in the path. Conforming CAs MUST mark this extension as critical. id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } InhibitAnyPolicy ::= SkipCerts SkipCerts ::= INTEGER (0..MAX)
4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point)
The freshest CRL extension identifies how delta CRL information is obtained. The extension MUST be marked as non-critical by conforming CAs. Further discussion of CRL management is contained in Section 5. The same syntax is used for this extension and the cRLDistributionPoints extension, and is described in Section 4.2.1.13. The same conventions apply to both extensions. id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } FreshestCRL ::= CRLDistributionPoints
Top   ToC   RFC5280 - Page 49

4.2.2. Private Internet Extensions

This section defines two extensions for use in the Internet Public Key Infrastructure. These extensions may be used to direct applications to on-line information about the issuer or the subject. Each extension contains a sequence of access methods and access locations. The access method is an object identifier that indicates the type of information that is available. The access location is a GeneralName that implicitly specifies the location and format of the information and the method for obtaining the information. Object identifiers are defined for the private extensions. The object identifiers associated with the private extensions are defined under the arc id-pe within the arc id-pkix. Any future extensions defined for the Internet PKI are also expected to be defined under the arc id-pe. id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
4.2.2.1. Authority Information Access
The authority information access extension indicates how to access information and services for the issuer of the certificate in which the extension appears. Information and services may include on-line validation services and CA policy data. (The location of CRLs is not specified in this extension; that information is provided by the cRLDistributionPoints extension.) This extension may be included in end entity or CA certificates. Conforming CAs MUST mark this extension as non-critical. id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } AuthorityInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF AccessDescription AccessDescription ::= SEQUENCE { accessMethod OBJECT IDENTIFIER, accessLocation GeneralName } id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
Top   ToC   RFC5280 - Page 50
   Each entry in the sequence AuthorityInfoAccessSyntax describes the
   format and location of additional information provided by the issuer
   of the certificate in which this extension appears.  The type and
   format of the information are specified by the accessMethod field;
   the accessLocation field specifies the location of the information.
   The retrieval mechanism may be implied by the accessMethod or
   specified by accessLocation.

   This profile defines two accessMethod OIDs: id-ad-caIssuers and
   id-ad-ocsp.

   In a public key certificate, the id-ad-caIssuers OID is used when the
   additional information lists certificates that were issued to the CA
   that issued the certificate containing this extension.  The
   referenced CA issuers description is intended to aid certificate
   users in the selection of a certification path that terminates at a
   point trusted by the certificate user.

   When id-ad-caIssuers appears as accessMethod, the accessLocation
   field describes the referenced description server and the access
   protocol to obtain the referenced description.  The accessLocation
   field is defined as a GeneralName, which can take several forms.

   When the accessLocation is a directoryName, the information is to be
   obtained by the application from whatever directory server is locally
   configured.  The entry for the directoryName contains CA certificates
   in the crossCertificatePair and/or cACertificate attributes as
   specified in [RFC4523].  The protocol that application uses to access
   the directory (e.g., DAP or LDAP) is a local matter.

   Where the information is available via LDAP, the accessLocation
   SHOULD be a uniformResourceIdentifier.  The LDAP URI [RFC4516] MUST
   include a <dn> field containing the distinguished name of the entry
   holding the certificates, MUST include an <attributes> field that
   lists appropriate attribute descriptions for the attributes that hold
   the DER encoded certificates or cross-certificate pairs [RFC4523],
   and SHOULD include a <host> (e.g., <ldap://ldap.example.com/cn=CA,
   dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>).
   Omitting the <host> (e.g., <ldap:///cn=exampleCA,dc=example,dc=com?
   cACertificate;binary>) has the effect of relying on whatever a priori
   knowledge the client might have to contact an appropriate server.

   Where the information is available via HTTP or FTP, accessLocation
   MUST be a uniformResourceIdentifier and the URI MUST point to either
   a single DER encoded certificate as specified in [RFC2585] or a
   collection of certificates in a BER or DER encoded "certs-only" CMS
   message as specified in [RFC2797].
Top   ToC   RFC5280 - Page 51
   Conforming applications that support HTTP or FTP for accessing
   certificates MUST be able to accept individual DER encoded
   certificates and SHOULD be able to accept "certs-only" CMS messages.

   HTTP server implementations accessed via the URI SHOULD specify the
   media type application/pkix-cert [RFC2585] in the content-type header
   field of the response for a single DER encoded certificate and SHOULD
   specify the media type application/pkcs7-mime [RFC2797] in the
   content-type header field of the response for "certs-only" CMS
   messages.  For FTP, the name of a file that contains a single DER
   encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the
   name of a file that contains a "certs-only" CMS message SHOULD have a
   suffix of ".p7c" [RFC2797].  Consuming clients may use the media type
   or file extension as a hint to the content, but should not depend
   solely on the presence of the correct media type or file extension in
   the server response.

   The semantics of other id-ad-caIssuers accessLocation name forms are
   not defined.

   An authorityInfoAccess extension may include multiple instances of
   the id-ad-caIssuers accessMethod.  The different instances may
   specify different methods for accessing the same information or may
   point to different information.  When the id-ad-caIssuers
   accessMethod is used, at least one instance SHOULD specify an
   accessLocation that is an HTTP [RFC2616] or LDAP [RFC4516] URI.

   The id-ad-ocsp OID is used when revocation information for the
   certificate containing this extension is available using the Online
   Certificate Status Protocol (OCSP) [RFC2560].

   When id-ad-ocsp appears as accessMethod, the accessLocation field is
   the location of the OCSP responder, using the conventions defined in
   [RFC2560].

   Additional access descriptors may be defined in other PKIX
   specifications.

4.2.2.2. Subject Information Access
The subject information access extension indicates how to access information and services for the subject of the certificate in which the extension appears. When the subject is a CA, information and services may include certificate validation services and CA policy data. When the subject is an end entity, the information describes the type of services offered and how to access them. In this case, the contents of this extension are defined in the protocol
Top   ToC   RFC5280 - Page 52
   specifications for the supported services.  This extension may be
   included in end entity or CA certificates.  Conforming CAs MUST mark
   this extension as non-critical.

   id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }

   SubjectInfoAccessSyntax  ::=
           SEQUENCE SIZE (1..MAX) OF AccessDescription

   AccessDescription  ::=  SEQUENCE {
           accessMethod          OBJECT IDENTIFIER,
           accessLocation        GeneralName  }

   Each entry in the sequence SubjectInfoAccessSyntax describes the
   format and location of additional information provided by the subject
   of the certificate in which this extension appears.  The type and
   format of the information are specified by the accessMethod field;
   the accessLocation field specifies the location of the information.
   The retrieval mechanism may be implied by the accessMethod or
   specified by accessLocation.

   This profile defines one access method to be used when the subject is
   a CA and one access method to be used when the subject is an end
   entity.  Additional access methods may be defined in the future in
   the protocol specifications for other services.

   The id-ad-caRepository OID is used when the subject is a CA that
   publishes certificates it issues in a repository.  The accessLocation
   field is defined as a GeneralName, which can take several forms.

   When the accessLocation is a directoryName, the information is to be
   obtained by the application from whatever directory server is locally
   configured.  When the extension is used to point to CA certificates,
   the entry for the directoryName contains CA certificates in the
   crossCertificatePair and/or cACertificate attributes as specified in
   [RFC4523].  The protocol the application uses to access the directory
   (e.g., DAP or LDAP) is a local matter.

   Where the information is available via LDAP, the accessLocation
   SHOULD be a uniformResourceIdentifier.  The LDAP URI [RFC4516] MUST
   include a <dn> field containing the distinguished name of the entry
   holding the certificates, MUST include an <attributes> field that
   lists appropriate attribute descriptions for the attributes that hold
   the DER encoded certificates or cross-certificate pairs [RFC4523],
   and SHOULD include a <host> (e.g., <ldap://ldap.example.com/cn=CA,
   dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>).
Top   ToC   RFC5280 - Page 53
   Omitting the <host> (e.g., <ldap:///cn=exampleCA,dc=example,dc=com?
   cACertificate;binary>) has the effect of relying on whatever a priori
   knowledge the client might have to contact an appropriate server.

   Where the information is available via HTTP or FTP, accessLocation
   MUST be a uniformResourceIdentifier and the URI MUST point to either
   a single DER encoded certificate as specified in [RFC2585] or a
   collection of certificates in a BER or DER encoded "certs-only" CMS
   message as specified in [RFC2797].

   Conforming applications that support HTTP or FTP for accessing
   certificates MUST be able to accept individual DER encoded
   certificates and SHOULD be able to accept "certs-only" CMS messages.

   HTTP server implementations accessed via the URI SHOULD specify the
   media type application/pkix-cert [RFC2585] in the content-type header
   field of the response for a single DER encoded certificate and SHOULD
   specify the media type application/pkcs7-mime [RFC2797] in the
   content-type header field of the response for "certs-only" CMS
   messages.  For FTP, the name of a file that contains a single DER
   encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the
   name of a file that contains a "certs-only" CMS message SHOULD have a
   suffix of ".p7c" [RFC2797].  Consuming clients may use the media type
   or file extension as a hint to the content, but should not depend
   solely on the presence of the correct media type or file extension in
   the server response.

   The semantics of other id-ad-caRepository accessLocation name forms
   are not defined.

   A subjectInfoAccess extension may include multiple instances of the
   id-ad-caRepository accessMethod.  The different instances may specify
   different methods for accessing the same information or may point to
   different information.  When the id-ad-caRepository accessMethod is
   used, at least one instance SHOULD specify an accessLocation that is
   an HTTP [RFC2616] or LDAP [RFC4516] URI.

   The id-ad-timeStamping OID is used when the subject offers
   timestamping services using the Time Stamp Protocol defined in
   [RFC3161].  Where the timestamping services are available via HTTP or
   FTP, accessLocation MUST be a uniformResourceIdentifier.  Where the
   timestamping services are available via electronic mail,
   accessLocation MUST be an rfc822Name.  Where timestamping services
   are available using TCP/IP, the dNSName or iPAddress name forms may
   be used.  The semantics of other name forms of accessLocation (when
   accessMethod is id-ad-timeStamping) are not defined by this
   specification.
Top   ToC   RFC5280 - Page 54
   Additional access descriptors may be defined in other PKIX
   specifications.

   id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

   id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }

   id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }

5. CRL and CRL Extensions Profile

As discussed above, one goal of this X.509 v2 CRL profile is to foster the creation of an interoperable and reusable Internet PKI. To achieve this goal, guidelines for the use of extensions are specified, and some assumptions are made about the nature of information included in the CRL. CRLs may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and an even broader spectrum of operational and assurance requirements. This profile establishes a common baseline for generic applications requiring broad interoperability. The profile defines a set of information that can be expected in every CRL. Also, the profile defines common locations within the CRL for frequently used attributes as well as common representations for these attributes. CRL issuers issue CRLs. The CRL issuer is either the CA or an entity that has been authorized by the CA to issue CRLs. CAs publish CRLs to provide status information about the certificates they issued. However, a CA may delegate this responsibility to another trusted authority. Each CRL has a particular scope. The CRL scope is the set of certificates that could appear on a given CRL. For example, the scope could be "all certificates issued by CA X", "all CA certificates issued by CA X", "all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise", or a set of certificates based on arbitrary local information, such as "all certificates issued to the NIST employees located in Boulder". A complete CRL lists all unexpired certificates, within its scope, that have been revoked for one of the revocation reasons covered by the CRL scope. A full and complete CRL lists all unexpired certificates issued by a CA that have been revoked for any reason. (Note that since CAs and CRL issuers are identified by name, the scope of a CRL is not affected by the key used to sign the CRL or the key(s) used to sign certificates.)
Top   ToC   RFC5280 - Page 55
   If the scope of the CRL includes one or more certificates issued by
   an entity other than the CRL issuer, then it is an indirect CRL.  The
   scope of an indirect CRL may be limited to certificates issued by a
   single CA or may include certificates issued by multiple CAs.  If the
   issuer of the indirect CRL is a CA, then the scope of the indirect
   CRL MAY also include certificates issued by the issuer of the CRL.

   The CRL issuer MAY also generate delta CRLs.  A delta CRL only lists
   those certificates, within its scope, whose revocation status has
   changed since the issuance of a referenced complete CRL.  The
   referenced complete CRL is referred to as a base CRL.  The scope of a
   delta CRL MUST be the same as the base CRL that it references.

   This profile defines one private Internet CRL extension but does not
   define any private CRL entry extensions.

   Environments with additional or special purpose requirements may
   build on this profile or may replace it.

   Conforming CAs are not required to issue CRLs if other revocation or
   certificate status mechanisms are provided.  When CRLs are issued,
   the CRLs MUST be version 2 CRLs, include the date by which the next
   CRL will be issued in the nextUpdate field (Section 5.1.2.5), include
   the CRL number extension (Section 5.2.3), and include the authority
   key identifier extension (Section 5.2.1).  Conforming applications
   that support CRLs are REQUIRED to process both version 1 and version
   2 complete CRLs that provide revocation information for all
   certificates issued by one CA.  Conforming applications are not
   required to support processing of delta CRLs, indirect CRLs, or CRLs
   with a scope other than all certificates issued by one CA.

5.1. CRL Fields

The X.509 v2 CRL syntax is as follows. For signature calculation, the data that is to be signed is ASN.1 DER encoded. ASN.1 DER encoding is a tag, length, value encoding system for each element.
Top   ToC   RFC5280 - Page 56
   CertificateList  ::=  SEQUENCE  {
        tbsCertList          TBSCertList,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, MUST be v2
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time OPTIONAL,
        revokedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             revocationDate          Time,
             crlEntryExtensions      Extensions OPTIONAL
                                      -- if present, version MUST be v2
                                  }  OPTIONAL,
        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
                                      -- if present, version MUST be v2
                                  }

   -- Version, Time, CertificateSerialNumber, and Extensions
   -- are all defined in the ASN.1 in Section 4.1

   -- AlgorithmIdentifier is defined in Section 4.1.1.2

   The following items describe the use of the X.509 v2 CRL in the
   Internet PKI.

5.1.1. CertificateList Fields

The CertificateList is a SEQUENCE of three required fields. The fields are described in detail in the following subsections.
5.1.1.1. tbsCertList
The first field in the sequence is the tbsCertList. This field is itself a sequence containing the name of the issuer, issue date, issue date of the next list, the optional list of revoked certificates, and optional CRL extensions. When there are no revoked certificates, the revoked certificates list is absent. When one or more certificates are revoked, each entry on the revoked certificate list is defined by a sequence of user certificate serial number, revocation date, and optional CRL entry extensions.
Top   ToC   RFC5280 - Page 57
5.1.1.2. signatureAlgorithm
The signatureAlgorithm field contains the algorithm identifier for the algorithm used by the CRL issuer to sign the CertificateList. The field is of type AlgorithmIdentifier, which is defined in Section 4.1.1.2. [RFC3279], [RFC4055], and [RFC4491] list supported algorithms for this specification, but other signature algorithms MAY also be supported. This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertList (Section 5.1.2.2).
5.1.1.3. signatureValue
The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the CRL signatureValue field. The details of this process are specified for each of the supported algorithms in [RFC3279], [RFC4055], and [RFC4491]. CAs that are also CRL issuers MAY use one private key to digitally sign certificates and CRLs, or MAY use separate private keys to digitally sign certificates and CRLs. When separate private keys are employed, each of the public keys associated with these private keys is placed in a separate certificate, one with the keyCertSign bit set in the key usage extension, and one with the cRLSign bit set in the key usage extension (Section 4.2.1.3). When separate private keys are employed, certificates issued by the CA contain one authority key identifier, and the corresponding CRLs contain a different authority key identifier. The use of separate CA certificates for validation of certificate signatures and CRL signatures can offer improved security characteristics; however, it imposes a burden on applications, and it might limit interoperability. Many applications construct a certification path, and then validate the certification path (Section 6). CRL checking in turn requires a separate certification path to be constructed and validated for the CA's CRL signature validation certificate. Applications that perform CRL checking MUST support certification path validation when certificates and CRLs are digitally signed with the same CA private key. These applications SHOULD support certification path validation when certificates and CRLs are digitally signed with different CA private keys.
Top   ToC   RFC5280 - Page 58

5.1.2. Certificate List "To Be Signed"

The certificate list to be signed, or TBSCertList, is a sequence of required and optional fields. The required fields identify the CRL issuer, the algorithm used to sign the CRL, and the date and time the CRL was issued. Optional fields include the date and time by which the CRL issuer will issue the next CRL, 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 profile requires conforming CRL issuers to include the nextUpdate field and the CRL number and authority key identifier CRL extensions in all CRLs issued.
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).
5.1.2.2. Signature
This field contains the algorithm identifier for the algorithm used to sign the CRL. [RFC3279], [RFC4055], and [RFC4491] list OIDs for the most popular signature algorithms used in the Internet PKI. This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence CertificateList (Section 5.1.1.2).
5.1.2.3. Issuer Name
The issuer name identifies the entity that has signed and issued the CRL. The issuer identity is carried in the issuer field. Alternative name forms may also appear in the issuerAltName extension (Section 5.2.2). The issuer field MUST contain a non-empty X.500 distinguished name (DN). The issuer field is defined as the X.501 type Name, and MUST follow the encoding rules for the issuer name field in the certificate (Section 4.1.2.4).
5.1.2.4. This Update
This field indicates the issue date of this CRL. thisUpdate may be encoded as UTCTime or GeneralizedTime. CRL issuers conforming to this profile MUST encode thisUpdate as UTCTime for dates through the year 2049. CRL issuers conforming to
Top   ToC   RFC5280 - Page 59
   this profile MUST encode thisUpdate as GeneralizedTime for dates in
   the year 2050 or later.  Conforming applications MUST be able to
   process dates that are encoded in either UTCTime or GeneralizedTime.

   Where encoded as UTCTime, thisUpdate MUST be specified and
   interpreted as defined in Section 4.1.2.5.1.  Where encoded as
   GeneralizedTime, thisUpdate MUST be specified and interpreted as
   defined in Section 4.1.2.5.2.

5.1.2.5. Next Update
This field indicates the date by which the next CRL will be issued. The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date. CRL issuers SHOULD issue CRLs with a nextUpdate time equal to or later than all previous CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. Conforming CRL issuers MUST include the nextUpdate field in all CRLs. Note that the ASN.1 syntax of TBSCertList describes this field as OPTIONAL, which is consistent with the ASN.1 structure defined in [X.509]. The behavior of clients processing CRLs that omit nextUpdate is not specified by this profile. CRL issuers conforming to this profile MUST encode nextUpdate as UTCTime for dates through the year 2049. CRL issuers conforming to this profile MUST encode nextUpdate as GeneralizedTime for dates in the year 2050 or later. Conforming applications MUST be able to process dates that are encoded in either UTCTime or GeneralizedTime. Where encoded as UTCTime, nextUpdate MUST be specified and interpreted as defined in Section 4.1.2.5.1. Where encoded as GeneralizedTime, nextUpdate MUST be specified and interpreted as defined in Section 4.1.2.5.2.
5.1.2.6. Revoked Certificates
When there are no revoked certificates, the revoked certificates list MUST be absent. Otherwise, revoked certificates are listed by their serial numbers. Certificates revoked by the CA are uniquely identified by the certificate serial number. The date on which the revocation occurred is specified. The time for revocationDate MUST be expressed as described in Section 5.1.2.4. Additional information may be supplied in CRL entry extensions; CRL entry extensions are discussed in Section 5.3.
Top   ToC   RFC5280 - Page 60
5.1.2.7. Extensions
This field may only appear if the version is 2 (Section 5.1.2.1). If present, this field is a sequence of one or more CRL extensions. CRL extensions are discussed in Section 5.2.

5.2. CRL Extensions

The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2 CRLs [X.509] [X9.55] provide methods for associating additional attributes with CRLs. The X.509 v2 CRL format also allows communities to define private extensions to carry information unique to those communities. Each extension in a CRL may be designated as critical or non-critical. If a CRL contains a critical extension that the application cannot process, then the application MUST NOT use that CRL to determine the status of certificates. However, applications may ignore unrecognized non-critical extensions. The following subsections present those extensions used within Internet CRLs. Communities may elect to include extensions in CRLs that are not defined in this specification. However, caution should be exercised in adopting any critical extensions in CRLs that might be used in a general context. Conforming CRL issuers are REQUIRED to include the authority key identifier (Section 5.2.1) and the CRL number (Section 5.2.3) extensions in all CRLs issued.

5.2.1. Authority Key Identifier

The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign a CRL. The identification can be based on either the key identifier (the subject key identifier in the CRL signer's certificate) or the issuer name and serial number. This extension is especially useful where an issuer has more than one signing key, either due to multiple concurrent key pairs or due to changeover. Conforming CRL issuers MUST use the key identifier method, and MUST include this extension in all CRLs issued. The syntax for this CRL extension is defined in Section 4.2.1.1.

5.2.2. Issuer Alternative Name

The issuer alternative name extension allows additional identities to be associated with the issuer of the CRL. Defined options include an electronic mail address (rfc822Name), a DNS name, an IP address, and a URI. Multiple instances of a name form and multiple name forms may
Top   ToC   RFC5280 - Page 61
   be included.  Whenever such identities are used, the issuer
   alternative name extension MUST be used; however, a DNS name MAY be
   represented in the issuer field using the domainComponent attribute
   as described in Section 4.1.2.4.

   Conforming CRL issuers SHOULD mark the issuerAltName extension as
   non-critical.

   The OID and syntax for this CRL extension are defined in Section
   4.2.1.7.

5.2.3. CRL Number

The CRL number is a non-critical CRL extension that conveys a monotonically increasing sequence number for a given CRL scope and CRL issuer. This extension allows users to easily determine when a particular CRL supersedes another CRL. CRL numbers also support the identification of complementary complete CRLs and delta CRLs. CRL issuers conforming to this profile MUST include this extension in all CRLs and MUST mark this extension as non-critical. If a CRL issuer generates delta CRLs in addition to complete CRLs for a given scope, the complete CRLs and delta CRLs MUST share one numbering sequence. If a delta CRL and a complete CRL that cover the same scope are issued at the same time, they MUST have the same CRL number and provide the same revocation information. That is, the combination of the delta CRL and an acceptable complete CRL MUST provide the same revocation information as the simultaneously issued complete CRL. If a CRL issuer generates two CRLs (two complete CRLs, two delta CRLs, or a complete CRL and a delta CRL) for the same scope at different times, the two CRLs MUST NOT have the same CRL number. That is, if the this update field (Section 5.1.2.4) in the two CRLs are not identical, the CRL numbers MUST be different. Given the requirements above, CRL numbers can be expected to contain long integers. CRL verifiers MUST be able to handle CRLNumber values up to 20 octets. Conforming CRL issuers MUST NOT use CRLNumber values longer than 20 octets. id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } CRLNumber ::= INTEGER (0..MAX)
Top   ToC   RFC5280 - Page 62

5.2.4. Delta CRL Indicator

The delta CRL indicator is a critical CRL extension that identifies a CRL as being a delta CRL. Delta CRLs contain updates to revocation information previously distributed, rather than all the information that would appear in a complete CRL. The use of delta CRLs can significantly reduce network load and processing time in some environments. Delta CRLs are generally smaller than the CRLs they update, so applications that obtain delta CRLs consume less network bandwidth than applications that obtain the corresponding complete CRLs. Applications that store revocation information in a format other than the CRL structure can add new revocation information to the local database without reprocessing information. The delta CRL indicator extension contains the single value of type BaseCRLNumber. The CRL number identifies the CRL, complete for a given scope, that was used as the starting point in the generation of this delta CRL. A conforming CRL issuer MUST publish the referenced base CRL as a complete CRL. The delta CRL contains all updates to the revocation status for that same scope. The combination of a delta CRL plus the referenced base CRL is equivalent to a complete CRL, for the applicable scope, at the time of publication of the delta CRL. When a conforming CRL issuer generates a delta CRL, the delta CRL MUST include a critical delta CRL indicator extension. When a delta CRL is issued, it MUST cover the same set of reasons and the same set of certificates that were covered by the base CRL it references. That is, the scope of the delta CRL MUST be the same as the scope of the complete CRL referenced as the base. The referenced base CRL and the delta CRL MUST omit the issuing distribution point extension or contain identical issuing distribution point extensions. Further, the CRL issuer MUST use the same private key to sign the delta CRL and any complete CRL that it can be used to update. An application that supports delta CRLs can construct a CRL that is complete for a given scope by combining a delta CRL for that scope with either an issued CRL that is complete for that scope or a locally constructed CRL that is complete for that scope. When a delta CRL is combined with a complete CRL or a locally constructed CRL, the resulting locally constructed CRL has the CRL number specified in the CRL number extension found in the delta CRL used in its construction. In addition, the resulting locally constructed CRL has the thisUpdate and nextUpdate times specified in
Top   ToC   RFC5280 - Page 63
   the corresponding fields of the delta CRL used in its construction.
   In addition, the locally constructed CRL inherits the issuing
   distribution point from the delta CRL.

   A complete CRL and a delta CRL MAY be combined if the following four
   conditions are satisfied:

      (a)  The complete CRL and delta CRL have the same issuer.

      (b)  The complete CRL and delta CRL have the same scope.  The two
           CRLs have the same scope if either of the following
           conditions are met:

         (1)  The issuingDistributionPoint extension is omitted from
              both the complete CRL and the delta CRL.

         (2)  The issuingDistributionPoint extension is present in both
              the complete CRL and the delta CRL, and the values for
              each of the fields in the extensions are the same in both
              CRLs.

      (c)  The CRL number of the complete CRL is equal to or greater
           than the BaseCRLNumber specified in the delta CRL.  That is,
           the complete CRL contains (at a minimum) all the revocation
           information held by the referenced base CRL.

      (d)  The CRL number of the complete CRL is less than the CRL
           number of the delta CRL.  That is, the delta CRL follows the
           complete CRL in the numbering sequence.

   CRL issuers MUST ensure that the combination of a delta CRL and any
   appropriate complete CRL accurately reflects the current revocation
   status.  The CRL issuer MUST include an entry in the delta CRL for
   each certificate within the scope of the delta CRL whose status has
   changed since the generation of the referenced base CRL:

      (a)  If the certificate is revoked for a reason included in the
           scope of the CRL, list the certificate as revoked.

      (b)  If the certificate is valid and was listed on the referenced
           base CRL or any subsequent CRL with reason code
           certificateHold, and the reason code certificateHold is
           included in the scope of the CRL, list the certificate with
           the reason code removeFromCRL.
Top   ToC   RFC5280 - Page 64
      (c)  If the certificate is revoked for a reason outside the scope
           of the CRL, but the certificate was listed on the referenced
           base CRL or any subsequent CRL with a reason code included in
           the scope of this CRL, list the certificate as revoked but
           omit the reason code.

      (d)  If the certificate is revoked for a reason outside the scope
           of the CRL and the certificate was neither listed on the
           referenced base CRL nor any subsequent CRL with a reason code
           included in the scope of this CRL, do not list the
           certificate on this CRL.

   The status of a certificate is considered to have changed if it is
   revoked (for any revocation reason, including certificateHold), if it
   is released from hold, or if its revocation reason changes.

   It is appropriate to list a certificate with reason code
   removeFromCRL on a delta CRL even if the certificate was not on hold
   in the referenced base CRL.  If the certificate was placed on hold in
   any CRL issued after the base but before this delta CRL and then
   released from hold, it MUST be listed on the delta CRL with
   revocation reason removeFromCRL.

   A CRL issuer MAY optionally list a certificate on a delta CRL with
   reason code removeFromCRL if the notAfter time specified in the
   certificate precedes the thisUpdate time specified in the delta CRL
   and the certificate was listed on the referenced base CRL or in any
   CRL issued after the base but before this delta CRL.

   If a certificate revocation notice first appears on a delta CRL, then
   it is possible for the certificate validity period to expire before
   the next complete CRL for the same scope is issued.  In this case,
   the revocation notice MUST be included in all subsequent delta CRLs
   until the revocation notice is included on at least one explicitly
   issued complete CRL for this scope.

   An application that supports delta CRLs MUST be able to construct a
   current complete CRL by combining a previously issued complete CRL
   and the most current delta CRL.  An application that supports delta
   CRLs MAY also be able to construct a current complete CRL by
   combining a previously locally constructed complete CRL and the
   current delta CRL.  A delta CRL is considered to be the current one
   if the current time is between the times contained in the thisUpdate
   and nextUpdate fields.  Under some circumstances, the CRL issuer may
   publish one or more delta CRLs before the time indicated by the
   nextUpdate field.  If more than one current delta CRL for a given
   scope is encountered, the application SHOULD consider the one with
   the latest value in thisUpdate to be the most current one.
Top   ToC   RFC5280 - Page 65
   id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }

   BaseCRLNumber ::= CRLNumber

5.2.5. Issuing Distribution Point

The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions. The CRL is signed using the CRL issuer's private key. CRL distribution points do not have their own key pairs. If the CRL is stored in the X.500 directory, it is stored in the directory entry corresponding to the CRL distribution point, which may be different from the directory entry of the CRL issuer. The reason codes associated with a distribution point MUST be specified in onlySomeReasons. If onlySomeReasons does not appear, the distribution point MUST contain revocations for all reason codes. CAs may use CRL distribution points to partition the CRL on the basis of compromise and routine revocation. In this case, the revocations with reason code keyCompromise (1), cACompromise (2), and aACompromise (8) appear in one distribution point, and the revocations with other reason codes appear in another distribution point. If a CRL includes an issuingDistributionPoint extension with onlySomeReasons present, then every certificate in the scope of the CRL that is revoked MUST be assigned a revocation reason other than unspecified. The assigned revocation reason is used to determine on which CRL(s) to list the revoked certificate, however, there is no requirement to include the reasonCode CRL entry extension in the corresponding CRL entry. The syntax and semantics for the distributionPoint field are the same as for the distributionPoint field in the cRLDistributionPoints extension (Section 4.2.1.13). If the distributionPoint field is present, then it MUST include at least one of names from the corresponding distributionPoint field of the cRLDistributionPoints
Top   ToC   RFC5280 - Page 66
   extension of every certificate that is within the scope of this CRL.
   The identical encoding MUST be used in the distributionPoint fields
   of the certificate and the CRL.

   If the distributionPoint field is absent, the CRL MUST contain
   entries for all revoked unexpired certificates issued by the CRL
   issuer, if any, within the scope of the CRL.

   If the scope of the CRL only includes certificates issued by the CRL
   issuer, then the indirectCRL boolean MUST be set to FALSE.
   Otherwise, if the scope of the CRL includes certificates issued by
   one or more authorities other than the CRL issuer, the indirectCRL
   boolean MUST be set to TRUE.  The authority responsible for each
   entry is indicated by the certificate issuer CRL entry extension
   (Section 5.3.3).

   If the scope of the CRL only includes end entity public key
   certificates, then onlyContainsUserCerts MUST be set to TRUE.  If the
   scope of the CRL only includes CA certificates, then
   onlyContainsCACerts MUST be set to TRUE.  If either
   onlyContainsUserCerts or onlyContainsCACerts is set to TRUE, then the
   scope of the CRL MUST NOT include any version 1 or version 2
   certificates.  Conforming CRLs issuers MUST set the
   onlyContainsAttributeCerts boolean to FALSE.

   Conforming CRLs issuers MUST NOT issue CRLs where the DER encoding of
   the issuing distribution point extension is an empty sequence.  That
   is, if onlyContainsUserCerts, onlyContainsCACerts, indirectCRL, and
   onlyContainsAttributeCerts are all FALSE, then either the
   distributionPoint field or the onlySomeReasons field MUST be present.

   id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }

   IssuingDistributionPoint ::= SEQUENCE {
        distributionPoint          [0] DistributionPointName OPTIONAL,
        onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
        onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
        onlySomeReasons            [3] ReasonFlags OPTIONAL,
        indirectCRL                [4] BOOLEAN DEFAULT FALSE,
        onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }

        -- at most one of onlyContainsUserCerts, onlyContainsCACerts,
        -- and onlyContainsAttributeCerts may be set to TRUE.
Top   ToC   RFC5280 - Page 67

5.2.6. Freshest CRL (a.k.a. Delta CRL Distribution Point)

The freshest CRL extension identifies how delta CRL information for this complete CRL is obtained. Conforming CRL issuers MUST mark this extension as non-critical. This extension MUST NOT appear in delta CRLs. The same syntax is used for this extension as the cRLDistributionPoints certificate extension, and is described in Section 4.2.1.13. However, only the distribution point field is meaningful in this context. The reasons and cRLIssuer fields MUST be omitted from this CRL extension. Each distribution point name provides the location at which a delta CRL for this complete CRL can be found. The scope of these delta CRLs MUST be the same as the scope of this complete CRL. The contents of this CRL extension are only used to locate delta CRLs; the contents are not used to validate the CRL or the referenced delta CRLs. The encoding conventions defined for distribution points in Section 4.2.1.13 apply to this extension. id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } FreshestCRL ::= CRLDistributionPoints

5.2.7. Authority Information Access

This section defines the use of the Authority Information Access extension in a CRL. The syntax and semantics defined in Section 4.2.2.1 for the certificate extension are also used for the CRL extension. This CRL extension MUST be marked as non-critical. When present in a CRL, this extension MUST include at least one AccessDescription specifying id-ad-caIssuers as the accessMethod. The id-ad-caIssuers OID is used when the information available lists certificates that can be used to verify the signature on the CRL (i.e., certificates that have a subject name that matches the issuer name on the CRL and that have a subject public key that corresponds to the private key used to sign the CRL). Access method types other than id-ad-caIssuers MUST NOT be included. At least one instance of AccessDescription SHOULD specify an accessLocation that is an HTTP [RFC2616] or LDAP [RFC4516] URI.
Top   ToC   RFC5280 - Page 68
   Where the information is available via HTTP or FTP, accessLocation
   MUST be a uniformResourceIdentifier and the URI MUST point to either
   a single DER encoded certificate as specified in [RFC2585] or a
   collection of certificates in a BER or DER encoded "certs-only" CMS
   message as specified in [RFC2797].

   Conforming applications that support HTTP or FTP for accessing
   certificates MUST be able to accept individual DER encoded
   certificates and SHOULD be able to accept "certs-only" CMS messages.

   HTTP server implementations accessed via the URI SHOULD specify the
   media type application/pkix-cert [RFC2585] in the content-type header
   field of the response for a single DER encoded certificate and SHOULD
   specify the media type application/pkcs7-mime [RFC2797] in the
   content-type header field of the response for "certs-only" CMS
   messages.  For FTP, the name of a file that contains a single DER
   encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the
   name of a file that contains a "certs-only" CMS message SHOULD have a
   suffix of ".p7c" [RFC2797].  Consuming clients may use the media type
   or file extension as a hint to the content, but should not depend
   solely on the presence of the correct media type or file extension in
   the server response.

   When the accessLocation is a directoryName, the information is to be
   obtained by the application from whatever directory server is locally
   configured.  When one CA public key is used to validate signatures on
   certificates and CRLs, the desired CA certificate is stored in the
   crossCertificatePair and/or cACertificate attributes as specified in
   [RFC4523].  When different public keys are used to validate
   signatures on certificates and CRLs, the desired certificate is
   stored in the userCertificate attribute as specified in [RFC4523].
   Thus, implementations that support the directoryName form of
   accessLocation MUST be prepared to find the needed certificate in any
   of these three attributes.  The protocol that an application uses to
   access the directory (e.g., DAP or LDAP) is a local matter.

   Where the information is available via LDAP, the accessLocation
   SHOULD be a uniformResourceIdentifier.  The LDAP URI [RFC4516] MUST
   include a <dn> field containing the distinguished name of the entry
   holding the certificates, MUST include an <attributes> field that
   lists appropriate attribute descriptions for the attributes that hold
   the DER encoded certificates or cross-certificate pairs [RFC4523],
   and SHOULD include a <host> (e.g., <ldap://ldap.example.com/cn=CA,
   dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>).
   Omitting the <host> (e.g., <ldap:///cn=exampleCA,dc=example,dc=com?
   cACertificate;binary>) has the effect of relying on whatever a priori
   knowledge the client might have to contact an appropriate server.
Top   ToC   RFC5280 - Page 69

5.3. CRL Entry Extensions

The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for X.509 v2 CRLs provide methods for associating additional attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also allows communities to define private CRL entry extensions to carry information unique to those communities. Each extension in a CRL entry may be designated as critical or non-critical. If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL to determine the status of any certificates. However, applications may ignore unrecognized non-critical CRL entry extensions. The following subsections present recommended extensions used within Internet CRL entries and standard locations for information. Communities may elect to use additional CRL entry extensions; however, caution should be exercised in adopting any critical CRL entry extensions in CRLs that might be used in a general context. Support for the CRL entry extensions defined in this specification is optional for conforming CRL issuers and applications. However, CRL issuers SHOULD include reason codes (Section 5.3.1) and invalidity dates (Section 5.3.2) whenever this information is available.

5.3.1. Reason Code

The reasonCode is a non-critical CRL entry extension that identifies the reason for the certificate revocation. CRL issuers are strongly encouraged to include meaningful reason codes in CRL entries; however, the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value. The removeFromCRL (8) reasonCode value may only appear in delta CRLs and indicates that a certificate is to be removed from a CRL because either the certificate expired or was removed from hold. All other reason codes may appear in any CRL and indicate that the specified certificate should be considered revoked.
Top   ToC   RFC5280 - Page 70
   id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }

   -- reasonCode ::= { CRLReason }

   CRLReason ::= ENUMERATED {
        unspecified             (0),
        keyCompromise           (1),
        cACompromise            (2),
        affiliationChanged      (3),
        superseded              (4),
        cessationOfOperation    (5),
        certificateHold         (6),
             -- value 7 is not used
        removeFromCRL           (8),
        privilegeWithdrawn      (9),
        aACompromise           (10) }

5.3.2. Invalidity Date

The invalidity date is a non-critical CRL entry extension that provides the date on which it is known or suspected that the private key was compromised or that the certificate otherwise became invalid. This date may be earlier than the revocation date in the CRL entry, which is the date at which the CA processed the revocation. When a revocation is first posted by a CRL issuer in a CRL, the invalidity date may precede the date of issue of earlier CRLs, but the revocation date SHOULD NOT precede the date of issue of earlier CRLs. Whenever this information is available, CRL issuers are strongly encouraged to share it with CRL users. The GeneralizedTime values included in this field MUST be expressed in Greenwich Mean Time (Zulu), and MUST be specified and interpreted as defined in Section 4.1.2.5.2. id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } InvalidityDate ::= GeneralizedTime

5.3.3. Certificate Issuer

This CRL entry extension identifies the certificate issuer associated with an entry in an indirect CRL, that is, a CRL that has the indirectCRL indicator set in its issuing distribution point extension. When present, the certificate issuer CRL entry extension includes one or more names from the issuer field and/or issuer alternative name extension of the certificate that corresponds to the CRL entry. If this extension is not present on the first entry in an indirect CRL, the certificate issuer defaults to the CRL issuer. On
Top   ToC   RFC5280 - Page 71
   subsequent entries in an indirect CRL, if this extension is not
   present, the certificate issuer for the entry is the same as that for
   the preceding entry.  This field is defined as follows:

   id-ce-certificateIssuer   OBJECT IDENTIFIER ::= { id-ce 29 }

   CertificateIssuer ::=     GeneralNames

   Conforming CRL issuers MUST include in this extension the
   distinguished name (DN) from the issuer field of the certificate that
   corresponds to this CRL entry.  The encoding of the DN MUST be
   identical to the encoding used in the certificate.

   CRL issuers MUST mark this extension as critical since an
   implementation that ignored this extension could not correctly
   attribute CRL entries to certificates.  This specification RECOMMENDS
   that implementations recognize this extension.



(page 71 continued on part 4)

Next Section