certificate
Click on the red underlined text to get to the source
... This specification profiles the format and semantics of certificates
and certificate revocation lists for the Internet ...
... Internet PKI. Procedures
are described for processing of certification paths in the Internet
environment. Encoding rules are provided for popular cryptographic
algorithms ...
... definition, but the presentation assumes one or more self-signed
trusted CA certificates. Implementations are required to derive the
same results but are not required to use the specified procedures.
...
... ASN.1 notation used within
this specification. Appendix D contains examples of a conforming
certificate and a conforming CRL.
...
... The goal of this specification is to develop a profile to facilitate
the use of X.509 certificates within Internet applications for those
communities wishing to make use of X.509 ...
... user authentication,
and IPsec. In order to relieve some of the obstacles to using X.509
certificates, this document defines a profile to promote the
development of certificate ...
... X.509
certificates, this document defines a profile to promote the
development of certificate management systems; development of
application tools ...
... application developers can obtain necessary information without
regard to the issuer of a particular certificate or certificate
revocation list (CRL).
...
...
A certificate user should review the certificate policy generated by
the certification authority ...
...
A certificate user should review the certificate policy generated by
the certification authority (CA ...
... certificate user should review the certificate policy generated by
the certification authority (CA) before relying on the authentication
...
... services associated with the public key in a
particular certificate. To this end, this standard does not
prescribe legally binding rules or duties.
...
... management tools emerge,
such as attribute certificates, it may be appropriate to limit the
authenticated attributes that are included in a certificate ...
... attribute certificates, it may be appropriate to limit the
authenticated attributes that are included in a certificate. These
other management tools ...
...
The users of certificates will operate in a wide range of
environments with respect to their communication topology ...
... profile does not prohibit the use of an X.500 Directory,
but other means of distributing certificates and certificate
revocation lists (CRLs) may be used.
...
... X.500 Directory,
but other means of distributing certificates and certificate
revocation lists (CRLs) may be used.
...
... authorization functions. Support for these
services determines the attributes contained in the certificate as
well as the ancillary control information in the certificate such as
...
... services determines the attributes contained in the certificate as
well as the ancillary control information in the certificate such as
policy data and certification path constraints ...
... well as the ancillary control information in the certificate such as
policy data and certification path constraints.
...
... PKI are people and processes who use client
software and are the subjects named in certificates. These uses
include readers and writers of electronic mail, the clients ...
... trusted CA keys, rules), explicit
platform usage constraints within the certificate, certification path
constraints ...
... platform usage constraints within the certificate, certification path
constraints which shield the user from many malicious actions, and
...
... Also, unbounded choices greatly complicate the software that shall
process and validate the certificates created by the CA.
...
... | e | <---------------------| RA | <---+ |
| p | Publish certificate +------+ | |
| o | | |
| s | | |
...
... | o | <------------------------------| CA |
| r | Publish certificate +------------+
| y | Publish CRL ^
...
... end entity: user of PKI certificates and/or end user system that
is the subject of a certificate ...
... certificates and/or end user system that
is the subject of a certificate;
CA: certification authority ...
... repository: a system or collection of distributed systems that
store certificates and CRLs and serves as a means of
distributing these certificates ...
... certificates and CRLs and serves as a means of
distributing these certificates and CRLs to end
entities.
...
... encryption or digital signature mechanism will be used.
This confidence is obtained through the use of public key
certificates, which are data structures that bind public key values
...
... binding is asserted by having a trusted CA
digitally sign each certificate. The CA may base this assertion upon
technical means (a.k.a., proof of posession through a challenge-
...
... valid lifetime
which is indicated in its signed contents. Because a certificate's
signature and timeliness ...
... signature and timeliness can be independently checked by a
certificate-using client, certificates can be distributed via
...
... certificate-using client, certificates can be distributed via
untrusted communications and server systems, and can be cached in
unsecured storage in certificate-using systems ...
... certificates can be distributed via
untrusted communications and server systems, and can be cached in
unsecured storage in certificate-using systems.
...
... first published in 1988 as part of the X.500 Directory
recommendations, defines a standard certificate format [X.509]. The
certificate ...
... certificate format [X.509]. The
certificate format in the 1988 standard is called the version 1 (v1)
format. When X.500 ...
... public key infrastructure based on X.509
v1 certificates [RFC 1422]. The experience gained in attempts to
deploy RFC 1422hist ...
... RFC 1422]. The experience gained in attempts to
deploy RFC 1422hist made it clear that the v1 and v2 certificate formats
are deficient in several respects. Most importantly, more fields
were needed to carry information which PEM ...
... X.509 version 3
(v3) certificate format. The v3 format extends the v2 format by
adding provision for additional extension fields. Particular
...
... subject identification information,
key attribute information, policy information, and certification path
constraints.
...
... Certification Paths and Trust ...
... public key
generally needs to obtain and validate a certificate containing the
required public key. If the public-key ...
... assured copy of the public key of the CA that signed the certificate,
the CA's name, and related information (such as the validity ...
... validity period
or name constraints), then it might need an additional certificate to
obtain that public key. In general, a chain of multiple certificates ...
... certificate to
obtain that public key. In general, a chain of multiple certificates
may be needed, comprising a certificate of the public key ...
... public key. In general, a chain of multiple certificates
may be needed, comprising a certificate of the public key owner (the
end entity ...
... end entity) signed by one CA, and zero or more additional
certificates of CAs signed by other CAs. Such chains, called
...
... CAs signed by other CAs. Such chains, called
certification paths, are required because a public key user is only
initialized with a limited number of assured CA public keys ...
... CAs might be configured in order
for public key users to be able to find certification paths. For
PEM, RFC 1422hist ...
... acts as the root of the PEM certification hierarchy at level 1.
It issues certificates only for the next level of authorities ...
... PEM certification hierarchy at level 1.
It issues certificates only for the next level of authorities,
PCAs. All certification paths ...
... certificates only for the next level of authorities,
PCAs. All certification paths start with the IPRA.
...
... start with the IPRA.
(b) Policy Certification Authorities (PCAs): PCAs are at level 2
of the hierarchy, each PCA being certified by the IPRA. A PCA
shall establish and publish a statement of its policy with respect
...
... of the hierarchy, each PCA being certified by the IPRA. A PCA
shall establish and publish a statement of its policy with respect
to certifying users or subordinate certification authorities.
Distinct PCAs aim to satisfy different user needs. For example,
one PCA (an organizational PCA) might support the general
...
... 1422hist furthermore has a name subordination rule which requires
that a CA can only issue certificates for entities whose names are
subordinate (in the X.500 naming tree ...
... The trust associated with a PEM certification path is implied by the
PCA name. The name subordination rule ensures that CAs below the PCA
...
... CA for an organization can only certify entities
in that organization's name tree). Certificate user systems are able
to mechanically check that the name subordination rule has been
followed.
...
... The RFC 1422hist uses the X.509 v1 certificate formats. The limitations
of X.509 v1 required imposition of several structural restrictions to
...
... X.509 v1 required imposition of several structural restrictions to
clearly associate policy information or restrict the utility of
certificates. These restrictions included:
...
...
(c) use of the PCA concept, which requires knowledge of individual
PCAs to be built into certificate chain verification logic.
Knowledge of individual PCAs was required to determine if a chain
...
... requirements addressed by RFC 1422hist can be
addressed using certificate extensions, without a need to restrict
the CA structures used. In particular, the certificate extensions ...
... certificate extensions, without a need to restrict
the CA structures used. In particular, the certificate extensions
relating to certificate policies obviate the need for PCAs and the
...
... CA structures used. In particular, the certificate extensions
relating to certificate policies obviate the need for PCAs and the
constraint extensions obviate the need for the name subordination
...
... Name constraints may be imposed through explicit inclusion of
a name constraints extension in a certificate, but are not
required.
...
... (c) Policy extensions and policy mappings replace the PCA
concept, which permits a greater degree of automation. The
application can determine if the certification path is acceptable
based on the contents of the certificates instead of a priori
...
... application can determine if the certification path is acceptable
based on the contents of the certificates instead of a priori
knowledge of PCAs. This permits automation of certificate chain
...
... based on the contents of the certificates instead of a priori
knowledge of PCAs. This permits automation of certificate chain
processing.
...
...
When a certificate is issued, it is expected to be in use for its
entire validity period. However, various circumstances may cause a
...
... entire validity period. However, various circumstances may cause a
certificate to become invalid prior to the expiration of the validity
period. Such circumstances include change of name, change of
...
... CA periodically issuing a signed data structure called
a certificate revocation list (CRL). A CRL is a time stamped list
...
... CRL). A CRL is a time stamped list
identifying revoked certificates which is signed by a CA and made
freely available in a public repository. Each revoked certificate ...
... certificates which is signed by a CA and made
freely available in a public repository. Each revoked certificate is
identified in a CRL by its certificate ...
... certificate is
identified in a CRL by its certificate serial number. When a
certificate-using system ...
... certificate serial number. When a
certificate-using system uses a certificate (e.g., for verifying a
remote user's digital signature ...
... serial number. When a
certificate-using system uses a certificate (e.g., for verifying a
remote user's digital signature), that system not only checks the
...
... remote user's digital signature), that system not only checks the
certificate signature and validity but also acquires a suitably-
...
... validity but also acquires a suitably-
recent CRL and checks that the certificate serial number is not on
that CRL ...
... CRL after appearing on one regularly scheduled CRL issued beyond
the revoked certificate's validity period.
...
... method is that CRLs may be
distributed by exactly the same means as certificates themselves,
namely, via untrusted communications and server systems.
...
... revocation is reported now, that revocation will not be reliably
notified to certificate-using systems until the next periodic CRL is
issued -- this may be up to one hour, one day, or one week depending
...
...
As with the X.509 v3 certificate format, in order to facilitate
interoperable implementations from multiple vendors, the X.509 ...
... on-line service will correctly reflect the
certificate validation impacts of the revocation. However, these
methods ...
...
Operational protocols are required to deliver certificates and CRLs
(or status information) to certificate ...
... certificates and CRLs
(or status information) to certificate using client systems.
Provision is needed for a variety of different means of certificate ...
... certificate using client systems.
Provision is needed for a variety of different means of certificate
and CRL delivery ...
... public key and other assured information of
the trusted CA(s), to be used in validating certificate paths.
Furthermore, a client typically needs to be initialized with its
...
... certification: This is the process in which a CA issues a
certificate for a user's public key, and returns that certificate
...
... certificate for a user's public key, and returns that certificate
to the user's client system and/or posts that certificate ...
... key pairs need to be updated regularly,
i.e., replaced with a new key pair, and new certificates issued.
(f) revocation request ...
... revocation request: An authorized person advises a CA of an
abnormal situation requiring certificate revocation.
...
... revocation.
(g) cross-certification: Two CAs exchange information used in
establishing a cross-certificate ...
... certification: Two CAs exchange information used in
establishing a cross-certificate. A cross-certificate is a
certificate ...
... CAs exchange information used in
establishing a cross-certificate. A cross-certificate is a
certificate issued by one CA ...
... cross-certificate. A cross-certificate is a
certificate issued by one CA to another CA which contains a CA ...
... the registration, initialization, and certification functions can be
combined into one protocol exchange.
...
...
This section presents a profile for public key certificates that will
foster interoperability and a reusable PKI ...
... PKI. This section is based
upon the X.509 v3 certificate format and the standard certificate
extensions defined in [X.509]. The ISO/IEC ...
... upon the X.509 v3 certificate format and the standard certificate
extensions defined in [X.509]. The ISO/IEC/ITU ...
... ASN.1; while this document uses the 1988 ASN.1
syntax, the encoded certificate and standard extensions are
equivalent. This section also defines private extensions required to
support a PKI ...
...
Certificates may be used in a wide range of applications and
environments covering a broad spectrum of interoperability ...
... requirements. In particular, the emphasis will be on
supporting the use of X.509 v3 certificates for informal Internet
electronic mail ...
... Basic Certificate Fields ...
...
The X.509 v3 certificate basic syntax is as follows. For signature
calculation, the certificate ...
... certificate basic syntax is as follows. For signature
calculation, the certificate is encoded using the ASN.1 distinguished
encoding rules (DER ...
...
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
...
... Certificate Fields ...
...
The Certificate is a SEQUENCE of three required fields. The fields
are described in detail in the following subsections.
...
... cryptographic algorithm used by the CA to sign this certificate.
Section 7.2 lists the supported signature algorithms ...
... ASN.1 encoded as a BIT STRING and included in
the Certificate's signature field. The details of this process are
specified for each of the supported algorithms ...
... The sequence TBSCertificate contains information associated with the
subject of the certificate and the CA who issued it. Every
TBSCertificate contains the names of the subject ...
...
This field describes the version of the encoded certificate. When
extensions are used, as expected in this profile, use X.509 ...
... version 2 (value is 1). If only basic fields are
present, use version 1 (the value is omitted from the certificate as
the default value).
...
...
Implementations SHOULD be prepared to accept any version certificate.
At a minimum, conforming implementations MUST recognize version 3
...
... At a minimum, conforming implementations MUST recognize version 3
certificates.
...
...
Generation of version 2 certificates is not expected by
implementations based on this profile.
...
... integer assigned by the CA to each
certificate. It MUST be unique for each certificate issued by a
given CA ...
... CA to each
certificate. It MUST be unique for each certificate issued by a
given CA (i.e., the issuer ...
... This field MUST contain the same algorithm identifier as the
signatureAlgorithm field in the sequence Certificate (see sec.
4.1.1.2). The contents of the optional parameters field will vary
...
... issuer field identifies the entity who has signed and issued the
certificate. The issuer field MUST contain a non-empty distinguished
name (DN ...
... UTF8String encoding is the preferred encoding, and all certificates
issued after December 31, 2003 MUST use the UTF8String encoding of
...
...
(a) CAs MAY issue "name rollover" certificates to support an
orderly migration to UTF8String encoding ...
... orderly migration to UTF8String encoding. Such certificates would
include the CA's UTF8String encoded name as issuer ...
... distinguished name matching the
contents of the issuer field in all certificates issued by the
subject CA ...
...
The TeletexString and UniversalString are included for backward
compatibility, and should not be used for certificates for new
subjects. However, these types may be used in certificates ...
... certificates for new
subjects. However, these types may be used in certificates where the
name was previously established. Certificate users SHOULD be
...
... subjects. However, these types may be used in certificates where the
name was previously established. Certificate users SHOULD be
prepared to receive certificates with these types.
...
... name was previously established. Certificate users SHOULD be
prepared to receive certificates with these types.
...
... set of attribute types that may
appear in names. However, conforming implementations MUST be
prepared to receive certificates with issuer names containing the set
of attribute types defined below. This specification also recommends
...
... subject distinguished name (see sec. 4.1.2.6)
fields to perform name chaining for certification path validation
(see section 6). Name chaining is performed by matching the issuer ...
... certificate user to validate
certificates issued using languages or encodings unfamiliar to the
...
... comparison rules to process unfamiliar attribute types for name
chaining. This allows implementations to process certificates with
unfamiliar attributes in the issuer name.
...
... CA warrants that it will maintain information about the status of the
certificate. The field is represented as a SEQUENCE of two dates:
the date on which the certificate validity ...
... certificate. The field is represented as a SEQUENCE of two dates:
the date on which the certificate validity period begins (notBefore)
and the date on which the certificate ...
... certificate validity period begins (notBefore)
and the date on which the certificate validity period ends
(notAfter). Both notBefore and notAfter may be encoded as UTCTime ...
... CAs conforming to this profile MUST always encode certificate
validity dates through the year 2049 as UTCTime ...
... validity dates through the year 2049 as UTCTime; certificate validity
dates in 2050 or later MUST be encoded as GeneralizedTime.
...
... distinguished
name matching the contents of the issuer field (see sec. 4.1.2.4) in
all certificates issued by the subject CA. If subject ...
... issuer name field. A
CA may issue more than one certificate with the same DN to the same
subject ...
... comparison rules to process unfamiliar
attribute types (i.e., for name chaining). This allows
implementations to process certificates with unfamiliar attributes in
the subject name.
...
... issuer unique identifiers are present in
the certificate to handle the possibility of reuse of subject and/or
issuer ...
... profile recommends that names not be
reused for different entities and that Internet certificates not make
use of unique identifiers. CAs ...
... CAs conforming to this profile SHOULD NOT
generate certificates with unique identifiers. Applications
conforming to this profile ...
... This field may only appear if the version is 3 (see sec. 4.1.2.1).
If present, this field is a SEQUENCE of one or more certificate
extensions. The format and content of certificate extensions in the
Internet ...
... version is 3 (see sec. 4.1.2.1).
If present, this field is a SEQUENCE of one or more certificate
extensions. The format and content of certificate extensions in the
Internet PKI ...
... Standard Certificate Extensions ...
...
The extensions defined for X.509 v3 certificates provide methods for
associating additional attributes with users or public keys ...
... associating additional attributes with users or public keys and for
managing the certification hierarchy. The X.509 v3 certificate
...
... managing the certification hierarchy. The X.509 v3 certificate
format also allows communities to define private extensions to carry
information unique to those communities. Each extension in a
...
... format also allows communities to define private extensions to carry
information unique to those communities. Each extension in a
certificate may be designated as critical or non-critical. A
...
... critical or non-critical. A
certificate using system MUST reject the certificate if it encounters
a critical ...
... critical. A
certificate using system MUST reject the certificate if it encounters
a critical extension it does not recognize; however, a non-critical ...
... sections present recommended extensions used within Internet
certificates and standard locations for information. Communities may
elect to use additional extensions; however, caution should be
exercised in adopting any critical ...
... elect to use additional extensions; however, caution should be
exercised in adopting any critical extensions in certificates which
might prevent use in a general context.
...
... OID and an ASN.1 structure. When an
extension appears in a certificate, the OID appears as the field
extnID and the corresponding ASN.1 ...
... ASN.1 encoded structure is the value of
the octet string extnValue. Only one instance of a particular
extension may appear in a particular certificate. For example, a
certificate may contain only one authority ...
... extension may appear in a particular certificate. For example, a
certificate may contain only one authority key identifier extension
...
... constraints (see sec. 4.2.1.10), key usage (see sec.
4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If
the CA issues certificates ...
... certificate policies (see sec. 4.2.1.5) extensions. If
the CA issues certificates with an empty sequence for the subject
field, the CA ...
... OPTIONAL. Conforming CAs may support extensions that are not
identified within this specification; certificate issuers are
cautioned that marking such extensions as critical ...
... critical in this specification.
These extensions are: key usage (see sec. 4.2.1.3), certificate
policies (see sec. 4.2.1.5), the subject alternative name (see sec.
...
...
This section identifies standard certificate extensions defined in
[X.509] for use in the Internet ...
... public key corresponding to the private key used to
sign a certificate. This extension is used where an issuer has
multiple signing ...
...
The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to
facilitate chain building. There is one exception; where a CA ...
... distributes its public key in the form of a "self-signed"
certificate, the authority key identifier may be omitted. In this
...
... The value of the keyIdentifier field SHOULD be derived from the
public key used to verify the certificate's signature or a method
...
... subject key identifier extension provides a means of identifying
certificates that contain a particular public key.
...
... To facilitate chain building, this extension MUST appear in all con-
forming CA certificates, that is, all certificates including the
basic constraints ...
... forming CA certificates, that is, all certificates including the
basic constraints extension (see sec. 4.2.1.10) where the value of cA
...
... Authority Key Identifier
extension (see sec. 4.2.1.1) of certificates issued by the subject of
this certificate ...
... subject key identifier extension
provides a means for identifying certificates containing the
particular public key used in an application. Where an end entity ...
... public key used in an application. Where an end entity has
obtained multiple certificates, especially from multiple CAs, the
subject ...
... subject key identifier provides a means to quickly identify the set
of certificates containing a particular public key. To assist
applications in identificiation the appropriate end entity
certificate ...
... certificates containing a particular public key. To assist
applications in identificiation the appropriate end entity
certificate, this extension SHOULD be included in all end entity
certificates.
...
... public key. To assist
applications in identificiation the appropriate end entity
certificate, this extension SHOULD be included in all end entity
certificates.
...
... key usage extension defines the purpose (e.g., encipherment,
signature, certificate signing) of the key contained in the
certificate. The usage restriction might be employed when a key that
...
... signature, certificate signing) of the key contained in the
certificate. The usage restriction might be employed when a key that
could be used for more than one operation is to be restricted. For
example, when an RSA key ...
... security
services other than non-repudiation (bit 1), certificate signing
(bit 5), or revocation ...
... service which protects against the signing entity
falsely denying some action, excluding certificate or CRL signing.
...
... public key is
used for verifying a signature on certificates. This bit may only
be asserted in CA ...
...
The private key usage period extension allows the certificate issuer
to specify a different validity ...
... validity period for the private key than the
certificate. This extension is intended for use with digital
signature keys. This extension consists of two optional components,
notBefore and notAfter. The private key ...
... notBefore and notAfter. The private key associated with the
certificate should not be used to sign objects before or after the
times specified by the two components, respectively. CAs conforming
...
... CAs conforming
to this profile MUST NOT generate certificates with private key usage
period extensions unless at least one of the two components is
...
... Certificate Policies ...
...
The certificate policies extension contains a sequence of one or more
policy information terms, each of which consists of an object
identifier (OID ...
... object
identifier (OID) and optional qualifiers. These policy information
terms indicate the policy under which the certificate has been issued
and the purposes for which the certificate may be used. Optional
...
... terms indicate the policy under which the certificate has been issued
and the purposes for which the certificate may be used. Optional
qualifiers, which may be present, are not expected to change the
definition of the policy.
...
... list of those policies which they will accept and to compare the
policy OIDs in the certificate to that list. If this extension is
critical, the path validation ...
... validation software MUST be able to interpret this
extension (including the optional qualifier), or MUST reject the
certificate.
...
...
This specification defines two policy qualifier types for use by
certificate policy writers and certificate issuers. The qualifier
...
... This specification defines two policy qualifier types for use by
certificate policy writers and certificate issuers. The qualifier
types are the CPS ...
...
The CPS Pointer qualifier contains a pointer to a Certification
Practice Statement (CPS) published by the CA ...
...
User notice is intended for display to a relying party when a
certificate is used. The application software SHOULD display all
user notices in all certificates of the certification path ...
... certificate is used. The application software SHOULD display all
user notices in all certificates of the certification path used,
except that if a notice is duplicated only one copy need be
...
... certificate is used. The application software SHOULD display all
user notices in all certificates of the certification path used,
except that if a notice is duplicated only one copy need be
displayed. To prevent such duplication, this qualifier SHOULD only
...
... except that if a notice is duplicated only one copy need be
displayed. To prevent such duplication, this qualifier SHOULD only
be present in end-entity certificates and CA certificates issued to
...
...
An explicitText field includes the textual statement directly in
the certificate. The explicitText field is a string with a
maximum size of 200 characters.
...
...
This extension is used in CA certificates. It lists one or more
pairs of OIDs; each pair includes an issuerDomainPolicy and a
...
... alternative names extension allows additional identities
to be bound to the subject of the certificate. Defined options
include an Internet electronic mail ...
... exist, including completely local definitions. Multiple name forms,
and multiple instances of each name form, may be included. Whenever
such identities are to be bound into a certificate, the subject
alternative name ...
... Further, if the only subject identity included in the certificate is
an alternative name form (e.g., an electronic mail ...
... subject field, conforming CAs MUST
NOT issue certificates with subjectAltNames containing empty
GeneralName fields. For example, an rfc822Name is represented as an
IA5String. While an empty string is a valid ...
... profile. The behavior of clients
that encounter such a certificate when processing a certificication
path is not defined by this profile.
...
... As with 4.2.1.7, this extension is used to associate Internet style
identities with the certificate issuer. Issuer alternative names ...
... constraints extension identifies whether the subject of the
certificate is a CA and how deep a certification path may exist
...
... The pathLenConstraint field is meaningful only if cA is set to TRUE.
In this case, it gives the maximum number of CA certificates that may
follow this certificate in a certification path ...
... CA certificates that may
follow this certificate in a certification path. A value of zero
indicates that only an end-entity certificate ...
... certificates that may
follow this certificate in a certification path. A value of zero
indicates that only an end-entity certificate may follow in the path.
...
... certificate in a certification path. A value of zero
indicates that only an end-entity certificate may follow in the path.
Where it appears, the pathLenConstraint field MUST be greater than or
equal to zero. Where pathLenConstraint does not appear, there is no
...
... Where it appears, the pathLenConstraint field MUST be greater than or
equal to zero. Where pathLenConstraint does not appear, there is no
limit to the allowed length of the certification path.
...
... critical extension in all CA
certificates. This extension SHOULD NOT appear in end entity
certificates.
...
... name constraints extension, which MUST be used only in a CA
certificate, indicates a name space within which all subject names in
...
... name space within which all subject names in
subsequent certificates in a certification path shall be located.
Restrictions may apply to the subject ...
... subject names in
subsequent certificates in a certification path shall be located.
Restrictions may apply to the subject distinguished name ...
... alternative names. Restrictions apply only when the specified name
form is present. If no name of the type is in the certificate, the
certificate is acceptable.
...
... form is present. If no name of the type is in the certificate, the
certificate is acceptable.
...
... subject distinguished name in an attribute of type EmailAddress (see
sec. 4.1.2.6). When rfc822 names are constrained, but the certificate
does not include a subject alternative name ...
... Restrictions of the form directoryName MUST be applied to the subject
field in the certificate and to the subjectAltName extensions of type
directoryName. Restrictions of the form x400Address MUST be applied
...
... comparison rules specified in
Section 4.1.2.4. CAs issuing certificates with a restriction of the
form directoryName SHOULD NOT rely on implementation of the full ISO
...
...
The policy constraints extension can be used in certificates issued
to CAs. The policy constraints ...
... 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 ...
... 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 ...
... certificates issued
by the subject of this certificate, but not in additional
certificates in the path.
...
...
If the requireExplicitPolicy field is present, subsequent
certificates shall include an acceptable policy identifier. The value
of requireExplicitPolicy indicates the number of additional
...
... identifier. The value
of requireExplicitPolicy indicates the number of additional
certificates that may appear in the path before an explicit policy is
required. An acceptable policy identifier is the identifier ...
... identifier of a
policy required by the user of the certification path or the
identifier of a policy which has been declared equivalent through
...
...
Conforming CAs MUST NOT issue certificates where policy constraints
is a null sequence. That is, at least one of the inhibitPolicyMapping
...
...
If the extension is flagged critical, then the certificate MUST be
used only for one of the purposes indicated.
...
... critical, then it indicates the
intended purpose or purposes of the key, and may be used in finding
the correct key/certificate of an entity that has multiple
keys/certificates ...
... certificate of an entity that has multiple
keys/certificates. It is an advisory field and does not imply that
usage of the key is restricted by the certification authority to the
...
... keys/certificates. It is an advisory field and does not imply that
usage of the key is restricted by the certification authority to the
purpose indicated. Certificate using applications may nevertheless
...
... usage of the key is restricted by the certification authority to the
purpose indicated. Certificate using applications may nevertheless
require that a particular purpose be indicated in order for the
certificate ...
... Certificate using applications may nevertheless
require that a particular purpose be indicated in order for the
certificate to be acceptable to that application.
...
... critical extended key usage field, then both fields MUST be processed
independently and the certificate MUST only be used for a purpose
consistent with both fields. If there is no purpose consistent with
both fields, then the certificate ...
... certificate MUST only be used for a purpose
consistent with both fields. If there is no purpose consistent with
both fields, then the certificate MUST NOT be used for any purpose.
...
... information and services for the issuer of the certificate in which
the extension appears. Information and services may include on-line ...
... format and location of additional information about the CA who issued
the certificate in which this extension appears. The type and format
of the information is specified by the accessMethod field; the
...
... OID is used when the additional information lists CAs that have
issued certificates superior to the CA that issued the certificate
...
... issued certificates superior to the CA that issued the certificate
containing this extension. The referenced CA Issuers ...
... 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.
...
... 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.
...
... intended to aid certificate users in the selection of a certification
path that terminates at a point trusted by the certificate user.
...
... CRLs if other revocation or
certificate status mechanisms are provided. Conforming CAs that
issue CRLs ...
... itself a sequence containing the name of the issuer, issue date,
issue date of the next list, the list of revoked certificates, and
optional CRL extensions. Further, each entry on the revoked
...
... optional CRL extensions. Further, each entry on the revoked
certificate list is defined by a sequence of user certificate serial
number, revocation ...
... CRL extensions. Further, each entry on the revoked
certificate list is defined by a sequence of user certificate serial
number, revocation date, and optional CRL ...
... 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 ...
...
Optional fields include lists of revoked certificates and CRL
extensions. The revoked certificate list is optional to support the
...
... Optional fields include 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 ...
... certificate list is optional to support the
case where a CA has not revoked any unexpired certificates that it
has issued. The profile requires conforming CAs ...
... Revoked Certificates ...
...
Revoked certificates are listed. The revoked certificates are named
by their serial numbers. Certificates ...
... certificates are named
by their serial numbers. Certificates revoked by the CA are uniquely
identified by the certificate ...
... Certificates revoked by the CA are uniquely
identified by the certificate serial number. The date on which the
revocation ...
... indicates whether the CRL covers revocation for end entity
certificates only, CA certificates only, or a limitied set of reason
...
... revocation for end entity
certificates only, CA certificates only, or a limitied set of reason
codes. Although the extension is critical, conforming
...
... critical CRL entry extension that identifies
the reason for the certificate revocation. CAs are strongly
...
... provides a registered instruction identifier which indicates the
action to be taken after encountering a certificate that has been
placed on hold.
...
...
Conforming applications which encounter an id-holdinstruction-
callissuer MUST call the certificate issuer or reject the
certificate ...
... certificate issuer or reject the
certificate. Conforming applications which encounter an
id-holdinstruction-reject MUST reject the certificate. The hold
...
... certificate. Conforming applications which encounter an
id-holdinstruction-reject MUST reject the certificate. The hold
instruction id-holdinstruction-none is semantically equivalent to the
absence of a holdInstructionCode, and its use is strongly deprecated
...
... 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 ...
... Certificate Issuer ...
...
This CRL entry extension identifies the certificate issuer associated
with an entry in an indirect CRL ...
... extension is not present on the first entry in an indirect CRL, the
certificate issuer defaults to the CRL issuer. On subsequent entries
...
... 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.
...
... critical. If an implementation ignored this extension it could not
correctly attribute CRL entries to certificates. This specification
RECOMMENDS that implementations recognize this extension.
...
... Certification Path Validation ...
... PKI are
based on section 12.4.3 of [X.509]. Certification path processing
verifies the binding between the subject ...
... binding is
limited by constraints which are specified in the certificates which
comprise the path. The basic constraints and policy constraints ...
... constraints and policy constraints
extensions allow the certification path processing logic to automate
the decision making process.
...
...
This section describes an algorithm for validating certification
paths. Conforming implementations of this specification are not
required to implement this algorithm, but MUST be functionally
...
... validation. This text
assumes that all valid paths begin with certificates issued by a
single "most-trusted CA". The algorithm ...
... The text assumes that the trusted public key (and related
information) is contained in a "self-signed" certificate. This
simplifies the description of the path processing procedure. Note
that the signature ...
... simplifies the description of the path processing procedure. Note
that the signature on the self-signed certificate does not provide
any security services. The trusted public key ...
... public key, as represented in the "end entity" certificate, based on
the public key of the "most-trusted CA ...
... public key of the "most-trusted CA". This requires obtaining a
sequence of certificates that support that binding. The procedures
performed to obtain this sequence is outside the scope of this
...
... recommended within this profile. However, if these components appear
in certificates, they MUST be processed. Finally, policy qualifiers
are also neglected for the sake of clarity.
...
...
A certification path is a sequence of n certificates where:
...
...
A certification path is a sequence of n certificates where:
...
... certificate x=1 is the the self-signed certificate, and ...
... certificate x=1 is the the self-signed certificate, and ...
... certificate x=n is the end entity certificate. ...
... certificate x=n is the end entity certificate. ...
...
(a) a certification path of length n;
(b) a set of initial policy identifiers ...
... element identifiers), which identifies one or
more certificate policies, any one of which would be acceptable
for the purposes of certification path processing, or the special
...
... more certificate policies, any one of which would be acceptable
for the purposes of certification path processing, or the special
value "any-policy";
...
... (c) the current date/time (if not available internally to the
certification path processing module); and
(d) the time, T, for which the validity ...
...
(a) acceptable policy set: A set of certificate policy
identifiers comprising the policy or policies recognized by the
public key user together with policies deemed equivalent through
...
... subtrees within which all subject names in subsequent certificates
in the certification path shall fall. The initial value is
...
... subject names in subsequent certificates
in the certification path shall fall. The initial value is
"unbounded".
...
... subtrees within which no subject name in subsequent certificates
in the certification path may fall. The initial value is "empty".
...
... subject name in subsequent certificates
in the certification path may fall. The initial value is "empty".
(d) explicit policy: an integer ...
... identifier is required. The integer indicates the first
certificate in the path where this requirement is imposed. Once
set, this variable may be decreased, but may not be increased.
...
... requirement is imposed. Once
set, this variable may be decreased, but may not be increased.
(That is, if a certificate in the path requires explicit policy
identifiers, a later certificate ...
... certificate in the path requires explicit policy
identifiers, a later certificate can not remove this requirement.)
...
... integer which indicates if policy mapping
is permitted. The integer indicates the last certificate on which
policy mapping may be applied. Once set, this variable may be
decreased, but may not be increased. (That is, if a certificate ...
... certificate on which
policy mapping may be applied. Once set, this variable may be
decreased, but may not be increased. (That is, if a certificate in
the path specifies policy mapping is not permitted, it can not be
overriden by a later certificate ...
... certificate in
the path specifies policy mapping is not permitted, it can not be
overriden by a later certificate.) The initial value is n+1.
...
...
The actions performed by the path processing software for each
certificate i=1 through n are described below. The self-signed
certificate is certificate i=1, the end entity certificate ...
... The actions performed by the path processing software for each
certificate i=1 through n are described below. The self-signed
certificate is certificate i=1, the end entity certificate is i=n.
...
... certificate i=1 through n are described below. The self-signed
certificate is certificate i=1, the end entity certificate is i=n.
The processing is performed sequentially, so that processing
...
... certificate i=1 through n are described below. The self-signed
certificate is certificate i=1, the end entity certificate is i=n.
The processing is performed sequentially, so that processing
certificate ...
... end entity certificate is i=n.
The processing is performed sequentially, so that processing
certificate i affects the state variables for processing certificate
...
... certificate i affects the state variables for processing certificate
(i+1). Note that actions (h) through (m) are not applied to the end
entity certificate (certificate ...
... state variables for processing certificate
(i+1). Note that actions (h) through (m) are not applied to the end
entity certificate (certificate n).
...
... certificate
(i+1). Note that actions (h) through (m) are not applied to the end
entity certificate (certificate n).
...
...
(a) Verify the basic certificate information, including:
(1) the certificate ...
... certificate information, including:
(1) the certificate was signed using the subject public key
...
... subject public key
from certificate i-1 (in the special case i=1, this step may be
omitted; if not, use the subject public key ...
... validity period includes time T,
(3) the certificate had not been revoked at time T and is not
currently on hold status that commenced before time T, (this
may be determined by obtaining the appropriate CRL ...
... issuer names chain correctly (that is, the
issuer of this certificate was the subject of the previous
certificate ...
... state variable is less than or equal
to i, a policy identifier in the certificate shall be in the
initial policy set; and
...
... acceptable policy set:
(1) if the certificate policies extension is marked critical,
the intersection of the policies extension and the acceptable
...
... (h) Recognize and process any other critical extension present in
the certificate.
(i) Verify that the certificate ...
... (i) Verify that the certificate is a CA certificate (as specified
in a basicConstraints extension or as verified out-of-band).
...
... out-of-band).
(j) If permittedSubtrees is present in the certificate, set the
constrained subtrees state ...
... extension field.
(k) If excludedSubtrees is present in the certificate, set the
excluded subtrees state ...
... (l) If a policy constraints extension is included in the
certificate, modify the explicit policy and policy mapping state
variables as follows:
...
... explicit policy state variable is set to the minimum of its
current value and the sum of r and i (the current certificate
in the sequence).
...
... policy mapping state variable is set to the minimum of its
current value and the sum of q and i (the current certificate
in the sequence).
...
... If any one of the above checks fail, the procedure terminates,
returning a failure indication and an appropriate reason. If none of
the above checks fail on the end-entity certificate, the procedure
terminates, returning a success indication together with the set of
all policy qualifier values encountered in the set of certificates ...
... end-entity certificate, the procedure
terminates, returning a success indication together with the set of
all policy qualifier values encountered in the set of certificates.
...
... This procedure may be extended for multiple trusted CAs by providing
a set of self-signed certificates to the validation module. In this
case, a valid ...
... validation module. In this
case, a valid path could begin with any one of the self-signed
certificates. Limitations in the trust paths for any particular key
may be incorporated into the self-signed certificate ...
... self-signed
certificates. Limitations in the trust paths for any particular key
may be incorporated into the self-signed certificate's extensions. In
this way, the self-signed certificates permit the path validation ...
... may be incorporated into the self-signed certificate's extensions. In
this way, the self-signed certificates permit the path validation
module to automatically incorporate local security policy ...
... It is also possible to specify an extended version of the above
certification path processing procedure which results in default
behavior identical to the rules of PEM [RFC 1422 ...
... version, additional inputs to the procedure are a list of one or more
Policy Certification Authorities (PCAs) names and an indicator of the
position in the certification path where the PCA is expected. At the
...
... Policy Certification Authorities (PCAs) names and an indicator of the
position in the certification path where the PCA is expected. At the
nominated PCA position, the CA name is compared against this list.
...
... constraint of
SubordinateToCA is implicitly assumed for the remainder of the
certification path and processing continues. If no valid PCA name is
found, and if the certification path ...
... certification path and processing continues. If no valid PCA name is
found, and if the certification path cannot be validated on the basis
of identified policies, then the certification path ...
... certification path cannot be validated on the basis
of identified policies, then the certification path is considered
invalid.
...
... digital signature algorithms which may be used to sign certificates
and CRLs, and identifies OIDs ...
...
Certificates and CRLs described by this standard may be signed with
any public key signature ...
... algorithm through an algorithm identifier which appears in the
signatureAlgorithm field in a Certificate or CertificateList. This
algorithm identifier is an OID ...
... parameters. This section identifies algorithm identifiers and
parameters that shall be used in the signatureAlgorithm field in a
Certificate or CertificateList.
...
... signature algorithm and one-way hash function used to sign a
certificate or CRL is indicated by use of an algorithm identifier.
...
... signature value is then ASN.1 encoded as a BIT
STRING and included in the Certificate or CertificateList in the
signature field.
...
... The DSA parameters in the subjectPublicKeyInfo field of the
certificate of the issuer shall apply to the verification of the
...
... public key for
any public key algorithm. The certificate indicates the algorithm
through an algorithm identifier ...
... CAs shall use the
identified OIDs when issuing certificates containing public keys for
these algorithms ...
...
If the keyUsage extension is present in an end entity certificate
which conveys an RSA public key, any combination of the following
...
... keyEncipherment; and dataEncipherment. If the keyUsage extension is
present in a CA certificate which conveys an RSA public key, any
combination of the following values may be present:
...
... AlgorithmIdentifier and the CA signed the subject certificate using a
signature algorithm other than DSA ...
...
If the keyUsage extension is present in an end entity certificate
which conveys a DSA public key, any combination of the following
...
...
If the keyUsage extension is present in an CA certificate which
conveys a DSA public key, any combination of the following values may
...
... Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management," RFC 1422hist, February 1993. ...
... ANSI X9.55-1995, Public Key Cryptography For The Financial Services Industry: Extensions To Public Key Certificates And Certificate Revocation Lists, 8 December, 1995. ...
... Public Key Cryptography For The Financial Services Industry: Extensions To Public Key Certificates And Certificate Revocation Lists, 8 December, 1995. ...
... ANSI X9.57-199x, Public Key Cryptography For The Financial Services Industry: Certificate Management (Working Draft), 21 June, 1996. ...
...
The majority of this specification is devoted to the format and
content of certificates and CRLs. Since certificates and CRLs ...
... content of certificates and CRLs. Since certificates and CRLs are
digitally signed, no additional integrity service ...
... digitally signed, no additional integrity service is necessary.
Neither certificates nor CRLs need be kept secret, and unrestricted
and anonymous access to certificates ...
... certificates nor CRLs need be kept secret, and unrestricted
and anonymous access to certificates and CRLs has no security
implications.
...
... However, security factors outside the scope of this specification
will affect the assurance provided to certificate users. This
section highlights critical issues that should be considered by
...
... identity of their public key greatly affect the
assurance that should be placed in the certificate. Relying parties
may wish to review the CA's certificate ...
... certificate. Relying parties
may wish to review the CA's certificate practice statement. This may
be particularly important when issuing certificates to other CAs ...
... CA's certificate practice statement. This may
be particularly important when issuing certificates to other CAs.
...
... private key unnoticed, the attacker may issue
bogus certificates and CRLs. Existence of bogus certificates and
...
... bogus certificates and CRLs. Existence of bogus certificates and
CRLs will undermine confidence in the system. If the compromise is
...
... CRLs will undermine confidence in the system. If the compromise is
detected, all certificates issued to the CA shall be revoked,
preventing services ...
... The availability and freshness of revocation information will affect
the degree of assurance that should be placed in a certificate.
While certificates expire naturally, events may occur during its
...
... the degree of assurance that should be placed in a certificate.
While certificates expire naturally, events may occur during its
natural lifetime which negate the binding ...
... CA is an important decision as it ultimately
determines the trust afforded a certificate. The authenticated
distribution of trusted CA ...
... trusted CA public keys (usually in the form of a
"self-signed" certificate) is a security critical out of band process
...
...
The quality of implementations that process certificates may also
affect the degree of assurance provided. The path validation
...
... key lengths or weak hash algorithms
will limit the utility of a certificate. CAs are encouraged to note
advances in cryptology so they can employ strong cryptographic ...
... cryptographic
techniques. In addition, CAs should decline to issue certificates to
CAs or end entities ...
... comparison rules may result in
acceptance of invalid X.509 certification paths, or rejection of
valid ones. The X.500 ...
... distinguished name in the issuer field
in certificates issued by the latter CA. If CAs use different
...
... encodings, implementations of this specification may fail to
recognize name chains for paths that include this certificate. As a
consequence, valid paths could be rejected.
...
... id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- arc for private certificate extensions
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
...
... bmpString BMPString (SIZE(1..MAX)) }
-- certificate and CRL specific structures begin here
...
... and CRL specific structures begin here
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
...
... -- Version, Time, CertificateSerialNumber, and Extensions were
-- defined earlier for use in the certificate structure
AlgorithmIdentifier ::= SEQUENCE {
...
... -- either notBefore or notAfter shall be present
-- certificate policies extension OID and syntax
...
... -- PKIX arcs
-- arc for private certificate extensions
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
...
... -- {joint-iso-ccitt ds(5) modules(1) authenticationFramework(7) 2}
-- Public Key Certificate --
Certificate ::= SIGNED { SEQUENCE {
...
...
-- The following information object set is defined to constrain the
-- set of legal certificate extensions.
ExtensionSet EXTENSION ::= { authorityKeyIdentifier |
...
... IDENTIFIED BY &id }
-- Certificate Revocation List --
CertificateList ::= SIGNED { SEQUENCE {
...
... issuingDistributionPoint }
-- EXTENSION defined above for certificates
EntryExtensions ::= SEQUENCE SIZE (1..MAX) OF EntryExtension
...
... AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute
-- Certification path constraints extensions --
...
... -- Object identifier assignments for ISO certificate extensions --
id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}
...
...
This section contains four examples: three certificates and a CRL.
The first two certificates ...
... certificates and a CRL.
The first two certificates and the CRL comprise a minimal
certification path ...
...
Section D.1 contains an annotated hex dump of a "self-signed"
certificate issued by a CA whose distinguished name is
...
... CA whose distinguished name is
cn=us,o=gov,ou=nist. The certificate contains a DSA public key with
parameters, and is signed by the corresponding DSA private key ...
...
Section D.2 contains an annotated hex dump of an end-entity
certificate. The end entity certificate contains a DSA public key,
...
...
Section D.2 contains an annotated hex dump of an end-entity
certificate. The end entity certificate contains a DSA public key,
and is signed by the private key ...
... and is signed by the private key corresponding to the "self-signed"
certificate in section D.1.
...
...
Section D.3 contains a dump of an end entity certificate which
contains an RSA public key and is signed with RSA ...
... CA whose distinguished name is cn=us,o=gov,ou=nist and
the list of revoked certificates includes the end entity certificate
presented in D.2.
...
... distinguished name is cn=us,o=gov,ou=nist and
the list of revoked certificates includes the end entity certificate
presented in D.2.
...
... D.1 Certificate ...
... This section contains an annotated hex dump of a 699 byte version 3
certificate. The certificate contains the following information:
(a) the serial number ...
... version 3
certificate. The certificate contains the following information:
(a) the serial number is 17 (11 hex);
...
... (a) the serial number is 17 (11 hex);
(b) the certificate is signed with DSA and the SHA-1 hash algorithm ...
... subject's distinguished name is OU=nist; O=gov; C=US
(e) the certificate was issued on June 30, 1997 and will expire on
December 31, 1997;
(f) the certificate ...
... certificate was issued on June 30, 1997 and will expire on
December 31, 1997;
(f) the certificate contains a 1024 bit DSA public key with
...
... DSA public key with
parameters;
(g) the certificate contains a subject key identifier extension; and
...
... subject key identifier extension; and
(h) the certificate is a CA certificate (as indicated through the
...
... (h) the certificate is a CA certificate (as indicated through the
basic constraints extension.)
...
... D.2 Certificate ...
... This section contains an annotated hex dump of a 730 byte version 3
certificate. The certificate contains the following information:
(a) the serial number ...
... version 3
certificate. The certificate contains the following information:
(a) the serial number is 18 (12 hex);
...
... (a) the serial number is 18 (12 hex);
(b) the certificate is signed with DSA and the SHA-1 hash algorithm ...
... CN=Tim Polk; OU=nist;
O=gov; C=US
(e) the certificate was valid from July 30, 1997 through December 1,
1997;
...
... valid from July 30, 1997 through December 1,
1997;
(f) the certificate contains a 1024 bit DSA public key;
...
... bit DSA public key;
(g) the certificate is an end entity certificate, as the basic
constraints ...
... DSA public key;
(g) the certificate is an end entity certificate, as the basic
constraints extension is not present;
...
... constraints extension is not present;
(h) the certificate contains an authority key identifier extension;
...
... key identifier extension;
and
(i) the certificate includes one alternative name - an RFC 822std11(-> 2822prop)
...
... D.3 End-Entity Certificate Using RSA ...
... This section contains an annotated hex dump of a 675 byte version 3
certificate. The certificate contains the following information:
(a) the serial number ...
... version 3
certificate. The certificate contains the following information:
(a) the serial number is 256;
...
... (a) the serial number is 256;
(b) the certificate is signed with RSA and the MD2 hash algorithm ...
... Catalunya; C=ES
(e) the certificate was issued on May 21, 1996 and expired on May 21,
1997;
(f) the certificate ...
... certificate was issued on May 21, 1996 and expired on May 21,
1997;
(f) the certificate contains a 768 bit RSA public key;
...
... end entity certificate (not a CA
certificate);
(h) the certificate includes an alternative subject ...
... certificate);
(h) the certificate includes an alternative subject name and an
alternative issuer ...
... authority key identifier and
certificate policies extensions; and
(j) the certificate includes a critical ...
... certificate policies extensions; and
(j) the certificate includes a critical key usage extension
...
... D.4 Certificate Revocation List ...
... on July 7, 1996; the next scheduled issuance was August 7, 1996. The
CRL includes one revoked certificates: serial number 18 (12 hex).
The CRL ...