ITU-T X.

509
SERIES X: Directory
Information technology – Open systems
interconnection – The Directory: Public-key
and attribute certificate frameworks
(10/2016)
-
-2016-Summary
Recommendation ITU-T X.509 | ISO/IEC 9594-8 defines frameworks for public-key infrastructure (PKI) and privilege
management infrastructure (PMI). It introduces the basic concept of asymmetric cryptographic techniques. It specifies the
following data types:
• public-key certificate,
• attribute certificate,
• certificate revocation list (CRL) and
• attribute certificate revocation list (ACRL).
-It also defines several certificates and CRL extensions, and it defines directory schema information allowing PKI and PMI related
data to be stored in a directory.
-In addition, it defines entity types, such as
• Certification authority (CA),
• attribute authority (AA),
• relying party,
• privilege verifier,
• trust broker and
• trust anchor.
-It specifies the principles for
• certificate validation,
• validation path,
• certificate policy etc.
It includes a specification for authorization validation lists that allow for fast validation and restrictions on communications. It
includes protocols necessary for maintaining authorization validation lists and a protocol for accessing a trust broker.
-2008-Introduction
This Recommendation | International Standard, together with other Recommendations | International Standards, has
been produced to facilitate the interconnection of information processing systems to provide directory services.
-A set of such systems, together with the directory information which they hold, can be viewed as an integrated whole, called the
Directory.
-The information held by the Directory, collectively known as the Directory Information Base (DIB), is typically used to facilitate
communication between, with or about objects such as
application-entities,
people,
terminals and
distribution lists.
-
-2008-The Directory plays a significant role in Open Systems Interconnection, whose aim is to allow, with a minimum of
technical agreement outside of the interconnection standards themselves, the interconnection of information processing
systems:
– from different manufacturers;
– under different managements;
– of different levels of complexity; and
– of different ages.
-Many applications have requirements for security to protect against threats to the communication of information.
Virtually all security services are dependent upon the identities of the communicating parties being reliably known, i.e.,
authentication.
-This Recommendation | International Standard defines a framework for public-key certificates. That framework
includes specification of data objects used to represent the certificates themselves as well as revocation notices for
issued certificates that should no longer be trusted.
-The public-key certificate framework defined in this
Recommendation | International Standard, while it defines some critical components of a Public-key Infrastructure
(PKI), it does not define a PKI in its entirety. However, this Recommendation | International Standard provides the
foundation upon which full PKIs and their specifications would be built.
-Similarly, this Recommendation | International Standard defines a framework for attribute certificates.
-The attribute certificate framework defined in this Recommendation | International Standard, while it defines some critical
components of a Privilege Management Infrastructure (PMI), does not define a PMI in its entirety.
-This Recommendation | International Standard also defines a framework for the provision of authentication services by
the Directory to its users.
-2016-Introduction
Many applications have requirements for security to protect against threats to the communication of information. Virtually
all security services are dependent upon the identities of the communicating parties being reliably known, i.e.,
authenticated.
-This Recommendation | International Standard defines a framework for public-key certificates. This framework includes
the specification of data objects used to represent the public-key certificates themselves, as well as revocation notices for
issued public-key certificates that should no longer be trusted. It defines some critical components of a public-key
infrastructure (PKI), but it does not define a PKI in its entirety. However, this Recommendation | International Standard
provides the foundation upon which full PKIs and their specifications can be built.
-Similarly, this Recommendation | International Standard defines a framework for attribute certificates.
-It defines some critical components of a privilege management infrastructure (PMI), but it does not define a PMI in its entirety.
-Schema definitions are defined for holding PKI and PMI information in a directory according to the specification found
in the ITU-T X.500 series of Recommendations | ISO/IEC 9594 (all parts) or according to the lightweight directory access
protocol (LDAP) specification.
-The extensibility function was added in an earlier edition with version 3 of the public-key certificate and with version 2
of the certificate revocation list and was incorporated into the attribute certificate from its initial inception.
1 Scope
This Recommendation | International Standard addresses some of the security requirements in the areas of authentication
and other security services through the provision of a set of frameworks upon which full services can be based. Specifically,
this Recommendation | International Standard defines frameworks for:
– public-key certificates; and
– attribute certificates.
-2008-SECTION 1 – GENERAL
1 Scope
This Recommendation | International Standard addresses some of the security requirements in the areas of
authentication and other security services through the provision of a set of frameworks upon which full services can be
based. Specifically, this Recommendation | International Standard defines frameworks for:
– Public-key certificates;
– Attribute certificates;
– Authentication services.
-The public-key certificate framework defined in this Recommendation | International Standard includes definition of the
information objects for Public Key Infrastructure (PKI), including
public-key certificates, and
Certificate Revocation List (CRL).
-The attribute certificate framework includes definition of the information objects for Privilege Management
Infrastructure (PMI), including
attribute certificates, and
Attribute Certificate Revocation List (ACRL).
-This Recommendation | International Standard also provides the framework for issuing, managing, using and revoking
certificates.
-The schema components (including object classes, attribute types and matching rules) for storing PKI and PMI objects in the
Directory, are included in this Recommendation | International Standard.
-Other elements of PKI and PMI, beyond these frameworks, such as key and certificate management protocols, operational
protocols, additional certificate and CRL extensions are expected to be defined by other standards bodies (e.g., ISO TC 68, IETF,
etc.).
-2008-The Directory makes use of public-key certificates and attribute certificates, and the framework for the Directory's use
of these facilities is also defined in this Recommendation | International Standard.
-Public-key technology, including certificates, is used by the Directory to enable
• strong authentication,
• signed and/or encrypted operations, and
• for storage of signed and/or encrypted data in the Directory.

