Information technology — Open Systems Interconnection — The Directory — Part 8: Authentication framework

Technologies de l'information — Interconnexion de systèmes ouverts — L'Annuaire — Partie 8: Cadre général d'authentification

General Information

Status
Withdrawn
Publication Date
19-Dec-1990
Withdrawal Date
19-Dec-1990
Current Stage
9599 - Withdrawal of International Standard
Completion Date
17-Jun-1998
Ref Project

Relations

Buy Standard

Standard
ISO/IEC 9594-8:1990 - Information technology -- Open Systems Interconnection -- The Directory
English language
26 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO/IEC 9594-8:1990 - Technologies de l'information -- Interconnexion de systemes ouverts -- L'Annuaire
French language
29 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)

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)

---------------------- Page: 1 ----------------------
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
6
Obtaining a User's Public Key . 6
7
8 Digital Signatures . 8
Strong Authentication Procedures . 10
9
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

---------------------- Page: 2 ----------------------
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.
...
111

---------------------- Page: 3 ----------------------
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

---------------------- Page: 4 ----------------------
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
0
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
1

---------------------- Page: 5 ----------------------
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
2

---------------------- Page: 6 ----------------------
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.
3

---------------------- Page: 7 ----------------------
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.
4
A-

---------------------- Page: 8 ----------------------
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
5

---------------------- Page: 9 ----------------------
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, t
...

NORME ISO/CEI
I NTE R NAT1 O NALE
9594-8
Première edition
1990-12-15
Technologies de l’information - Interconnexion
de systèmes ouverts - L’Annuaire -
Partie 8:
Cadre généra
d’a ut hentificat
on
Information technolc ~y -- Open Systems Ir
lerconnection - The
Directory -
Part 8: Authentication framework
Numéro de référence
ISO/CEI 9594-8:1990(F)

