ISO/IEC 15945:2002
(Main)Information technology — Security techniques — Specification of TTP services to support the application of digital signatures
Information technology — Security techniques — Specification of TTP services to support the application of digital signatures
This Recommendation | International Standard will define those TTP services needed to support the application of digital signatures for the purpose of non-repudiation of creation of documents. This Recommendation | International Standard will also define interfaces and protocols to enable interoperability between entities associated with these TTP services. Definitions of technical services and protocols are required to allow for the implementation of TTP services and related commercial applications. This Recommendation | International Standard focuses on: ? implementation and interoperability; ? service specifications; and ? technical requirements. This Recommendation | International Standard does not describe the management of TTPs or other organizational, operational or personal issues. Those topics are mainly covered in ITU-T Rec. X.842 | ISO/IEC TR 14516, Information technology ? Security techniques ? Guidelines on the use and management of Trusted Third Party services. NOTE 1 ? Because interoperability is the main issue of this Recommendation | International Standard, the following restrictions hold: i) Only those services which may be offered by a TTP, either to end entities or to another TTP, are covered in this Recommendation | International Standard. ii) Only those services which may be requested and/or delivered by means of standardizable digital messages are covered. iii) Only those services for which widely acceptable standardized messages can be agreed upon at the time this Recommendation | International Standard is published are specified in detail. Further services will be specified in separate documents when widely acceptable standardized messages are available for them. In particular, time stamping services will be defined in a separate document. NOTE 2 ? The data structures and messages in this Recommendation | International Standard will be specified in accordance to RFC documents, RFC 2510 and RFC 2511 (for certificate management services) and to RFC 2560 (for OCSP services). The certificate request format also allows interoperability with PKCS#10. See Annex C for references to the documents mentioned in this Note. NOTE 3 ? Other standardization efforts for TTP services in specific environments and applications, like SET or EDIFACT, exist. These are outside of the scope of this Recommendation | International Standard. NOTE 4 ? This Recommendation | International Standard defines technical specifications for services. These specifications are independent of policies, specific legal regulations, and organizational models (which, for example, might define how duties and responsibilities are shared between Certification Authorities and Registration Authorities). Of course, the policy of TTPs offering the services described in this Recommendation | International Standard will need to specify how legal regulations and the other aspects mentioned before will be fulfilled by the TTP. In particular, the policy has to specify how the validity of digital signatures and certificates is determined.
Technologies de l'information — Techniques de sécurité — Spécification de services de tiers de confiance TTP pour la prise en charge des applications de signature numérique
La présente Recommandation | Norme internationale définit les services TTP nécessaires à la prise en charge des applications de signature numérique aux fins de non-répudiation de création de documents. La présente Recommandation | Norme internationale définit également les interfaces et protocoles permettant l'interopérabilité entre des entités associées à ces services TTP. Les définitions de services techniques et de protocoles sont nécessaires pour permettre l'implémentation des services TTP et des applications commerciales associées. La présente Recommandation | Norme internationale est centrée sur: . l'implémentation et l'interopérabilité; . les spécifications de services; . les prescriptions techniques. La présente Recommandation | Norme internationale ne décrit pas la gestion des tiers TTP ou d'autres questions organisationnelles, d'exploitation ou personnelles. Ces sujets sont principalement couverts dans la Rec. UIT-T X.842 | ISO/CEI TR 14516, Technologies de l'information . Techniques de sécurité . Lignes directrices pour l'utilisation et la gestion des services de tiers de confiance. NOTE 1 . Puisque l'interopérabilité est le sujet principal de la présente Recommandation | Norme internationale, les restrictions suivantes s'appliquent: i) ne sont pris en considération dans la présente Recommandation | Norme internationale que les services qui peuvent être fournis par un TTP soit aux entités terminales soit à un autre TTP; ii) ne sont pris en considération que les services qui peuvent être demandés ou fournis au moyen de messages numériques normalisables; iii) ne sont spécifiés en détail que les services pour lesquels des messages normalisés acceptables à grande échelle peuvent être adoptés au moment de la publication de la présente Recommandation | Norme internationale. D'autres services seront spécifiés dans des documents distincts lorsque des messages normalisés acceptables à grande échelle seront disponibles pour eux. La définition des services horodateurs en particulier fera l'objet d'un document séparé. NOTE 2 . La structure des données et les messages figurant dans la présente Recommandation | Norme internationale seront spécifiés conformément aux documents RFC 2510 et 2511 (pour les services de gestion de certificats) et RFC 2560 (pour les services OCSP). Le format de la demande de certificat permet aussi l'interopérabilité avec le système PKCS # 10. Voir l'Annexe C pour des références aux documents mentionnés dans la présente note. NOTE 3 . Il existe d'autres tentatives de normalisation des services TTP dans des environnements et des applications spécifiques, comme SET ou EDIFACT. Ils ne s'inscrivent pas dans le cadre de la présente Recommandation | Norme internationale. NOTE 4 . La présente Recommandation | Norme internationale définit des spécifications techniques pour les services. Ces spécifications ne dépendent pas des politiques, des règlements juridiques particuliers ou des modèles organisationnels (qui pourraient par exemple définir comment sont réparties les tâches et les responsabilités entre les autorités de certification et les autorités d'enregistrement). Evidemment, la politique des TTP offrant les services décrits dans la présente Recommandation | Norme internationale devra spécifier comment les règlements juridiques et les autres aspects susmentionnés seront respectés par le TTP. La politique doit en particulier spécifier comment la validité des signatures et des certificats numériques est déterminée.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 15945
First edition
2002-02-01
Information technology — Security
techniques — Specification of TTP
services to support the application of
digital signatures
Technologies de l'information — Techniques de sécurité —
Spécifications des services TTP pour supporter l'application des
signatures numériques
Reference number
©
ISO/IEC 2002
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 2002
All rights reserved. Unless otherwise specified, 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 either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 2002 – All rights reserved
CONTENTS
Page
1 Scope . 1
2 Normative references. 1
2.1 Identical Recommendations | International Standards. 2
2.2 Additional references. 2
3 Definitions . 3
4 Abbreviations. 4
5 Descriptive classification of services. 5
5.1 Certificate management services. 5
5.2 Key management services . 8
5.3 Other services . 9
6 Minimal certificate and CRL profile. 10
6.1 Minimal certificate profile. 10
6.2 Minimal CRL profile. 11
7 Certificate management messages . 11
7.1 Overview of certificate management services and messages . 12
7.2 Assumptions and restrictions for some of the services. 15
8 Data structures for certificate management messages . 19
8.1 Overall message . 19
8.2 Common Data Structures . 22
8.3 Data structures specific for Certificate Request Messages of type CertReq. 24
8.4 Data structures specific for other messages. 29
8.5 Transport protocols. 32
8.6 Complete ASN.1 Module . 32
9 Online Certificate Status Protocol . 40
9.1 Protocol Overview. 40
9.2 Functional Requirements. 42
9.3 Detailed Protocol. 43
9.4 ASN.1 Module for OCSP . 47
Annex A – Interworking . 50
Annex B – Algorithms . 51
B.1 Hash Algorithms. 51
B.2 Digital Signature Algorithms. 51
Annex C – Bibliography . 52
© ISO/IEC 2002 – All rights reserved iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the
specialized system for worldwide standardization. National bodies that are members of ISO 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. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In
the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
The main task of the joint technical committee is to prepare International Standards. 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 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 15945 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 27, IT
Security techniques, in collaboration with ITU-T. The identical text is published as ITU-T Rec. X.843.
Annexes A to C of this International Standard are for information only.
iv © ISO/IEC 2002 – All rights reserved
Introduction
Today the development of information technology, as well as that of the worldwide communication infrastructure, opens
the possibility to implement electronic commerce in economically relevant dimensions. Digital signatures are an
important technique to add security to these commercial applications and to other application fields with a need for
legally effective electronic transactions.
Digital signatures are suitable to assure the integrity of data and the authentication of participants in transactions. They
can supply an analogue of the handwritten signature for digital orders, offers and contracts. The most important property
of digital signatures in this context is that a person who signed a document cannot successfully deny this fact. This
property is called "non-repudiation of creation" of a document.
In several countries and in international contexts, legislation concerning digital signatures is being pushed forward with
the aim to support the development of electronic commerce and other application fields with a need for legally effective
electronic transactions.
A number of standards exist that specify digital signatures, as well as their use for different purposes, like
non-repudiation or authentication. A number of commercial applications, as well as TTPs offering services in connection
with digital signatures, are implemented or planned. Interoperability of these TTPs, among each other and with the
commercial applications, is needed for an economically and legally effective worldwide use of digital signatures.
The goal of this Recommendation | International Standard is to define the services required to support the application of
digital signatures for non-repudiation of creation. Since the use of digital signature mechanisms for non-repudiation of
creation of a document implies integrity of the document and authenticity of the creator, the services described in this
Recommendation | International Standard can also be combined to implement integrity and authenticity services. This is
done in a way to promote interoperability among TTPs as well as between TTPs and commercial applications.
NOTE – There is no inherent reason why every TTP planning to support the application of digital signatures should be required to
offer all of these services. It is possible that a number of TTPs offering different services cooperate in supporting the use of digital
signatures. But, from the view of the potential commercial applications, the whole range of the services may be required and
interoperability becomes even more important in this scenario. This is an additional justification to collect all these services
together in one document.
© ISO/IEC 2002 – All rights reserved v
INTERNATIONAL STANDARD
ISO/IEC 15945:2001 (E)
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY – SECURITY TECHNIQUES – SPECIFICATION
OF TTP SERVICES TO SUPPORT THE APPLICATION OF DIGITAL SIGNATURES
1 Scope
This Recommendation | International Standard will define those TTP services needed to support the application of digital
signatures for the purpose of non-repudiation of creation of documents.
This Recommendation | International Standard will also define interfaces and protocols to enable interoperability
between entities associated with these TTP services.
Definitions of technical services and protocols are required to allow for the implementation of TTP services and related
commercial applications.
This Recommendation | International Standard focuses on:
– implementation and interoperability;
– service specifications; and
– technical requirements.
This Recommendation | International Standard does not describe the management of TTPs or other organizational,
operational or personal issues. Those topics are mainly covered in ITU-T Rec. X.842 | ISO/IEC TR 14516, Information
technology – Security techniques – Guidelines on the use and management of Trusted Third Party services.
NOTE 1 – Because interoperability is the main issue of this Recommendation | International Standard, the following restrictions
hold:
i) Only those services which may be offered by a TTP, either to end entities or to another TTP, are covered in this
Recommendation | International Standard.
ii) Only those services which may be requested and/or delivered by means of standardizable digital messages are
covered.
iii) Only those services for which widely acceptable standardized messages can be agreed upon at the time this
Recommendation | International Standard is published are specified in detail.
Further services will be specified in separate documents when widely acceptable standardized messages are available for them. In
particular, time stamping services will be defined in a separate document.
NOTE 2 – The data structures and messages in this Recommendation | International Standard will be specified in accordance to
RFC documents, RFC 2510 and RFC 2511 (for certificate management services) and to RFC 2560 (for OCSP services). The
certificate request format also allows interoperability with PKCS#10. See Annex C for references to the documents mentioned in
this Note.
NOTE 3 – Other standardization efforts for TTP services in specific environments and applications, like SET or EDIFACT, exist.
These are outside of the scope of this Recommendation | International Standard.
NOTE 4 – This Recommendation | International Standard defines technical specifications for services. These specifications are
independent of policies, specific legal regulations, and organizational models (which, for example, might define how duties and
responsibilities are shared between Certification Authorities and Registration Authorities). Of course, the policy of TTPs offering
the services described in this Recommendation | International Standard will need to specify how legal regulations and the other
aspects mentioned before will be fulfilled by the TTP. In particular, the policy has to specify how the validity of digital signatures
and certificates is determined.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of this
Recommendation | International Standard. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this Recommendation | International Standard are
encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated
below. For undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards. The Telecommunication Standardization Bureau of ITU
maintains a list of currently valid ITU-T Recommendations.
ITU-T X.843 (10/2000 E) 1
2.1 Identical Recommendations | International Standards
– ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1998, Information technology – Open Systems
Interconnection – The Directory: Models.
– ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, Information technology – Open Systems
Interconnection – The Directory: Public-key and attribute certificate frameworks.
– ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1998, Information technology – Open Systems
Interconnection – The Directory: Selected attribute types.
– ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, Information technology – Abstract Syntax
Notation One (ASN.1): Specification of basic notation.
– ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998, Information technology – Abstract Syntax
Notation One (ASN.1): Information object specification.
– ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998, Information technology – Abstract Syntax
Notation One (ASN.1): Constraint specification.
– ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998, Information technology – Abstract Syntax
Notation One (ASN.1): Parameterization of ASN.1 specifications.
– ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, Information technology – ASN.1 encoding
rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER).
– ITU-T Recommendation X.810 (1995) | ISO/IEC 10181-1:1996, Information technology – Open Systems
Interconnection – Security frameworks for open systems: Overview.
– ITU-T Recommendation X.813 (1996) | ISO/IEC 10181-4:1997, Information technology – Open Systems
Interconnection – Security frameworks for open systems: Non-repudiation framework.
2.2 Additional references
– ISO/IEC 9796-2:1997, Information technology – Security techniques – Digital signature schemes giving
message recovery – Part 2: Mechanisms using a hash-function.
– ISO/IEC 9796-3:2000, Information technology – Security techniques – Digital signature schemes giving
message recovery – Part 3: Discrete logarithm based mechanisms.
– ISO/IEC 10118-1:1994, Information technology – Security techniques – Hash-functions – Part 1:
General.
– ISO/IEC 10118-2:1994, Information technology – Security techniques – Hash-functions – Part 2:
Hash-functions using an n-bit block cipher algorithm.
– ISO/IEC 10118-3:1998, Information technology – Security techniques – Hash-functions – Part 3:
Dedicated hash-functions.
– ISO/IEC 11770-1:1996, Information technology – Security techniques – Key management – Part 1:
Framework.
– ISO/IEC 11770-2:1996, Information technology – Security techniques – Key management – Part 2:
Mechanisms using symmetric techniques.
– ISO/IEC 11770-3:1999, Information technology – Security techniques – Key management – Part 3:
Mechanisms using asymmetric techniques.
– ISO/IEC 13888-1:1997, Information technology – Security techniques – Non-repudiation – Part 1:
General.
– ISO/IEC 13888-2:1998, Information technology – Security techniques – Non-repudiation – Part 2:
Mechanisms using symmetric techniques.
– ISO/IEC 13888-3:1997, Information technology – Security techniques – Non-repudiation – Part 3:
Mechanisms using asymmetric techniques.
– ISO/IEC 14888-1:1998, Information technology – Security techniques – Digital signatures with appendix
– Part 1: General.
2 ITU-T X.843 (10/2000 E)
– ISO/IEC 14888-2:1999, Information technology – Security techniques – Digital signatures with appendix
– Part 2: Identity-based mechanisms.
– ISO/IEC 14888-3:1998, Information technology – Security techniques – Digital signatures with appendix
– Part 3: Certificate-based mechanisms.
– ISO/IEC 15946-2 (to be published), Information technology – Security techniques – Cryptographic
techniques based on elliptic curves – Part 2: Digital signatures.
3 Definitions
The following term is defined in ISO/IEC 11770-1:
key management
The following term is defined in ISO/IEC 10181-1:
Trusted Third Party (TTP)
The following terms are defined in ITU-T Rec. X.509 | ISO/IEC 9594-8:
CA-certificate
Certification Authority (CA)
public key certificate
NOTE – The shorter term "certificate" will also be used in this Recommendation | International Standard to denote "public key
certificate".
certificate policy
certificate revocation list (CRL)
certification path
The following terms are defined in ISO/IEC 10118-1:
hash function
hash-code (hash-value)
The following term is defined in ISO/IEC 14888-1:
domain parameter
For the purposes of this Recommendation | International Standard, the following definitions apply:
3.1 certificate management services: All services needed for the maintenance of the lifecycle of certificates,
including registration, certification, distribution, and revocation of certificates.
3.2 certification service: The service of creating and assigning certificates performed by a CA and described in
ISO/IEC 9594-8:1995.
3.3 digital signature: A cryptographic transformation of a data unit that allows a recipient of the data unit to prove
the origin and integrity of the data unit and protect the sender and the recipient of the data unit against forgery by third
parties, and the sender against forgery by the recipient.
NOTE – Digital signatures may be used by end entities (see below) for the purposes of authentication, of data integrity, and of
non-repudiation of creation of data. The usage for non-repudiation of creation of data is the most important one for legally binding
digital signatures. The definition above is taken from ISO/IEC 9798-1.
3.4 directly trusted CA: A directly trusted CA is a CA whose public key has been obtained and is being stored by
an end entity in a secure, trusted manner, and whose public key is accepted by that end entity in the context of one or
more applications.
ITU-T X.843 (10/2000 E) 3
3.5 directly trusted CA key: A directly trusted CA key is a public key of a directly trusted CA. It has been
obtained and is being stored by an end entity in a secure, trusted manner. It is used to verify certificates without being
itself verified by means of a certificate created by another CA.
NOTE – If, for example, the CAs of several organizations cross-certify each other (see Annex A), the directly trusted CA for an
entity may be the CA of the entity's organization. Directly trusted CAs and directly trusted CA keys may vary from entity to entity.
An entity may regard several CAs as directly trusted CAs.
3.6 directory service: A service to search and retrieve information from a catalogue of well defined objects, which
may contain information about certificates, telephone numbers, access conditions, addresses, etc. An example is provided
by a directory service conforming to the ITU-T Rec. X.500 | ISO/IEC 9594-1.
3.7 key distribution service: The service of distributing keys securely to authorized entities performed by a Key
Distribution Center and described in ISO/IEC 11770-1.
3.8 non-repudiation of creation: Protection against an entity's false denial of having created the content of a
message (i.e. being responsible for the content of a message).
3.9 personal security environment (PSE): Secure local storage for an entity's private key, the directly trusted CA
key and possibly other data. Depending on the security policy of the entity or the system requirements, this may be, for
example, a cryptographically protected file or a tamper resistant hardware token.
3.10 personalization service: The service of storing cryptographic information (especially private keys) to a PSE.
NOTE – The organizational and physical security measures for a service like this are not in the scope of this Recommendation |
International Standard. For organizational measures, refer to ITU-T Rec. X.842 | ISO/IEC TR 14516 Guidelines on the use and
management of Trusted Third Party services.
3.11 public key directory (PKD): A directory containing a well defined (sub)set of public key certificates. This
directory can contain certificates from different Certification Authorities.
3.12 public key infrastructure (PKI): The system consisting of TTPs, together with the services they make
available to support the application (including generation and validation) of digital signatures, and of the persons or
technical components, who use these services.
NOTE – Sometimes the persons and the technical components participating in a PKI, by using the services of TTPs, but not being
TTPs themselves, are referred to as end entities. An example of a technical equipment used by an end entity is a smartcard which
may be used as a storage and/or processing device.
3.13 registration authority (RA): Authority entitled and trusted to perform the registration service as described
below.
3.14 registration service: The service of identifying entities and registering them in a way that allows the secure
assignment of certificates to these entities.
3.15 time stamping service: A service which attests the existence of electronic data at a precise instant of time.
NOTE – Time stamping services are useful and probably indispensable to support long-term validation of signatures. They will be
defined in a separate document.
4 Abbreviations
For the purposes of this Recommendation | International Standard, the following abbreviations apply:
CA Certification Authority
CRL Certificate Revocation List
EE End Entity
OCSP On-line Certificate Status Protocol
PKD Public Key Directory
PKI Public Key Infrastructure
PSE Personal Security Environment
RA Registration Authority
TTP Trusted Third Party
4 ITU-T X.843 (10/2000 E)
5 Descriptive classification of services
This clause describes services that may be used within the context of TTP services for digital signatures. Here a
high-level description for those services is given, this description is independent of data formats, algorithms, description
languages, etc.
A detailed specification of some of these services is given in the following clauses.
It is not required that every TTP planning to support the application of digital signatures offers all of these services. It is
possible that a number of TTPs, offering different services, cooperate in supporting the use of digital signatures.
NOTE 1 – Because interoperability is the main issue of this Recommendation | International Standard, only those services which
are offered by a TTP, either to end entities or to another TTP, are described here. Furthermore, only those services are covered
which may be requested and/or delivered by means of standardizable digital messages. (However, this does not imply that
standardized messages are in fact defined for all services mentioned in this Recommendation | International Standard.)
The following examples show services that are not covered:
1) Logging of security relevant events. With respect to a digital signature PKI this is an internal service of TTPs but
not offered to entities.
2) General cryptographic services (e.g. encryption service). Processes like encryption are part of some services but
not relevant as stand-alone service in the context of digital signatures.
3) Key archiving or recovery. This may be an internal service for directly trusted CA keys. This will usually not be
done for digital signature keys of end entities.
NOTE 2 – Time stamping services will be defined in a separate document.
5.1 Certificate management services
This subclause contains a description of the following services that are part of the certificate lifecycle:
• Registration;
• Public Key Certification;
• Revocation of Certificates;
• Certificate Update; and
• Key Update.
A detailed specification for the online message flow of these services (except certificate status determination) is given in
clause 7, and the ASN.1 specification of the data structures needed for these messages is given in clause 8. The analogue
specifications for online certificate status determination (see 5.1.3.3, second method) are given in clause 9.
The directory access protocols used to make certificates and CRLs publicly available are not specified here since
specifications for these protocols already exist in ITU-T Rec. X.511 | ISO/IEC 9594-3 and ITU-T Rec. X.519 |
ISO/IEC 9594-5.
NOTE – Other protocols for directory access are LDAP (RFCs 1777, 2555 and 2587-LDAPv2) or WEB-access (RFC 2585).
Figure 1 gives an overview over the architecture of a PKI with some example services.
– certificate retrieval
EE
– certificate revocation
status determination
– registration
– certification
RA
PKD
PKD
OCSP
CA
CA
– certificate
information
T0733480-00
– cross certification
Figure 1 – Overview of Certificate Management Services
ITU-T X.843 (10/2000 E) 5
5.1.1 Registration
The trustworthiness of any Public Key infrastructure relies on the proper identification and registration of entities.
For all end entities, an RA (which may also be the CA) has to verify the end entity's identity by suitable means, and has
to assign an unambiguous and unique name to each end entity within its own domain. The certificate policy determines
the kind of means to be used for identification (e.g. ID documents) and whether the end entity has to be present in
person. Aliasing of end entity's names may also be required. Those end entities which are technical components are
registered according to the security policy for the application, e.g. network management. Applications, for which the
distinction between human and non-human end entities is important, should make this distinction clear within the
certificate. For example, a "name" could be "device type X", number "Y" located in "Z", the distinction could be made
according to policy, or an extension may indicate the difference.
A registration form may be used to collect the relevant data, e.g. name, business unit, business address, and delivery
address for the keying material.
EXAMPLE: A scenario within a company may be that each employee has to be present in person at the relevant
personnel office, showing his valid identity card. The personnel officer in charge attests the identity and sends a signed
registration form to the CA.
5.1.2 Public Key certification
The CA is responsible for the certification process, the binding of an entity's name or a pseudonym with public keys. A
certificate format is described in ITU-T Rec. X.509 | ISO/IEC 9594-8.
This Recommendation | International Standard requires that proof of possession of the private key corresponding to the
public key included in the certificate is carried out in the course of the certification service. Depending on policy, a CA
may guarantee further properties of the public key of the end entity, e.g. by including one or both of the services
described in 5.3.2 and 5.3.3.
5.1.3 Revocation of certificates
5.1.3.1 General considerations
A major concern with public key certificates is that they may have to be revoked prior to their scheduled expiration time
due to different circumstances. Revoking may be done by the issuing CA or by another authority, depending on the
policy.
The revocation is mandatory, if a private key is compromised. Other reasons may be change of name, termination of
employment, etc.
The certificate policy should state all revocation reasons. Some of these reasons can be found in ITU-T Rec. X.509 |
ISO/IEC 9594-8. The policy should include who can request revocations, and also if a specific token can be used to
identify entities who are authorized to revoke certificates such as one-time revocation passwords.
5.1.3.2 Revocation methods
Two different methods can be used to revoke certificates:
1) Issuing of a Certificate revocation list (CRL).
A CRL is a periodically issued list which is signed by the CA and identifies all certificates that are
revoked.
Revocation leads to an immediate entry in the CRL which also includes the time of revocation of the
concerned certificate. Additionally, the policy of the CA may require that the certificate is removed from
the PKD.
NOTE – Depending on the policy, it may be suitable to keep the certificate in order to check the validity of
signatures made before the revocation date (e.g. if the revocation reason is not key compromise).
In addition to the periodic publishing, the updated CRL may be published immediately.
ISO/IEC 11770-1 identifies two different revocation time stamps:
– The time of known or suspected compromise; and
– the time at which the CA was notified of the compromise by the entity.
Depending on the policy, the entry of the certificate in the CRL may be deleted when the certificate
expires (compare 5.1.3.3 Certificate revocation status determination).
2) Storing the status of the certificate in an internal trusted database of the CA and offering online certificate
status information to entities (compare 5.1.3.3 Certificate revocation status determination).
6 ITU-T X.843 (10/2000 E)
Both methods may be combined.
If a key is compromised, the standard procedure is to revoke the corresponding certificate, re-initialize the end entity,
generate a new public/private key pair, and certify the new public key with the previous attributes.
Depending on the policy, a certificate may:
– be revoked permanently;
– be suspended. The CRL entry includes a flag indicating the status "on hold".
The policy of the CA shall specify what the status "on hold" means with regard to the level of trust it represents to an
entity, and how an entity should treat this situation. For example, a certificate might be suspended as a result of an
unauthorized revocation request. Some policies do not allow the status "on hold" at all.
EXAMPLE: A policy may state the following: Whenever a verification is performed, it shall be rejected as long as the
certificate is suspended. When an evidence is verifiable using a suspended certificate, the result of the verification shall
be negative if a result is immediately needed, but can also be interpreted as a conditional validity. When the suspension
is followed by a revocation, then the evidence becomes invalid and the revocation date shall be the date of the start of the
suspension (i.e. not the date of the end of the suspension).
5.1.3.3 Certificate revocation status determination
This service allows an entity to determine if a certificate is revoked. This can be done by different methods
corresponding to the methods of revocation as described in 5.1.3.2:
1) Method 1: Checking the PKD and CRL.
2) Method 2: To request on-line the status from a TTP that is trusted for that purpose. The TTP's answer has
to be conveyed in an authentic manner to the entity.
5.1.3.4 Revocation of a CA certificate
A special scenario is encountered if a CA's private key is compromised. If that occurs:
– the certificate of the public key corresponding to the CA's compromised key has to be revoked.
Trust in the certificates, calculated with the compromised key of the CA, is not provided any more by the
CA's signature contained in these certificates. However, it is possible to guarantee the validity of such
certificates with other means (e.g. if the certificates are stored in a trustworthy way by a TTP which
provides an OCSP service). In any case, the entities should obtain a new certificate and a new directly
trusted CA key for future signatures.
Depending on the policy, the certificates calculated with the compromised key are revoked as a means of
informing the end entities about the necessity of getting new certificates.
In some situations, depending on the certificate policy and the system architecture, new key pairs should
be generated for the entities.
It is important to note that under this scenario, any signatures that were issued before the compromise
occurred, and are made secure by additional means (e.g. that are time-stamped by a time stamping
authority whose certificate is still valid), may still be considered valid, depending on policy, while any
signatures issued after the time of determined compromise, or not made secure by additional means, will
be considered invalid.
– if the public key corresponding to the CA's compromised private key is cross-certified with other CAs, an
alert message has to be sent to the other CAs. This alert message will notify them to revoke the cross-
certified CAs certificate.
5.1.4 Certificate update
In case of expiration of a certificate, it may be updated by issuing a new certificate for the public key of the entity that
was already contained in the old certificate.
This method shall not be used if :
– the key pair of the entity is compromised; or
– the state of cryptography indicates that the public key algorithm in connection with the parameters of the
key pair may not guarantee security of signatures generated with this key pair for the validity period of the
new certificate; or
– the new certificate will have substantial differences in terms of policy, extensions or attributes from the
old certificate.
ITU-T X.843 (10/2000 E) 7
The certificate policy of the CA may specify that a simplified registration procedure is acceptable to issue a new
certificate.
EXAMPLE: If the old certificate is not revoked, this may be accepted as sufficient to issue a new certificate.
The change of non-critical attributes in a certificate during its period of validity, such as name or affiliation (e.g. by a
change to another department), may also lead to the requirement for a recertification of the amended attributes with the
same keys as before. Nevertheless, in this case the previous certificate has to be revoked.
5.1.5 Key update
A new key pair is generated, either by the entity itself or by the TTP, and a certificate is issued for the public key of this
new pair.
This method shall be chosen in case of expiration of a certificate if certificate update is not acceptable for one of the
reasons given in 5.1.4. Depending on the policy of the CA, it may also be used in other situations.
The certificate policy of the CA may specify that a simplified registration procedure is acceptable to issue a certificate
for an updated key.
5.2 Key management services
General descriptions for key management services are given in ISO/IEC 11770 (all parts).
This subclause contains a description only of those key management services that may be offered as a part of services
related to the certificate lifecycle (compare 5.1). The detailed specification for the on-line message flow of those services
in clause 7, and the ASN.1 specification of the data structures in clause 8, cover the key management services as far as
they result in on-line messages between CA, RA and/or EE.
5.2.1 Key generation
In the context of digital signatures, TTPs may generate private/public key pairs for end entities if this is not done by the
entities themselves. Though the service might be offered by independent TTPs, it is assumed further on that it is done
either by a CA or a RA in response to a certification request or by the end entity prior to a certification request.
5.2.2 Key distribution
5.2.2.1 Distribution of private keys
For the description of the service, "key distribution", different modes of key transmission (on-line or off-line) and the key
generating component (TTP or entity) can be distinguished. In the case of a centralized key generation, the TTP is
responsible for a secure transmission of the entity's private key and public key certificate. Moreover, it must be ensured
that an entity's private key will be sent in a confidential manner. This can be achieved by encrypting this key with a
special (symmetric) transportation key known only to the TTP and the corresponding entity. Alternatively, the private
key may be transmitted using appropriate secure hardware facilities as for example, smartcards. The transmission of the
private key is not necessary if the entity is able to generate its own asymmetric key pair. In this case, the TTP merely has
to perform some plausibility checks (e.g. if the entity is able to sign a message with a private key corresponding to the
public key), to certify the entity's public key, and to make this certificate available.
5.2.2.2 Distribution of public keys
Public keys must be made available to entities in a way that guarantees their authenticity. In the case of certified public
keys, the key distribution is done by distribution of the certificate and authenticity is guaranteed by the signature of the
CA which has created the certificate.
In the case of a directly trusted CA key, other means of secure distribution have to be used. If private keys of an entity
are distributed to an entity using a secure hardware token, this token can also be used for delivery of the CA key. In other
cases an additional process is required. See ISO/IEC 11770-3, subclause 8.1 "Public key distribution without a trusted
third party" for methods to do this.
5.2.3 Personalization
The storage of private keys and additional data may be provided by using a physical token. In this situation the
personalization of a token has to be supported by the CA, RA or end entities. For example, the personalization of
smartcards may include set-up procedures (e.g. creation of the file system), the selection of a random PIN (Personal
Identification Number) or password and the shipment and storage of all relevant data within a smartcard.
8 ITU-T X.843 (10/2000 E)
5.3 Other services
5.3.1 Cross certification
Cross certification is a service offered to allow verification of signatures from end entities with certificates from one CA
by end entities with certificates from another CA. For example, a CA1 issues a certificate for a CA2 in another PKI with
the effect that entities trusting CA1 can verify certificates of entities in the other PKI via a certification path including
this new certificate.
A detailed specification for the on-line message flow of this service is given in clause 7 and the ASN.1 specification of
the data structures needed for these messages is given in clause 8.
5.3.2 Domain parameter validation
Domain Parameter Validation is the validation of a proposed set of domain parameters to ensure that each parameter in
the set meets all the attributes that are claimed for it.
EXAMPLES:
a) a valid parameter may be required to be a prime: to validate this, a primality test (perhaps probabilistic) is
run to make sure that the claimed prime is actually a prime;
b) a valid parameter may be required to be in some arithmetic relationship with some other parameter(s): to
validate this, the arithmetic relationship is tested to ensure it holds;
c) a specific weak case (for example, on an exclude list) may be checked to ensure it does not apply to the
set in question; or
d) a parameter may be required to be generated by use of a seed in a canonical seeded hash function: to
validate this, the seed is input to the canonical seeded hash function to ensure that it actually does generate
the parameter.
The generator of a set of domain parameters should ensure that they pass domain parameter validation. Whether anyone
else needs to do domain parameter validation depends on the trust relationship between the generator and the entity. If a
set of invalid domain parameters is used, unpredictable results may occur, including loss of any intended security. As
domain parameters are typically public, it is best if the validation can be done in an off-line manner (that is, not needing
the generator of the domain parameters to answer queries) and this is typically the case.
Usually a CA will generate and validate a set of domain parameters which can then be implicitly trusted by all members
of the PKI.
5.3.3 Public key validation
Public Key Validation is the validation of a claimed public key to ensure it conforms to the arithmetic requirements for
such a key, that is, that the claimed public key is plausible. Public Key Validation assumes that any domain parameters
have previously been validated.
EXAMPLES:
a) a valid parameter may be required to be in a specific range of values: to validate this, the claimed
parameter is tested to ensure it is in the correct range;
b) a valid parameter may be required
...
NORME ISO/CEI
INTERNATIONALE 15945
Première édition
2002-02-01
Technologies de l'information —
Techniques de sécurité — Spécification de
services de tiers de confiance TTP pour la
prise en charge des applications de
signature numérique
Information technology — Security techniques — Specification of TTP
services to support the application of digital signatures
Numéro de référence
ISO/CEI 15945:2002(F)
©
ISO/CEI 2002
ISO/CEI 15945:2002(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
© ISO/CEI 2002
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l’ISO à
l’adresse ci-après ou du comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56• CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
ImpriméenSuisse
ii © ISO/CEI 2002 – Tous droits réservés
ISO/CEI 15945:2002(F)
TABLE DES MATIÈRES
Page
1 Domaine d'application . 1
2 Références normatives. 2
2.1 Recommandations | Normes internationales identiques . 2
2.2 Références supplémentaires . 2
3 Définitions . 3
4 Abréviations. 4
5 Classification descriptive des services. 5
5.1 Services de gestion de certificats. 5
5.2 Services de gestion de clés . 8
5.3 Autres services . 9
6 Profil minimum de certificat et de liste CRL. 11
6.1 Profil minimum de certificat. 11
6.2 Profil minimum de liste CRL . 12
7 Messages de gestion de certificats . 12
7.1 Aperçu général des services et messages de gestion de certificats . 13
7.2 Hypothèses et restrictions pour un certain nombre de services . 16
8 Structures de données pour les messages de gestion de certificat. 21
8.1 Message global . 22
8.2 Structures de données communes. 25
8.3 Structures de données spécifiques pour les messages de demande de certificat du type CertReq. 27
8.4 Structures de données spécifiques pour d'autres messages. 31
8.5 Protocoles de transport . 35
8.6 Module complet de l'ASN.1 . 35
9 Protocole de statut de certificat en ligne. 43
9.1 Aperçu général du protocole. 43
9.2 Prescriptions fonctionnelles. 45
9.3 Protocole détaillé. 46
9.4 Module ASN.1 pour le protocole OCSP. 50
Annexe A – Interfonctionnement. 53
Annexe B – Algorithmes. 55
B.1 Algorithmes de hachage . 55
B.2 Algorithmes de signature digitale. 55
Annexe C – Bibliographie. 56
© ISO/CEI 2002 – Tous droits réservés iii
ISO/CEI 15945:2002(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) et la CEI (Commission électrotechnique internationale)
forment le système spécialisé de la normalisation mondiale. Les organismes nationaux membres de l'ISO ou de la
CEI 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 domaines particuliers de l'activité technique. Les comités
techniques de l'ISO et de la CEI collaborent dans des domaines d'intérêt commun. D'autres organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l'ISO et la CEI participent également
aux travaux. Dans le domaine des technologies de l'information, l'ISO et la CEI ont créé un comité technique mixte,
l'ISO/CEI JTC 1.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI, Partie 3.
La tâche principale du comité technique mixte est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par le comité technique mixte sont soumis aux organismes nationaux pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des organismes nationaux
votants.
L'attention est appelée sur le fait que certains des éléments de la présente Norme internationale peuvent faire
l'objet de droits de propriété intellectuelle ou de droits analogues. L'ISO et la CEI ne sauraient être tenues pour
responsables de ne pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO/CEI 15945 a été élaborée par le comité technique mixte ISO/CEI JTC 1, Technologies de l'information,
sous-comité SC 27, Techniques de sécurité des technologies de l'information, en collaboration avec l'UIT-T. Le
texte identique est publié en tant que Rec. UIT-T X.843.
Les annexes A à C de la présente Norme internationale sont données uniquement à titre d'information.
iv © ISO/CEI 2002 – Tous droits réservés
ISO/CEI 15945:2002(F)
Introduction
Actuellement le développement des technologies de l'information ainsi que celui de l'infrastructure mondiale de
communication ouvrent la possibilité d'implémenter le commerce électronique dans des dimensions économiques
appropriées. Les signatures numériques constituent une technique importante pour ajouter de la sécurité à ces
applications commerciales et à d'autres champs d'application qui ont besoin de transactions électroniques légalement
efficaces.
Les signatures numériques conviennent pour assurer l'intégrité des données et l'authentification des participants aux
transactions. Elles peuvent constituer une analogie avec la signature manuscrite pour les commandes, offres et contrats
numériques. La caractéristique la plus importante des signatures numériques dans ce contexte est qu'une personne ayant
signé un document ne peut pas par la suite le nier. Cette caractéristique est appelée "non-répudiation de création" d'un
document.
Dans de nombreux pays et dans le contexte international, la législation concernant les signatures numériques est mise en
avant dans le but de prendre en charge le développement du commerce électronique et d'autres champs d'application qui
ont besoin de transactions électroniques légalement efficaces.
Il existe un certain nombre de normes qui spécifient les signatures numériques ainsi que leur utilisation pour différents
besoins tels que la non-répudiation ou l'authentification. Un certain nombre d'applications commerciales ainsi que des
services d'offres TTP liés aux signatures numériques sont implémentés ou prévus. L'interopérabilité de ces tiers TTP
entre eux et avec les applications commerciales est nécessaire pour une utilisation mondiale économiquement et
légalement efficace des signatures numériques.
L'objectif de la présente Recommandation | Norme internationale est de définir les services nécessaires à la prise en
charge des applications de signature numérique pour la non-répudiation de création. Comme l'utilisation des mécanismes
pour la non-répudiation de création d'un document suppose l'intégrité du document et l'authenticité du créateur, les
services décrits dans la présente Recommandation | Norme internationale peuvent également être combinés afin
d'implémenter les services pour l'intégrité et l'authenticité. Ceci est réalisé d'une manière qui favorise l'interopérabilité
entre tiers TTP ainsi qu'entre tiers TTP et applications commerciales.
NOTE – Il n'y a aucune raison inhérente que chaque tiers TTP prévoyant la prise en charge des applications de signature
numérique doive offrir tous ces services. Il est possible que des tiers TTP offrant des services différents coopèrent pour prendre en
charge l'utilisation de signatures numériques. Toutefois, du point de vue des applications commerciales potentielles, la totalité de
la gamme des services peut être nécessaire et l'interopérabilité devient encore plus importante dans ce scénario. Il s'agit d'une
raison supplémentaire de recueillir l'ensemble de tous ces services dans un document unique.
© ISO/CEI 2002 – Tous droits réservés v
ISO/CEI 15945:2002 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L'INFORMATION – TECHNIQUES DE SÉCURITÉ –
SPÉCIFICATION DE SERVICES DE TIERS DE CONFIANCE (TTP)
POUR LA PRISE EN CHARGE DES APPLICATIONS
DE SIGNATURE NUMÉRIQUE
1 Domaine d'application
La présente Recommandation | Norme internationale définit les services TTP nécessaires à la prise en charge des
applications de signature numérique aux fins de non-répudiation de création de documents.
La présente Recommandation | Norme internationale définit également les interfaces et protocoles permettant
l'interopérabilité entre des entités associées à ces services TTP.
Les définitions de services techniques et de protocoles sont nécessaires pour permettre l'implémentation des services TTP
et des applications commerciales associées.
La présente Recommandation | Norme internationale est centrée sur:
– l'implémentation et l'interopérabilité;
– les spécifications de services;
– les prescriptions techniques.
La présente Recommandation | Norme internationale ne décrit pas la gestion des tiers TTP ou d'autres questions
organisationnelles, d'exploitation ou personnelles. Ces sujets sont principalement couverts dans la Rec. UIT-T X.842 |
ISO/CEI TR 14516, Technologies de l'information – Techniques de sécurité – Lignes directrices pour l'utilisation et la
gestion des services de tiers de confiance.
NOTE 1 – Puisque l'interopérabilité est le sujet principal de la présente Recommandation | Norme internationale, les restrictions
suivantes s'appliquent:
i) ne sont pris en considération dans la présente Recommandation | Norme internationale que les services qui
peuvent être fournis par un TTP soit aux entités terminales soit à un autre TTP;
ii) ne sont pris en considération que les services qui peuvent être demandés ou fournis au moyen de messages
numériques normalisables;
iii) ne sont spécifiés en détail que les services pour lesquels des messages normalisés acceptables à grande échelle
peuvent être adoptés au moment de la publication de la présente Recommandation | Norme internationale.
D'autres services seront spécifiés dans des documents distincts lorsque des messages normalisés acceptables à grande échelle
seront disponibles pour eux. La définition des services horodateurs en particulier fera l'objet d'un document séparé.
NOTE 2 – La structure des données et les messages figurant dans la présente Recommandation | Norme internationale seront
spécifiés conformément aux documents RFC 2510 et 2511 (pour les services de gestion de certificats) et RFC 2560 (pour les
services OCSP). Le format de la demande de certificat permet aussi l'interopérabilité avec le système PKCS # 10. Voir l'Annexe C
pour des références aux documents mentionnés dans la présente note.
NOTE 3 – Il existe d'autres tentatives de normalisation des services TTP dans des environnements et des applications spécifiques,
comme SET ou EDIFACT. Ils ne s'inscrivent pas dans le cadre de la présente Recommandation | Norme internationale.
NOTE 4 – La présente Recommandation | Norme internationale définit des spécifications techniques pour les services. Ces
spécifications ne dépendent pas des politiques, des règlements juridiques particuliers ou des modèles organisationnels (qui
pourraient par exemple définir comment sont réparties les tâches et les responsabilités entre les autorités de certification et les
autorités d'enregistrement). Evidemment, la politique des TTP offrant les services décrits dans la présente Recommandation |
Norme internationale devra spécifier comment les règlements juridiques et les autres aspects susmentionnés seront respectés par le
TTP. La politique doit en particulier spécifier comment la validité des signatures et des certificats numériques est déterminée.
UIT-T X.843 (10/2000 F) 1
ISO/CEI 15945:2002 (F)
2 Références normatives
Les Recommandations et Normes internationales suivantes contiennent des dispositions qui, par suite de la référence qui
y est faite, constituent des dispositions valables pour la présente Recommandation | Norme internationale. Au moment de
la publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à révision et
les parties prenantes aux accords fondés sur la présente Recommandation | Norme internationale sont invitées à
rechercher la possibilité d'appliquer les éditions les plus récentes des Recommandations et Normes indiquées ci-après.
Les membres de la CEI et de l'ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de l'UIT tient à jour une liste des Recommandations de l'UIT-T en vigueur.
2.1 Recommandations | Normes internationales identiques
– Recommandation UIT-T X.501 (1997) | ISO/CEI 9594-2:1998, Technologies de l'information –
Interconnexion des systèmes ouverts – L'annuaire: les modèles.
– Recommandation UIT-T X.509 (2000) | ISO/CEI 9594-8:2001, Technologies de l'information –
Interconnexion des systèmes ouverts – L'annuaire: cadre général des certificats de clé publique et
d'attribut.
– Recommandation UIT-T X.520 (1997) | ISO/CEI 9594-6:1998, Technologies de l'information –
Interconnexion des systèmes ouverts – L'annuaire: types d'attributs sélectionnés.
– Recommandation UIT-T X.680 (1997) | ISO/CEI 8824-1:1998, Technologies de l'information – Notation
de syntaxe abstraite numéro un (ASN.1): spécification de la notation de base.
– Recommandation UIT-T X.681 (1997) | ISO/CEI 8824-2:1998, Technologies de l'information – Notation
de syntaxe abstraite numéro un: spécification des objets informationnels.
– Recommandation UIT-T X.682 (1997) | ISO/CEI 8824-3:1998, Technologies de l'information – Notation
de syntaxe abstraite numéro un: spécification des contraintes.
– Recommandation UIT-T X.683 (1997) | ISO/CEI 8824-4:1998, Technologies de l'information – Notation
de syntaxe abstraite numéro un: paramétrage des spécifications de la notation de syntaxe abstraite
numéro un.
– Recommandation UIT-T X.690 (1997) | ISO/CEI 8825-1:1998, Technologies de l'information – Règles de
codage ASN.1: spécification des règles de codage de base, des règles de codage canoniques et des règles
de codage distinctives.
– Recommandation UIT-T X.810 (1995) | ISO/CEI 10181-1:1996, Technologies de l'information –
Interconnexion des systèmes ouverts – Cadres de sécurité pour les systèmes ouverts: aperçu général.
– Recommandation UIT-T X.813 (1996) | ISO/CEI 10181-4:1997, Technologies de l'information –
Interconnexion des systèmes ouverts – Cadres de sécurité pour les systèmes ouverts: non-répudiation.
2.2 Autres références
– ISO/CEI 9796-2:1997, Technologies de l'information – Techniques de sécurité – Schémas de signature
numérique rétablissant le message – Partie 2: Mécanismes utilisant une fonction de hachage.
– ISO/CEI 9796-3:2000, Technologies de l'information – Techniques de sécurité – Schéma de signature
numérique rétablissant le message – Partie 3: Mécanismes basés sur les logarithnmes discrets.
– ISO/CEI 10118-1:1994, Technologies de l'information – Techniques de sécurité – Fonctions de brouillage
– Partie 1: Généralités.
– ISO/CEI 10118-2:1994, Technologies de l'information -Techniques de sécurité – Fonctions de brouillage
– Partie 2: Fonctions de brouillage utilisant un algorithme de chiffrement par blocs de n bits.
– ISO/CEI 10118-3:1998, Technologies de l'information – Techniques de sécurité – Fonctions de brouillage
– Partie 3: Fonctions de hachage dédiées.
– ISO/CEI 11770-1:1996, Technologies de l'information – Techniques de sécurité – Partie 1: Cadre
général.
– ISO/CEI 11770-2:1996, Technologies de l'information – Techniques de sécurité – Gestion de clés –
Partie 2: Mécanismes utilisant des techniques symétriques.
2 UIT-T X.843 (10/2000 F)
ISO/CEI 15945:2002 (F)
– ISO/CEI 11770-3:1999, Technologies de l'information – Techniques de sécurité – Gestion de clés –
Partie 3: Mécanismes utilisant des techniques asymétriques.
– ISO/CEI 13888-1:1997, Technologies de l'information – Techniques de sécurité – Non-répudiation –
Partie 1: Généralités.
– ISO/CEI 13888-2:1998, Technologies de l'information – Techniques de sécurité – Non-répudiation –
Partie 2: Mécanismes utilisant des techniques symétriques.
– ISO/CEI 13888-3:1997, Technologies de l'information – Techniques de sécurité – Non-répudiation –
Partie 3: Mécanismes utilisant des techniques asymétriques.
– ISO/CEI 14888-1:1998, Technologies de l'information – Techniques de sécurité – Signatures digitales
avec appendice – Partie 1: Généralités.
– ISO/CEI 14888-2:1999, Technologies de l'information – Techniques de sécurité – Signatures digitales
avec appendice – Partie 2: Mécanismes basés sur des identités.
– ISO/CEI 14888-3:1998, Technologies de l'information – Techniques de sécurité – Signatures digitales
avec appendice – Partie 3: Mécanismes fondés sur certificat.
– ISO/CEI 15946-2 (à publier), Technologies de l'information – Techniques de sécurité – Techniques
cryptographiques basées sur des courbes elliptiques – Partie 2: Signatures digitales.
3 Définitions
Le terme suivant est utilisé comme défini dans l'ISO/CEI 11770-1:
gestion de clés
Le terme suivant est utilisé comme défini dans l'ISO/CEI 10181-1:
tiers de confiance (TTP, trusted third party)
Les termes ci-après sont utilisés tels que définis dans la Rec. UIT-T X.509 | ISO/CEI 9594-8:
certificat CA
autorité de certification (CA)
certificat de clé publique
NOTE – La dénomination abrégée "certificat" sera également employée dans la présente Recommandation | Norme internationale
pour désigner un "certificat de clé publique".
politique de certification
liste d'annulation de certificats (CRL, certificate revocation list)
chemin de certification
Les termes suivants sont utilisés tels que définis dans l'ISO/CEI 10118-1:
fonction de hachage, fonction de brouillage
code de hachage; valeur de hachage
Le terme suivant est utilisé comme défini dans l'ISO/CEI 14888-1:
paramètre de domaine
Pour les besoins de la présente Recommandation | Norme internationale, les définitions suivantes s'appliquent:
3.1 services de gestion de certificats: tous les services nécessaires à la maintenance du cycle de vie des certificats,
y compris l'enregistrement, certification, distribution et annulation de certificats.
3.2 service de certification: service de création et d'attribution de certificats assuré par une autorité de certification
et décrit dans l'ISO/CEI 9594-8:1995.
3.3 signature numérique: transformation cryptographique d'une unité de donnée qui permet au destinataire de
l'unité de donnée de prouver l'origine et l'intégrité de cette unité de donnée, qui protège l'émetteur et le destinateur de
l'unité de donnée contre un faux fabriqué par un tiers et qui protège l'émetteur contre un faux fabriqué par le destinataire.
NOTE – Les signatures numériques peuvent être utilisées par des entités finales (voir ci-après) pour des besoins d'authentification,
d'intégrité de données et de non-répudiation de création de données. L'utilisation aux fins de non-répudiation de création de
données est le plus important de ces besoins de disposer de signatures numériques ayant force légale. La définition ci-dessus
provient de l'ISO/CEI 9798-1.
UIT-T X.843 (10/2000 F) 3
ISO/CEI 15945:2002 (F)
3.4 autorité CA de confiance directe: une autorité CA de confiance directe est une autorité CA dont la clé
publique a été obtenue et est en cours de mémorisation par une entité finale, en toute confiance et sécurité, et dont la clé
publique est acceptée par cette entité finale dans le contexte d'une ou plusieurs applications.
3.5 clé de CA de confiance directe: une clé de CA de confiance directe est une clé publique d'une autorité CA de
confiance directe. Elle a été obtenue et est en cours de mémorisation par une entité finale, en toute confiance et sécurité.
Elle sert à vérifier des certificats sans être elle-même vérifiée au moyen d'un certificat créé par une autre autorité.
NOTE – Si, par exemple, les autorités CA de plusieurs organisations se certifient réciproquement les unes les autres (voir
l'Annexe A), l'autorité CA de confiance directe pour une entité peut être l'autorité CA de l'organisation à laquelle appartient cette
entité. Les autorités CA de confiance directe et les clés de CA de confiance directe peuvent varier d'une entité à l'autre. Une entité
peut considérer plusieurs autorités CA comme des autorités CA de confiance directe.
3.6 service d'annuaire: service pour la recherche et la récupération d'informations à partir d'un catalogue d'objets
bien définis, qui peut contenir des informations sur les certificats, numéros de téléphone, conditions d'accès, adresses,
etc. Un exemple en est un service d'annuaire conforme à la Rec. UIT-T X.500 | ISO/CEI 9594-1.
3.7 service de distribution de clés: service de distribution de clés en toute sécurité à des entités autorisées, fourni
par un Centre de distribution de clés et décrit dans l'ISO/CEI 11770-1.
3.8 non-répudiation de création: protection contre un démenti fallacieux par une entité du fait qu'elle a créé le
contenu d'un message (c'est-à-dire, du fait qu'elle est responsable du contenu d'un message).
3.9 environnement de sécurité personnelle (PSE, personal security environment): stockage local sûr pour la clé
privée d'une entité, pour la clé d'une autorité CA de confiance directe et pour d'autres données éventuelles. En fonction
de la politique de sécurité appliquée par l'entité ou en fonction des prescriptions du système, il peut s'agir par exemple
d'un fichier protégé par chiffrement ou d'un jeton de matériel inviolable.
3.10 service de personnalisation: service de stockage d'informations cryptographiques (spécialement des clés
privées) dans un environnement PSE.
NOTE – Les mesures organisationnelles et de sécurité physique destinées à un tel service ne s'inscrivent pas dans le domaine
d'application de la présente Recommandation | Norme internationale. Pour les mesures organisationnelles, se reporter à la
Rec. UIT-T X.842 | ISO/CEI TR 14516, Lignes directrices pour l'utilisation et la gestion des services de tiers de confiance.
3.11 annuaire de clé publique (PKD, public key directory): annuaire contenant un (sous-)ensemble bien défini de
certificats de clé publique. Cet annuaire peut contenir des certificats provenant de différentes autorités de certification.
3.12 infrastructure de clé publique (PKI, public key infrastructure): système constitué de tiers TTP, avec les
services qu'ils fournissent pour la prise en charge de l'application (y compris la création et la validation) de signatures
numériques, et des personnes ou composants techniques qui utilisent ces services.
NOTE – Parfois on appelle entités finales les personnes et composants techniques qui participent à une infrastructure PKI en
utilisant les services de tiers TTP, mais sans être eux-mêmes des tiers TTP. Un exemple d'équipement technique utilisé par une
entité finale est une carte à puce qui peut être utilisée comme mémoire de stockage et/ou dispositif de traitement.
3.13 autorité d'enregistrement (RA, registration authority): autorité habilitée et chargée en toute confiance
d'exécuter un service d'enregistrement tel que décrit ci-dessous.
3.14 service d'enregistrement: service d'identification d'entités et de leur enregistrement d'une manière qui permet
l'attribution sûre de certificats à ces entités.
3.15 service d'horodatage: service attestant de l'existence d'une donnée électronique à un moment précis dans le
temps.
NOTE – Les services d'horodatage sont utiles et probablement indispensables pour prendre à charge la validation à long terme de
signatures. Ils seront définis dans une norme distincte.
4 Abréviations
Pour les besoins de la présente Recommandation | Norme internationale, les abréviations suivantes s'appliquent:
CA Autorité de certification (certification authority)
CRL Liste d'annulation de certificat (certificate revocation list)
EE Entité finale (end entity)
4 UIT-T X.843 (10/2000 F)
ISO/CEI 15945:2002 (F)
OCSP Protocole de statut de certificat en ligne (on-line certificate status protocol)
PKD Annuaire de clé publique (public key directory)
PKI Infrastructure de clé publique (public key infrastructure)
PSE Environnement de sécurité personnelle (personal security environment)
RA Autorité d'enregistrement (registration authority)
TTP Tiers de confiance (trusted third party)
5 Classification descriptive des services
Le présent article décrit des services qui peuvent être utilisés dans le contexte de services TTP pour des signatures
numériques. Une description de haut niveau de ces services y est donnée, indépendante des formats de données,
d'algorithmes, de langages de descriptions, etc.
Une spécification détaillée d'un certain nombre de ces services est fournie dans les articles ci-après.
Il n'est pas nécessaire que chaque tiers TTP prévoyant de prendre en charge l'application de signatures numériques offre
la totalité de ces services. Il est possible que plusieurs tiers TTP offrant des services différents collaborent dans la prise
en charge de l'utilisation de signatures numériques.
NOTE 1 – Sachant que l'interopérabilité est la question principale de la présente Recommandation | Norme internationale, seuls
sont décrits ici les services qui sont offerts par un tiers TTP soit à des entités finales soit à un autre tiers TTP. En outre, seuls sont
couverts les services qui peuvent être demandés ou fournis à l'aide de messages numériques normalisables. (Cela n'implique pas
cependant que les messages normalisés soient effectivement définis pour tous les services mentionnés dans la présente
Recommandation | Norme internationale.)
Les exemples suivants illustrent des services qui ne sont pas couverts:
1) enregistrement d'événements liés à la sécurité. Compte tenu de l'infrastructure PKI d'une signature numérique, il
s'agit d'un service interne de tiers TTP mais qui n'est pas offert à des entités;
2) services cryptographiques généraux (par exemple service de chiffrement). Les procédés tels que le chiffrement
font partie de certains services mais ne sont pas pertinents en tant que service autonome dans le contexte des
signatures numériques;
3) archivage ou récupération de clés. Il peut s'agir d'un service interne pour les clés de CA de confiance directe. Ces
actions ne sont pas généralement exécutées pour les clés de signatures numériques d'entités finales.
NOTE 2 – Les services d'horodatage seront définis dans un document distinct.
5.1 Services de gestion de certificats
Le présent paragraphe contient une description des services suivants qui font partie du cycle de vie des certificats:
• enregistrement;
• certification de clé publique;
• annulation de certificats;
• mise à jour de certificats;
• mise à jour de clé.
Une spécification détaillée du flux de messages en ligne de ces services (à l'exception de la détermination du statut du
certificat) est fournie à l'article 7 et la spécification ASN.1 des structures de données nécessaires à ces messages est
fournie à l'article 8. Les spécifications analogues pour la détermination du statut de certification en ligne (voir § 5.1.3.3,
deuxième méthode) sont fournies à l'article 9.
Les protocoles d'accès à l'annuaire qui sont utilisés pour rendre publiquement disponibles les certificats et listes CRL ne
sont pas spécifiés ici car les spécifications pour ces protocoles existent déjà dans les Rec. UIT-T X.511 | ISO/CEI 9594-3
et Rec. UIT-T X.519 | ISO/CEI 9594-5.
NOTE – D'autres protocoles d'accès à l'annuaire sont LDAP (LDAPv2 1777, 2555 et 2587 des RFC) ou l'accès WEB (RFC 2585).
La Figure 1 ci-après fournit un aperçu général de l'architecture d'une infrastructure PKI avec un certain nombre
d'exemples de services.
UIT-T X.843 (10/2000 F) 5
ISO/CEI 15945:2002 (F)
– récupération de certificat
EE
– détermination de l'état
d'annulation du certificat
– enregistrement
– certification
RA
PKD
PKD
OCSP
CA
CA
– information
du certificat
T0733480-00
– certification réciproque
Figure 1 – Aperçu général des services de gestion de certificats
5.1.1 Enregistrement
La véracité d'une infrastructure de clé publique s'appuie sur l'identification et l'enregistrement corrects des entités.
Pour toutes les entités, une autorité RA (qui peut être également une autorité de certification) doit vérifier l'identité des
entités finales par des moyens appropriés et doit attribuer un nom unique non ambigu à chaque entité finale à l'intérieur
de son domaine. La politique de certification détermine la nature des moyens à utiliser pour effectuer cette identification
(par exemple des documents d'identité) et la question de savoir si l'entité finale doit être présente en personne. Une
dénomination des noms d'entité finale peut également être nécessaire. Les entités finales qui sont des composants
techniques sont enregistrées conformément à la politique de sécurité de l'application, par exemple la gestion de réseau. Il
convient que les applications dans lesquelles la différence entre entités finales humaines et non humaines est importante
établissent clairement cette distinction dans le certificat. Par exemple, un "nom" pourrait être "dispositif de type X",
numéro "Y" situé dans "Z", la distinction pourrait être établie conformément à la politique ou une extension peut
indiquer la différence.
Un formulaire d'enregistrement peut être utilisé pour recueillir les données pertinentes, par exemple le nom, l'unité
d'entreprise, l'adresse d'entreprise et l'adresse de livraison du matériel de codage.
EXEMPLE: un scénario dans une entreprise peut consister en ce que chaque employé doit être présent en personne au
bureau du personnel approprié et montrer sa carte d'identité en cours de validité. Le responsable du personnel en fonction
atteste de l'identité et envoie un formulaire d'enregistrement signé à l'autorité de certification.
5.1.2 Certification de clé publique
L'autorité de certification est responsable du processus de certification, du lien d'un nom d'entité ou d'un pseudonyme
avec les clés publiques. Un format de certificat est décrit dans la Rec. UIT-T X.509 | ISO/CEI 9594-8.
La présente Recommandation | Norme internationale exige que la preuve de la possession de la clé privée correspondant
à la clé publique incluse dans le certificat soit apportée au cours du service de certification. En fonction de la politique,
une autorité de certification peut garantir d'autres propriétés de la clé publique de l'entité finale, en incluant par exemple
l'un ou les deux services décrits aux § 5.3.2 et 5.3.3.
5.1.3 Annulation de certificats
5.1.3.1 Généralités
Un souci majeur avec les certificats de clés publiques est qu'ils peuvent devoir être annulés avant le moment prévu de
leur expiration à cause de circonstances diverses. L'annulation peut être effectuée par l'autorité CA émettrice ou par une
autre autorité en fonction de la politique.
L'annulation est obligatoire si la clé privée a été altérée. D'autres raisons d'annulation peuvent être un changement de
nom, la fin d'une période d'embauche, etc.
Il convient que la politique de certification établisse toutes les raisons d'annulation. On peut trouver un certain nombre de
ces raisons dans la Rec. UIT-T X.509 | ISO/CEI 9594-8. Il convient que la politique définisse qui peut faire les demandes
d'annulation et, aussi, si un jeton spécifique peut être utilisé pour identifier des entités autorisées à annuler des certificats
tels que les mots de passe d'annulation à usage unique.
6 UIT-T X.843 (10/2000 F)
ISO/CEI 15945:2002 (F)
5.1.3.2 Méthodes d'annulation
On peut utiliser deux méthodes pour annuler des certificats:
1) Emission d'une liste d'annulation de certificats (CRL)
Une liste CRL est une liste émise périodiquement et signée par l'autorité de certification et elle identifie
tous les certificats qui ont été annulés.
L'annulation entraîne une saisie immédiate dans la liste CRL, qui inclut également le moment de
l'annulation du certificat concerné. En outre, la politique de l'autorité de certification peut exiger de retirer
le certificat de l'annuaire des clés publiques PKD.
NOTE – Selon la politique, il peut être indiqué de conserver le certificat afin de vérifier la validité des signatures
apposées avant la date d'annulation (par exemple, lorsque le motif d'annulation n'altère pas la clé).
Outre la publication périodique, la liste CRL mise à jour peut être publiée immédiatement.
L'ISO/CEI 11770-1 indique deux horodatages d'annulation différents:
– le moment de l'altération connue ou suspectée; et
– le moment auquel l'autorité de certification a été avisée par l'entité de l'altération.
En fonction de la politique, la saisie du certificat dans la liste CRL peut être effacée lorsque le certificat
expire (comparer avec le § 5.1.3.3, Détermination de l'état d'annulation de certificat).
2) Le stockage du statut du certificat dans une base de données interne de confiance de l'autorité de
certification et l'offre aux entités d'informations en ligne sur le statut des certificats (comparer avec le
§ 5.1.3.3. Détermination de l'état d'annulation de certificat).
Ces deux méthodes peuvent être combinées.
Si une clé est altérée, la procédure normale est d'annuler le certificat correspondant, de réinitialiser l'entité finale, de créer
une nouvelle paire de clés publique/privée et de certifier la nouvelle clé publique avec les attributs précédents.
En fonction de la politique, un certificat peut:
– être annulé de manière permanente;
– être suspendu. La saisie dans la liste CRL inclut un fanion qui indique l'état "en suspens" ("on hold").
La politique de l'autorité de certification doit spécifier la signification de l'état "en suspens" relativement au niveau de
confiance qu'il représente pour une entité et la manière dont il convient qu'une entité traite cette situation. Par exemple,
un certificat pourrait être suspendu à la suite d'une demande d'annulation non autorisée. Certaines politiques ne
permettent pas du tout l'état "en suspens".
EXEMPLE: une politique peut établir ce qui suit: lorsqu'une vérification est effectuée, elle doit être rejetée tant que le
certificat est suspendu. Lorsqu'une preuve est vérifiable à l'aide d'un certificat suspendu, le résultat de la vérification doit
être négatif si un résultat est immédiatement nécessaire mais il peut également être interprété comme une validité
conditionnelle. Si la suspension est suivie d'une annulation, la preuve devient non valide et la date d'annulation doit être
la date du début de la suspension (et non la date de la fin de la suspension).
5.1.3.3 Détermination de l'état d'annulation de certificat
Ce service permet à une entité de déterminer si un certificat est annulé. On peut le faire suivant différentes méthodes qui
correspondent aux méthodes d'annulation telles que décrites au § 5.1.3.2:
1) Méthode 1: vérification de l'annuaire PKD et de la liste CRL.
2) Méthode 2: demande en ligne du statut auprès d'un tiers TTP en qui on a confiance pour ce besoin. La
réponse du tiers TTP doit être acheminée d'une manière authentique à l'entité.
5.1.3.4 Annulation d'un certificat d'une autorité CA
Un scénario spécial est constitué par l'altération de la clé privée d'une autorité de certification. Si cela se produit:
– le certificat de la clé publique correspondant à la clé altérée de l'autorité CA doit être annulé.
La confiance en les certificats calculés avec la clé altérée de l'autorité CA n'est plus assurée par la
signature de l'autorité CA qui est contenue dans ces certificats. Il est toutefois possible de garantir la
validité de ces certificats par d'autres moyens (par exemple, lorsque les certificats sont stockés d'une
manière digne de confiance par un TTP qui assure un service OCSP). Dans tous les cas, les entités doivent
obtenir un nouveau certificat et une nouvelle clé de l'autorité CA non altérée pour des signatures
ultérieures.
UIT-T X.843 (10/2000 F) 7
ISO/CEI 15945:2002 (F)
En fonction de la politique, les certificats calculés avec la clé altérée sont annulés, ce qui constitue un
moyen d'informer les entités finales de la nécessité d'obtenir de nouveaux certificats.
Dans un certain nombre de situations dépendant de la politique de certification et de l'architecture du
système, il convient de créer de nouvelles paires de clés destinées aux entités.
Il est important de remarquer que dans un tel scénario, toute signature qui a été émise avant que ne se
produise l'altération et qui est sécurisée par des moyens supplémentaires (par exemple horodatée par une
autorité d'horodatage dont le certificat est toujours valide) peut être toujours considérée valide en fonction
de la politique, alors que toute signature qui a été émise après le moment de l'altération déterminée ou qui
n'a pas été sécurisée par des moyens supplémentaires sera considérée non valide;
– si la clé publique correspondant à la clé privée altérée de l'autorité CA est certifiée de manière réciproque
avec d'autres autorités CA, un message d'alerte doit être envoyé à ces autorités de certification. Ce
message d'alerte leur notifie d'annuler le certificat des autorités de certification qui a été l'objet de
certification réciproque.
5.1.4 Mise à jour de certificat
Dans le cas où un certificat expire, il peut être mis à jour en émettant un nouveau certificat pour la clé publique de l'entité
qui était déjà contenue dans l'ancien certificat.
On ne doit pas utiliser cette méthode:
– si la paire de clés de l'entité est altérée; ou
– si l'état de cryptographie indique que l'algorithme de clé publique en rapport avec les paramètres de la
paire de clés ne peut pas garantir la sécurité des signatures qui ont été créées avec cette paire de clés pour
la période de validité du nouveau certificat; ou
– si le nouveau certificat présente des différences substantielles en termes de politique, extensions ou
attributs par rapport à l'ancien certificat.
La politique de certification d'une autorité CA peut spécifier qu'une procédure d'enregistrement simplifiée est acceptable
pour l'émission d'un nouveau certificat.
EXEMPLE: si l'ancien certificat n'est pas annulé, on peut accepter ce fait comme suffisant pour émettre un nouveau
certificat.
La modification d'attributs non critiques dans un certificat pendant sa période de validité, tels que le nom ou l'affiliation
(par exemple par un déplacement à un autre département) peut également conduire à la prescription pour une
recertification des attributs modifiés, avec les mêmes clés qu'auparavant. Néanmoins, le certificat précédent doit être
annulé dans ce cas.
5.1.5 Mise à jour de clés
Une nouvelle paire de clés est créée soit par l'entité elle-même, soit par le tiers TTP et un certificat est émis pour la clé
publique de cette nouvelle paire.
Cette méthode doit être choisie dans le cas d'expiration d'un certificat si la mise à jour du certificat n'est pas acceptable
pour l'une des raisons fournies au § 5.1.4. Elle peut également être utilisée dans d'autres situations en fonction de la
politique de l'autorité de certification.
La politique de certification de l'autorité CA peut spécifier qu'une procédure d'enregistrement simplifiée est acceptable
pour l'émission d'un certificat destiné à une clé mise à jour.
5.2 Services de gestion de clés
Des descriptions générales des services de gestion de clés sont fournies dans l'ISO/CEI 11770 (dans toutes les parties).
Le présent paragraphe contient seulement une description des services de gestion de clés qui peuvent être offerts comme
faisant partie des services liés au cycle de vie de certificats (comparer avec le § 5.1). La spécificat
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...