-Attribute certificates can be used by the Directory to enable rule-based access control.
-Although the framework for these is provided in this Recommendation | International Standard, the full
definition of the Directory's use of these frameworks, and the associated services provided by the Directory and its
components is supplied in the complete set of X.500 ITU-T series of Recommendation | ISO/IEC 9594 (all parts).
-This Recommendation | International Standard, in the Authentication services framework, also:
– specifies the form of authentication information held by the Directory;
– describes how authentication information may be obtained from the Directory;
– states the assumptions made about how authentication information is formed and placed in the Directory;
– defines three ways in which applications may use this authentication information to perform
authentication and describes how other security services may be supported by authentication.
-This Recommendation | International Standard describes two levels of authentication: simple authentication, using a
password as a verification of claimed identity; and strong authentication, involving credentials formed using
cryptographic techniques. While simple authentication offers some limited protection against unauthorized access, only
strong authentication should be used as the basis for providing secure services. It is not intended to establish this as a
general framework for authentication, but it can be of general use for applications which consider these techniques
adequate.
-2008-Authentication (and other security services) can only be provided within the context of a defined security policy. It is a
matter for users of an application to define their own security policy which may be constrained by the services provided
by a standard.
-It is a matter for standards-defining applications which use the authentication framework to specify the protocol
exchanges which need to be performed in order to achieve authentication based upon the authentication information
obtained from the Directory. The protocol used by applications to obtain credentials from the Directory is the Directory
Access Protocol (DAP), specified in ITU-T Rec. X.519 | ISO/IEC 9594-5.
-– ITU-T Recommendation X.812 (1995) | ISO/IEC 10181-3:1996, Information technology – Open Systems
Interconnection – Security frameworks for open systems: Access control framework.
– ITU-T Recommendation X.813 (1996) | ISO/IEC 10181-4:1997, Information technology – Open Systems
Interconnection – Security frameworks for open systems: Non-repudiation framework.
2.2 Paired Recommendations | International Standards equivalent in technical content
– CCITT Recommendation X.800 (1991), Security Architecture for Open Systems Interconnection for
CCITT applications.
ISO 7498-2:1989, Information processing systems – Open Systems Interconnection – Basic Reference
Model – Part 2: Security Architecture.
2.3 Other references
– IETF RFC 5280 (2008), Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile.
-The public-key certificate framework defined in this Recommendation | International Standard specifies the information
objects and data types for a public-key infrastructure (PKI), including
• public-key certificates,
• certificate revocation lists (CRLs),
• trust broker and
• authorization and validation lists (AVLs).

-The attribute certificate framework specifies the information objects and data types for a privilege management infrastructure
(PMI), including
• attribute certificates, and
• attribute certificate revocation lists (ACRLs).
-This Recommendation | International Standard also provides the framework for
• issuing,
• managing,
• using and revoking
certificates.
-An extensibility mechanism is included in the defined formats for both certificate types and for all revocation list schemes.
-This Recommendation | International Standard also includes a set of extensions, which is expected to be generally useful across
a number of applications of PKI and PMI.
-The schema components (including object classes, attribute types and matching rules) for storing PKI and PMI information in a
directory, are included in this Recommendation | International Standard.
-This Recommendation | International Standard specifies the framework for strong authentication, involving credentials
formed using cryptographic techniques. It is not intended to establish this as a general framework for authentication, but it
can be of general use for applications which consider these techniques adequate.
-Authentication (and other security services) can only be provided within the context of a defined security policy. It is a
matter for users of an application to define their own security policy.
2 Normative references
2.1 Identical Recommendations | International Standards
…
– Recommendation ITU-T X.812 (1995) | ISO/IEC 10181-3:1996, Information technology – Open Systems
Interconnection – Security frameworks for open systems: Access control framework.
– Recommendation ITU-T X.813 (1996) | ISO/IEC 10181-4:1997, Information technology – Open Systems
Interconnection – Security frameworks for open systems: Non-repudiation framework.
– Recommendation ITU-T X.841 (2000) | ISO/IEC 15816:2002, Information technology – Security
techniques – Security information objects for access control.
2.2 Paired Recommendations | International Standards equivalent in technical content
– Recommendation ITU-T X.800 (1991), Security architecture for Open Systems Interconnection for CCITT
applications.
ISO 7498-2:1989, Information processing systems – Open Systems Interconnection – Basic Reference
Model – Part 2: Security Architecture.
2.3 Recommendations
– Recommendation ITU-T X.1252 (2010), Baseline identity management terms and definitions.
-2.4 Other references
– IETF RFC 791 (1981), Internet Protocol.
– IETF RFC 822 (1982), Standard for the Format of ARPA Internet Text Messages.
– IETF RFC 1630 (1994), Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of
Names and Addresses of Objects on the Network as used in the World-Wide Web.
– IETF RFC 3492 (2003), Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names
in Applications (IDNA).
– IETF RFC 4511 (2006), Lightweight Directory Access Protocol (LDAP): The Protocol.
– IETF RFC 4523 (2006), Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509
Certificates.
– IETF RFC 5280 (2008), Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile.
– IETF RFC 5890 (2010), Internationalized Domain Names for Applications (IDNA): Definitions and
Document Framework.
– IETF RFC 5914 (2010), Trust Anchor Format.
– IETF RFC 6960 (2013), X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
-3.5.36 hash function: A (mathematical) function which maps data of arbitrary size into data of a fixed size called a
digest.
-3.5.41 key agreement: A method for negotiating a symmetric key value on-line without transferring the key, even in
an encrypted form, e.g., the Diffie-Hellman technique (see ISO/IEC 11770-1 for more information on key agreement
mechanisms).
3.5.49 private key: (In a public-key cryptosystem) that key of an entity's key pair which is known only by that entity.
3.5.56 public key: That key of an entity's key pair which is publicly known.
3.5.57 public-key certificate: The public key of an entity, together with some other information, rendered unforgeable
by digital signature with the private key of the certification authority (CA) that issued it.
3.5.58 public-key certificate validation: The process of ensuring that a public-key certificate was valid at a given time,
including possibly the construction and processing of a certification path, and ensuring that all public-key certificates in
that path were valid (e.g., were not expired or revoked) at that given time.
3.5.53 privilege management infrastructure (PMI): The infrastructure able to support the management of privileges
in support of a comprehensive authorization service and in relationship with a public-key infrastructure.
3.5.59 public-key infrastructure (PKI): The infrastructure able to support the management of public keys able to
support authentication, encryption, integrity or non-repudiation services.
3.5.60 registration authority (RA): Those aspects of the responsibilities of a certification authority that are related to
identification and authentication of the subject of a public-key certificate to be issued by that certification authority. An
RA may either be a separate entity or be an integrated part of the certification authority.
NOTE – This definition is different in scope from the one defined in Rec. ITU-T X.660 | ISO/IEC 9834-1.
3.5.76 trust in a public-key certificate: Belief that the public-key certificate belongs to the subject identified in the
public-key certificate.
-6 Frameworks overview
This Specification defines a framework for obtaining and trusting a public key of an entity in order to verify the digital signature of
that entity.
-If the key pair is of a type that allows encryption and decryption, the public key may also be used for encrypting information to
be decrypted by the entity owning the private key.
-The framework includes the issuance of a public-key certificate by a certification authority (CA) and the validation of that public-
key certificate by the relying party, i.e., the entity relying on the content of the public-key certificate. The validation includes:
– establishing a trusted path of public-key certificates between a trusted entity called a trust anchor (see clause 7.5) and the
public-key certificate subject, i.e., the entity for which the public-key certificate has been issued;
– verifying the digital signatures on each public-key certificate in the path; and
– validating all the public-key certificates along that path (i.e., that they obey restrictions, were not expired or not revoked at a
given time); and
– optionally, asking a trust broker if the public-key certificate can be trusted for the intended purpose.
-The public-key infrastructure (PKI) is the infrastructure established to support the issuing, revocation and validation of public-key
certificates.
-This Specification defines a framework for obtaining and trusting privilege attributes of an entity in order to determine
whether they are authorized to access a particular resource. The framework includes the issuance of an attribute certificate
by an attribute authority (AA) and the validation of that attribute certificate by a privilege verifier. The validation includes:
– ensuring that the privileges in the attribute certificate are sufficient when compared against the privilege policy;
– establishing a trusted delegation path of attribute certificates if necessary;
– verifying the digital signature on each attribute certificate in the path;
– ensuring that each issuer was authorized to delegate privileges; and
– validating that the attribute certificates have not expired or been revoked by their issuers.
-Privileges are provided in directory attributes as defined by Rec. ITU-T X.501 | ISO/IEC 9594-2.
-Public-key certificates may also include directory attributes for providing privileges. Such aspects of privileges carried by
public-key certificates are also covered by the attribute certificate framework within Section 3.
-The privilege management infrastructure (PMI) is the infrastructure established to support the issuing, revocation and
validation of attribute-key certificates.
-Although PKI and PMI are separate infrastructures and may be established independently from one another, they are
related. This Specification recommends that holders and issuers of attribute certificates be identified within attribute certificates
by pointers to their appropriate public-key certificates.
-Authentication of the attribute certificate issuers and
holders, to ensure that entities claiming privilege and issuing privilege are who they claim to be, is done using the normal
processes of the PKI to authenticate identities. This authentication process is not duplicated within the attribute certificate
framework.
-An entity may take one more roles in a PKI and/or a PMI. It may act as a CA, as an AA, as an end entity in a PKI
environment (PKI end entity), as an end entity in a PMI environment (PMI end entity), as a relying party, etc.
-A PKI end entity is an entity that has been assigned an end-entity public-key certificate, where the private key cannot be
used to sign other public-key certificates, but may be used for signing for other purposes. A PMI end entity is an entity
that uses its end-entity attribute certificate to assess privilege, but it cannot be used for delegating such privilege to other
entities.
-This Specification makes extensive use of cryptographic algorithms, such as hashing algorithms, public-key algorithms
and digital signature algorithms. Annex H introduces these algorithms.