---------------------- Page: 1 ----------------------
ISO/CEI 9594-8 : 1990 (FI
O ISOKEI 1990
Droits de reprodudion réservés. Aucune partie de cette publication ne peut être reproduite ni utilisée
forme que œ soit et par aucun procédé, électronique ou mécanique, y compris la
sous quelque
photocopie et les microfilms, sans l'accord écrit de l'éditeur.
ISOlCEl Copyright Office 0 Case postale 56 CH 1211 Genève 20 Suisse
Version française tirée en 1991
Imprimé en Suisse
ii

---------------------- Page: 2 ----------------------
ISO/CEI 9594-8 : 1990 (FI
Sommaire
Page
Avant-propos . iv
Introduction . v
Section 1 : Généralités 1
1 Domaine d'application . 1
2 Références normatives . 2
3 Définitions . 2
4 Notation et abréviations . 3
Section 2 : Authentification simple
4
5 Procédure d'authentification simple . 4
Section 3 : Authentification forte
6
6 Principes de base de l'authentification forte . 6
7 Comment obtenir une clé publique d'utilisateur . 7
8 Signatures numériques . 10
9 Procédures d'authentification forte . 12
10 Gestion de clés et de certificats . 14
Annexe A - Besoins de sécurité . 17
Annexe B - Introduction au chiffrement à clé publique . 20
Annexe C - Système de chiffrement à clé publique RSA . 21
Annexe D - Fonctions de condensation . 23
Annexe E - Menaces contre lesquelles l'authentification forte assure une protection . 24
Annexe F - Confidentialité des données . 25
Annexe G - Module ASN.l AuthenticationFramework . 26
Annexe H - Identificateurs d'objet . 29
...
III

---------------------- Page: 3 ----------------------
ISO/CEI 9594-8 : 1990 (FI
Avant-propos
L'ISO (Organisation internationale de normalisation) et la CE1 (Commission élec-
trotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes natio-
naux membres de I'ISO ou de la CE1 participent au développement de Normes
internationales par l'intermédiaire des comités techniques créés par l'organisation
concernée afin de s'occuper des différents domaines particuliers de l'activité tech-
nique. Les comités techniques de I'ISO et de la CE1 collaborent dans les domaines
d'intérêt commun. D'autres organisations internationales, gouvernementales ou
non gouvernementales, en liaison avec l'lS0 et la CE1 participent également aux
travaux.
Dans le domaine des technologies de l'information, 1'1S0 et la CE1 ont créé un
comité technique mixte, I'ISO/CEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux
pour approbation, avant leur acceptation comme Normes internationales. Les
Normes internationales sont approuvées conformément aux procédures qui
requièrent l'approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISO/CEI 9594-8 a été élaborée par le comité technique
mixte ISO/CEI JTC 1, Technologies de /'information.
Sous le titre général Technologies de l'information - Interconnexion de systèmes
ouverts-l'Annuaire, I'ISO/CEI 9594 est composée des parties suivantes :
- Partie I :Aperçu général des concepts, modèles et services
- Partie 2 : Modèles
- Partie 3: Définition de service abstrait
- Partie 4 : Procédures d'exploitation répartie
- Partie 5: Spécifications de protocoles
- Partie 6: Types d'attribut sélectionnés
- Partie 7: Classes d'objet sélectionnées
- Partie 8: Cadre général d'authentification
L'annexe G de la présente partie de I'ISO/CEI 9594 est normative. Les annexes A, B,
C, D, E, F et H sont informatives.
iv

---------------------- Page: 4 ----------------------
Introduction
0.1 La présente partie de I'ISO/CEI 9594, ainsi que les autres parties ont été élaborées pour faciliter I'inter-
connexion de systèmes de traitement de l'information pour fournir des services d'Annuaire. L'ensemble de
ces systèmes, ainsi que les informations d'Annuaire qu'ils détiennent, peuvent être considérés comme un
tout intégré, appelé l'((Annuaire)). Les informations détenues par l'Annuaire, appelées Base d'informations
d'Annuaire (DIB), sont généralement utilisées pour faciliter la communication entre, avec ou sur des objets
tels que entités d'application, individus, terminaux, listes de diffusion.
0.2 L'Annuaire joue un rôle important dans l'interconnexion de systèmes ouverts, dont le but est de per-
mettre, moyennant un minimum d'accords techniques en dehors des normes d'interconnexion proprement
dites, l'interconnexion de systèmes de traitement de l'information :
provenant de divers fabricants ;
gérés différemment ;
de niveaux de complexité différents ; et
d'âges différents.
0.3 Un grand nombre d'applications ont besoin de sécurité pour assurer une protection contre des mena-
ces sur la communication des informations. L'annexe A décrit brièvement les menaces les plus courantes
ainsi que les services et les mécanismes qui peuvent être utilisés pour assurer une protection contre ces
menaces. En pratique tous les services de sécurité s'appuient sur l'authentification qui est le fait que !'iden-
tité des parties communicantes est connue de manière fiable.
0.4 La présente partie de I'ISO/CEI 9594 définit un cadre général pour la fourniture de services d'authentifi-
cation par l'Annuaire à ses utilisateurs. Ces utilisateurs comprennent l'Annuaire lui-même aussi bien que
d'autres applications et services. L'Annuaire peut utilement répondre aux besoins d'authentification et
d'autres services de sécurité parce que c'est de là que les parties communicantes peuvent obtenir des infor-
mations d'authentification les unes sur les autres, ces informations étant la base de l'authentification. En
effet, l'Annuaire détient d'autres informations nécessaires à la communication et obtenues avant que la
communication ait lieu. L'obtention, à partir de l'Annuaire, d'informations d'authentification, relatives à un
partenaire potentiel de la communication, ressemble à l'obtention d'une adresse. Grâce à la portée étendue
de l'Annuaire, il est prévu que le cadre d'authentification, défini dans la présente partie de I'ISO/CEI 9594,
soit largement utilisé par toute une gamme d'applications.
V

---------------------- Page: 5 ----------------------
ISO/CEI 9594-8 : 1990 (F)
NORME INTERNATIONALE
Technologies de l'information - Interconnexion de
systèmes ouverts - L'Annuaire
Partie 8 :
Cad re généra I d'a ut hent ificat io n
Section 1 : Généralités
exécuter pour réaliser l'authentification fondée
1 Domaine d'application
O
sur les informations d'authentification obtenues
de l'Annuaire. Le protocole utilisé par les appli-
1 .I La présente partie de I'ISO/CEI 9594 :
cations pour obtenir, de l'Annuaire, des
justificatifs d'identité est le protocole d'accès à
- spécifie le format des informations d'au-
l'Annuaire (DAP) spécifié dans I'ISO/CEI 9594-5.
thentification détenues par l'Annuaire ;
- décrit comment peuvent être obtenues les
1.5 L'authentification forte définie dans la pré-
informations d'authentification, à partir de
sente partie de I'ISO/CEI 9594 est fondée sur des
l'Annuaire ;
systèmes de chiffrement à clé publique. L'avan-
- établit les hypothèses faites sur la façon tage majeur de ces systèmes est que les certifi-
cats d'utilisateur peuvent être détenus dans
dont les informations d'authentification sont
l'Annuaire en tant qu'attributs pouvant être com-
formées et entrées dans l'Annuaire ;
muniqués librement à l'intérieur du système
- définit trois façons dont les applications
d'Annuaire et livrés aux utilisateurs de I'An-
peuvent utiliser ces informations d'authentifi-
nuaire par les mêmes méthodes que d'autres
cation pour réaliser l'authentification et décrit
informations d'Annuaire. II est supposé que les
comment d'autres services de sécurité peuvent
certificats d'utilisateurs sont créés par des
être assurés par l'authentification.
moyens externes et entrés dans l'Annuaire par
leur créateur. La création des certificats est assu-
rée par une autorité de certification qui est com-
1.2 La présente partie de I'ISO/CEI 9594 décrit
0
plètement indépendante des DSA de l'Annuaire.
deux niveaux d'authentification : I'authentifica-
En particulier, rien n'est exigé des fournisseurs
tion simple, fondée sur l'utilisation d'un mot de
de l'Annuaire pour que le stockage et la commu-
passe pour vérifier une identité déclarée ; et I'au-
nication des certificats d'utilisateurs soient sûrs.
thentification forte, impliquant des justificatifs
L'annexe B présente brièvement les systèmes de
d'identité formés en utilisant des techniques de
chiffrement à clé publique.
chiffrement. Alors que l'authentification simple
assure une protection limitée contre l'accès non
autorisé, seule l'authentification forte devrait
1.6 Le cadre général d'authentification n'impose
servir de base à la fourniture de services de
pas l'utilisation d'un algorithme de chiffrement
sécurité. II n'est pas question de faire de ces
particulier, pourvu que celui qui est utilisé ait les
techniques une règle générale pour réaliser I'au-
propriétés décrites en 6.1. Plusieurs algorithmes
thentification mais elles peuvent être utilisées
différents peuvent être utilisés. Cependant deux
par les applications qui les jugent appropriées.
utilisateurs souhaitant s'authentifier doivent
adopter le même algorithme pour que I'authenti-
1;3 L'authentification (ainsi que d'autres servi-
fication soit réalisée correctement. Ainsi, dans le
ces de sécurité) ne peuvent être fournis que
contexte d'un ensemble d'applications, le choix
dans le contexte d'une politique de sécurité défi-
d'un algorithme unique permettra d'élargir au
nie. II appartient aux utilisateurs d'une applica-
maximum la communauté des utilisateurs capa-
tion de définir leur propre politique de sécurité
bles de s'authentifier et de communiquer en toute
qui peut être limitée aux services définis par une
sécurité. L'annexe C donne un exemple d'algo-
. norme.
rithme dechiffrement à clé publique.
1.4 II appartient aux normes où sont définies des
applications utilisant le cadre général d'authenti-
fication de spécifier les échanges de protocole à
1

---------------------- Page: 6 ----------------------
ISO/CEI 9594-8 : 1990 (F)
1.7 De même, deux utilisateurs souhaitant s’au-
3 Définitions
thentifier doivent utiliser la même fonction de
condensation (voir 3.3 f)) dans la formation de
3.1 La présente partie de I’ISO/CEI 9594 utilise
justificatifs d’identité et de jetons d‘authentifica-
les termes suivants, définis dans I’ISO 7498-2 :
tion. En principe, plusieurs fonctions de conden-
sation différentes pourraient être utilisées au
a) chiffrement asymétrique ;
prix d’un rétrécissement de la communauté des
utilisateurs capables de s’authentifier. L’annexe b) échange d‘authentification ;
D présente brièvement les fonctions de conden-
c) information d‘authentification ;
sation ainsi qu‘un exemple de fonction de
condensation.
d) confidentialité ;
e) justificatif d‘identité ;
2 Références normatives
f) chiffrement ;
g) authentification de l’origine des données ;
Les normes suivantes contiennent des disposi-
tions qui, par suite de la référence qui est en
h) déchiffrement ;
faite, constituent des dispositions valables pour
i) chiffrement ;
la présente partie de I’ISO/CEI 9594. Au moment
de la publication, les éditions indiquées étaient
j) clé ;
en vigueur. Toute norme est sujette à révision et
les parties prenantes des accords fondés sur la k) mot de passe ;
présente partie de I‘ISO/CEI 9594 sont invitées à
I) authentification de l’entité homologue ;
rechercher la possibilité d’appliquer les éditions
les plus récentes des normes indiquées ci-après.
m) chiffrement symétrique.
Les membres de la CE1 et de I‘ISO possèdent le
registre des Normes internationales en vigueur a
3.2 La présente partie de I‘ISO/CEI 9594 utilise
un moment donné.
les termes suivants, définis dans I’ISO/CEI
9594-2 :
IS0 7498-2:1987, Systèmes de traitement
de l‘information - Inter-
a) attribut ;
connexion de systèmes
ouverts - Modèle de
b) base d‘informations d’Annuaire (DIB) ;
référence de base - Par-
c) arbre d’informations d‘Annuaire (DIT) ;
tie 2 : Architecture de
sécurité.
d) nom distinctif;
ISO/CEI 8824:1990, Technologies de I‘infor-
e) entrée ;
mation - Interconnexion
f) objet ;
de systèmes ouverts -
Spécification de la nota-
g) racine.
tion de syntaxe abstraite
numéro 1 (ASN.1).
3.3 Dans le cadre de la présente partie de
ISO/CEI 8825:1990, Technologies de I‘infor-
I‘ISO/CEI 9594, les définitions suivantes sont
mation - Interconnexion
également utilisées :
de systèmes ouverts -
Spécification des règles
3.3.1 jeton d‘authentification (jeton) : Informa-
de codage de base pour
tions véhiculées au cours d’un échange d’au-
la notation de syntaxe
thentification forte et pouvant être utilisées pour
abstraite numéro 1
authentifier l’expéditeur.
(ASN. 1).
3.3.2 certificat d’utilisateur (certificat) : Clés
ISO/CEI 10021-3: 1990, Technologies de I‘infor-
publiques d’un utilisateur, avec d‘autres informa-
mation - Communica-
tions, rendues infalsifiables par chiffrement avec
tion de texte - Systèmes
la clé privée de l’autorité de certification qui
d‘échange de texte en
émet le certificat.
mode message - Partie 3 :
Conventions pour la défi-
3.3.3 autorité de certification : Autorité chargée
nition de service abstrait.
par un ou plusieurs utilisateurs de créer et d’at-
tribuer des certificats. L’autorité peut, en option,
créer les clés d‘utilisateur.
2

