`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`INTERNATIONAL TELECOMMUNICATION UNION
`
`
`
`CCITT
`
`THE INTERNATIONAL
`TELEGRAPH AND TELEPHONE
`CONSULTATIVE COMMITTEE
`
`X.509
`
`(11/1988)
`
`SERIES X: DATA COMMUNICATION NETWORKS:
`DIRECTORY
`
`
`THE DIRECTORY – AUTHENTICATION
`FRAMEWORK
`
`
`
`Reedition of CCITT Recommendation X.509 published in
`the Blue Book, Fascicle VIII.8 (1988)
`
`
`1
`
`EX 1018
`IPR of Pat. No. 6,892,304
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`NOTES
`CCITT Recommendation X.509 was published in Fascicle VIII.8 of the Blue Book. This file is an extract from
`1
`the Blue Book. While the presentation and layout of the text might be slightly different from the Blue Book version, the
`contents of the file are identical to the Blue Book version and copyright conditions remain unchanged (see below).
`2
`In this Recommendation, the expression “Administration” is used for conciseness to indicate both a
`telecommunication administration and a recognized operating agency.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`© ITU 1988, 2008
`All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written
`permission of ITU.
`
`2
`
`

`

`
`
`Recommendation X.509
`
`THE DIRECTORY – AUTHENTICATION FRAMEWORK 1)
`(Melbourne, 1988)
`
`
`
`CONTENTS
`
`
`0
`
`1
`
`2
`
`3
`
`4
`
`Introduction
`
`Scope and field of application
`
`References
`
`Definitions
`
`Notation and abbreviations
`
`SECTION 1 – Simple authentication
`
`5
`
`Simple authentication procedure
`
`SECTION 2 – Strong authentication
`
`6
`
`7
`
`8
`
`9
`
`10
`
`
`Basis of strong authentication
`
`Obtaining a user's public key
`
`Digital signatures
`
`Strong authentication procedures
`
`Management of keys and certificates
`
`Annex A – Security requirements
`
`Annex B – An introduction to public key cryptography
`
`Annex C – The RSA public key cryptosystem
`
`Annex D – Hash functions
`
`Annex E – Threats protected against by the strong authentication method
`
`Annex F – Data confidentiality
`
`Annex G – Authentication framework in ASN.1
`
`Annex H – Reference definition of algorithm object identifiers
`
`_________
`1) Recommendations X.509 and ISO 9594-8, Information Processing Systems – Open Systems Interconnection – The
`Directory – Authentication Framework, were developed in close collaboration and are technically aligned.
`
`
`
`
`
`Fascicle VIII.8 – Rec. X.509
`
`1
`
`3
`
`

`

`
`
`Introduction
`0
`This document, together with the others of the series, has been produced to facilitate the interconnection of
`0.1
`information processing systems to provide directory services. The set of all 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 OSI application-entities, people, terminals and distribution lists.
`0.2
`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.
`0.3
`Many applications have requirements for security to protect against threats to the communication of
`information. Some commonly known threats, together with the security services and mechanisms that can be used to
`protect against them, are briefly described in Annex A. Virtually all security services are dependent upon the identities of
`the communicating parties being reliably known, i.e. authentication.
`0.4
`This Recommendation defines a framework for the provision of authentication services by the Directory to its
`users. These users include the Directory itself, as well as other applications and services. The Directory can usefully be
`involved in meeting their needs for authentication and other security services because it is a natural place from which
`communicating parties can obtain authentication information of each other: knowledge which is the basis of
`authentication. The Directory is a natural place because it holds other information which is required for communication
`and obtained prior to communication taking place. Obtaining the authentication information of a potential
`communication partner from the Directory is, with this approach, similar to obtaining an address. Owing to the wide
`reach of the Directory for communications purposes, it is expected that this authentication framework will be widely
`used by a range of applications.
`
`1
`1.1
`
`
`
`
`
`
`–
`
`Scope and field of application
`This Recommendation:
`–
`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 this 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 describes two levels of authentication: simple authentication, using a password as a
`1.2
`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.
`1.3
`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.
`1.4
`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 Recommendation X.519.
`1.5
`The strong authentication method specified in this Recommendation is based upon public-key cryptosystems. It
`is a major advantage of such systems that user certificates may be held within the Directory as attributes, and may be
`freely communicated within the Directory System and obtained by users of the Directory in the same manner as other
`Directory information. The user certificates are assumed to be formed by "off-line" means, and placed in the Directory
`by their creator. The generation of user certificates is performed by some off-line Certification Authority which is
`
`2
`
`Fascicle VIII.8 – Rec. X.509
`
`
`
`
`
`4
`
`

