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

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

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

General Information

• Status: Withdrawn
• Publication Date: 18-Sep-2002
• Withdrawal Date: 18-Sep-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 3
Published 2002-09-01

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


Information technology — Open Systems Interconnection —
The Directory: Authentification framework
TECHNICAL CORRIGENDUM 3
Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — L'annuaire: Cadre
d'authentification
RECTIFICATIF TECHNIQUE 3
Technical Corrigendum 3 to 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.3:2002(E)
©  ISO/IEC 2002 – All rights reserved
Published in Switzerland

---------------------- Page: 1 ----------------------
ISO/IEC 9594-8:1998/Cor.3:2002 (E)
INTERNATIONAL STANDARD

ITU-T RECOMMENDATION
Information technology – Open Systems Interconnection – The Directory:
Authentication framework
TECHNICAL CORRIGENDUM 3
(covering resolutions to defect reports 272, 273, 275 and 277)
1) This corrects the defects reported in defect report 272
In 12.4.2.1, add the following text to the end of the paragraph that begins with "The pathLenConstraint component
shall be present only if…"
The constraint takes effect beginning with the next certificate in the path. The constraint restricts the length of the
segment of the certification path between the certificate containing this extension and the end-entity certificate. It has no
impact on the number of CA-certificates in the certification path between the trust anchor and the certificate containing
this extension. Therefore, the length of a complete certification path may exceed the maximum length of the segment
constrained by this extension. The constraint controls the number of non self-issued CA certificates between the CA
certificate containing the constraint and the end-entity certificate. Therefore the total length of this segment of the path,
excluding self-issued certificates, may exceed the value of the constraint by as many as two certificates. (This includes
the certificates at the two endpoints of the segment plus the CA certificates between the two endpoints that are
constrained by the value of this extension.)
2) This corrects the defects reported in defect report 273
Replace 12.4.2.2 with the following:
12.4.2.2 Name constraints extension
This field, which shall be used only in a CA-certificate, indicates a name space within which all subject names in
subsequent certificates in a certification path must be located. This field is defined as follows:
nameConstraints EXTENSION ::= {
SYNTAX NameConstraintsSyntax
IDENTIFIED BY id-ce-nameConstraint }

NameConstraintsSyntax ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL,
requiredNameForms [2] NameForms OPTIONAL }