---------------------- Page: 7 ----------------------
ISO/CEI 9594-8 : 1990 (FI
3.3.4 chemin de certification : Séquence ordon- 3.3.11 politique de sécurité : Ensemble de
règles établies par l'autorité de sécurité régissant
née de certificats d'objets dans le DIT qui, avec la
clé publique de l'objet initial du chemin, peut l'utilisation et la fourniture de services et facilités
être traitée pour obtenir la clé publique de l'objet de sécurité.
final du chemin.
3.3.12 authentification forte : Authentification
3.3.5 système de chiffrement : Transformations fondée sur des justificatifs d'identité déterminés
de texte en clair en cryptogramme et vice-versa, par chiffrement.
la (les) transformation(s) particulière(s) à utiliser
étant choisie(s) par des clés. Les transformations
3.3.13 confiance : Une entité fait confiance à
sont normalement définies par un algorithme une autre entité quand la première suppose que
mathématique. la seconde se comportera comme elle s'y attend.
Cette confiance ne peut s'appliquer que pour
3.3.6 fonction de condensation : Fonction quelques fonctions spécifiques. Dans le cadre
mathématique qui met en correspondance des général d'authentification, le rôle de la confiance
valeurs d'une plage très étendue avec celle d'une est de décrire les relations entre une entité utili-
plage plus petite. Une bonne fonction de sant l'authentification et une autorité de certifica-
condensation est telle que les résultats de I'appli- tion ; une entité utilisant l'authentification doit
cation de la fonction seront répartis sur la plage être sûre que l'autorité de certification ne crée
(apparemment de façon aléatoire).
que des certificats valides et fiables.
3.3.7 fonction univoque : Fonction mathémati- 3.3.14 numéro de série de certificat : Entier, uni-
que f facile à calculer mais, pour laquelle, il est que à l'intérieur du domaine de l'autorité de
difficile de trouver une valeur x telle que f(x) = y, certification qui l'émet, associé sans ambiguïté à
étant une valeur générale de la plage. II peut y un certificat émis par cette autorité de certifica-
y
avoir très peu de valeurs y pour lesquelles il est tion.
aisé de calculer x.
4 Notation et abréviations
3.3.8 clé publique : Dans un système de chiffre-
ment à clé publique, la clé d'une paire de clés
d'utilisateur qui est rendue publique.
4.1 Le tableau 1 définit la notation utilisée dans
la présente partie de I'ISO/CEI 9594.
3.3.9 clé privée (ou clé secrète) : Dans un sys-
NOTE - Dans le tableau, les symboles X, X, et X,
tème de chiffrement à clé publique, la clé d'une
désignent des utilisateurs ; I désigne une informa-
paire de clés d'utilisateur qui n'est connue que
tion quelconque.
de l'utilisateur.
3.3.10 authentification simple : Authentification
fondée sur des mots de passe simples.
3

---------------------- Page: 8 ----------------------
ISO/CEI 9594-8 : 1990 (FI
Tableau 1 - Notation
Notation Signification
Clé publique d'un utilisateur X
KP
KS Clé privée de X
XP [II Chiffrement d'une information, I, en utilisant la clé publique de X
Chiffrement de I en utilisant la clé privée de X
Signature de I par X, se composant de I et d' un résumé chiffré attaché
CA(X) Autorité de certification de l'utilisateur X
(où n > 1) : CA (CA (. n fois . (X)))
EAn (X)
x1ccx2>> Certificat de l'utilisateur X, émis par l'autorité de certification X,
Chaîne de certificat (de longueur arbitraire) dont chaque élément est le certificat
pour l'autorité de certification qui a produit le suivant. II est équivalent au certificat
X,ccXn+l>>. Par exemple, la possession de A<>B> fournit la même capa-
cité que A>, à savoir, la possibilité de trouver Cp, Ap étant donné.
x,p , x, > Opération de révélation d'un certificat (ou d'une chaîne de certificats) pour en
extraire une clé publique. C'est un opérateur d'infixe dont l'opérande gauche est la
clé publique d'une autorité de certification, et l'opérande droit est un certificat émis
par cette autorité. Le résultat est la clé publique de l'utilisateur dont le certificat est
l'opérande droit. Par exemple :
Ap . A ccBz> B ccC>>
indique les opérations d'apres lesquelles la clé publique de B, Bp, est obtenue en uti-
lisant la clé publique de A, à partir du certificat de B, le certificat de C est ensuite
révélé en utilisant Bp.
Le résultat de l'opération est la clé publique de C, Cp.
A+B Chemin de certification allant de A à B, formé d"une chaîne de certificats, commen-
çant par CA(A) <> et se terminant par CA(B)ccB>>.
Section 2 : Authentification simple
5 Procédure d'authentification simple de diverses manières :
a) l'envoi au destinataire, qui les évalue, du
5.1 L'authentification simple vise à fournir une
nom distinctif de l'utilisateur et (en option) du
autorisation locale fondée sur un nom distinctif
mot de passe en clair (non protégé) ;
d'utilisateur, un mot de passe accepté par
accord bilatéral (en option) et une entente
b) l'envoi du nom distinctif de l'utilisateur, du
mutuelle sur les modalités d'emploi de ce mot
mot de passe, d'un numéro aléatoire et/ou
de passe dans un domaine unique. L'utilisation
d'une indication horaire, protégés par I'appli-
de l'authentification simple est avant tout desti-
cation d'une fonction univoque ;
née à un usage local uniquement, c'est-à-dire à
c) l'envoi des informations définies en b) en
l'authentification de l'entité homologue entre un
même temps qu'un numéro aléatoire et/ou
DUA et un DSA ou entre un DSA et un autre
qu'une indication horaire, protégés par I'ap-
DSA. L'authentification simple peut être réalisée
plication d'une fonction univoque.
4

