ISO/IEC 9594-8:1990

I N T E R NAT I O NA L ISO/IEC
STANDARD
First edition
1990-12-1 5
Information technology - Open Systems
- The Directory -
Interconnection
Part 8:
Authentication framework
Technologies de I'information - interconnexion de systèmes ouverts - L 'annuaire -
Partie 8: Cadre général d'authentification
Reference number
ISOIIEC 9594-8 : 1990 (E)
ISO/IEC 9594-8 : 1990(E)
Contents
Page
...
Foreword . 111
Introduction . iv
SECTION 1 : GENERAL 1
1 Scope . 1
2 Normative references . 1
3 Definitions . 2
4 Notation and Abbreviations . 3
SECTION 2: SIMPLE AUTHENTICATION 3
5 Simple Authentication Procedure . 3
SECTION 3: STRONG AUTHENTICATION 5
Basis of Strong Authentication . 5
Obtaining a User's Public Key . 6
8 Digital Signatures . 8
Strong Authentication Procedures . 10
10 Management of Keys and Certificates . 11
Annex A - Security Requirements . 14
Annex B - An Introduction to Public Key Cryptography . 17
Annex C -The RSA Public Key Cryptosystem . 18
Annex D - Hash Functions . 20
Annex E - Threats Protected Against by the Strong Authentication Method . 21
Annex F - Data Confidentiality . 22
Annex G - Authentication Framework in ASN.l . 23
Annex H - Reference Definition of Algorithm Object Identifiers . 26
O ISO/IEC 1990
All rights reserved . No part of this publication may be reproduced or utilized in any form or by
any means. electronic or mechanical. including photocopying and microfilm. without permission
in writing from the publisher .
ISO/IEC Copyright Office 0 Case postale 56 0 CH-1211 Genève 20 0 Switzerland
Printed in Switzerland
ii
ISO/IEC 9594-8 : 1990(E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardiz-
ation. National bodies that are members of IS0 or IEC participate in the development.
of International Standards through technical committees established by the respective
organization to deal with particular fields of technical activity. IS0 and IEC technical
committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with IS0 and IEC, also take part in the
work.
In the field of information technology, IS0 and IEC have established a joint technical
committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint
technical committee are circulated to national bodies for voting. Publication as an
International Standard requires approval by at least 75 070 of the national bodies casting
a vote.
International Standard ISO/IEC 9594-8 was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology.
ISO/IEC 9594 consists of the following parts, under the general title Information
technology - Open Systems Interconnection - The Directory:
- Part I: Overview of concepts, models and services
-- Part 2: Models
- Part 3: Abstract service definition
- Part 4: Procedures for distributed operation
- Part 5: Protocol specifcations
- Part 6: Selected attribute types
- Part 7: Selected object classes
- Part 8: Authentication framework
Annex G forms an integral part of this part of ISO/IEC 9594. Annexes A, B, C, D,
E, F and H are for information only.
...
ISO/IEC 9594-8 1990(E)
Introduction
0.1 This part of ISO/IEC 9594, together with the other parts, has been produced to facilitate the interconnection of
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 OS1 application-entities, people, terminals and distribution lists.
a
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 part of ISO/IEC 9594 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 0

INTERNATIONAL STANDARD ISO/IEC 9594-8 : 1990 (E)
Information technology - Open Systems Interconnection -
The Directory -
Part 8:
Authentication framework
SECTION 1: GENERAL
the same manner as other Directory information. The user
1 Scope
certificates are assumed to be formed by 'off-line' means,
1.1 This part of ISO/IEC 9594:
and placed in the Directory by their creator. The
generation of user certificates is performed by some off-
specifies the form of authentication information held
line Certification Authority which is completely separate
by the Directory;
from the DSAs in the Directory. In particular, no special
describes how authentication information may be
requirements are placed upon Directory providers to store
obtained from the Directory;
or communicate user certificates in a secure manner.
states the assumptions made about how
A brief introduction to public-key cryptography can be
authentication information is formed and placed in
found in annex B.
the Directory;
defines three ways in which applications may use
1.6 In general, the authentication framework is not
this authentication information to perform
dependent on the use of a particular cryptographic
authentication and describes how other security
algorithm, provided it has the properties described in 6.1.
services may be supported by authentication.
Potentially a number of different algorithms may be used.
However, two users wishing to authenticate shall support
1.2 This part of ISO/iEC 9594 describes two levels of
the same cryptographic algorithm for authentication to be
authentication: simple authentication, using a password as
performed correctly. Thus, within the context of a set of
a verification of claimed identity; and strong
related applications, the choice of a single algorithm will
authentication, involving credentials formed using
serve to maximize the community of users able to
cryptographic techniques. While simple authentication
authenticate and communicate securely. One example of a
offers some limited protection against unauthorized access,
public key cryptographic algorithm can be found in Annex
only strong authentication should be used as the basis for
C.
providing secure services. It is not intended to establish
this as a general framework for authentication, but it can
1.7 Similarly, two users wishing to authenticate shall
be of general use for applications which consider these
support the same hash function (see 3.30 (used in forming
@ techniques adequate.
credentials and authentication tokens). Again, in principle,
a number of alternative hash functions could be used, at
1.3 Authentication (and other security services) can only
the cost of narrowing the communities of users able to
be provided within the context of a defined security policy.
authenticate. A brief introduction to hash functions
It is a matter for users of an application to define their own
together with one example hash function can be found in
security policy which may be constrained by the services
annex D.
provided by a standard.
1.4 It is a matter for standards defining applications
which use the authentication framework to specify the
2 Normative references
protocol exchanges which need to be performed in order to
The following standards contain provisions which, through
achieve authentication based upon the authentication
reference in this text, constitute provisions of this part of
information obtained from the Directory. The protocol
ISO/IEC 9594. At the time of publication, the editions
used by applications to obtain credentials from the
indicated were valid. All standards are subject to revision,
Directory is the Directory Access Protocol (DAP),
and parties to agreements based on this part of
specified in ISO/IEC 9594-5.
ISO/IEC 9594 are encouraged to investigate the possibility
of applying the most recent editions of the standards listed
1.5 The strong authentication method specified in this
below. Members of IEC and IS0 maintain registers of
part of ISQ/IEC 9594 is based upon public-key
currently valid International Standards.
cryptosysterns. It is a major advantage of such systems that
user certificates may be held within the Directory as
IS0 7498-2: 1987, Itformation Pi.ocessirîg Systems -
attributes, and may be freely communicated within the
Open Systems Interconnection -
Directory System and obtained by users of the Directory in
ISO/IEC 9594-8 : 1990(E)
Basic Reference Model - Part 2: unforgeable by encipherment with the secret key of the
certification authority which issued it.
Security Arclzitecture.
3.3.3 certification authority : An authority trusted by one
ISOflEC 8824: 1990, Information Technology - Open
- or more users to create and assign certificates. Optionally
Systems Interconnection
the certfication authority may create the users' keys.
Specification of Abstract Syntax
Notation One (ASN.1).
3.3.4 certification path : An ordered sequence of
certificates of objects in the DIT which, together with the
ISOflEC 8825: 1990, Information Technology - Open
public key of the initial object in the path, can be
Systems Interconnection -
processed to obtain that of the final object in the path.
Specification of Basic Encoding
rules for Abstract Syntas Notation
One (ASN.1) 3.3.5 cryptograplzic system, ciyptosystem : A collection
of transformations from plain text into ciphertext and vice
versa, the particular transformation(s) to be used being
ISOAEC 10021-3:1990, Information Technology - Text
selected by keys. The transformations are normally defined
Communication - Message
by a mathematical algorithm.
Oriented Interchange System
(MOTIS) - Part 3: Abstract Ser-
vice Definition Conventions.
3.3.6 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
3 Definitions
the domain will be evenly distributed (and apparently at
random) over the range.
3.1 This part of ISO/IEC9594 makes use of the
following general security-related terms defined in
3.3.7 one-way function : A (mathematical) function f
IS0 7498-2:
which is easy to compute, but which for a general value y
a) asymmetric (encipherment):
in the range, it is computationally difficult to find a value x
b) authentication exchange;
in the domain such that f(x) = y. There may be a few
c) authenticution information;
values y for which finding x is not computationally
d) confidentiality;
difficult.
e) credentials;
f> CryPtW-QPhY ;
3.3.8 public key : (In a public key cryptosystem) that key
g) data origin authentication;
of a user's key pair which is publicly known.
h) decipliernient ;
i) encipherment ;
3.3.9 private key (secret key - deprecated): (In a public
j) key;
key cryptosystem) that key of a user's key pair which is
k) password;
known only by that user.
1) peer-entity authentication ;
m) symmetric (encipherment).
3.3.10 simple authentication : Authentication by means of
O
simple password arrangements.
3.2 The following terms used in this part of
ISO/IEC 9594 are defined in ISOflEC 9594-2:
3.3.11 security policy : The set of rules laid down by the
a) attribute ; security authority governing the use and provision of
b) Directory Information Base ; security services and facilities.
c) Directory Information Tree ;
d) distinguished name ;
3.3.12 strong authentication : Authentication by means of
e) entry;
cryptographicall y derived credentials.
f) object;
g) root.
3.3.13 trust: Generally, an entity can be said to "trust" a
second entity when it (the first entity) makes the
3.3 For the purpose of this part of ISOfiEC9594 the
assumption that the second entity will behave exactly as
following definitions apply:
the first entity expects. This trust may apply only for some
specific function. The key role of trust in the
3.3.1 authentication token (token): Information
authentication framework is to describe the relationship
conveyed during a strong authentication exchange, which
between an authenticating entity and a certification
can be used to authenticate its sender.
authority; an authenticating entity shall be certain that it
can trust the certification authority to create only valid and
3.3.2 user certificate (certificate) : The public keys of a
reliable certificates.
user, together with some other information, rendered
ISO/IEC 9594-8 : 1990(E)
Note - in the table, the symbols X, X l,X2 etc. occur in place of
3.3.14 certificate serial number: An integer value, unique
the names of users, while the symbol I occurs in place of
within the issuing CA, which is unambiguously associated
arbitrary information
with a certificate issued by that CA.
4.2 The following abbreviations are used in this part of
ISODEC 9594:
4 Notation and Abbreviations
CA Certification Authority
4.1 The notation used in this part of ISO/IEC 9594 is
DIB Directory Information Base
defined in table 1 below.
DIT Directory Information Tree
PKCS Public key cryptosystem
Table 1 - Notation
NOTATION I MEANING 1
xp
secret key of X.
encipherment of some information, I, using the public key of X.
encipherment of I using the secret key of X.
the signing of I by user X. It consists of I with w enciphered summary appended.
a certification authority of user X.
(where n> 1 ): CA(CA(. .n times .( X)))
the certificate of user X2 issued by certification authority Xi.
a chain of certificates (can be of arbitrary length), where each item is the certificate for the
certification authority which produced the next. It is functionally equivalent to the following
certificate X1( A«C», namely the ability to find out Cp given Ap.
the operation of unwrapping a certificate (or certificate chain) to extract a public key. It is an infix
operator, whose left operand is the public key of a certification authority, and whose right operand is
a certificate issued by that certification authority. The outcome is the public key of the user whose
certificate is the right operand. For example:
denotes the operation of using the public key of A to obtain B's public key, Bp, from its certificüte,
followed by using Bp to unwrap C's certificate. The outcome of the operation is the public key of C,
cp.
a certification path from A to B, formed of a chain of certificates, starting with CA(A)«CA2(A)» and
ending with CA(B)«B».
SECTION 2: SIMPLE AUTHENTICATION
the transfer of the user's distinguished name and
a)
(optional) password in the clear (non-protected) to
5 Simple Authentication Procedure
the recipient for evaluation;
5.1 Simple authentication is intended to provide local
the transfer of the user's distinguished name,
b)
authorization based upon a Distinguished Name of a user,
password, and a random number and/or a
a bilaterally agreed (optional) password, and a bilateral
timestamp, all of which are protected by applying a
understanding of the means of using and handling this
one-way function;
password within a single domain. Utilization of simple
authentication is primarily intended for local use only, i.e. the transfer of the protected information described
c)
for peer entity authentication between one DUA and one in b) together with a random number and/or a
DSA or between one DSA and one DSA. Simple timestamp, all of which is protected by applying a
authentication may be achieved by several means: one-way function.
ISO/IEC 9594-8 : 1990(E)
Notes
1. There is no requirement that the one-way functions applied
I Protectedl
be different.
2 The signalling of procedures for protecting passwords may
be a matter for extension to the document.
Protected2
5.2 Where passwords are not protected, a minimal degree
of security is provided for preventing unauthorized access.
t2A
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
q2A - I
used for the protection mechanism are typically non-
enciphering one-way functions that are very simple to
Legend
implement.
A = user's distinguished name
tA = timestamps
passwA = password of A
qA = random numbers, optionally
with a counter included
Figure 2 - Protected Simple Authentication
5.4.1 Figure 3 illustrates the procedure for protected
simple authentication.
I I
Figure 1- The Unprotected Simple Authentication
Procedure
5.3 The general procedure for achieving simple
authentication is shown in figure 1.
O
5.3.1 The following steps are involved:
0 an originating user A sends its distinguished name
Figure 3 - The Protected Simple Authentication Procedure
and password to a recipient user B;
The following steps are involved (initially using f 1 only):
0 B sends the purported distinguished name and
0 an originating user, user A, sends its protected
password of A to the Directory, where the password
is checked against that held as the UserPassword
identifying information (Authenticatorl) to user B.
attribute within the directory entry for A (using the
Protection is achieved by applying the one-way
Compare operation of the Directory);
function (fi) of figure 2, where the timestamp
and/or random number (when used) is used to
@ the Directory confirms (or denies) to B that the
minimize replay and to conceal the password.
credentials are valid;
The protection of As password is of the form:
@ the success (or failure) of authentication may be
Protectedl = f 1 (tlA, qlA , A, passwA)
conveyed to A.
The information conveyed to B is of the form:
5.3.2 The most basic form of simple authentication
Authenticatorl = tlA, qlA , A, Protectedl
involves only step 0 and after B has checked the
B verifies the protected identifying information
distinguished name and password, may include step
offered by A by generating (using the distinguished
name and optional timestamp and/or random
5.4 Figure 2 illustrates two approaches by which protected
number provided by A, together with a local copy of
identifying information may be generated. f 1 and f2 are
A's password) a local protected copy of A's
one-way functions (either identical or different) and the
password (of the form Protectedl). B compares for
timestamps and random numbers are optional and subject
equality the purported identifying information
to bilateral agreements.
(Protectedl) with the locally generated value.
A-
ISO/IEC 9594-8 : 1990(E)
@ B confirms or denies to A the verification of the @ B confirms or denies to A the verification of the
protected identifying information. protected identifying information.
Note - The procedures defined in these clauses are specified in
5.4.2 The procedure of 5.4.1 can be modified to afford
terms of A and B. As applied to the Directory (specified in
greater protection using fi and f2. The main differences
ISO/IEC 9594-3 and ISO/IEC 9594-4), A could be a DUA
are as follows:
binding to a DSA, B; alternatively, A could be a DSA binding to
another DSA, B.
0 A sends its additionally protected identifying
information (Authenticator2) to B. Additional
5.5 A User Password attribute type contains the
protection is achieved by applying a further one-
password of an object. An attribute value for the user
way function, f2, as illustrated in figure 2. The
password is a string specified by the object.
further protection is of the form:
UserPassword ::= ATTRIBUTE
Protected2 = f2 (t2A, q2A, Protectedl)
WITH ATTRIBUTE-SYNTAX
OCTET STRING (SIZE (O.ub-user-password))
The information conveyed to B is of the form:
MATCHES FOR EQUALITY
Authenticator2 = tlA, t2A, qlA, q2A, A,
5.6 The following ASN.l macro may be used to define
Protected2
the data type arising from applying a one-way function to a
For comparison, B generates a local value of A's
given other data type:
0 additionally protected password and compares it for
equality with that of Protected2 (this is similar in
PROTECTED MACRO ::= SIGNATURE
principle to step 0 of 5.4.1).
SECTION 3: STRONG AUTHENTICATION
capabilities. However, two users wishing to authenticate
shall support the same cryptographic algorithm for
6 Basis of Strong Authentication
authentication to be performed correctly. Thus, within the
context of a set of related applications, the choice of a
6.1 The approach to strong authentication taken in this
single algorithm shall serve to maximize the community of
part of ISO/IEC 9594 makes use of the properties of a
users able to authenticate and communicate securely. One
family of cryptographic systems, known as public-key
example of a cryptographic algorithm can be found in
cryptosystems (PKCS). These cryptosystems, also
annex C.
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 6.3 Authentication relies on each user possessing a
unique distinguished name. The allocation of distinguished
to these cryptosystems and the properties which make
names is the responsibility of the Naming Authorities.
them useful in authentication. For a PKCS to be usable in
O
Each user shall therefore trust the Naming Authorities not
this authentication framework at this present time, it shall
to issue duplicate distinguished names.
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
6.4 Each user is identified by its possession of its secret
being used to decipher if the secret key was used. In other
key. A second user is able to determine if a communication
words, Xp Xs = Xs Xp, where Xp/Xs are
partner is in possession of the secret key, and can use this
encipherment/decipherment functions using the to corroborate that the communication partner is in fact the
public/private keys of user X. user. The validity of this corroboration depends on the
secret key remaining confidential to the user.
Note - Alternative types of PKCS, i.e., ones which do 1101
require the properly of permutability and that can be supported
6.5 For a user to determine that a communication partner
without great modification to this part of ISO/IEC 9594, are a
is in possession of another user's secret key, it shall itself
possible future extension.
be in possession of that user's public key. Whilst obtaining
the value of this public key from the user's entry in the
6.2 This authentication framework does not mandate a
Directory is straightforward, verifying its correctness is
particular cryptosystem for use. It is intended that the
more problematic. there are many possible ways for doing
framework shall be applicable to any suitable public key
this: clause 7 describes a process whereby a user's public
cryptosystem, and shall thus support changes to the
key can be checked by reference to the Directory. This
methods used as a result of future advances in
process can only operate if there is an unbroken chain of
cryptography, mathematical techniques or computational
trusted points in the Directory between the users requiring
ISO/IEC 9594-8 : 1990(E)
CertificateSerialNumber ::= INTEGER
to authenticate. Such a chain can be constructed by
identifying a common point of trust. This common point of
Validity ::=
trust shall be linked to each user by an unbroken chain of
SEQUENCE{
trusted points.
notBefore UTCTime,
notAfter UTCTime]
.--
SubjectPublicKeylnfo .-
SEQUENCE {
7 Obtaining a User's Public Key
algorithm Algorithmldentifier,
7.1 In order for a user to trust the authentication
subjectKey BIT STRING,}
procedure, it shall obtain the other user's public key from a
Algorithmldentifier ::=
source that it trusts. Such a source, called a certification
SEQUENCE {
authority (CA), uses the public key algorithm to certify the
alaorithm OBJECT IDENTIFIER.
public key, producing a certificate. The certificate, the
p6ameters ANY DEFINED BY algorithm
form of which is specified in 7.2, has the following
OPTIONAL]
properties:
7.3 The directory entry of each user, A, who is
any user with access to the public key of the
participating in strong authentication, contains the
certification authority can recover the public key
certificate(s) of A. Such a certificate is generated by a
which was certified;
Certification Authority of A, which is an entity in the DIT.
A Certification Authority of A, which may not be unique,
no party other than the certification authority can
is denoted CA(A), or simply CA if A is understood. The
a
modify the certificate without this being detected
public key of A can thus be discovered by any user
(certificates are unforgeable).
knowing the public key of CA. Discovering public keys is
thus recursive.
Because certificates are unforgeable, they can be published
by being placed in the Directory, without the need for the
7.4 If user A, trying to obtain the public key of user B,
latter to make special efforts to protect them.
has already obtained the public key of CA(B), then the
process is complete. In order to enable A to obtain the
Note - Although the CAS are unambiguously dcfined by a
public key of CA(B), the directory entry of each
distinguished name in the DIT, this does not imply that there is
Certification Authority, X, contains a number of
any relationship between the organization of the CAS and the
certificates. These certificates are of two types. First there
DIT.
are forward certificates of X generated by other
Certification Authorities. Second there are reverse
7.2 A certification authority produces the certificate of a
certificates generated by X itself which are the certified
user by signing (see clause 8) a collection of information,
public keys of other certification authorities. The existence
including the user's distinguished name and public key.
of these certificates enables users to construct certification
Specifically, the certificate of a user with distinguished
paths from one point to another.
name A, produced by the certification authority CA, has
the following form:
7.5 A list of certificates needed to allow a particular user
CA«A» = CA[ SN, AI, CA, A, Ap, TA)
to obtain the public key of another, is known as a
certification path. Each item in the list is a certificate of the
where SN is the serial number of the certificate, AI is the
certification authority of the next item in the list. A
identifier of the algorithm used to sign the certificate and,
certification path from A to B (denoted A+B):
TA indicates the period of validity of the certificate, and
consists of two dates, the first and last on which the
starts with a certificate produced by CA(A), namely
certificate is valid. Since TA is assumed to be changed in
CA(A)«X~>> for some entity XI;
periods not less than 24 hours, it is expected that systems
continues with further certificates Xk;
would use Coordinated Universal Time as a reference time
base. The signature in the certificate can be checked for
ends with the certificate of B.
validity by any user with knowledge of CAP. The following
ASN. 1 data type can be used to represent certificates:
A certification path logically forms an unbroken chain of
trusted points in the Directory Information Tree between
Certificate .*- .- SIGNED SEQUENCE I
two users wishing to authenticate. The precise method
version [O] Version DEFAULT v1988,
employed by users A and B to obtain certification paths
serialNum ber CertificateSerialNumber,
A+B and B+A may vary. One way to facilitate this is to
signature Algorithmldentifier,
issuer arrange a hierarchy of CAS, which may or may not coincide
Name,
validity
Validity,
with all or part of the DIT hierarchy. The benefit of this is
subject Name,
that users who have CAS in the hierarchy may establish a
su bjectPublicKeylnfo SubjectPublicKeylnfo]
certification path between them using the Directory without
Version ._ .- INTEGER {v1988(0)}
any prior information. in order to allow for this each CA
ISO/IEC 9594-8 : 1990(E)
if two users have communicated before and have
may store one certificate and one reverse certificate
e)
designated as corresponding to its superior CA. learned one another's certificates, they are able to
authenticate without any recourse to the Directory.
7.6 Certificates are held) within directory entries as
attributes of type Usercertificate, CACertificate and In any case, having learned each others' certificates from
the certification path, the users shall check the validity of
CrossCertificatePair. These attribute types are known to
the Directory. These attributes can be operated on using the received certificates.
the same protocol operations as other attributes. The
definition of these types can be found in clause 3.3 of this
part of ISOflEC 9594; the specification of these attribute
types is as follows:
Usercertificate ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Certificate
CACertificate ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Certificate
CrossCertificatePair ::= ATTRIBUTE
WITH ATTRIBUTE-SYNTAX Certificatepair
Certificatepair:=
SEQUENCE{
forward [DI Certificate OPTIONAL,
reverse 111 Certificate OPTIONAL
- -at least one shall be present - - 1
A user may obtain one or more certificates from one or
more Certification Authorities. Each certificate bears the
name of the Certification Authority which issued it.
Figure 4 -CA Hierarchy -A Hypothetical Example
7.7 In the general case, before users can mutually
authenticate, the Directory shall supply the complete
certification and return certification paths. However, in 7.8 (Example). Figure 4 illustrates a hypothetical
practice, the amount of information which shall be example of a DIT fragment, where the CAS form a
obtained from the Directory can be reduced for a particular hierarchy. Besides the information shown at the CAS, we
instance of authentication by: assume that each user knows the public key of its
certification authority, and its own public and secret keys.
if the two users that want to authenticate are served
a)
by the same certification authority, then the
7.8.1 If the CAS of the users are arranged in a hierarchy,
certification path becomes trivial, and the users
A can acquire the following certificates from the directory
unwrap each others' certificates directly;
to establish a certification path to B:
if the CAS of the users are arranged in a hierarchy, a
b)
X«W», W«V», V«Y», Y«Z», Z«B»
user could store the public keys, certificates and
reverse certificates of all certification authorities
When A has obtained these certificates, it can unwrap thc
between the user and the root of the DIT. Typically,
certification path in sequence to yield the contents of thc
this would involve the user in knowing the public
certificate of B, including Bp:
keys and certificates of only three or four
certification authorities. The user would then only
Bp = Xp X«W» W«V» V«Y» Y«Z» Z«B»
require to obtain the certification paths from the
common point of trust ;
In general A also has to acquire the following Certificate:
c) if a user frequently communicates with users
from the directory to establish the return certification pat1
certified by a particular other CA, that user could
from B to A:
learn the certification path to that CA and the return
Z«Y», Y«V», V«W», W«X», X«A».
certification path from that CA, making it necessary
only to obtain the certificate of the other user itself
When B receives these certificates from A, it can unwrai
from the directory;
the return certification path in sequence to yield the content
d) certification authorities can cross-certify one
of the certificate of A, including Ap:
another by bilateral agreement. The result is to
shorten the certification path;
Ap = Zp Z«Y» Y«V» V«W» W«X» X«A»
7.8.2 Applying the optimizations of 7.7:
ISO/IEC 9594-8 : 1990(E)
taking A and C, for example: both know Xp, so that 7.8.3 In the more general case the Certification
A simply has to directly acquire the certificate of C. Authorities do not relate in a hierarchical manner.
Referring to the hypothetical example in figure 5, suppose
Unwrapping the certification path reduces to:
a user D, certified by U, wishes to authenticate to user E,
cp = xp X«C»
certified by W. The directory entry of user D shall hold the
certificate UND» and the entry of user E shall hold the
and unwrapping the return certification Path
certificate W«E».
reduces to:
Let V be a CA with whom CAS U and W have at some
Ap = Xp X«A»
previous time exchanged public keys in a trusted way. As a
assuming that A would thus know W«X», Wp, result, certificates U«V», V«U», W«V» and V«W» have
V«W>>, Vp, U«V», Up, etc., reduces the information been generated and stored in the Directory. Assume U«V»
which A has to obtain from the directory to form the and W«V» are stored in the entry of V, V«U» is stored in
U's entry, and V«W» is stored in Ws entry.
certification path to:
V«Y», Y«Z», Z«B»
User D must find a certification path to E. Various
strategies could be used. One such strategy would be to
and the information which A has to obtain from the
directory to form the return certification path to: regard the users and CAS as nodes, and the certificates as
arcs in a directed graph. in these terms, D has to perform a
Z«Y », Y «V».
search in the graph to find a path from U to E, one such
being U«V», V«W», W«E». When this path has been
assuming that A frequently communicates with
discovered, the reverse path W«V», V«U», U«D» can also
users certified by Z, it can learn (in addition to the
be constructed.
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.
8 Digital Signatures
assuming that users certified by X and Z frequently
communicate, then X«Z» would be held in the
This clause is not intended to specify a standard for digital
directory entry for X, and vice versa (this is shown
signatures in general, but to specify the means by which
in figure 4). If A wants to authenticate to B, A need
the tokens are signed in the Directory.
only obtain:
X«Z», Z«B»
8.1 Information (info) is signed by appending to it an
enciphered summary of the information. The summary is
to form the certification path, and:
produced by means of a one-way hash function, while the
Z«X» enciphering is carried out using the secret key of the signer
(see figure 6). Thus
to form the return certification path.
X(Info} = Info, Xs[h (Info)]
assuming users A and C have communicated before
and have learned one anothers certificates, they may
Note - Thc encipherment using the secret key ensures that the
use each other's public key directly, i.e.,
signature cannot be forged. The one-way nature of the hash
function ensures that false information, generated so as to have
cp = xp X«C»
the same hash result (and thus signature), cannot be substituted.
and
Ap = Xp X«A»
Figure 6 - Digital Signatures
Figure 5 - Non-hierarchical Certification Path - An
Example
ISO/IEC 9594-8 : 1990(E)
The recipient of signed information verifies the define the data type resulting from applying a signature to
8.2
signature by: the given data type.
applying the one-way hash function to the
SIGNED MACRO ::=
information,
BEGIN
comparing the result with that obtained by
TYPE NOTATION ::= type (ToBeSigned)
deciphering the signature using the public key of the
VALUE NOTATION ::= value (VALUE
signer.
SEQUENCE {
ToBeSigned,
8.3 This authentication framework does not mandate a
Algorithmldentifier,
single one-way hash function for use in signing. It is
- - of the algorithm used to compute
intended that the framework shall be applicable to any
- - the signature
suitable hash function, and shall thus support changes to
ENCRYPTED OCTET STRING
the methods used as a result of future advances in
- - where the octef strhg is the result
cryptography, mathematical techniques or computational
- - of the hashing of the value of
capabilities. However, two users wishing to authenticate
- - 'ToBeSigned'- -1
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
END - - Of SIGNED
@serve to maximize the community of users able to
8.6 In the case where only the signature is required, the
authenticate and communicate securely. An example hash
following ASN.l macro may be used to define the data
function is specified in annex D.
type resulting from applying a signature to the given data
tY Pe.
The signed information includes indicators that identify the
hashing algorithm and the encryption algorithm used to
SIGNATURE MACRO ::=
compute the digital signature.
BEGIN
8.4 The encipherment of some data item may be TYPE NOTATION ::= type (OfSignature)
described using the following ASN. 1 macro:
VALUE NOTATION ::= value (VALUE
SEQUENCE {
ENCRYPTED MACRO ::=
Algoriihmldentifier,
BEGIN
- - of the algorithm used to compute
- - the signature
TYPE NOTATION := type(T0BeEnciphered)
ENCRYPTED OCTET STRING
- -where the octet string is a function (e.g. a
VALUE NOTATION ::= value (VALUE BIT STRING)
- - compressed or hashed version) of the
- -value OfSignature: which niuy it~clude
END - - Of ENCRYPTED
- - the identifier of the algorithm used to
The value of the bit string is generated by taking the octets
- - compute the signature - -1
which form the complete encoding (using the ASN.l Basic
)
Encoding Rules - IS0 8825) of the value of the
e
ToBeEnciphered type and applying an encipherment END - - Of SIGNATURE
procedure to those octets.
8.7 In order to enable the validation of SIGNED and
SIGNATURE types in a distributed environment, a
Notes
distinguished encoding is required. A distinguished
1 The encryption procedure requires agreement on the
encoding of a SIGNED or SIGNATURE data value shall
algorithm to be applied, including any parameters of the
be obtained by applying the Basic Encoding Rules defined
algorithm such as any necessary keys, initialization values, and
in IS0 8825, with the following restrictions:
padding instructions. It is the responsibility of the encryption
procedures to specify the means by which synchronization of the
a) the definite form of length encoding shall be used,
sender and receiver of data is achieved, which may include
encoded in the minimum number of octets;
information in the bits to be transmitted.
b) for string types, the constructed form of encoding
2 The encryptioii procedure is required to take as input a
shall not be used;
string of octets and to generate a single string of bits as its result.
c) if the value of a type is its default value, it shall be
3 Mechanisms for secure agreement on the encryptioii
absent;
algorithm and its parameters by the sender and receiver of data
are outside the scope of this part of ISO/IEC 9594.
d) the components of a Set type shall be encoded in
8.5 In the case where a signature must be appended to a
ascending order of their tag value;
data type, the following ASN.l macro may be used to
e) the components of a Set-of type shall be encoded in
ascending order of their octet value;
ISO/IEC 9594-8 : 1990(E)
three-way authentication, described in 9.4, involves,
if the value of a Boolean type is true, the encoding
c)
in addition, a further transfer from A to B. It
shall have its contents octet set to 'FF16;
establishes, the same properties as the two-way
each unused bits in the final octet of the encoding of
g)
authentication, but does so without the need for
a Bit String value, if there are any, shall be set to
association time stamp checking.
zero;
In each case where Strong Authentication is to take place,
the encoding of a Real type shall be such that bases
h)
A must obtain the public key of B, and the return
8, 10, and 16 shall not be used, and the binary
certification path from B to A, prior to any exchange of
scaling factor shall be zero.
information. This may involve access to the Directory, as
described in clause 7 above. Any such access is not
mentioned again in the description of the procedures
9 Strong Authentication Procedures
below.
9.1 Overview
The checking of timestamps as mentioned in the following
9.1.1 The basic approach to authentication has been clauses only applies when either synchronized clocks are
outlined above, namely the corroboration of identity by used in a local environment, or if clocks are logically
demonstrating possessio
...