6.1 Digital signatures

-There are different types of digital signatures, such as
• Rivest-Shamir-Adelman (RSA) digital signatures,
• digital signature algorithm (DSA) digital signatures and
• elliptic curve digital signature algorithm (ECDSA) digital signatures.
NOTE 1 – It is not within the scope of this Specification to describe these different techniques in detail, but Annex F gives a short
introduction with references to more detailed specifications.
An introduction to public key cryptography
-In conventional cryptographic systems, the key used to encipher information by the originator of a secret message is the same as
that used to decipher the message by the legitimate recipient.
-In public key cryptosystems (PKCS), however, keys come in pairs, one key of which is used for enciphering and the other for
deciphering.
-Each key pair is associated with a particular user X.
-One of the keys, known as the public key (Xp) is publicly known, and can be used by any user to encipher data.
-Only X, who possesses the complementary private key (Xs) may decipher the data.
-This is represented notationally by D = Xs[Xp[D]]

-It is computationally unfeasible to derive the private key from

knowledge of the public key.
-Any user can thus communicate a piece of
information which only X can find out, by enciphering it under Xp.
An introduction to public key cryptography
By extension, two users can communicate in secret, by using each other's public key to encipher the data, as shown in Figure E.1.
-User A has public key Ap and private key As, and user B has another set of keys, Bp and Bs. A and B both know the public keys of
each other, but are unaware of the private key of the other party. A and B may therefore exchange secret information with one
another using the following steps (illustrated in Figure E.1).
1) A wishes to send some secret information x to B. A therefore enciphers x under B's enciphering key and sends the enciphered
information e to B. This is represented by:
e = Bp[x]
2) B may now decipher this encipherment e to obtain the information x by using the secret decipherment key Bs. Note that B is
the only possessor of Bs, and because this key may never be disclosed or sent, it is impossible for any other party to obtain the
information x. The possession of Bs determines the identity of B. The decipherment operation is represented by:
x = Bs[e], or x = Bs[Bp[x]]
3) B may now similarly send some secret information, x', to A, under A's enciphering key, Ap:
e' = Ap[x']
4) A obtains x' by deciphering e':
x' = As[e'], or x' = As[Ap[x']]
-By this means, A and B have exchanged secret information x and x'. This
information may not be obtained by anyone other than A and B,
providing that their private keys are not revealed.
An introduction to public key cryptography
Such an exchange can, as well as transferring secret information between the parties, serve to verify their identities. Specifically,
A and B are identified by their possession of the secret deciphering keys, As and Bs respectively. A may determine if B is in
possession of the secret deciphering key, Bs, by having returned part of his information x in B's message x'. This indicates to A
that communication is taking place with the possessor of Bs. B may similarly test the identity of A.
-It is a property of some PKCS that the steps of decipherment and encipherment can be reversed, as in D = Xp[Xs[D]]. This allows
a piece of information which could only have been originated by X, to be readable by any user (who has possession of Xp). This
can, therefore, be used in the certifying of the source of information, and is the basis for digital signatures. Only PKCS which have
this (permutability) property are suitable for use in this authentication framework. One such algorithm is described in Annex D.
-X.509(08)
Xp: Public key of a user X
Xs: Private key of X
Xp[I]: Encipherment of some information, I, using the public key of X
Xs[I]: Encipherment of I using the private key of X
-Figure 1 illustrates how a signer of instances of PKI/PMI data types (public-key certificates, attribute certificates,
revocation lists, etc.) creates a digital signature and then adds that to the data before transmission. It also illustrates how
the recipient of the signed data (the validator) validates the digital signature.
The digital signature signer goes through the following procedure:
1) The signer creates a hash digest over the PKI/PMI data using a secure hashing algorithm (see annex F).
2) The hash digest is then supplemented by additional information in preparation for generation of the digital
signature for improved security and for padding the hash digest to a length required by the asymmetric
cryptographic function. For the RSA algorithms, that supplementation can be the addition of some
information to the hash digest and in some cases, to perform yet another hashing operation. For the DSA
and ECDSA signature algorithms, additional domain parameters are added.
3) The result from item 2) together with the private key of the signer and the use of a specific algorithm result
in a bit string that together with the used algorithm constitute the digital signature.
4) The signature is appended to data to be signed.
Having received the data, the recipient (validator) goes through a similar procedure:
1) The validator goes through the same procedure as in steps 1) and 2) above, and if the received data is
unmodified, the result will be the same as for the signer. If not, the next step will fail.
2) From the result from item 1) together with the public key of the signer, the bit string of the signature and
the use of an associated algorithm, the digital signature is evaluated as either valid or invalid.
-If the digital signature proves valid, the validator has ensured that the data has not been modified and that the signer is in
the position of the private key that corresponds to the public key used by the validator, i.e., the digital signature provides
insurance of data integrity and authentication of the signer.
-If the digital signature proves invalid, either the data has been modified or the signing private key does not corresponds to
the public key used by the validator.
NOTE 2 – Data to be stored in a database or a directory may also be appended a digital signature, which then can evaluated at
the retrieval of the data.
-2008
This subclause is not intended to specify a standard for digital signatures in general, but to specify the means by which
the tokens are signed in PKI, PMI and in the Directory.
-Information (info) is signed by appending to it an enciphered summary of the information. The summary is produced by
means of a one-way hash function, while the enciphering is carried out using the private key of the signer (see
Figure 1). Thus:

NOTE 1 – The encipherment using the private key ensures that the
signature cannot be forged. The one-way nature of the hash
function ensures that false information, generated to have the same
hash result (and thus signature), cannot be substituted.
-The recipient of signed information verifies the signature by:
– applying the one-way hash function to the information;
– comparing the result with that obtained by deciphering the
signature using the public key of the signer.
-2008
This Directory Specification does not mandate a single one-way hash function for use in signing. It is intended that the
framework shall be applicable to any suitable hash function, and shall thus support changes to the methods used because
of future advances in cryptography, mathematical techniques or computational capabilities. However, two users wishing
to authenticate shall support the same hash function for authentication to be performed correctly. Thus, within the context of a
set of related applications, the choice of a single function shall serve to maximize the community of users
able to authenticate and communicate securely.
The signed information includes indicators that identify the hashing algorithm and the encryption algorithm used to
compute the digital signature.
-SECTION 2 – PUBLIC-KEY CERTIFICATE FRAMEWORK
7 Public keys and public-key certificates
7.1 Introduction
The public-key certificate framework defined here is for use by applications with requirements for
• authentication,
• integrity,
• confidentiality and
• non-repudiation.
-The binding of a public-key to an entity is provided by an authority through a digitally signed data structure called a public-key
certificate issued by an authority called a certification authority (CA).
-An entity that makes decisions based on the validity of a public-key certificates is called a relying party.
-A relying party needs to validate a public-key certificate prior to using it for a particular transaction in an application.
-In order for a relying party to be able to trust a public-key of another entity, for instance to authenticate the identity of that
entity, the public key shall be obtained from a trusted source. Such a source, called a certification authority (CA), certifies
a public key by issuing a public-key certificate which binds the public-key to the entity which holds the corresponding
private key.
-Because public-key certificates are intended to be unforgeable, they can be published by being placed in a directory,
without the need for the latter to make special efforts to protect them.
7.3 Public-key certificate extensions
The extensions component of a public-key certificate allows for the addition of extensions to the structure without
modification to the basic ASN.1 data type.
-7.4 Types of public-key certificates
There are two primary types of public-key certificates, end-entity public-key certificates and CA certificates.
-7.8 Generation of key pairs
The overall security management policy of an implementation shall define the lifecycle of key pairs, and is, thus, outside
the scope of this Specification. However, it is vital to the overall security that all private keys remain known only to the
entity (subject) to whom they belong.
-Key data is not easy for a human user to remember, so a suitable method for storing it in a convenient transportable manner
shall be employed. One possible mechanism when an entity is associated with a human user would be to use a "Smart
Card". This would hold
• the private and (optionally) public keys of the user,
• the user's public-key certificate, and
• a copy of the CA's public key.
-The use of this card shall additionally be secured by, e.g., at least the use of a personal identification number (PIN), increasing
the security of the system by requiring the user to
• possess the card and
• to know how to access it.
-In other environments, e.g., in a machine-to-machine environment (M2M), a hardware security module (HSM) may be
used for storing critical data. The exact method chosen for storing such data, however, is beyond the scope of this
Specification.
-Three ways in which a key pair of an entity may be produced are:
a) The entity generates its own key pair. This method has the advantage that the private key of an entity is
never released to another entity, but requires a certain level of competence by the entity.
b) The key pair is generated by a third party. The third party shall release the private key to the entity in a
physically secure manner, and then actively destroy all information relating to the creation of the key pair
plus the keys themselves. Suitable physical security measures shall be employed to ensure that the third
party and the data operations are free from tampering.
c) The key pair is generated by the CA. This is a special case of b), and the considerations there apply.
NOTE – The CA already exhibits trusted functionality with respect to the entity, and shall be protected by the necessary physical
security measures. This method has the advantage of not requiring secure data transfer to the CA for certification.
-The cryptosystem in use imposes particular (technical) constraints on key generation.
-7.9 Public-key certificate creation
A public-key certificate associates the public key and the unique name of the subject it describes. Thus:
a) a CA shall be satisfied of the identity of a subject before creating a public-key certificate for it;
b) a CA shall not issue public-key certificates for two different subjects with the same subject name.
It is important that the transfer of information to the CA is not compromised, and suitable physical security measures shall
be taken. In this regard: …