`

`
`
`completely separate from the DSAs in the Directory. In particular, no special requirements are placed upon Directory
`providers to store or communicate user certificates in a secure manner.
`
`A brief introduction to public-key cryptography can be found in Annex B.
`1.6
`In general, the authentication framework is not dependent on the use of a particular cryptographic algorithm,
`provided it has the properties described in § 6.1. Potentially a number of different algorithms may be used. However, two
`users wishing to authenticate must support the same cryptographic algorithm for authentication to be performed
`correctly. Thus, within the context of a set of related applications, the choice of a single algorithm will serve to maximize
`the community of users able to authenticate and communicate securely. One example of a public key cryptographic
`algorithm can be found in Annex C.
`1.7
`Similarly, two users wishing to authenticate must support the same hash function (see § 3.3 f)) (used in
`forming credentials and authentication tokens). Again, in principle, a number of alternative hash functions could be used,
`at the cost of narrowing the communities of users able to authenticate. A brief introduction to hash functions together
`with one example hash function can be found in Annex D.
`
`2
`2.1
`
`References
`ISO 7498-2: Information Processing Systems – Open Systems Interconnection – Security Architecture.
`
`Definitions
`3
`This Recommendation makes use of the following general security-related terms defined in Part 2 of the OSI
`3.1
`Reference Model on Security:
`a) asymmetric (encipherment);
`
`b) authentication exchange;
`
`c) authentication information;
`
`confidentiality;
`
`d)
`credentials;
`
`e)
`cryptography;
`
`f)
`g) data origin authentication;
`
`h) decipherment;
`
`encipherment;
`
`i)
`key;
`
`j)
`k) password;
`
`peer-entity authentication;
`
`l)
`m) symmetric (encipherment).
`
`3.2
`The following terms used in this Recommendation are defined in Recommendation X.501:
`a) attribute;
`
`b) Directory Information Base;
`
`c) Directory Information Tree;
`
`d) distinguished name;
`
`entry;
`
`e)
`object;
`
`f)
`root.
`
`g)
`
`
`
`
`
`Fascicle VIII.8 – Rec. X.509
`
`3
`
`5
`
`

