ISO/IEC 9594-8:1998/Cor 2:2002

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

Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — L'annuaire: Cadre d'authentification — Partie 8: — Rectificatif technique 2

General Information

• Status: Withdrawn
• Publication Date: 12-Jun-2002
• Withdrawal Date: 12-Jun-2002
• ICS: 35.100.70 - Application layer
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6/WG 7 - Network, transport and future network
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 21-May-2007

Relations

• Corrects: ISO/IEC 9594-8:1998 - Information technology — Open Systems Interconnection — The Directory: Authentication framework — Part 8:
• Effective Date: 06-Jun-2022
• Child: ISO/IEC 9594-8:1998 - Information technology — Open Systems Interconnection — The Directory: Authentication framework — Part 8:
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL STANDARD ISO/IEC 9594-8:1998
TECHNICAL CORRIGENDUM 2
Published 2002-06-15

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION  •  МЕЖДУНАРОДНАЯ ОРГАНИЗАЦИЯ ПО СТАНДАРТИЗАЦИИ  •  ORGANISATION INTERNATIONALE DE NORMALISATION
INTERNATIONAL ELECTROTECHNICAL COMMISSION • МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОМИССИЯ • COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE


Information technology — Open Systems Interconnection —
The Directory: Authentication framework
TECHNICAL CORRIGENDUM 2
Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — L'annuaire: Cadre d'authentification
RECTIFICATIF TECHNIQUE 2
Technical Corrigendum 2 to International Standard ISO/IEC 9594-8:1998 was prepared by Joint Technical
Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 6, Telecommunications and information
exchange between systems.


ICS 35.100.70 Ref. No. ISO/IEC 9594-8:1998/Cor.2:2002(E)
©  ISO/IEC 2002 – All rights reserved
Printed in Switzerland

---------------------- Page: 1 ----------------------
ISO/IEC 9594-8:1998/Cor.2:2002 (E)
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
Information technology – Open Systems Interconnection –
The Directory: Authentication framework

TECHNICAL CORRIGENDUM 2



NOTE – This Technical Corrigendum covers Draft Technical Corrigenda 8 and 9.

1) Defect reports resolved by Draft Technical Corrigendum 8

(covering resolutions to defect reports 226, 227 and 240)



1.1) This corrects the defects reported in defect report 226

In 11.2, delete the 2nd paragraph:

The production of a certificate … compromise unlikely.



1.2) This corrects the defects reported in defect report 227

In 12.2.2.1, add the following 2 sentences to the end of the paragraph that begins with "Certification authorities shall
assign…":

The keyIdentifier form can be used to select CA certificates during path construction. The authorityCertIssuer,
authoritySerialNumber pair can only be used to provide preference to one certificate over others during path
construction.



1.3) This corrects the defects reported in defect report 240

The following corrections should be made to the 1997 edition authenticationFramework module in Annex A:
1) Add id-mr to the list of objects imported from UsefulDefinitions module in the authenticationFramework
module.
2) Add AttributeType, Attribute, and MATCHING-RULE to the set of objects imported into the
authenticationFramework module from the InformationFramework module.
3) Add GeneralNames to the set of objects imported into the authenticationFramework module from the
CertificateExtensions module.
4) Add the following definition to the authenticationFramework module because this is imported into other
modules in the X.500 series of Recommendations, but had never been included in the 1997 text of this
Recommendation:
HASH {ToBeHashed} ::= SEQUENCE {
algorithmIdentifier AlgorithmIdentifier,
hashValue  BIT STRING ( CONSTRAINED BY {
-- must be the result of applying a hashing procedure to the DER-encoded octets --
-- of a value of --ToBeHashed } ) }
 ITU-T Rec. X.509 (1997)/Cor.2 (02/2001 E) 1

---------------------- Page: 2 ----------------------
ISO/IEC 9594-8:1998/Cor.2:2002 (E)
5) Add the following OID assignments in the authenticationFramework module:
id-at-attributeCertificateRevocationList OBJECT IDENTIFIER ::= {id-at 59}
id-mr-attributeCertificateMatch OBJECT IDENTIFIER ::= {id-mr 42}
6) Add Time to the set of objects imported into the certificateExtensions module from the
authenticationFramework module.
7) In the certificateExtensions module, and in the main text of 12.7.2 replace:
CertPolicySet ::= SEQUENCE (1.MAX) OF CertPolicyId
with:
CertPolicySet ::= SEQUENCE SIZE (1.MAX) OF CertPolicyId