-A public-key certificate is a publicly available piece of information, and no specific security measures need to be employed
with respect to its transmission e.g., to a directory server (directory system agent) according to the Directory Specifications
or to the LDAP specification. As it is produced by an offline CA on behalf of a subject who shall be given a copy of it, the
subject needs only store this information in its directory entry on a subsequent directory access. Alternatively, the CA
could lodge the public-key certificate for the subject, in which case the CA shall be given suitable access rights to the
entity's directory entry.
-7.10 Certificate revocation list
7.10.1 Certificate revocation list principles
The CA that issues public-key certificates also has the responsibility to indicate the validity of the public-key certificates
that it issues. Generally, public-key certificates are subject to possible subsequent revocation. This revocation and a
notification of the revocation may be done directly by the same CA that issued the public-key certificate, or indirectly by
another authority duly authorized by the CA that issued the public-key certificate. A CA that issues public-key certificates
is required to state, possibly through a published statement of their practices, through the public-key certificates themselves,
or through some other identified means, whether:
– the public-key certificates cannot be revoked;
– the public-key certificates may be revoked by the same CA directly; or
– the issuing CA authorizes a different entity to perform revocation.
-CAs that do revoke public-key certificates are required to state, through similar means, what mechanism(s) can be used by
relying parties to obtain revocation status information about public-key certificates issued by that CA.
-This Specification defines a certificate revocation list (CRL) mechanism and validation and authorization list (AVL) mechanism,
but does not preclude the use of alternative mechanisms.
-One such alternative mechanism is the online certificate status protocol (OCSP) specified in IETF RFC 6960.
-Public-key certificates shall have a lifetime associated with them, at the end of which they expire.
-Two related points are:
– Validity of public-key certificates may be designed so that each becomes valid at the time of expiry of its
predecessor, or an overlap may be allowed. The latter prevents the CA from having to install and distribute
a large number of public-key certificates that may run out at the same expiration date.
– Expired public-key certificates will normally be removed from a directory. It is a matter for the security
policy and responsibility of the CA to keep old public-key certificates for a period if a non-repudiation of
data service is provided.
-If revocation lists are published in a directory, they are held within directory entries as attributes of the following types:
– certificateRevocationList;
– authorityRevocationList; and
– deltaRevocationList.
-7.13 Repudiation of a digital signing
Participants in an event may subsequently decide to repudiate anything that they digitally signed in that event. For example,
one can dispute one's participation in a key establishment or being the originator of a signed email message as easily as
one can dispute one's signing of a document with the intent to be bound to the content of that document. The repudiation
may not be successful. The Non-repudiation Framework, Rec. ITU-T X.813 | ISO/IEC 10181-4, describes a dispute
resolution process as follows:
1) evidence generation;
2) evidence transfer, storage and retrieval;
3) evidence verification; and
4) dispute resolution.
-9 Public-key certificate and CRL extensions
Some extensions defined in this clause are for use with public-key certificates. Other extensions are defined for CRLs
(including CARLs and EPRLs). Extensions for use with attribute certificates and ACRLs (including AARLs and EARLs)
are defined in clause 17.
This clause specifies extensions in the following areas: …
-In a public-key certificate or CRL, an extension is flagged as being either critical or as non-critical.
-If an extension is flagged as critical and a relying party does not recognize the extension type or does not implement the
semantics of the extension, then that relying party shall consider the public-key certificate as invalid.
-If an extension is flagged as non-critical, a relying party that does not recognize or implement that extension type may process
the remainder of the public-key certificate ignoring the extension.

9.1 Policy handling