`

`
`
`3.3
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`c)
`
`d)
`
`e)
`
`f)
`
`The following specific terms are defined and used in this Recommendation:
`a) authentication token (token): information conveyed during a strong authentication exchange, which can be
`used to authenticate its sender;
`b) user certificate (certificate): the public keys of a user, together with some other information, rendered
`unforgeable by encipherment with the secret key of the certification authority which issued it;
`certification authority: an authority trusted by one or more users to create and assign certificates.
`Optionally the certification authority may create the user's keys;
`certification path: an ordered sequence of certificates of objects in the DIT which, together with the public
`key of the initial object in the path, can be processed to obtain that of the final object in the path;
`cryptographic system, cryptosystem: a collection of transformations from plain text into ciphertext and
`vice versa, the particular transformation(s) to be used being selected by keys. The transformations are
`normally defined by a mathematical algorithm.
`hash function: a (mathematical) function which maps values from a large (possibly very large) domain
`into a smaller range. A "good" hash function is such that the results of applying the function to a (large)
`set of values in the domain will be evenly distributed (and apparently at random) over the range;
`g) one-way function: a (mathematical) function f which is easy to compute, but which for a general value y
`in the range, it is computationally difficult to find a value x in the domain such that f(x) = y. There may be
`a few values y for which finding x is not computationally difficult;
`h) public key: (in a public key cryptosystem) that key of a user's key pair which is publicly known;
`private key (secret key – deprecated): (in a public key cryptosystem) that key of a user's key pair which is
`i)
`known only by that user;
`simple authentication: authentication by means of simple password arrangements;
`security policy: the set of rules laid down by the security authority governing the use and provision of
`security services and facilities;
`strong authentication: authentication by means of cryptographically derived credentials;
`trust: generally, an entity can be said to "trust" a second entity when it (the first entity) makes the
`assumption that the second entity will behave exactly as the first entity expects. This trust may apply only
`for some specific function. The key role of trust in the authentication framework is to describe the
`relationship between an authenticating entity and a certification authority; an authenticating entity must be
`certain that it can trust the certification authority to create only valid and reliable certificates;
`certificate serial number: an integer value, unique within the issuing CA, which is unambiguously
`associated with a certificate issued by that CA.
`
`j)
`k)
`
`l)
`m)
`
`n)
`
`Notation and abbreviations
`4
`The notation used in this Recommendation is defined in Table 1/X.509 below.
`4.1
`Note – In the table, the symbols X, X1, X2 etc. occur in place of the names of users, while the symbol I occurs
`
`in place of arbitrary information.
`4.2
`The following abbreviations are used in this Recommendation:
`
`CA
`Certification Authority
`
`DIB
`Directory Information Base
`
`DIT
`Directory Information Tree
`
`PKCS
`Public key cryptosystem.
`
`4
`
`Fascicle VIII.8 – Rec. X.509
`
`
`
`
`
`6
`
`

`

`
`
`TABLE 1/X.509
`Notation
`
`
`
`
`
`Fascicle VIII.8 – Rec. X.509
`
`5
`
`
`
`
`
`7
`
`

`

`
`
`SECTION 1 – Simple authentication
`
`b)
`
`c)
`
`
`
`
`
`Simple authentication procedure
`5
`Simple authentication is intended to provide local authorization based upon a Distinguished Name of a user,
`5.1
`bilaterally agreed (optional) password and a bilateral understanding of the means of using and handling this password
`within a single domain. Utilization of Simple Authentication is primarily intended for local use only, i.e. for peer entity
`authentication between one DUA and one DSA or between one DSA and one DSA. Simple authentication may be
`achieved by several means:
`
`a)
`the transfer of the user's distinguished name and (optional) password in the clear (non- protected) to the
`recipient for evaluation;
`the transfer of the user's distinguished name, password, and a random number and/or a timestamp, all of
`which are protected by applying a one-way function;
`the transfer of the protected information described in b) together with a random number and/or timestamp,
`all of which is protected by applying a one-way function.
`Note 1 – There is no requirement that the one-way functions applied be different.
`
`Note 2 – The signalling of procedures for protecting passwords may be a matter for extension to the Document.
`
`Where passwords are not protected, a minimal degree of security is provided for preventing unauthorized
`5.2
`access. It should not be considered a basis for secure services. Protecting the user's distinguished name and password
`provides greater degrees of security. The algorithms to be used for the protection mechanism are typically non-
`enciphering one-way functions that are very simple to implement.
`5.3
`The general procedure for achieving simple authentication is shown in Figure 1/X.509.
`
`
`
`FIGURE 1/X.509
`The unprotected simple authentication procedure
`
`
`
`
`5.3.1
`
`
`
`The following steps are involved:
`1)
`an originating user A sends its distinguished name and password to a recipient user B;
`2) B sends the purported distinguished name and password of A to the Directory, where the password is
`checked against that held as the User Password attribute within the directory entry for A (using the
`Compare operation of the Directory);
`the Directory confirms (or denies) to B that the credentials are valid;
`3)
`
`the success (or failure) of authentication may be conveyed to A.
`4)
`
`The most basic form of simple authentication involves only step 1) and after B has checked the distinguished
`5.3.2
`name and password, may include step 4).
`
`6
`
`Fascicle VIII.8 – Rec. X.509
`
`
`
`
`
`8
`
`