2) Defect reports resolved by Draft Technical Corrigendum 9

(covering resolutions to defect reports 244, 256, 257 and 258)



2.1) This corrects the defects reported in defect report 244

In clause 8:

In the paragraph that begins "The extensions field allows addition of new .", add the following two sentences to the
end of the paragraph:

When a certificate-using implementation recognizes and is able to process an extension, then the certificate-using
implementation shall process the extension regardless of the value of the criticality flag. Note that any extension that is
flagged non-critical will cause inconsistent behaviour between certificate-using systems that will process the extension
and certificate-using systems that do not recognize the extension will ignore it.


Add the following immediately after the paragraph that begins "If unknown elements appear within the extension …":

A CA has three options with respect to an extension:

i) it can exclude the extension from the certificate;
ii) it can include the extension and flag it non-critical;
iii) it can include the extension and flag it critical.
A validation engine has two possible actions to take with respect to an extension:

i) it can ignore the extension and accept the certificate (all other things being equal);
ii) it can process the extension and accept or reject the certificate depending on the content of the extension and
the conditions under which processing is occuring (e.g. the current values of the path processing variables).
Some extensions can only be marked critical. In these cases, a validation engine that understands the extension
processes it and acceptance/rejection of the certificate is dependent (at least in part) on the content of the extension. A
validation engine that does not understand the extension rejects the certificate.

Some extensions can only be marked non-critical. In these cases, a validation engine that understands the extension
processes it and acceptance/rejection of the certificate is dependent (at least in part) on the content of the extension. A
validation engine that does not understand the extension accepts the certificate (unless factors other than this extension
cause it
...

NORME INTERNATIONALE ISO/CEI 9594-8:1998
RECTIFICATIF TECHNIQUE 2
Publié 2002-06-15

INTERNATIONAL ORGANIZATION FOR STANDARDIZATION • МЕЖДУНАРОДНАЯОРГАНИЗАЦИЯПОСТАНДАРТИЗАЦИИ • ORGANISATION INTERNATIONALE DE NORMALISATION
INTERNATIONAL ELECTROTECHNICAL COMMISSION • МЕЖДУНАРОДНАЯЭЛЕКТРОТЕХНИЧЕСКАЯКОМИССИЯ • COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE

Technologies de l'information — Interconnexion de systèmes
ouverts (OSI) — L'annuaire: Cadre d'authentification
RECTIFICATIF TECHNIQUE 2
Information technology — Open Systems Interconnection — The Directory: Authentification framework
TECHNICAL CORRIGENDUM 2
Le Rectificatif technique 2 à la Norme internationale ISO/CEI 9594-8:1998 a été élaboré par le comité technique
mixte ISO/CEI JTC 1, Technologies de l'information, sous-comité SC 6, Téléinformatique.
o
ICS 35.100.70 Réf. n ISO/CEI 9594-8:1998/Cor.2:2002(F)
© ISO/CEI 2002 – Tous droits réservés
ImpriméenSuisse

---------------------- Page: 1 ----------------------
ISO/CEI 9594-8:1998/Cor.2:2002 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
Technologies de l'information – Interconnexion des systèmes ouverts –
L'annuaire: cadre d'authentification

CORRIGENDUM TECHNIQUE 2



NOTE – Ce corrigendum technique couvre les projets de Corrigenda techniques 8 et 9.
1) Relevés de défauts couverts par le projet de Corrigendum technique 8

(couvrant les résolutions relatives aux relevés de défauts 226, 227 et 240)


1.1) Ce qui suit rectifie les défauts figurant dans le relevé de défauts 226

Au § 11.2, supprimer le deuxième alinéa:

La production d'un certificat … compromission improbable.


1.2) Ce qui suit rectifie les défauts figurant dans le relevé de défauts 227

Au § 12.2.2.1, ajouter les 2 phrases suivantes à la fin de l'alinéa qui commence par "Les autorités de certification
doivent attribuer …"

On peut utiliser la forme keyIdentifier pour sélectionner des certificats d'une autorité de certification pendant la
construction de chemin. On ne peut utiliser la paire authorityCertIssuer, authoritySerialNumber que pour donner la
préférence à un certificat par rapport aux autres pendant la construction de chemin.


1.3) Ce qui suit rectifie les défauts figurant dans le relevé de défauts 240