GeneralSubtrees ::= SEQUENCE SIZE (1.MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {
base  GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0.MAX)

NameForms ::= SEQUENCE {
   basicNameForms [0] BasicNameForms OPTIONAL,
   otherNameForms [1] SEQUENCE SIZE (1.MAX) OF OBJECT IDENTIFIER OPTIONAL }
(ALL EXCEPT ({ -- none; i.e.:at least one component shall be present -- }))
  ITU-T Rec. X.509 (1997)/Cor.3 (10/2001 E) 1

---------------------- Page: 2 ----------------------
ISO/IEC 9594-8:1998/Cor.3:2002 (E)
BasicNameForms ::= BIT STRING {
  rfc822Name  (0),
dNSName  (1),
x400Address (2),
directoryName (3),
ediPartyName (4),
uniformResourceIdentifier (5),
iPAddress  (6),
registeredID  (7) } (SIZE (1.MAX))

If present, the permittedSubtrees and excludedSubtrees components each specify one or more naming subtrees, each
defined by the name of the root of the subtree and optionally, within that subtree, an area that is bounded by upper and/or
lower levels. If permittedSubtrees is present, subject names within these subtrees are acceptable. If excludedSubtrees
is present, any certificate issued by the subject CA or subsequent CAs in the certification path that has a subject name
within these subtrees is unacceptable. If both permittedSubtrees and excludedSubtrees are present and the name
spaces overlap, the exclusion statement takes precedence for names within that overlap. If neither permitted nor excluded
subtrees are specified for a name form, then any name within that name form is acceptable. If requiredNameForms is
present, all subsequent certificates in the certification path must include a name of at least one of the required name
forms.
If permittedSubtrees is present, the following applies to all subsequent certificates in the path. If any certificate contains
a subject name (in the subject field or subjectAltNames extension) of a name form for which permitted subtrees are
specified, the name must fall within at least one of the specified subtrees. If any certificate contains only subject names
of name forms other than those for which permitted subtrees are specified, the subject names are not required to fall
within any of the specified subtrees. For example, assume that two permitted subtrees are specified, one for the DN name
form and one for the rfc822 name form, no excluded subtrees are specified, but requiredNameForms is specified with
the directoryName bit and rfc822Name bit present. A certificate that contained only names other than a directory name
or rfc822 name would be unacceptable. If requiredNameForms were not specified, however, such a certificate would be
acceptable. For example, assume that two permitted subtrees are specified, one for the DN name form and one for the
rfc822 name form, no excluded subtrees are specified, and requiredNameForms is not present. A certificate that only
contained a DN and where the DN is within the specified permitted subtree would be acceptable. A certificate that
contained both a DN and an rfc822 name and where only one of them is within its specified permitted subtree would be
unacceptable. A certificate that contained only names other than a DN or rfc822 name would also be acceptable.
If excludedSubtrees is present, any certificate issued by the subject CA or subsequent CAs in the certification path that
has a subject name (in the subject field or subjectAltNames extension) within these subtrees is unacceptable. For
example, assume that two excluded subtrees are specified, one for the DN name form and one for the rfc822 name form.
A certificate that only contained a DN and where the DN is within the specified excluded subtree would be unacceptable.
A certificate that contained both a DN and an rfc822 name and where at least one of them is within its specified excluded
subtree would be unacceptable.
When a certificate subject has multiple names of the same name form (including, in the case of t
...

NORME INTERNATIONALE ISO/CEI 9594-8:1998
RECTIFICATIF TECHNIQUE 3
Publié 2002-09-01

Version française parue en 2003

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 3
Information technology — Open Systems Interconnection — The Directory: Authentication framework
TECHNICAL CORRIGENDUM 3
Le Rectificatif technique 3 à l'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.3:2002(F)
© ISO/CEI 2002 – Tous droits réservés
Publié en Suisse

---------------------- Page: 1 ----------------------
ISO/CEI 9594-8:1998/Cor.3:2002 (F)
NORME INTERNATIONALE

RECOMMANDATION UIT-T
Technologies de l'information – Interconnexion des systèmes ouverts –
L'annuaire: cadre d'authentification
CORRIGENDUM TECHNIQUE 3
(couvrant les résolutions des rapports de défauts 272, 273, 275 et 277)
1) Ce qui suit corrige les défauts signalés dans le rapport de défaut 272
Au § 12.4.2.1, ajouter le texte suivant à la fin de l'alinéa qui commence par "la composante pathLenConstraint sera
présente ."
Cette contrainte prend effet à partir du certificat suivant sur le chemin. Cette contrainte limite la longueur du segment du
chemin de certification entre le certificat contenant cette extension et le certificat d'entité finale. Elle n'a pas d'effet sur le
nombre de certificats CA sur le chemin de certification entre l'ancre de confiance et le certificat contenant cette
extension. Par conséquent, la longueur d'un chemin de certification complet peut être supérieure à la longueur maximale
du chemin limitée par cette extension. La contrainte limite le nombre de certificats CA non auto-émis entre le certificat
CA contenant la contrainte et le certificat d'entité finale. Par conséquent, la longueur totale de ce segment de chemin, à
l'exclusion des certificats auto-émis, peut être supérieure à la valeur de la contrainte de deux certificats au maximum.
(Ceci inclut les certificats aux deux points d'extrémité du segment plus les certificats CA entre les deux points
d'extrémité soumis à des contraintes imposées par la valeur de cette extension.)
2) Ce qui suit corrige les défauts signalés dans le rapport de défaut 273
Remplacer le § 12.4.2.2 par le texte suivant:
12.4.2.2 Extension des contraintes de nom
Ce champ, qui doit uniquement être utilisé dans un certificat CA, indique un espace nom dans lequel tous les noms de
sujet dans les certificats subséquents d'un chemin de certification doivent se trouver. Ce champ est défini comme suit:
nameConstraints EXTENSION ::= {
SYNTAX NameConstraintsSyntax
IDENTIFIED BY id-ce-nameConstraint }

NameConstraintsSyntax ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL,
requiredNameForms [2] NameForms OPTIONAL }