`

`
`
`Figure 2/X.509 illustrates two approaches by which protected identifying information may be generated. f1
`5.4
`and f2 are one-way functions (either identical or different) and the timestamps and random numbers are optional and
`subject to bilateral agreements.
`
`
`
`
`
`
`
`
`
`5.4.1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`= user's distinguished name
`
`A
`tA
`= timestamps
`
`passwA = password of A
`qA
`
`= random numbers, optionally with a counter included
`
`FIGURE 2/X.509
`Protected simple authentication
`
`Figure 3/X.509 illustrates the procedure for protected simple authentication.
`
`
`FIGURE 3/X.509
`The protected simple authentication procedure
`
`
`
`The following steps are involved (initially using f1 only):
`1) An originating user, User A, sends its protected identifying information (Authenticator1) to User B.
`
`Protection is achieved by applying the one-way function (f1) of Figure 2/X.509, where the timestamp
`
`and/or random number (when used) is to minimize replay and to conceal the password.
`The protection of A's password is of the form:
`Protected1 = f1 (t1A, q1A, passwA).
`
`The information conveyed to B is of the form:
`Authenticator1 = t1A, q1A, A, Protected1.
`
`B verifies the protected identifying information offered by A by generating (using the timestamp, distinguished
`name and, optionally, additional timestamp and/or random number provided by A, together with a local copy
`of A's password) a local protected copy of A's password (of the form of Protected1). B compares (for equality)
`the purported identifying information (Protected1) with the locally generated value).
`2) B confirms (or denies) to A the verification of the protected identifying information.
`
`
`
`Fascicle VIII.8 – Rec. X.509
`
`7
`
`9
`
`

`

`
`
`
`
`
`
`
`5.4.2
`
`
`
`The procedure of § 5.4.1 can be modified to afford greater protection (using f1 and f2).
`The main differences are as follows:
`1) A sends its (additionally) protected identifying information (Authenticator2) to B. Additional protection is
`achieved by applying a further one-way function, f2, as illustrated in Figure 2/X.509. The further
`protection is of the form:
`Protected2 = f2 (t2A, q2A, Protected1).
`
`
`The information conveyed to B is of the form:
`
`Authenticator2 = t1A, t2A, q1A, q2A, A, Protected2.
`
`
`For comparison, B generates a local value of A's additionally protected password and compares it (for equality)
`with that of Protected2. (Similar in principle to step 1) of § 5.4.1.)
`2) B confirms (or denies) to A the verification of the protected identifying information.
`
`Note – The procedures defined in this are specified in terms of A and B. As applied to the Directory (specified
`
`in Recommendation X.511 and X.518), A could be a DUA binding to a DSA, B; alternatively A could be a DSA binding
`to another DSA, B.
`5.5
`A User Password attribute type contains the password of an object. An attribute value for the user password is
`a string specified by the object.
`UserPassword ::= ATTRIBUTE
`
` WITH
`ATTRIBUTE-SYNTAX
`
`OCTET STRING (SIZE (0..ub-user-password))
`
`
`
`
`
`MATCHES FOR EQUALITY
`
`
`
`
`
`5.6
`The following ASN.1 macro may be used to define the data type arising from applying a one-way function to a
`given other data type.
`PROTECTED MACRO ::= SIGNATURE
`
`
`
`SECTION 2 – Strong authentication
`
`Basis of strong authentication
`6
`The approach to strong authentication taken in this Recommendation makes use of the properties of a family of
`6.1
`cryptographic systems, known as public-key cryptosystems (PKCS). These cryptosystems, also described as asymmetric,
`involve a pair of keys, one secret and one public, rather than a single key as in conventional cryptographic systems.
`Annex B gives a brief introduction to these cryptosystems and the properties which make them useful in authentication.
`For a PKCS to be usable in this authentication framework, at the present time, it must have the property that both keys in
`the key pair can be used for encipherment with the secret key being used to decipher if the public key was used, and the
`public key being used to decipher if the secret key was used. In other words Xp . Xs = Xs . Xp where Xp/Xs are
`encipherment/decipherment functions using the public/secret keys of user X.
`Note – Alternative types of PKCS, i.e., ones which do not require the property of permutability and that can be
`
`supported without great modification to this Recommendation, are a possible future extension.
`6.2
`This authentication framework does not mandate a particular cryptosystem for use. It is intended that the
`framework will be applicable to any suitable public key cryptosystem, and will thus support changes to the methods used
`as a result of future advances in cryptography, mathematical techniques or computational capabilities. However, two
`users wishing to authenticate must support the same cryptographic algorithm for authentication to be performed
`correctly. Thus, within the context of a set of related applications, the choice of a single algorithm will serve to maximize
`the community of users able to authenticate and communicate securely. One example of a cryptographic algorithm can
`be found in Annex C.
`6.3
`Authentication relies on each user possessing a unique distinguished name. The allocation of distinguished
`names is the responsibility of the Naming Authorities. Each user must therefore trust the Naming Authorities not to issue
`duplicate distinguished names.
`6.4
`Each user is identified by its possession of its secret key. A second user is able to determine if a
`communication partner is in possession of the secret key, and can use this to corroborate that the communication partner
`is in fact the user. The validity of this corroboration depends on the secret key remaining confidential to the user.
`
`8
`
`Fascicle VIII.8 – Rec. X.509
`
`
`
`
`
`10
`
`

