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.

   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.

   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.

   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

   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 }

   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

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 }

   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].

   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

   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>).

   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.

   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.)

   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.

   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.

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.

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

   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.

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

   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)

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

   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.

      (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.

   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

   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.

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.

   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.

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.

   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

   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.