9.1.1 Certificate policy
This framework contains four types of entities: The relying party, the CA, the trust broker, and the public-key certificate
subject.
-The obligations and warranties of a CA are defined in its certificate policy.
-The set of policies administered by a policy authority is called a policy domain.
9.2 Key and policy information extensions
9.2.1 Requirements
The following requirements relate to key and policy information:
d) The private key corresponding to a certified public key is typically used over a different period from the
validity of the public key. With a key pair used for creating and validating signatures, the usage period for
the private key used for signing is typically shorter than that for the public key used to verify the signature.
The validity period of the public-key certificate indicates a period for which the public key may be used,
which is not necessarily the same as the usage period of the private key. In the event of a private key
compromise, the period of exposure can be limited if the relying party knows the legitimate use period for
the private key. There is therefore a requirement to be able to indicate the usage period of the private key in
a public-key certificate.
f) When cross-certifying from one organization to another, it can sometimes be agreed that certain of the two
organizations' policies can be considered equivalent. A CA certificate needs to allow the issuing CA to
indicate that one of its own certificate policies is equivalent to another certificate policy in the subject CA's
domain. This is known as policy mapping.
g) A user of an encipherment or digital signature system which uses public-key certificates defined in this
Specification needs to be able to determine in advance the algorithms supported by other users.
h) There is a need to specify that an end-entity public-key certificate shall be validated using an authorization
and validation list.
-9.2.2 Public-key certificate and CRL extensions
The following extensions are defined:
a) authority key identifier;
b) subject key identifier;
c) key usage;
d) extended key usage;
e) private key usage period;
f) certificate policies;
g) policy mappings
h) authorization and validation.
These extensions shall be used only as public-key certificate extensions, except for the authorityKeyIdentifier
extension which may also be used as a CRL extension. Unless otherwise noted, these extensions may be used in both CA
certificates and end-entity public-key certificates.
-9.3 Subject and issuer information extensions
9.3.1 Requirements
The following requirements relate to public-key certificate subject component and public-key certificate and CRL
issuer component:
a) Public-key certificates need to be usable by applications that employ a variety of name forms, including
Internet electronic mail names, Internet domain names, Rec. ITU-T X.400 originator/recipient addresses,
and EDI party names. It is therefore necessary to be able securely to associate multiple names of a variety
of name forms with a public-key certificate subject or a public-key certificate or CRL issuer.
b) There may be a need for convoying identity and/or privilege information in a public-key certificate. Such
information is provided as directory attributes.
-9.3.2 Certificate and CRL extensions
The following extensions are defined:
a) Subject alternative name;
b) Issuer alternative name;
c) Subject directory attributes.
These extensions shall be used only as public-key certificate extensions, except for issuer alternative name, which may
also be used as a CRL extension. As public-key certificate extensions, they may be present in CA certificates and endentity public-
key certificates.
-9.3.2.1 Subject alternative name extension
This extension contains one or more alternative names, using any of a variety of name forms, for the entity that is bound
by the issuing CA to the certified public key. This extension is defined as follows:
-The values in the alternatives of the GeneralName type are names of various forms as follows:
– the otherName alternative shall be a name of any form whose type is defined as an instance of the OTHERNAME information
object class;
– the rfc822Name alternative shall be an Internet electronic mail address defined in accordance with
IETF RFC 822;
– the dNSName alternative shall be a fully qualified domain name (FQDN). The domain name shall be in the
syntax as specified by section 2.3.1 of IETF RFC 5890 meaning that a domain name is a sequence of labels
in the letters, digits, hyphen (LDH) format separated by dots.
A label may be in one of two formats:
– the x400Address alternative shall be an O/R address as defined by Rec. ITU-T X.411 | ISO/IEC 10021-4;
– the directoryName alternative shall be a distinguished name as defined by Rec. ITU-T X.501 | ISO/IEC
9594-2;
– the ediPartyName alternative shall be a name of a form agreed between communicating electronic data
interchange (EDI) partners; the nameAssigner component identifies an authority that assigns unique
values of names in the partyName component;
– the uniformResourceIdentifier alternative shall be a uniform resource identifier for the worldwide
web defined in accordance with IETF RFC 1630;
– the iPAddress alternative shall be an Internet Protocol address defined in accordance with IETF RFC 791
for IPv4 (four octets) or in accordance with IETF RFC 2460 for IPv6 (16 octets);
– the registeredID alternative shall be an object identifier of any registered object assigned in accordance
with Rec. ITU-T X.660 | ISO/IEC 9834-1.
-9.5 Basic CRL extensions
9.5.1 Requirements
The following requirements relate to CRLs:…
-9.5.2 CRL extensions
The following extensions are defined:
a) CRL number;
b) status referral;
c) CRL stream identifier;
d) ordered list;
e) delta information;
f) to be revoked;
g) revoked group of certificates; and
h) expired certificates on CRL.
9.5.3 CRL entry extension
The following extensions are defined:
a) reason code;
b) hold instruction code; and
c) invalidity date.
-9.6.2 CRL distribution point and delta CRL extensions
The following extensions are defined:
a) CRL distribution points;
b) issuing distribution point;
c) certificate issuer;
d) delta CRL indicator;
e) base update; and
f) freshest CRL.
-13 PKI directory schema
This clause defines the directory schema elements used to represent PKI information in a directory. It includes specifications of
relevant object classes,
attribute types and
attribute value
matching rules.
13.1 PKI directory object classes and name forms
This subclause includes the definition of object classes used to represent PKI objects in a directory.
13.1.1 PKI user object class
The PKI user object class is used in defining entries for objects that may be the subject of end-entity public-key certificates.
13.1.2 PKI CA object class
The PKI CA object class is used in defining entries for objects (entities) that act as CAs.
13.1.3 CRL distribution points object class and name form
The CRL distribution point object class is used in defining entries for objects which act as CRL distribution points.
13.1.4 Delta CRL object class
The delta CRL object class is used in defining entries for objects that hold delta revocation lists (e.g., CAs, AAs etc.).
13.1.5 Certificate Policy and CPS object class
The CP CPS object class is used in defining entries for objects that contain certificate policy and/or certification practice
information.
13.1.6 PKI certification path object class
The PKI cert path object class is used in defining entries for objects that contain PKI paths. It will generally be used in
conjunction with entries that include auxiliary object class pkiCA or pkiUser.
-13.2 PKI directory attributes
This subclause includes the definition of directory attributes to store PKI information elements in a directory.
13.2.1 User certificate attribute
An attribute value of type userCertificate holds an end-entity public-key certificate.
An entity may obtain one or more end-entity public-key certificates from one or more CAs.
13.2.2 CA certificate attribute
The cACertificate attribute of a CA's directory entry shall be used to store self-issued certificates (if any) and CA
certificates issued to this CA by CAs in the same realm as this CA. The definition of realm is purely a matter of local
policy.
13.2.3 Cross-certificate pair attribute type
13.2.4 Public-key certificate revocation list attribute type
A value of this attribute type holds a CRL providing information about revoked public-key certificates.
13.2.5 End-entity public-key certificate revocation list attribute type
A value of the following attribute type holds a CRL providing information about revoked end-entity public-key certificates.
13.2.6 CA revocation list attribute type
A value of the following attribute type contains a list of revoked CA certificates.
13.2.7 Delta revocation list attribute
The following attribute type is defined for holding a dCRL in a directory entry:
13.2.7 Supported algorithms attribute
A directory attribute is defined to support the selection of an algorithm for use when communicating with a remote end
entity using end-entity public-key certificates as defined in this Specification. The following ASN.1 defines this (multivalued)
attribute type:
-13.2.8 Certification practice statement attribute
The certificationPracticeStmt attribute is used to store information about a CA's certification practice statement.
13.2.9 Certificate policy attribute
The certificatePolicy attribute is used to store information about a certificate policy.
13.2.10 PKI path attribute
The PKI path attribute is used to store certification paths, each consisting of a sequence of public-key certificates.

13.3 PKI directory matching rules

13.4 PKI directory syntax definitions

14 Attribute certificates
-14 Attribute certificates
Public-key certificates are principally intended to provide an identity service upon which other security services, such as
data integrity,
entity authentication,
confidentiality and
authorization,
may be built. There are two distinct mechanisms provided in this Specification for binding a privilege attribute to a holder.
-Public-key certificates, used in combination with the entity authentication service, can provide an authorization service directly,
if privileges are associated with the subject.
-Public-key certificates may contain a subjectDirectoryAttributes extension that contains privileges associated with the subject of
the public-key certificate (see clause 9.3.2.3).
-This mechanism is appropriate in situations where the CA issuing the public-key certificate has an associated authority for
delegating the privilege (i.e., an AA) and the validity period of the privilege corresponds to the validity period of the public-key
certificate.
-In the more general case, entity privileges will have lifetimes that do not match the validity period for a public-key certificate.
-----Privileges will often have a much shorter lifetime.
-The authority for the assignment of privilege will frequently be one other than the authority issuing that same entity a public-key
certificate and different privileges may be assigned by different attribute authorities (AA).
-Privileges may also be assigned based on a temporal context and the 'turn on/turn off‘ aspect of privileges may well be
asynchronous with the lifetime of the public-key certificate and/or asynchronous with entity privileges issued from a different AA.