`

`
`
`For a user to determine that a communication partner is in possession of another user's secret key, it must itself
`6.5
`be in possession of that user's public key. Whilst obtaining the value of this public key from the user's entry in the
`Directory is straightforward, verifying its correctness is more problematic. There are many possible ways for doing this:
`7 describes a process whereby a user's public key can be checked by reference to the Directory. This process can only
`operate if there is an unbroken chain of trusted points in the Directory between the users requiring to authenticate. Such a
`chain can be constructed by identifying a common point of trust. This common point of trust must be linked to each user
`by an unbroken chain of trusted points.
`
`
`
`–
`
`SIGNED SEQUENCE{
`Certificate ::=
`[0]Version DEFAULT 1988,
`version
`
`
`
`SerialNumber,
`serialNumber
`
`Algorithmidentifier
`signature
`
`
`Name
`issuer
`
`
`
`Validity,
`validity
`
`
`Name,
`subject
`
`
`
`subjectPublicKeyInfo
`SubjectPublicKeyInfo}
`
`Version
` ::=
`INTEGER { 1988(0)}
`SerialNumber ::=
`INTEGER
`Validity
` ::=
`SEQUENCE{
`
`
` notBefore
`
`
` notAfter
`
`
`SubjectPublicKeyInfo
` SEQUENCE{
`
`algorithm
`
`
`
`subjectKey
`
`
`
`AlgorithmIdentifier
`::=
` SEQUENCE{
`
` algorithm
`
`
`
` parameters
`
`
`
`
`
`
`
`
`UTCTime,
`UTCTime}
`
`::=
`
`AlgorithmIdentifier
`BIT STRING}
`
`Obtaining a user's public key
`7
`In order for a user to trust the authentication procedure, it must obtain the other user's public key from a source
`7.1
`that it trusts. Such a source, called a certification authority (CA), uses the public key algorithm to certify the public key,
`producing a certificate. The certificate, the form of which is specified in § 7.2 has the following properties:
`
`–
`any user with access to the public key of the certification authority can recover the public key which was
`certified;
`no party other than the certification authority can modify the certificate without this being detected
`(certificates are unforgeable).
`Because certificates are unforgeable, they can be published by being placed in the Directory, without the need
`
`for the latter to make special efforts to protect them.
`Note – Although the CAs are unambiguously defined by a distinguished name in the DIT, this does not imply
`
`that there is any relationship between the organization of the CAs and the DIT.
`7.2
`A certification authority produces the certificate of a user by signing (see § 8) a collection of information,
`including the user's distinguished name and public key. Specifically, the certificate of a user with distinguished name A,
`produced by the certification authority CA, has the following form:
`CA<<A>> = CA {SN, AI, CA, A, Ap, TA}
`
`where SN is the serial number of the certificate, AI is the identifier of the algorithm used to sign the certificate, and TA
`indicates the period of validity of the certificate, and consists of two dates, the first and last on which the certificate is
`valid. Since TA is assumed to be changed in periods not less than 24 hours, it is expected that systems would use
`Coordinated Universal Time as a reference time base. The signature in the certificate can be checked for validity by any
`user with knowledge of CAP. The following ASN.1 data type can be used to represent certificates.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`OBJECT IDENTIFIER
`ANY DEFINED BY algorithm
` OPTIONAL}
`
`
`
`
`
`Fascicle VIII.8 – Rec. X.509
`
`9
`
`11
`
`

`

