As per Relevance of the word structure, we have this rfc below:
Network Working Group R.
Request for Comments: 2459
Category: Standards Track W.
W.
D.
January 1999
Internet X.509 Public Key
Certificate and CRL
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for
in the Internet. An overview of the approach and model are
as an introduction. The X.509 v3 certificate format is described
detail, with additional information regarding the format
semantics of Internet name forms (e.g., IP addresses).
certificate extensions are described and one new Internet-
extension is defined. A required set of certificate extensions
specified. The X.509 v2 CRL format is described and a
extension set is defined as well. An algorithm for X.509
path validation is described. Supplemental information is
describing the format of public keys and digital signatures in X.509
certificates for common Internet public key encryption
(i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples
provided in the appendices
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.
Housley, et. al. Standards Track [Page 1]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
Please send comments on this document to the ietf-pkix@imc.org
list
TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttsss
1 Introduction ................................................ 5
2 Requirements and Assumptions ................................ 6
2.1 Communication and Topology ................................ 6
2.2 Acceptability Criteria .................................... 7
2.3 User Expectations ......................................... 7
2.4 Administrator Expectations ................................ 7
3 Overview of Approach ........................................ 7
3.1 X.509 Version 3 Certificate ............................... 9
3.2 Certification Paths and Trust ............................. 10
3.3 Revocation ................................................ 12
3.4 Operational Protocols ..................................... 13
3.5 Management Protocols ...................................... 13
4 Certificate and Certificate Extensions Profile .............. 15
4.1 Basic Certificate Fields .................................. 15
4.1.1 Certificate Fields ...................................... 16
4.1.1.1 tbsCertificate ........................................ 16
4.1.1.2 signatureAlgorithm .................................... 16
4.1.1.3 signatureValue ........................................ 17
4.1.2 TBSCertificate .......................................... 17
4.1.2.1 Version ............................................... 17
4.1.2.2 Serial number ......................................... 18
4.1.2.3 Signature ............................................. 18
4.1.2.4 Issuer ................................................ 18
4.1.2.5 Validity .............................................. 21
4.1.2.5.1 UTCTime ............................................. 22
4.1.2.5.2 GeneralizedTime ..................................... 22
4.1.2.6 Subject ............................................... 22
4.1.2.7 Subject Public Key Info ............................... 23
4.1.2.8 Unique Identifiers .................................... 24
4.1.2.9 Extensions ............................................. 24
4.2 Certificate Extensions .................................... 24
4.2.1 Standard Extensions ..................................... 25
4.2.1.1 Authority Key Identifier .............................. 25
4.2.1.2 Subject Key Identifier ................................ 26
4.2.1.3 Key Usage ............................................. 27
4.2.1.4 Private Key Usage Period .............................. 29
4.2.1.5 Certificate Policies .................................. 29
4.2.1.6 Policy Mappings ....................................... 31
4.2.1.7 Subject Alternative Name .............................. 32
Housley, et. al. Standards Track [Page 2]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
4.2.1.8 Issuer Alternative Name ............................... 34
4.2.1.9 Subject Directory Attributes .......................... 34
4.2.1.10 Basic Constraints .................................... 35
4.2.1.11 Name Constraints ..................................... 35
4.2.1.12 Policy Constraints ................................... 37
4.2.1.13 Extended key usage field ............................. 38
4.2.1.14 CRL Distribution Points .............................. 39
4.2.2 Private Internet Extensions ............................. 40
4.2.2.1 Authority Information Access .......................... 41
5 CRL and CRL Extensions Profile .............................. 42
5.1 CRL Fields ................................................ 43
5.1.1 CertificateList Fields .................................. 43
5.1.1.1 tbsCertList ........................................... 44
5.1.1.2 signatureAlgorithm .................................... 44
5.1.1.3 signatureValue ........................................ 44
5.1.2 Certificate List "To Be Signed" ......................... 44
5.1.2.1 Version ............................................... 45
5.1.2.2 Signature ............................................. 45
5.1.2.3 Issuer Name ........................................... 45
5.1.2.4 This Update ........................................... 45
5.1.2.5 Next Update ........................................... 45
5.1.2.6 Revoked Certificates .................................. 46
5.1.2.7 Extensions ............................................ 46
5.2 CRL Extensions ............................................ 46
5.2.1 Authority Key Identifier ................................ 47
5.2.2 Issuer Alternative Name ................................. 47
5.2.3 CRL Number .............................................. 47
5.2.4 Delta CRL Indicator ..................................... 48
5.2.5 Issuing Distribution Point .............................. 48
5.3 CRL Entry Extensions ...................................... 49
5.3.1 Reason Code ............................................. 50
5.3.2 Hold Instruction Code ................................... 50
5.3.3 Invalidity Date ......................................... 51
5.3.4 Certificate Issuer ...................................... 51
6 Certificate Path Validation ................................. 52
6.1 Basic Path Validation ..................................... 52
6.2 Extending Path Validation ................................. 56
7 Algorithm Support ........................................... 57
7.1 One-way Hash Functions .................................... 57
7.1.1 MD2 One-way Hash Function ............................... 57
7.1.2 MD5 One-way Hash Function ............................... 58
7.1.3 SHA-1 One-way Hash Function ............................. 58
7.2 Signature Algorithms ...................................... 58
7.2.1 RSA Signature Algorithm ................................. 59
7.2.2 DSA Signature Algorithm ................................. 60
7.3 Subject Public Key Algorithms ............................. 60
7.3.1 RSA Keys ................................................ 61
7.3.2 Diffie-Hellman Key Exchange Key ......................... 61
Housley, et. al. Standards Track [Page 3]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
7.3.3 DSA Signature Keys ...................................... 63
8 References .................................................. 64
9 Intellectual Property Rights ................................ 66
10 Security Considerations .................................... 67
Appendix A. ASN.1 Structures and OIDs ......................... 70
A.1 Explicitly Tagged Module, 1988 Syntax ...................... 70
A.2 Implicitly Tagged Module, 1988 Syntax ...................... 84
Appendix B. 1993 ASN.1 Structures and OIDs .................... 91
B.1 Explicitly Tagged Module, 1993 Syntax ...................... 91
B.2 Implicitly Tagged Module, 1993 Syntax ...................... 108
Appendix C. ASN.1 Notes ....................................... 116
Appendix D. Examples .......................................... 117
D.1 Certificate ............................................... 117
D.2 Certificate ............................................... 120
D.3 End-Entity Certificate Using RSA .......................... 123
D.4 Certificate Revocation List ............................... 126
Appendix E. Authors' Addresses ................................ 128
Appendix F. Full Copyright Statement .......................... 129
Housley, et. al. Standards Track [Page 4]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
1
This specification is one part of a family of standards for the X.509
Public Key Infrastructure (PKI) for the Internet. This
is a standalone document; implementations of this standard
proceed independent from the other parts
This specification profiles the format and semantics of
and certificate revocation lists for the Internet PKI.
are described for processing of certification paths in the
environment. Encoding rules are provided for popular
algorithms. Finally, ASN.1 modules are provided in the
for all data structures defined or referenced
The specification describes the requirements which inspire
creation of this document and the assumptions which affect its
in Section 2. Section 3 presents an architectural model
describes its relationship to previous IETF and ISO/IEC/
standards. In particular, this document's relationship with the
PEM specifications and the ISO/IEC/ITU X.509 documents are described
The specification profiles the X.509 version 3 certificate in
4, and the X.509 version 2 certificate revocation list (CRL)
Section 5. The profiles include the identification of ISO/IEC/ITU
ANSI extensions which may be useful in the Internet PKI. The
are presented in the 1988 Abstract Syntax Notation One (ASN.1)
than the 1994 syntax used in the ISO/IEC/ITU standards
This specification also includes path validation procedures
Section 6. These procedures are based upon the ISO/IEC/
definition, but the presentation assumes one or more self-
trusted CA certificates. Implementations are required to derive
same results but are not required to use the specified procedures
Section 7 of the specification describes procedures
identification and encoding of public key materials and
signatures. Implementations are not required to use any
cryptographic algorithms. However, conforming implementations
use the identified algorithms are required to identify and encode
public key materials and digital signatures as described
Finally, four appendices are provided to aid implementers.
A contains all ASN.1 structures defined or referenced within
specification. As above, the material is presented in the 1988
Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax
Appendix B contains the same information in the 1994 ASN.1
as a service to implementers using updated toolsets. However
Appendix A takes precedence in case of conflict. Appendix C
Housley, et. al. Standards Track [Page 5]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
notes on less familiar features of the ASN.1 notation used
this specification. Appendix D contains examples of a
certificate and a conforming CRL
2 Requirements and
The goal of this specification is to develop a profile to
the use of X.509 certificates within Internet applications for
communities wishing to make use of X.509 technology.
applications may include WWW, electronic mail, user authentication
and IPsec. In order to relieve some of the obstacles to using X.509
certificates, this document defines a profile to promote
development of certificate management systems; development
application tools; and interoperability determined by policy
Some communities will need to supplement, or possibly replace,
profile in order to meet the requirements of specialized
domains or environments with additional authorization, assurance,
operational requirements. However, for basic applications,
representations of frequently used attributes are defined so
application developers can obtain necessary information
regard to the issuer of a particular certificate or
revocation list (CRL).
A certificate user should review the certificate policy generated
the certification authority (CA) before relying on the
or non-repudiation services associated with the public key in
particular certificate. To this end, this standard does
prescribe legally binding rules or duties
As supplemental authorization and attribute management tools emerge
such as attribute certificates, it may be appropriate to limit
authenticated attributes that are included in a certificate.
other management tools may provide more appropriate methods
conveying many authenticated attributes
2.1 Communication and
The users of certificates will operate in a wide range
environments with respect to their communication topology,
users of secure electronic mail. This profile supports users
high bandwidth, real-time IP connectivity, or high
availability. In addition, the profile allows for the presence
firewall or other filtered communication
Housley, et. al. Standards Track [Page 6]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
This profile does not assume the deployment of an X.500
system. The profile does not prohibit the use of an X.500 Directory
but other means of distributing certificates and
revocation lists (CRLs) may be used
2.2 Acceptability
The goal of the Internet Public Key Infrastructure (PKI) is to
the needs of deterministic, automated identification, authentication
access control, and authorization functions. Support for
services determines the attributes contained in the certificate
well as the ancillary control information in the certificate such
policy data and certification path constraints
2.3 User
Users of the Internet PKI are people and processes who use
software and are the subjects named in certificates. These
include readers and writers of electronic mail, the clients for
browsers, WWW servers, and the key manager for IPsec within a router
This profile recognizes the limitations of the platforms these
employ and the limitations in sophistication and attentiveness of
users themselves. This manifests itself in minimal
configuration responsibility (e.g., trusted CA keys, rules),
platform usage constraints within the certificate, certification
constraints which shield the user from many malicious actions,
applications which sensibly automate validation functions
2.4 Administrator
As with user expectations, the Internet PKI profile is structured
support the individuals who generally operate CAs.
administrators with unbounded choices increases the chances that
subtle CA administrator mistake will result in broad compromise
Also, unbounded choices greatly complicate the software that
process and validate the certificates created by the CA
3 Overview of
Following is a simplified view of the architectural model assumed
the PKIX specifications
Housley, et. al. Standards Track [Page 7]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
+---+
| C | +------------+
| e | <-------------------->| End entity |
| r | Operational +------------+
| t | transactions ^
| | and management |
| / | transactions |
| | | PKI
| C |
| R | -------------------+--+-----------+----------------
| L | ^ ^
| | | | PKI
| | v |
| R | +------+ |
| e | <---------------------| RA | <---+ |
| p | Publish certificate +------+ | |
| o | | |
| s | | |
| I | v
| t | +------------+
| o | <------------------------------| CA |
| r | Publish certificate +------------+
| y | Publish CRL ^
| | |
+---+ Management |
transactions |
+------+
| CA |
+------+
Figure 1 - PKI
The components in this model are
end entity: user of PKI certificates and/or end user system
is the subject of a certificate
CA: certification authority
RA: registration authority, i.e., an optional system
which a CA delegates certain management functions
repository: a system or collection of distributed systems
store certificates and CRLs and serves as a means
distributing these certificates and CRLs to
entities
Housley, et. al. Standards Track [Page 8]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
3.1 X.509 Version 3
Users of a public key shall be confident that the associated
key is owned by the correct remote subject (person or system)
which an encryption or digital signature mechanism will be used
This confidence is obtained through the use of public
certificates, which are data structures that bind public key
to subjects. The binding is asserted by having a trusted
digitally sign each certificate. The CA may base this assertion
technical means (a.k.a., proof of posession through a challenge
response protocol), presentation of the private key, or on
assertion by the subject. A certificate has a limited valid
which is indicated in its signed contents. Because a certificate'
signature and timeliness can be independently checked by
certificate-using client, certificates can be distributed
untrusted communications and server systems, and can be cached
unsecured storage in certificate-using systems
ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 9594-8, which
first published in 1988 as part of the X.500
recommendations, defines a standard certificate format [X.509].
certificate format in the 1988 standard is called the version 1 (v1)
format. When X.500 was revised in 1993, two more fields were added
resulting in the version 2 (v2) format. These two fields may be
to support directory access control
The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
include specifications for a public key infrastructure based on X.509
v1 certificates [RFC 1422]. The experience gained in attempts
deploy RFC 1422 made it clear that the v1 and v2 certificate
are deficient in several respects. Most importantly, more
were needed to carry information which PEM design and
experience has proven necessary. In response to these
requirements, ISO/IEC/ITU and ANSI X9 developed the X.509 version 3
(v3) certificate format. The v3 format extends the v2 format
adding provision for additional extension fields.
extension field types may be specified in standards or may be
and registered by any organization or community. In June 1996,
standardization of the basic v3 format was completed [X.509].
ISO/IEC/ITU and ANSI X9 have also developed standard extensions
use in the v3 extensions field [X.509][X9.55]. These extensions
convey such data as additional subject identification information
key attribute information, policy information, and certification
constraints
Housley, et. al. Standards Track [Page 9]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
However, the ISO/IEC/ITU and ANSI X9 standard extensions are
broad in their applicability. In order to develop
implementations of X.509 v3 systems for Internet use, it is
to specify a profile for use of the X.509 v3 extensions tailored
the Internet. It is one goal of this document to specify a
for Internet WWW, electronic mail, and IPsec applications
Environments with additional requirements may build on this
or may replace it
3.2 Certification Paths and
A user of a security service requiring knowledge of a public
generally needs to obtain and validate a certificate containing
required public key. If the public-key user does not already hold
assured copy of the public key of the CA that signed the certificate
the CA's name, and related information (such as the validity
or name constraints), then it might need an additional certificate
obtain that public key. In general, a chain of multiple
may be needed, comprising a certificate of the public key owner (
end entity) signed by one CA, and zero or more
certificates of CAs signed by other CAs. Such chains,
certification paths, are required because a public key user is
initialized with a limited number of assured CA public keys
There are different ways in which CAs might be configured in
for public key users to be able to find certification paths.
PEM, RFC 1422 defined a rigid hierarchical structure of CAs.
are three types of PEM certification authority
(a) Internet Policy Registration Authority (IPRA):
authority, operated under the auspices of the Internet Society
acts as the root of the PEM certification hierarchy at level 1.
It issues certificates only for the next level of authorities
PCAs. All certification paths 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
shall establish and publish a statement of its policy with
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
electronic mail needs of commercial organizations, and another
(a high-assurance PCA) might have a more stringent policy
for satisfying legally binding digital signature requirements
Housley, et. al. Standards Track [Page 10]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
(c) Certification Authorities (CAs): CAs are at level 3 of
hierarchy and can also be at lower levels. Those at level 3
certified by PCAs. CAs represent, for example,
organizations, particular organizational units (e.g., departments
groups, sections), or particular geographical areas
RFC 1422 furthermore has a name subordination rule which
that a CA can only issue certificates for entities whose names
subordinate (in the X.500 naming tree) to the name of the CA itself
The trust associated with a PEM certification path is implied by
PCA name. The name subordination rule ensures that CAs below the
are sensibly constrained as to the set of subordinate entities
can certify (e.g., a CA for an organization can only certify
in that organization's name tree). Certificate user systems are
to mechanically check that the name subordination rule has
followed
The RFC 1422 uses the X.509 v1 certificate formats. The
of X.509 v1 required imposition of several structural restrictions
clearly associate policy information or restrict the utility
certificates. These restrictions included
(a) a pure top-down hierarchy, with all certification
starting from IPRA
(b) a naming subordination rule restricting the names of a CA'
subjects;
(c) use of the PCA concept, which requires knowledge of
PCAs to be built into certificate chain verification logic
Knowledge of individual PCAs was required to determine if a
could be accepted
With X.509 v3, most of the requirements addressed by RFC 1422 can
addressed using certificate extensions, without a need to
the CA structures used. In particular, the certificate
relating to certificate policies obviate the need for PCAs and
constraint extensions obviate the need for the name
rule. As a result, this document supports a more
architecture, including
(a) Certification paths may start with a public key of a CA in
user's own domain, or with the public key of the top of
hierarchy. Starting with the public key of a CA in a user's
domain has certain advantages. In some environments, the
domain is the most trusted
Housley, et. al. Standards Track [Page 11]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
(b) Name constraints may be imposed through explicit inclusion
a name constraints extension in a certificate, but are
required
(c) Policy extensions and policy mappings replace the
concept, which permits a greater degree of automation.
application can determine if the certification path is
based on the contents of the certificates instead of a
knowledge of PCAs. This permits automation of certificate
processing
3.3
When a certificate is issued, it is expected to be in use for
entire validity period. However, various circumstances may cause
certificate to become invalid prior to the expiration of the
period. Such circumstances include change of name, change
association between subject and CA (e.g., an employee
employment with an organization), and compromise or
compromise of the corresponding private key. Under
circumstances, the CA needs to revoke the certificate
X.509 defines one method of certificate revocation. This
involves each CA periodically issuing a signed data structure
a certificate revocation list (CRL). A CRL is a time stamped
identifying revoked certificates which is signed by a CA and
freely available in a public repository. Each revoked certificate
identified in a CRL by its certificate serial number. When
certificate-using system uses a certificate (e.g., for verifying
remote user's digital signature), that system not only checks
certificate signature and validity but also acquires a suitably
recent CRL and checks that the certificate serial number is not
that CRL. The meaning of "suitably-recent" may vary with
policy, but it usually means the most recently-issued CRL. A
issues a new CRL on a regular periodic basis (e.g., hourly, daily,
weekly). An entry is added to the CRL as part of the next
following notification of revocation. An entry may be removed
the CRL after appearing on one regularly scheduled CRL issued
the revoked certificate's validity period
An advantage of this revocation method is that CRLs may
distributed by exactly the same means as certificates themselves
namely, via untrusted communications and server systems
One limitation of the CRL revocation method, using
communications and servers, is that the time granularity
revocation is limited to the CRL issue period. For example, if
revocation is reported now, that revocation will not be
Housley, et. al. Standards Track [Page 12]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
notified to certificate-using systems until the next periodic CRL
issued -- this may be up to one hour, one day, or one week
on the frequency that the CA issues CRLs
As with the X.509 v3 certificate format, in order to
interoperable implementations from multiple vendors, the X.509 v2
format needs to be profiled for Internet use. It is one goal of
document to specify that profile. However, this profile does
require CAs to issue CRLs. Message formats and protocols
on-line revocation notification may be defined in other
specifications. On-line methods of revocation notification may
applicable in some environments as an alternative to the X.509 CRL
On-line revocation checking may significantly reduce the
between a revocation report and the distribution of the
to relying parties. Once the CA accepts the report as authentic
valid, any query to the on-line service will correctly reflect
certificate validation impacts of the revocation. However,
methods impose new security requirements; the certificate
shall trust the on-line validation service while the repository
not need to be trusted
3.4 Operational
Operational protocols are required to deliver certificates and
(or status information) to certificate using client systems
Provision is needed for a variety of different means of
and CRL delivery, including distribution procedures based on LDAP
HTTP, FTP, and X.500. Operational protocols supporting
functions are defined in other PKIX specifications.
specifications may include definitions of message formats
procedures for supporting all of the above operational environments
including definitions of or references to appropriate MIME
types
3.5 Management
Management protocols are required to support on-line
between PKI user and management entities. For example, a
protocol might be used between a CA and a client system with which
key pair is associated, or between two CAs which cross-certify
other. The set of functions which potentially need to be
by management protocols include
(a) registration: This is the process whereby a user first
itself known to a CA (directly, or through an RA), prior to
CA issuing a certificate or certificates for that user
Housley, et. al. Standards Track [Page 13]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
(b) initialization: Before a client system can operate
it is necessary to install key materials which have
appropriate relationship with keys stored elsewhere in
infrastructure. For example, the client needs to be
initialized with the public key and other assured information
the trusted CA(s), to be used in validating certificate paths
Furthermore, a client typically needs to be initialized with
own key pair(s).
(c) certification: This is the process in which a CA issues
certificate for a user's public key, and returns that
to the user's client system and/or posts that certificate in
repository
(d) key pair recovery: As an option, user client key
(e.g., a user's private key used for encryption purposes) may
backed up by a CA or a key backup system. If a user needs
recover these backed up key materials (e.g., as a result of
forgotten password or a lost key chain file), an on-line
exchange may be needed to support such recovery
(e) key pair update: All key pairs need to be updated regularly
i.e., replaced with a new key pair, and new certificates issued
(f) revocation request: An authorized person advises a CA of
abnormal situation requiring certificate revocation
(g) cross-certification: Two CAs exchange information used
establishing a cross-certificate. A cross-certificate is
certificate issued by one CA to another CA which contains a
signature key used for issuing certificates
Note that on-line protocols are not the only way of implementing
above functions. For all functions there are off-line methods
achieving the same result, and this specification does not
use of on-line protocols. For example, when hardware tokens
used, many of the functions may be achieved as part of the
token delivery. Furthermore, some of the above functions may
combined into one protocol exchange. In particular, two or more
the registration, initialization, and certification functions can
combined into one protocol exchange
The PKIX series of specifications may define a set of
message formats supporting the above functions in
specifications. In that case, the protocols for conveying
messages in different environments (e.g., on-line, file transfer, e
mail, and WWW) will also be described in those specifications
Housley, et. al. Standards Track [Page 14]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
4 Certificate and Certificate Extensions
This section presents a profile for public key certificates that
foster interoperability and a reusable PKI. This section is
upon the X.509 v3 certificate format and the standard
extensions defined in [X.509]. The ISO/IEC/ITU documents use
1993 version of ASN.1; while this document uses the 1988 ASN.1
syntax, the encoded certificate and standard extensions
equivalent. This section also defines private extensions required
support a PKI for the Internet community
Certificates may be used in a wide range of applications
environments covering a broad spectrum of interoperability goals
a broader spectrum of operational and assurance requirements.
goal of this document is to establish a common baseline for
applications requiring broad interoperability and limited
purpose requirements. In particular, the emphasis will be
supporting the use of X.509 v3 certificates for informal
electronic mail, IPsec, and WWW applications
4.1 Basic Certificate
The X.509 v3 certificate basic syntax is as follows. For
calculation, the certificate is encoded using the ASN.1
encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length
value encoding system for each element
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate
signatureAlgorithm AlgorithmIdentifier
signatureValue BIT STRING }
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber
signature AlgorithmIdentifier
issuer Name
validity Validity
subject Name
subjectPublicKeyInfo SubjectPublicKeyInfo
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL
-- If present, version shall be v2 or v
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL
-- If present, version shall be v2 or v
extensions [3] EXPLICIT Extensions
-- If present, version shall be v
}
Housley, et. al. Standards Track [Page 15]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::=
Validity ::= SEQUENCE {
notBefore Time
notAfter Time }
Time ::= CHOICE {
utcTime UTCTime
generalTime GeneralizedTime }
UniqueIdentifier ::= BIT
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier
subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE SIZE (1..MAX) OF
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER
critical BOOLEAN DEFAULT FALSE
extnValue OCTET STRING }
The following items describe the X.509 v3 certificate for use in
Internet
4.1.1 Certificate
The Certificate is a SEQUENCE of three required fields. The
are described in detail in the following subsections
4.1.1.1
The field contains the names of the subject and issuer, a public
associated with the subject, a validity period, and other
information. The fields are described in detail in section 4.1.2;
the tbscertificate may also include extensions which are described
section 4.2.
4.1.1.2
The signatureAlgorithm field contains the identifier for
cryptographic algorithm used by the CA to sign this certificate
Section 7.2 lists the supported signature algorithms
An algorithm identifier is defined by the following ASN.1 structure
Housley, et. al. Standards Track [Page 16]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER
parameters ANY DEFINED BY algorithm OPTIONAL }
The algorithm identifier is used to identify a
algorithm. The OBJECT IDENTIFIER component identifies the
(such as DSA with SHA-1). The contents of the optional
field will vary according to the algorithm identified. Section 7.2
lists the supported algorithms for this specification
This field MUST contain the same algorithm identifier as
signature field in the sequence tbsCertificate (see sec. 4.1.2.3).
4.1.1.3
The signatureValue field contains a digital signature computed
the ASN.1 DER encoded tbsCertificate. The ASN.1 DER
tbsCertificate is used as the input to the signature function.
signature value is then ASN.1 encoded as a BIT STRING and included
the Certificate's signature field. The details of this process
specified for each of the supported algorithms in Section 7.2.
By generating this signature, a CA certifies the validity of
information in the tbsCertificate field. In particular, the
certifies the binding between the public key material and the
of the certificate
4.1.2
The sequence TBSCertificate contains information associated with
subject of the certificate and the CA who issued it.
TBSCertificate contains the names of the subject and issuer, a
key associated with the subject, a validity period, a version number
and a serial number; some may contain optional unique
fields. The remainder of this section describes the syntax
semantics of these fields. A TBSCertificate may also
extensions. Extensions for the Internet PKI are described in
4.2.
4.1.2.1
This field describes the version of the encoded certificate.
extensions are used, as expected in this profile, use X.509 version 3
(value is 2). If no extensions are present, but a
is present, use version 2 (value is 1). If only basic fields
present, use version 1 (the value is omitted from the certificate
the default value).
Housley, et. al. Standards Track [Page 17]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
Implementations SHOULD be prepared to accept any version certificate
At a minimum, conforming implementations MUST recognize version 3
certificates
Generation of version 2 certificates is not expected
implementations based on this profile
4.1.2.2 Serial
The serial number is an integer assigned by the CA to
certificate. It MUST be unique for each certificate issued by
given CA (i.e., the issuer name and serial number identify a
certificate).
4.1.2.3
This field contains the algorithm identifier for the algorithm
by the CA to sign the certificate
This field MUST contain the same algorithm identifier as
signatureAlgorithm field in the sequence Certificate (see sec
4.1.1.2). The contents of the optional parameters field will
according to the algorithm identified. Section 7.2 lists
supported signature algorithms
4.1.2.4
The issuer field identifies the entity who has signed and issued
certificate. The issuer field MUST contain a non-empty
name (DN). The issuer field is defined as the X.501 type Name
[X.501] Name is defined by the following ASN.1 structures
Name ::= CHOICE {
RDNSequence }
RDNSequence ::= SEQUENCE OF
RelativeDistinguishedName ::=
SET OF
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType
value AttributeValue }
AttributeType ::= OBJECT
AttributeValue ::= ANY DEFINED BY
Housley, et. al. Standards Track [Page 18]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1.. MAX)),
bmpString BMPString (SIZE (1..MAX)) }
The Name describes a hierarchical name composed of attributes,
as country name, and corresponding values, such as US. The type
the component AttributeValue is determined by the AttributeType;
general it will be a DirectoryString
The DirectoryString type is defined as a choice of PrintableString
TeletexString, BMPString, UTF8String, and UniversalString.
UTF8String encoding is the preferred encoding, and all
issued after December 31, 2003 MUST use the UTF8String encoding
DirectoryString (except as noted below). Until that date,
CAs MUST choose from the following options when creating
distinguished name, including their own
(a) if the character set is sufficient, the string MAY
represented as a PrintableString
(b) failing (a), if the BMPString character set is sufficient
string MAY be represented as a BMPString;
(c) failing (a) and (b), the string MUST be represented as
UTF8String. If (a) or (b) is satisfied, the CA MAY still
to represent the string as a UTF8String
Exceptions to the December 31, 2003 UTF8 encoding requirements are
follows
(a) CAs MAY issue "name rollover" certificates to support
orderly migration to UTF8String encoding. Such certificates
include the CA's UTF8String encoded name as issuer and and the
name encoding as subject, or vice-versa
(b) As stated in section 4.1.2.6, the subject field MUST
populated with a non-empty distinguished name matching
contents of the issuer field in all certificates issued by
subject CA regardless of encoding
The TeletexString and UniversalString are included for
compatibility, and should not be used for certificates for
subjects. However, these types may be used in certificates where
name was previously established. Certificate users SHOULD
prepared to receive certificates with these types
Housley, et. al. Standards Track [Page 19]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
In addition, many legacy implementations support names encoded in
ISO 8859-1 character set (Latin1String) but tag them
TeletexString. The Latin1String includes characters used in
European countries which are not part of the TeletexString
set. Implementations that process TeletexString SHOULD be
to handle the entire ISO 8859-1 character set.[ISO 8859-1]
As noted above, distinguished names are composed of attributes.
specification does not restrict the set of attribute types that
appear in names. However, conforming implementations MUST
prepared to receive certificates with issuer names containing the
of attribute types defined below. This specification also
support for additional attribute types
Standard sets of attributes have been defined in the X.500 series
specifications.[X.520] Implementations of this specification MUST
prepared to receive the following standard attribute types in
names: country, organization, organizational-unit, distinguished
qualifier, state or province name, and common name (e.g., "
Housley"). In addition, implementations of this specification
be prepared to receive the following standard attribute types
issuer names: locality, title, surname, given name, initials,
generation qualifier (e.g., "Jr.", "3rd", or "IV"). The syntax
associated object identifiers (OIDs) for these attribute types
provided in the ASN.1 modules in Appendices A and B
In addition, implementations of this specification MUST be
to receive the domainComponent attribute, as defined in [RFC 2247].
The Domain (Nameserver) System (DNS) provides a hierarchical
labeling system. This attribute provides is a convenient
for organizations that wish to use DNs that parallel their DNS names
This is not a replacement for the dNSName component of
alternative name field. Implementations are not required to
such names into DNS names. The syntax and associated OID for
attribute type is provided in the ASN.1 modules in Appendices A
B
Certificate users MUST be prepared to process the
distinguished name and subject distinguished name (see sec. 4.1.2.6)
fields to perform name chaining for certification path
(see section 6). Name chaining is performed by matching the
distinguished name in one certificate with the subject name in a
certificate
This specification requires only a subset of the name
functionality specified in the X.500 series of specifications.
requirements for conforming implementations are as follows
Housley, et. al. Standards Track [Page 20]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
(a) attribute values encoded in different types (e.g.,
PrintableString and BMPString) may be assumed to
different strings
(b) attribute values in types other than PrintableString are
sensitive (this permits matching of attribute values as
objects);
(c) attribute values in PrintableString are not case
(e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON");
(d) attribute values in PrintableString are compared
removing leading and trailing white space and converting
substrings of one or more consecutive white space characters to
single space
These name comparison rules permit a certificate user to
certificates issued using languages or encodings unfamiliar to
certificate user
In addition, implementations of this specification MAY use
comparison rules to process unfamiliar attribute types for
chaining. This allows implementations to process certificates
unfamiliar attributes in the issuer name
Note that the comparison rules defined in the X.500 series
specifications indicate that the character sets used to encode
in distinguished names are irrelevant. The characters themselves
compared without regard to encoding. Implementations of the
are permitted to use the comparison algorithm defined in the X.500
series. Such an implementation will recognize a superset of
matches recognized by the algorithm specified above
4.1.2.5
The certificate validity period is the time interval during which
CA warrants that it will maintain information about the status of
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 validity period
(notAfter). Both notBefore and notAfter may be encoded as UTCTime
GeneralizedTime
CAs conforming to this profile MUST always encode
validity dates through the year 2049 as UTCTime; certificate
dates in 2050 or later MUST be encoded as GeneralizedTime
Housley, et. al. Standards Track [Page 21]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
4.1.2.5.1
The universal time type, UTCTime, is a standard ASN.1 type
for international applications where local time alone is
adequate. UTCTime specifies the year through the two low
digits and time is specified to the precision of one minute or
second. UTCTime includes either Z (for Zulu, or Greenwich Mean Time
or a time differential
For the purposes of this profile, UTCTime values MUST be
Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times
YYMMDDHHMMSSZ), even where the number of seconds is zero.
systems MUST interpret the year field (YY) as follows
Where YY is greater than or equal to 50, the year shall
interpreted as 19YY;
Where YY is less than 50, the year shall be interpreted as 20YY
4.1.2.5.2
The generalized time type, GeneralizedTime, is a standard ASN.1
for variable precision representation of time. Optionally,
GeneralizedTime field can include a representation of the
differential between local and Greenwich Mean Time
For the purposes of this profile, GeneralizedTime values MUST
expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero
GeneralizedTime values MUST NOT include fractional seconds
4.1.2.6
The subject field identifies the entity associated with the
key stored in the subject public key field. The subject name may
carried in the subject field and/or the subjectAltName extension.
the subject is a CA (e.g., the basic constraints extension,
discussed in 4.2.1.10, is present and the value of cA is TRUE,)
the subject field MUST be populated with a non-empty
name matching the contents of the issuer field (see sec. 4.1.2.4)
all certificates issued by the subject CA. If subject
information is present only in the subjectAltName extension (e.g.,
key bound only to an email address or URI), then the subject
MUST be an empty sequence and the subjectAltName extension MUST
critical
Housley, et. al. Standards Track [Page 22]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
Where it is non-empty, the subject field MUST contain an X.500
distinguished name (DN). The DN MUST be unique for each
entity certified by the one CA as defined by the issuer name field.
CA may issue more than one certificate with the same DN to the
subject entity
The subject name field is defined as the X.501 type Name
Implementation requirements for this field are those defined for
issuer field (see sec. 4.1.2.4). When encoding attribute values
type DirectoryString, the encoding rules for the issuer field MUST
implemented. Implementations of this specification MUST be
to receive subject names containing the attribute types required
the issuer field. Implementations of this specification SHOULD
prepared to receive subject names containing the
attribute types for the issuer field. The syntax and
object identifiers (OIDs) for these attribute types are provided
the ASN.1 modules in Appendices A and B. Implementations of
specification MAY use these comparison rules to process
attribute types (i.e., for name chaining). This
implementations to process certificates with unfamiliar attributes
the subject name
In addition, legacy implementations exist where an RFC 822 name
embedded in the subject distinguished name as an
attribute. The attribute value for EmailAddress is of type IA5
to permit inclusion of the character '@', which is not part of
PrintableString character set. EmailAddress attribute values are
case sensitive (e.g., "fanfeedback@redsox.com" is the same
"FANFEEDBACK@REDSOX.COM").
Conforming implementations generating new certificates
electronic mail addresses MUST use the rfc822Name in the
alternative name field (see sec. 4.2.1.7) to describe
identities. Simultaneous inclusion of the EmailAddress attribute
the subject distinguished name to support legacy implementations
deprecated but permitted
4.1.2.7 Subject Public Key
This field is used to carry the public key and identify the
with which the key is used. The algorithm is identified using
AlgorithmIdentifier structure specified in section 4.1.1.2.
object identifiers for the supported algorithms and the methods
encoding the public key materials (public key and parameters)
specified in section 7.3.
Housley, et. al. Standards Track [Page 23]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
4.1.2.8 Unique
These fields may only appear if the version is 2 or 3 (see sec
4.1.2.1). The subject and issuer unique identifiers are present
the certificate to handle the possibility of reuse of subject and/
issuer names over time. This profile recommends that names not
reused for different entities and that Internet certificates not
use of unique identifiers. CAs conforming to this profile SHOULD
generate certificates with unique identifiers.
conforming to this profile SHOULD be capable of parsing
identifiers and making comparisons
4.1.2.9
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
extensions. The format and content of certificate extensions in
Internet PKI is defined in section 4.2.
4.2 Standard Certificate
The extensions defined for X.509 v3 certificates provide methods
associating additional attributes with users or public keys and
managing the certification hierarchy. The X.509 v3
format also allows communities to define private extensions to
information unique to those communities. Each extension in
certificate may be designated as critical or non-critical.
certificate using system MUST reject the certificate if it
a critical extension it does not recognize; however, a non-
extension may be ignored if it is not recognized. The
sections present recommended extensions used within
certificates and standard locations for information. Communities
elect to use additional extensions; however, caution should
exercised in adopting any critical extensions in certificates
might prevent use in a general context
Each extension includes an OID and an ASN.1 structure. When
extension appears in a certificate, the OID appears as the
extnID and the corresponding ASN.1 encoded structure is the value
the octet string extnValue. Only one instance of a
extension may appear in a particular certificate. For example,
certificate may contain only one authority key identifier
(see sec. 4.2.1.1). An extension includes the boolean critical,
a default value of FALSE. The text for each extension specifies
acceptable values for the critical field
Housley, et. al. Standards Track [Page 24]
RFC 2459 Internet X.509 Public Key Infrastructure January 1999
Conforming CAs MUST support key identifiers (see sec. 4.2.1.1
4.2.1.2), basic 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.
the CA issues certificates with an empty sequence for the
field, the CA MUST support the subject alternative name
(see sec. 4.2.1.7). Support for the remaining extensions
OPTIONAL. Conforming CAs may support extensions that are
identified within this specification; certificate issuers
cautioned that marking such extensions as critical may
interoperability
At a minimum, applications conforming to this profile MUST
the extensions which must or may be critical in this specification
These extensions are: key usage (see sec. 4.2.1.3),
policies (see sec. 4.2.1.5), the subject alternative name (see sec
4.2.1.7), basic constraints (see sec. 4.2.1.10), name
(see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12),
extended key usage (see sec. 4.2.1.13).
In addition, this profile RECOMMENDS application support for
authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2)
extensions
4.2.1 Standard
This section identifi