---------------------- Page: 9 ----------------------
ISO/CEI 9594-8 : 1990 (F)
NOTES 5.4 La figure 2 montre deux manières de pro-
duire des informations d'identification proté-
1 II n'est pas nécessaire que les fonctions univo-
gées. fl et f2 sont des fonctions univoques
ques appliquées soient différentes.
(identiques ou différentes) ; les indications horai-
res et les numéros aléatoires sont optionnels et
2 Les procédures de protection des mots de passe
font l'objet d'accords bilatéraux.
peuvent faire l'objet d'additifs a la présente Norme
internationale.
5.2 Quand les mots de passe ne sont pas proté-
gés, un niveau minimum de sécurité est fourni
Protectedl
A
*
pour empêcher un accès non autorisé. Ce niveau
passwA --) *
ne doit pas être considéré comme une base de
-
fl
tlA
services de sécurité. La protection du nom dis-
tinctif de l'utilisateur et du mot de passe assure
qlA--) Protected2
une plus grande sécurité. Les algorithmes à utili-
f2 m
ser pour les mécanismes de protection sont des
t2A *
fonctions univoques sans chiffrement qui sont
-D
e -
très simples à mettre en œuvre.
5.3 La figure 1 représente la procédure générale
d'authentification simple.
Légende
A = nom distinctif d'utilisateur
t A = indications horaires
passwA = mot de passe de A
qA = numéros aléatoires, avec
un compteur
(en option)
Figure 2 - Authentification simple
protégée
5.4.1 La figure 3 montre la procédure d'authen-
tification simple protégée.
Figure 1 - Procédure d'authentification
simple non protégée
e
5.3.1 La procédure comporte les étapes suivan-
tes :
1) un expéditeur A envoie son nom distinctif et
son mot de passe au destinataire B ;
2) B envoie le nom distinctif et le mot de passe
présentés à l'Annuaire où le mot de passe est
Figure 3 - Procédure d'authentification simple
comparé à celui détenu par l'Annuaire en tant
protégée
qu'attribut Userpassword de l'entrée A (ceci
est réalisé en utilisant l'opération d'Annuaire
La procédure comporte les étapes suivantes :
Compare) ;
1) un expéditeur A envoie ses informations pro-
3) l'Annuaire confirme (ou infirme) à B que le
tégées (Authenticatorl) à B. La protection est
justificatif d'identité est valide ;
obtenue en appliquant la fonction (fl) de la
figure 2, où l'indication horaire et/ou le
4) le résultat de l'authentification (succès ou
numéro aléatoire sont utilisés (s'ils le sont)
échec) peut être transmis à A.
pour minimiser le risque de rejouer et pour
cacher le mot de passe.
5.3.2 La forme d'authentification simple la plus
peut
élémentaire ne comprend que l'étape 1) et
La protection du mot de passe de A a la forme :
inclure l'étape 4) après que B ait vérifié le nom
distinctif et le mot de passe.
Protectedl = fl (tlA , qIA , A, passwA)
5