`
`
`
`
`
`
`The directory entry of each user, A, who is participating in strong authentication, contains the certificate(s) of
`7.3
`A. Such a certificate is generated by a Certification Authority of A which is an entity in the DIT. A Certification
`Authority of A, which may not be unique, is denoted CA(A), or simply CA if A is understood. The public key of A can
`thus be discovered by any user knowing the public key of CA. Discovering public keys is thus recursive.
`7.4
`If user A, trying to obtain the public key of user B, has already obtained the public key of CA(B), then the
`process is complete. In order to enable A to obtain the public key of CA(B), the directory entry of each Certification
`Authority, X, contains a number of certificates. These certificates are of two types. First there are forward certificates of
`X generated by other Certification Authorities. Second there are reverse certificates generated by X itself which are the
`certified public keys of other certification authorities. The existence of these certificates enables users to construct
`certification paths from one point to another.
`7.5
`A list of certificates needed to allow a particular user to obtain the public key of another, is known as a
`certification path. Each item in the list is a certificate of the certification authority of the next item in the list. A
`certification path from A to B (denoted A → B):
`starts with a certificate produced by CA(A), namely CA(A)<<X1>> for some entity X1;
`
`–
`continues with further certificates Xi<<Xi+1>>;
`
`–
`
`–
`ends with the certificate of B.
`
`A certification path logically forms an unbroken chain of trusted points in the Directory Information Tree
`between two users wishing to authenticate. The precise method employed by users A and B to obtain certification paths
`A → B and B → A may vary. One way to facilitate this is to arrange a hierarchy of CAs, which may or may not coincide
`with all or part of the DIT hierarchy. The benefit of this is that users who have CAs in the hierarchy may establish a
`certification path between them using the Directory without any prior information. In order to allow for this each CA
`may store one certificate and one reverse certificate designated as corresponding to its superior CA.
`Certificates are held within directory entries as attributes of type UserCertificate, CACertificate and
`7.6
`CrossCertificatePair. These attribute types are known to the Directory. These attributes can be operated on using the
`same protocol operations as other attributes. The definition of these types may be found in § 3.3 of this
`Recommendation, the specification of these attribute types is as follows:
`
`
`
`
`
`
`
`
`
`
`
`
`
`A user may obtain one ore more certificates from one or more Certification Authorities. Each certificate bears
`
`the name of the Certification Authority which issued it.
`7.7
`In the general case, before users can mutually authenticate, the Directory must supply the complete
`certification and return certification paths. However, in practice, the amount of information which must be obtained from
`the Directory can be reduced for a particular instance of authentication by:
`
`a)
`if the two users that want to authenticate are served by the same certification authority, then the
`certification path becomes trivial, and the users unwrap each other's certificates directly;
`if the CAs of the users are arranged in a hierarchy, a user could store the public keys, certificates and
`reverse certificates of all certification authorities between the user and the root of the DIT. Typically, this
`would involve the user in knowing the public keys and certificates of only three or four certification
`authorities. The user would then only require to obtain the certification paths from the common point of
`trust;
`if a user frequently communicates with users certified by a particular other CA, that user could learn the
`certification path to that CA and the return certification path from that CA, making it necessary only to
`obtain the certificate of the other user itself from the directory;
`
`ATTRIBUTE
` ::=
`UserCertificate
` WITH ATTRIBUTE-SYNTAX Certificate
`CACertificate
` ::=
`ATTRIBUTE
` WITH ATTRIBUTE-SYNTAX Certificate
`CrossCertificatePair ::=
`ATTRIBUTE
` WITH ATTRIBUTE-SYNTAX CertificatePair
`CertificatePair
` ::=
`SEQUENCE{
`
`forward [o] Certificate OPTIONAL
`
`
`reverse [1] Certificate OPTIONAL
`
`
`-- at least one must be present --}
`
`
`
`b)
`
`c)
`
`10
`
`Fascicle VIII.8 – Rec. X.509
`
`
`
`
`
`12
`
`