Il convient d'apporter les corrections suivantes à l'édition de 1997 du module authenticationFramework donné à
l'Annexe A:
1) Ajouter "id-mr" à la liste d'objets importés depuis le module UsefulDefinitions dans le module
authenticationFramework.
2) Ajouter "AttributeType", "Attribute" et "MATCHING-RULE" à l'ensemble d'objets importés dans le module
authenticationFramework depuis le module InformationFramework.
3) Ajouter "GeneralNames" à l'ensemble d'objets importés dans le module authenticationFramework depuis le
module CertificateExtensions.
4) Ajouter la définition suivante au module authenticationFramework car elle est importée dans d'autres
modules des Recommandations de la série X.500, mais ne figure pas dans l'édition de 1997 de la
Recommandation X.509:
HASH {ToBeHashed} ::= SEQUENCE {
algorithmIdentifier AlgorithmIdentifier,
hashValue  BIT STRING ( CONSTRAINED BY {
-- doit être le résultat de l'application d'une procédure de dispersion aux octets à codage DER --
-- de valeur --ToBeHashed } ) }
 Rec. UIT-T X.509 (1997)/Cor.2 (02/2001 F) 1

---------------------- Page: 2 ----------------------
ISO/CEI 9594-8:1998/Cor.2:2002 (F)
5) Ajouter les assignations d'identificateur d'objet suivantes dans le module authenticationFramework:
id-at-attributeCertificateRevocationList OBJECT IDENTIFIER ::= {id-at 59}
id-mr-attributeCertificateMatch OBJECT IDENTIFIER ::= {id-mr 42}
6) Ajouter "Time" à l'ensemble d'objets importés dans le module CertificateExtensions depuis le module
authenticationFramework.
7) Dans le module CertificateExtensions et au § 12.7.2 du corps de la Recommandation X.509, remplacer:
CertPolicySet ::= SEQUENCE (1.MAX) OF CertPolicyId
par:
CertPolicySet ::= SEQUENCE SIZE (1.MAX) OF CertPolicyId

2) Relevés de défauts couverts par le projet de Corrigendum technique 9

(couvrant les résolutions relatives aux relevés de défauts 244, 256, 257 et 258)


2.1) Ce qui suit rectifie les défauts figurant dans le relevé de défauts 244

Dans l'article 8:

ajouter à la fin de l'alinéa qui commence par "Le champ d'extension permet d'ajouter de nouveaux …" les deux
phrases suivantes:

Lorsqu'une application qui utilise la certification reconnaît une extension et est en mesure de la traiter, elle effectue ce
traitement quelle que soit la valeur du fanion de criticité. Il convient de noter que les extensions marquées comme étant
non critiques seront traitées différemment selon les systèmes. Les systèmes qui utilisent la certification traiteront
l'extension, tandis que ceux qui utilisent la certification mais ne la reconnaissent pas n'en tiendront pas compte.

Ajouter le texte suivant juste après l'alinéa qui commence par "Si des éléments inconnus apparaissent dans l'extension
…":

Une autorité de certification a trois possibilités en ce qui concerne une extension:
i) elle peut exclure l'extension du certificat;
ii) elle peut inclure l'extension et la marquer comme étant non critique;
iii) elle peut inclure l'extension et la marquer comme étant critique.

Un moteur de validation a deux possibilités en ce qui concerne une extension:
i) il peut ne pas tenir compte de l'extension et accepter le certificat (les autres éléments étant les mêmes);
ii) il peut effectuer le traitement de l'extension et accepter ou rejeter le certificat en fonction du contenu de
l'extension et des conditions de traitement (par exemple, les valeurs en cours des variables de traitement
de l'itinéraire).

Certaines extensions ne peuvent être marquées que comme étant critiques. Dans ces cas, un moteur de validation qui
comprend l'extension la traite et accepte ou rejette le certificat en fonction (au moins en partie) du contenu de
l'extension. Un moteur de validation qui ne comprend pas l'extension rejette le certificat.

Certaines extensions ne peuvent être marquées que comme étant non critiques. Dans ces cas, un moteur de validation
qui comprend l'extension la traite et accepte ou rejette le certificat en fonction (au moins en partie) du contenu de
l'extension. Un moteur de validation qui ne comprend pas l'extension accepte le certificat (à moins que des facteurs
autres que cette extension ne provoquent son rejet).

Certaines extensions peuvent être marquées comme étant critiques ou non critiques. Dans ces cas, un moteur de
validation qui comprend l'extension la traite et accepte ou rejette le certificat en fonction (au moins en partie) du
contenu de l'extension, quel que soit le fanion de critici
...