-The use of attribute certificates issued by an AA provides a flexible privilege management infrastructure (PMI) which can be
established and managed independently from a PKI.
-At the same time, there is a relationship between the two whereby the PKI is used to authenticate identities of issuers and
holders in attribute certificates.
14.1 Attribute certificate structure
An attribute certificate is a separate structure from a subject's public-key certificate.
- A subject may have multiple attribute certificates associated with each of its public-key certificates.
-There is no requirement that the same authority create both the public-key certificate and attribute certificate(s) for an entity; in
fact, a separation of duties will frequently dictate otherwise.
-In environments where different authorities have responsibility for issuing public key and attribute certificates,
the public-key certificate(s) issued by a CA and the attribute certificate(s) issued by an attribute authority (AA) would be
signed using different private signing keys.
-In environments where a single entity is both the CA, issuing public-key certificates, and the AA, issuing attribute certificates, it is
strongly recommended that a different key be used to sign attribute certificates than the key used to sign public-key certificates.
14.3 Attribute certificate revocation lists
14.3.1 Attribute certificate revocation list principles
…
15 Attribute authority, source of authority and certification authority relationship
The attribute authority (AA) and certification authority (CA) are logically completely independent. The creation and
maintenance of "identity" can (and often should) be separated from the PMI. Thus the entire PKI, including CAs, may be
existing and operational prior to the establishment of the PMI. The CA, although it is the source of authority (SOA) for
identity within its domain, is not automatically the SOA for privilege. The CA, therefore, will not necessarily itself be an
AA and, by logical implication, will not necessarily be responsible for the decision as to what other entities will be able to
function as AAs.
-An SOA is analogous to a trust anchor in the PKI, in that a privilege verifier trusts attribute certificates signed by the SOA.
-In some environments there is a need for CAs to have tight control over the entities that can act as SOAs. This framework
provides a mechanism for supporting that requirement.
15.1 Privilege in attribute certificates
15.2 Privilege in public-key certificates
16 PMI models
16.1 General model
The general privilege management model consists of three entities: the object, the privilege asserter and the privilege
verifier.
-The object may be a resource being protected, for example, in an access control application. The resource being protected
is referred to as the object. This type of object has methods which may be invoked (for example, the object may be a
firewall which has an "Allow Entry" object method, or the object may be a file in a file system which has Read, Write, and
Execute object methods). Another type of object in this model may be an object that was signed in a non-repudiation
application.
-The privilege asserter is the entity that holds a particular privilege and asserts its privileges for a particular context of use.
-The privilege verifier is the entity that makes the determination as to whether or not asserted privileges are sufficient for
the given context of use.
16.1.1 PMI in access control context
There is a standard framework for access control (Rec. ITU-T X.812 | ISO/IEC 10181-3) that defines a corresponding set
of terms that are specific to the access control application.
16.1.2 PMI in a non-repudiation context
There is a standard framework for non-repudiation (Rec. ITU-T X.813 | ISO/IEC 10181-4) which defines a corresponding
set of terms that are specific to non-repudiation.
-17 Attribute certificate and attribute certificate revocation list extensions
17.7 Use of basic CRL extension for ACRLs
19 PMI directory schema
This clause defines the directory schema elements used to represent PMI information in the Directory. It includes
specification of relevant object classes, attributes and attribute value matching rules.
19.1 PMI directory object classes
19.2 PMI directory attributes
19.3 PMI general directory matching rules
- SECTION 4 – COMMUNICATIONS CAPABILITIES
20 Protocol support for public-key and privilege management infrastructures
The purpose of this clause to provide a specification for the transport a general wrapper protocol for the transport of PKI
and/or PMI data.
20.1 General syntax
The PKI-PMI-Wrapper protocol adds authentication, integrity and optionally confidentiality to protocol data units (PDUs)
used for supporting a PKI and/or a PMI. The wrapping protocol allows inclusion of any type of PDU.
20.2 Wrapping of non-encrypted protocol data units
20.3 Wrapping of encrypted protocol data unit
20.3.1 Use of the Diffie-Hellman key agreement method
- To encrypt a wrapped PDU requires the establishment of shared symmetric keys. Two types of symmetric keys are defined.
One type, called the content encryption key and the other type is used to encrypt (wrap) the content encryption key and is
called the key-encryption key.
- The key agreement technique, known as the Diffie-Hellman (DH) key agreement method is used by this Specification to
establish the key encryption key.
- This method results in a shared secret that may be used for keying material that allows generation of shared, symmetric keys.
The DH method has two modes of operation relevant for this Specification. These modes are
• the ephemeral-static mode and
• the static-static mode.
-The ephemeral-static mode requires that the recipient have a public-key certificate with a DH public key as certified by
the issuing CA. This public-key certificate for the recipient shall be available to the sender. The sender creates a new DH
key pair for each wrapped PDU it sends. In the way, the shared secret becomes different for each message.
-The static-static mode requires each of the communicating entities to have a certified DH public-key certificate. In this
mode, the same-shared secret number is created for each wrapped PDU. Therefore, some random user keying material has
to be supplied by the sender to make different keying material for each PDU.
-Both methods require both entities in a communication to have the certified end-entity public-key certificate of its partner,
as communication goes in both directions.
-From the shared secret, key material may be generated as specified by IETF RFC 2631. This key material is then used to
create a so-called key encryption key. This key is used to encrypt a content encryption key (key wrapping). This content
encryption key is generated by the sender. The key wrapping uses a different algorithm than the one used for ordinary
encryption.
NOTE – The key wrapping algorithms used for AES key encryption may be found in IETF RFC 3394. These key wrapping
algorithms are also listed in Annex B.
20.3.2 Encryption information syntax
-The keyAgreement component, when present, shall provide the necessary information to perform the Diffie-Hellman
exchange followed by the generation of the key encryption key for wrapping the content encryption key. This is detailed
in clause 20.3.3. This component may be absent, if the key encryption key is not required to be renewed. Otherwise, this
component shall be present.
-An instance of the KeyAgreement data type has the following components:
The senderDhInfo components shall hold an instance of the SenderDhInfo data type, which has two alternatives:
a) The SenderStaticInfo alternative shall be taken if the Diffie-Hellman static-static mode is used. It shall
identify the sender's DH public-key certificate and additional keying material. It shall have the following
components:
b) The senderDhPublicKey alternative shall be taken if the Diffie-Hellman ephemeral-static mode is used.
It shall have the following components:
…
20.3.4 Generation of keying material
-IETF RFC 2631 specifies how keying material is generated from the developed shared secret. It is repeated here for easy
reference.
-The keying material is produced by providing a hash using the SHA-1 algorithms of the shared secret concatenated with
the DER encoding of an instance of the OtherInfo data type below. The SHA-1 produces 160 bits of keying material. If
that is insufficient, the hash operation has to be repeated until sufficient keying material has been produced. The leftmost
part (most significant bits) of the keying material is then used as the key-encryption key.
-Annex M
Directory concepts
-Annex M: Directory concepts
-M.1 Scope
This Specification makes use of several directory concepts that are defined in other part of the of the ITU-T X.500 series of
Recommendations | ISO/IEC 9594 (all parts).
-M.2 Basic directory concepts
-Objects to be represented in a directory typically have a hierarchical relationship, e.g.,
country,
town,
street,
house number and
person.
-Object can be almost anything. It can be a physical object or an abstract objects, like passwords.
-Objects are in a directory represented by directory entries, where the entries have the same hierarchical relationships as the
objects themselves.
-Information about an object is stored as attributes in its corresponding entry.
-Information about an object is stored as attributes in its corresponding entry.
-Figure M.1 is a simple example of a hierarchical structure of entries representing information about objects. The set of entries
within a directory form a tree.
-This tree is referred to as the directory information tree (DIT).
-M.3 Directory schema
To ensure consistency in a directory, the structure of directory information is controlled by a so-called directory schema.
-Objects having common characteristics form an object class. An object class is identified by an object identifier and as part
of its definition, it is specified what type of information shall and which information may be included in an entry for an
object of this object class.
-Information about an object is modelled as attributes. Attributes with common characteristics form an attribute type.
-Examples of attribute types are country name, given name, organization name, etc.
-An attribute type is identified by an object identifier. The specification of an attribute type includes the syntax for a value of that
attribute type. Some attribute types allow multiple values to be included in an attribute of that type, while other types only allow
a single value.
M.4 Directory distinguished names
An object and its corresponding entry has a (directory) distinguished name that identifies its position within the DIT as described
above.
-Such a distinguished name consists of sequence name components called relative distinguished names (RDNs).
-The distinguished name of the root of the DIT is an empty sequence.
-Distinguished names just below the root consist of a single RDN. At the next level, the distinguished names consist of two RDNs,
etc.
-A distinguished name is supposed to be globally unique and unambiguous.
NOTE 1 – It cannot be assumed, as there is a naming authority that can assure such uniqueness.
NOTE 2 – In a directory context distinguished names are associated with directory entries holding information about the
represented entities.
M.5 Subtrees
A subtree is a part of a DIT that has its root, also called the base, somewhere within the DIT. The subtree then consists of
the base plus all distinguished names subordinates to the base. This concept is used to identify a group of entities that might
-Annex N
Considerations on strong authentication
-N.1 Introduction
Strong authentication makes use of PKI as specified by this Specification, which provides the basic approach to authentication.
-However, many authentication procedures employing this approach are possible.
-In general, it is the business of a specific application to determine the appropriate procedures, so as to meet the security policy
of the application. This annex describes five particular authentication procedures that may be found useful across a range of
applications (see ISO/IEC 9798-3 for more information on entity authentication mechanisms using PKI techniques).
The five procedures involve different numbers of entities and exchanges of authentication information, and consequently
provide different types of assurance to their participants. Specifically:
a) One-way authentication, described in clause N.2, involves a single transfer of information from one user (A) intended for
another (B), and establishes the following:
– the identity of A, and that the authentication token actually was generated by A;
– the identity of B, and that the authentication token actually was intended to be sent to B;
– the origin, integrity and timeliness (the property of not having been sent two or more times) of the authentication token being
transferred.
The latter properties can also be established for arbitrary additional data accompanying the transfer.
b) Two-way authentication, described in clause N.3, involves, in addition, a reply from B to A. It establishes, in addition, the
following:
– that the authentication token generated in the reply actually was generated by B and was intended to be sent to A;
– the origin, integrity and timeliness of the authentication token sent in the reply;
– (optionally) the mutual confidentiality of part of the tokens.
-c) Three-way authentication, described in clause N.4, involves, in addition, a further transfer from A to B. It
establishes the same properties as the two-way authentication, but does so without the need for association
timestamp checking.
d) five-way authentication initiated by A, described in clause N.5, involves five transfers of information among
the trust broker, A and B. It establishes the following without the need for association timestamp checking:
– the identity of A, and the authentication token originating from A addressing B;
– the identity of B, and the authentication token originating from B addressing A;
– the identity of the trust broker, and that the authentication tokens originating from the trust broker
addressing A and B, respectively;
– the origin, integrity and timeliness of the authentication tokens being transferred.
e) five-way authentication initiated by B, described in clause N.6, also involves five transfers of information
among the trust broker, A and B. It establishes the same properties without the need for association
timestamp checking as the five-way authentication initiated by A, but initiates the authentication procedure
by B.
-In each case of a), b) and c), where strong authentication is to take place, A shall obtain the public key of B, and the return
certification path from B to A, prior to any exchange of information. In cases d) and e), A and B shall possess a reliable
copy of the public key of the trust broker. A’s public-key certificate PKC-A and B’s public-key certificate PKC-B will be
contained in the information exchange.
-For each of the first three authentication procedures described below, it is assumed that party A has checked the validity
of all of the certificates in the certification path. In five-way authentication procedures, there is no such assumption and
the trust broker acts on behalf of the relying party in validating certificates and certificate chains.
Note - Some relying parties may not have enough resources to check the validity of a public-key certificate, or evaluate the
certificate policy or the trust broker policy in a certain security domain. Then, in order to decrease the implementation
complexity of the end entities, the trust broker may be deployed to provide a central validation service of public-key certificates
for relying parties in both open and closed public-key infrastructures.