`

`
`
`
`
`
`
`d)
`
`e)
`
`certification authorities can cross-certify one another by bilateral agreement. The result is to shorten the
`certification path;
`if two users have communicated before and have learned one another's certificates, they are able to
`authenticate without any recourse to the Directory.
`In any case, having learned each other's certificates from the certification path, the users must check the
`
`validity of the received certificates.
`7.8
`(Example). Figure 4/X.509 illustrates a hypothetical example of a DIT fragment, where the CAs form a
`hierarchy. Besides the information shown at the CAs, we assume that each user knows the public key of its certification
`authority, and its own public and secret keys.
`7.8.1
`If the CAs of the users are arranged in a hierarchy, A can acquire the following certificates from the directory
`to establish a certification path to B:
`
`X<<W>>, W<<V>>, V<<Y>>, Y<<Z>>, Z<<B>>
`
`When A has obtained these certificates, it can unwrap the certification path in sequence to yield the contents of
`the certificate of B, including Bp:
`Bp = Xp . X<<W>> W<<V>> V<<Y>> Y<<Z>> Z<<B>>
`
`
`In general, A also has to acquire the following certificates from the directory to establish the return certification
`path from B to A:
`
`Z<<Y>>, Y<<V>>, V<<W>>, W<<X>>, X<<A>>.
`
`When B receives these certificates from A, it can unwrap the return certification path in sequence to yield the
`contents of the certificate of A, including Ap:
`Ap = Zp . Z<<Y>> Y<<V>> V<<W>> W<<X>> X<<A>>.
`
`
`
`
`FIGURE 4/X.509
`CA hierarchy – a hypothetical example
`
`
`
`
`7.8.2
`
`
`
`
`
`
`
`
`Applying the optimizations of § 7.7:
`a)
`taking A and C, for example: both know Xp, so that A simply has to directly acquire the certificate of C.
`Unwrapping the certification path reduces to:
`Cp = Xp . X<<C>>
`and unwrapping the return certification Path reduces to:
`Ap = Xp . X<<A>>
`
`
`
`
`
`
`
`Fascicle VIII.8 – Rec. X.509
`
`11
`
`13
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`b)
`
`
`
`
`c)
`
`d)
`
`assuming that A would thus know W<<X>>, Wp, V<<W>>, Vp, U<<V>>, Up, etc., reduces the
`information which A has to obtain from the directory to form the certification path to:
`V<<Y>>, Y<<Z>>, Z<<B>>
`and the information which A has to obtain from the directory to form the return certification path to:
`Z<<Y>>, Y<<V>>
`assuming that A frequently communicates with users certified by Z, it can learn (in addition to the public
`keys learned in b) above) V<<Y>>, Y<<V>>, Y<<Z>>, and Z<<Y>>. To communicate with B, it need
`therefore only obtain Z<<B>> from the directory;
`assuming that users certified by X and Z frequently communicate, then X<<Z>> would be held in the
`directory entry for X, and vice versa (this is shown in Figure 4/X.509). If A wants to authenticate to B, A
`need only obtain:
`
`
`
`
`
`
`
` X<<Z>>, Z<<B>>
`
`to form the certification path, and
`
`Z<<X>>
`
`to form the return certification path;
`e)
`assuming users A and C have communicated before and have learned one another's certificates, they may
`use each other's public key directly, i.e.
`Cp = Xp . X<<C>>
`
`
`and
`
`
`Ap = Xp . X<<A>>.
`
`
`In the more general case the Certifi