GeneralSubtrees ::= SEQUENCE SIZE (1.MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {
base  GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0.MAX)

NameForms ::= SEQUENCE {
   basicNameForms [0] BasicNameForms OPTIONAL,
   otherNameForms [1] SEQUENCE SIZE (1.MAX) OF OBJECT IDENTIFIER OPTIONAL }
(ALL EXCEPT ({ -- néant; c'est-à-dire qu'au moins un composant doit être présent -- }))
  Rec. UIT-T X.509 (1997)/Cor.3 (10/2001 F) 1

---------------------- Page: 2 ----------------------
ISO/CEI 9594-8:1998/Cor.3:2002 (F)
BasicNameForms ::= BIT STRING {
  rfc822Name  (0),
dNSName  (1),
x400Address (2),
directoryName (3),
ediPartyName (4),
uniformResourceIdentifier (5),
iPAddress  (6),
registeredID  (7) } (SIZE (1.MAX))

S'ils sont présents, les composants permittedSubtrees et excludedSubtrees spécifient chacun un ou plusieurs
sous-arbres de nommage, chacun étant défini par le nom de la racine du sous-arbre et, optionnellement, à l'intérieur du
sous-arbre, une zone qui est limitée par des niveaux supérieurs et/ou inférieurs. Si la composante permittedSubtrees est
présente, les noms de sujet dans ces sous-arbres sont acceptables. Si le composant excludedSubtrees est présent, tout
certificat émis par l'autorité CA considérée, ou les CA subséquents dans le chemin de certification qui ont un nom de
sujet à l'intérieur de ces sous-arbres, est inacceptable. Si les deux composants permittedSubtrees et excludedSubtrees
sont simultanément présents et que les espaces de noms se chevauchent, la déclaration d'exclusion a la priorité pour les
noms situés dans la partie qui se chevauchent. Si les sous-arbres autorisés ou exclus ne sont pas présents pour une fore de
nom, tout nom dans la forme de nom est acceptable. Si le composant requiredNameForms est présent, tous les
certificats subséquents dans le chemin de certification doivent inclure un nom d'au moins une des formes de nom
requises.
Si le composant permittedSubtrees est présent, ce qui suit s'applique à tous les certificats subséquents situés sur le
chemin. Si un certificat contient un nom de sujet (dans le champ subject ou une extension subjectAltNames) d'une
forme de nom pour lequel des sous-arbres autorisés sont spécifiés, le nom doit se trouver dans au moins un des
sous-arbres spécifiés. Si un certificat contient seulement les noms de sujet des formes de nom autres que celles pour
lesquelles les sous-arbres autorisés sont spécifiés, il n'est pas exigé que les noms de sujet se trouvent dans l'un des
sous-arbres spécifiés. Par exemple, supposons que deux sous-arbres soient spécifiés, l'un pour la forme de nom DN et
l'autre pour la forme de nom rfc822, aucun sous-arbre exclu n'est spécifié, mais requiredNameForms est spécifié avec le
bit du directoryName et le bit rfc822Name présents. Un certificat qui contient seulement des noms autres que le nom
d'annuaire ou le nom rfc822 serait inacceptable. Si toutefois les requiredNameForms n'étaient pas spécifiés, un tel
certificat serait acceptable. Par exemple, supposons que deux sous-arbres autorisés soient spécifiés, un pour la forme de
nom DN et l'autre la forme de nom rfc 822, on ne spécifie pas de sous-arbres exclus, et le composant
requiredNameForms n'est pas présent. Un certificat qui n'aurait contenu qu'un DN et où le DN se trouve dans le
sous-arbre autorisé spécifié aurait été acceptable. Un certificat qui aurait contenu à la fois un nom de DN et un nom
rfc822 et dans lequel un seul de ces noms aurait été à l'intérieur de son sous-arbre autorisé spécifié aurait été
inacceptable. Un certificat qui contient seulement des noms autres qu'un nom de DN ou un nom rfc822 serait également
acceptable.
Si le composant excludedSubtrees est présent, tout certificat émis par l'autorité CA considérée ou les autorités CA
subséquentes sur le chemin de certification qui a un nom de sujet (dans le champ subject ou l'extension
subjectAltNames) dans ces sous-arbres est inacceptable. Par exemple, si l'on suppose que deux sous-arbres exclus sont
spécifiés, l'un pour la forme de nom DN et l'autre pour la forme de nom rfc822, un certificat qui n'aurait contenu qu'un
nom DN se trouvant dans le sous-arbre exclu spécifié aurait été inacceptable. Un certificat qui contiendrait un nom DN et
un nom rfc822 dans lequel un de ces noms se trouverait dans le sous-arbre exclu spécifié aurait été inacceptable.
Lorsqu'un sujet d'un certificat a plusieurs noms de la même forme de nom (y compris dans le cas d'une forme de nom
directoryName, le nom dans le champ sujet du certificat s'il n'est pas vide), l'homogénéité de tous ces noms doit être
vérifiée avec une contrainte de nom de cette forme de nom.
...