---------------------- Page: 10 ----------------------
ISO/CEI 9594-8 : 1990 (F)
Les informations envoyées à B ont la forme :
Les informations envoyées à B ont la forme
Authenticator1 = tlA , qlA , A, Protectedl Authenticator2 = tlA, t2*, qIA , q2A, A,
Protected2
B vérifie les informations d'identification pro-
tégées envoyées par A en produisant une B produit une valeur locale du mot de passe
copie protégée locale du mot de passe de A protégé supplémentaire de A et le compare à
celui de Protected2 (comme dans l'étape 1 de
(ayant la forme Protectedl) ; ceci est réalisé en
utilisant le nom distinctif, une indication 5.4.1) ;
horaire et/ou un numéro aléatoire fournis par
A, en même temps qu'une copie locale du mot
2) B confirme ou infirme à A la vérification des
de passe de A. B compare les informations
informations d'identification protégées.
d'identification présentées (Protectedl) aux
valeurs produites localement ;
NOTE - Les procédures définies dans les paragra-
A et B. Appli-
phes précédents utilisent les termes
2) B confirme ou infirme à A la vérification des à l'Annuaire (voir ISOKEI 9594-3 et ISO/CEI
quées
informations d'identification protégées. 9594-4), A pourrait être un DUA lié à un DSA, B ;
autre possibilité, A pourrait être un DSA lié à un
a
autre DSA, B.
5.4.2 La procédure décrite en 5.4.1 peut être
modifiée pour offrir une plus grande protection
5.5 Un type d'attribut UserPassword contient le
en utilisant fl et f2. Les principales différences
mot de passe d'un objet. La valeur d'attribut est
sont :
une chaîne de caractères définie par l'objet.
1) A envoie à B ses informations d'identification
UserPassword ::= ATTRIBUTE
protégées supplémentaires (Authenticator2).
WITH ATTRIBUTE-SYNTAX
La protection supplémentaire est réalisée en
OCTET STRING (SIZE (O.ub-user-password))
utilisant une autre fonction, f2, comme le MATCHES FOR EQUALITY
montre la figure 2. La protection a la forme :
5.6 La macro ASN.l suivante peut être utilisée
Protected2 = f2 (t2A, q2A, Protected1
pour définir le type de données obtenu par Yap-
plication d'une fonction univoque à un autre
type de données :
PROTECTED MACRO ::= SIGNATURE
a
Section 3 : Authentification forte
menvdéchiffrement utilisant les clés publique et
6 Principes de base de l'authentifica-
privée de l'utilisateur X.
tion forte
NOTE - D'autres types de PKCS pourraient faire
l'objet d'additifs a la présente partie de I'ISO/CEI
6.1 L'authentification forte est abordée dans la
9594 ; c'est-à-dire, des PKCS n'exigeant pas la pro-
présente partie de I'ISO/CEI 9594 en utilisant les
priété de permutabilité et qui peuvent être pris en
propriétés des systèmes de chiffrement à clé
charge sans que la présente partie de I'ISO/CEI 9594
publique (PKCS). Ces systèmes, également
soit beaucoup modifiée.
décrits comme asymétriques, font intervenir une
paire de clés, une clé privée et une clé publique,
au lieu d'une seule clé comme c'est le cas dans 6.2 Le cadre général d'authentification défini
les systèmes de chiffrement classiques. L'an- dans la présente partie de I'ISO/CEI 9594 n'im-
nexe B présente brièvement ces systèmes de pose pas l'utilisation d'un système de chiffre-
chiffrement et les propriétés qui les rendent uti- ment particulier. Ce cadre général vise à être
les pour l'authentification. Pour qu'un PKCS soit applicable à tout système de chiffrement à clé
utilisable dans ce cadre général d'authentifica-
publique approprié et à intégrer les modifica-
tion, les deux clés doivent pouvoir être utilisées tions apportées aux méthodes résultant du pro-
pour le chiffrement, la clé privée étant utilisée grès des techniques mathématiques ou des
pour déchiffrer si la clé publique a été utilisée et capacités des ordinateurs. Cependant, deux uti-
lisateurs souhaitant s'authentifier doivent choi-
la clé publique étant utilisée si la clé privée a été
sir le même algorithme de chiffrement pour que
utilisée. En d'autres termes, Xp . Xs = Xs . Xp,
avec Xp/Xs étant des fonctions de chiffre- l'authentification soit réalisée correctement.
6

---------------------- Page: 11 ----------------------
ISO/CEI 9594-8 : 1990 (F)
Ainsi, dans le contexte d'un ensemble d'appli- - l'autorité de certification peut seule modifier
cations en relation, le choix d'un algorithme le certificat sans que ce soit détecté (les certifi-
unique doit permettre d'élargir au maximum la cats sont infalsifiables).
communauté des utilisateurs capables de s'au-
thentifier et de communiquer en toute sécurité,
Puisque les certificats sont infalsifiables, ils peu-
L'annexe C donne un exemple d'algorithme de
vent être rendus publics en les mettant dans
chiffrement.
l'Annuaire sans que celui-ci ait besoin de les pro-
téger.
6.3 L'authentification est fondée sur la posses-
NOTE - Bien que les autorités de certification
sion d'un nom distinctif unique par chaque utili-
soient définies sans ambiguïté par un nom distinctif
sateur. L'attribution de noms distinctifs relève
dans le DIT, il n'y a pas de relation entre l'organisa-
des autorités de dénomination. Les utilisateurs
tion de l'autorité de certification et celle du DIT.
doivent donc faire confiance aux autorités de
dénomination pour qu'elles n'attribuent pas
7.2 Une autorité de certification produit le certi-
deux fois le même nom distinctif.
ficat d'un utilisateur en signant (voir article 8) un
ensemble d'informations, y compris le nom dis-
6.4 Chaque utilisateur est identifié par la pos-
tinctif de l'utilisateur et la clé publique. Le certifi-
0
session de sa clé privée. Un se
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.