Title :

Title :

Final Text of Draft Amendments DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions

Source :

ISO/IEC JTC 1/SC 21/WG 4 and ITU-T Q15/7 Collaborative Editing Meeting on the Directory, Geneva, April 1996

Project:

21.29.18

Status :

Final Final draft (1 DecemberJune 30). This document will be distributed by the SC21 Secretariat and integrated into the 3rd edition

Requested Action :

Text forwarded to the JTC1 SC21 Secretariat for NB/LO circulation and eventual inclusion into the 3rd edition of ISO/IEC 9594.

Introduction

This document collects together in a single document, the changes necessary to extend the definitions of certificates and certificate revocation lists.

This document defines amendments to the following parts of ITU-T Recommendation X.500 (1993) | ISO/IEC 9594 : 1995:

— AM 4 to ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1995, Information Technology — Open Systems Interconnection — The Directory: The Models.

— AM 2 to ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1995, Information Technology — Open Systems Interconnection —The Directory: Selected Attribute Types.

— AM 1 to ITU-T Recommendation X.521 (1993) | ISO/IEC 9594-7:1995, Information Technology — Open Systems Interconnection —The Directory: Selected Object Classes .

— AM 1 to ITU-T Recommendation X.509 (1993) | ISO/IEC 9594-8:1995, Information Technology — Open Systems Interconnection —The Directory: Authentication Framework.

Amendment 4 to ITU Rec. X.501 (1993) | ISO/IEC 9594-2 : 1995

Information Technology — Open Systems Interconnection — The Directory: The Models

AMENDMENT 4: Certificate Extensions

Introduction
This clause provides an introduction to this amendment. The text in this clause is not intended for inclusion in ITU-T Rec. X.500 | ISO/IEC 9594-2.

This amendment supports extensions to the definitions of certificates and certificate revocation lists (CRLs) in ITU-T Rec. X.509 | ISO/IEC 9594-8. The extensions to ITU-T Rec. X.501 | ISO/IEC 9594-2 are required to obtain the necessary object identifier assignments.

Annex A: Object identifier usage

At the end of the list of categories of information object add the following:

certificateExtension ID ::= {ds 29}

At the end of the list of modules add the following:

certificateExtensions ID ::= {module certificateExtensions (26) 02}

At the end of the list of synonyms add the following:

id-ce ID ::= certificateExtension

Amendment 2 to ITU Rec. X.520 (1993) | ISO/IEC 9594-6 : 1995

Information Technology — Open Systems Interconnection — The Directory: Selected Attribute Types

AMENDMENT 2: Certificate Extensions

Introduction
This clause provides an introduction to this amendment. The text in this clause is not intended for inclusion in ITU-T Rec. X.520 | ISO/IEC 9594-6.

This amendment supports extensions to the definitions of certificates and certificate revocation lists (CRLs) in ITU-T Rec. X.509 | ISO/IEC 9594-8. The extensions to ITU-T Rec. X.520 | ISO/IEC 9594-6 are required to record in that document new object identifier assignments for selected attribute types and matching rules.

Annex A: Selected attribute types in ASN.1

After the line defining the object identifier for id-at-houseIdentifier, insert the following commented ASN.1 lines:

-- id-at-supportedAlgorithms OBJECT IDENTIFIER ::= {id-at 52}

-- id-at-deltaRevocationList OBJECT IDENTIFIER ::= {id-at 53}

After the line defining the object identifier for id-mr-keywordMatch, insert the following commented ASN.1 lines:

-- id-mr-certificateExactMatch OBJECT IDENTIFIER ::= {id-mr 34}

-- id-mr-certificateMatch OBJECT IDENTIFIER ::= {id-mr 35}

-- id-mr-certificatePairExactMatch OBJECT IDENTIFIER ::= {id-mr 36}

-- id-mr-certificatePairMatch OBJECT IDENTIFIER ::= {id-mr 37}

-- id-mr-certificateListExactMatch OBJECT IDENTIFIER ::= {id-mr 38}

-- id-mr-certificateListMatch OBJECT IDENTIFIER ::= {id-mr 39}

-- id-mr-algorithmIdentifierMatch OBJECT IDENTIFIER ::= {id-mr 40}

Amendment 1 to ITU Rec. X.521 (1993) | ISO/IEC 9594-7 : 1995

Information Technology — Open Systems Interconnection — The Directory: Selected Object Classes

AMENDMENT 1: Certificate Extensions

Introduction
This clause provides an introduction to this amendment. The text in this clause is not intended for inclusion in ITU-T Rec. X.521 | ISO/IEC 9594-6.

This amendment supports extensions to the definitions of certificates and certificate revocation lists (CRLs) in ITU-T Rec. X.509 | ISO/IEC 9594-8. The extensions to ITU-T Rec. X.521 | ISO/IEC 9594-7 are required to record in that document new object object class definitions and name forms for new attribute types.

After clause 6.15 insert the following clause and renumber:

6.15bis User Security Information

The User Security Information object class is used in defining entries for objects which need to indicate security information associated with them as defined in ITU X.509 | ISO/IEC 9594-8.

userSecurityInformation OBJECT-CLASS ::= {
SUBCLASS OF { top }
KIND auxiliary
MAY CONTAIN { supportedAlgorithms }
ID id-oc-userSecurityInformation }
After clause 6.16 (renumbered to 6.17) insert the following clauses:

6.18 Certification Authority-V2

The Certification Authority-V2 object class is used in defining entries for objects which act as certification authorities and can support the delta revocation list as defined in ITU X.509 | ISO/IEC 9594-8.

certificationAuthority-V2 OBJECT-CLASS ::= {
SUBCLASS OF { certificationAuthority }
KIND auxiliary
MAY CONTAIN { deltaRevocationList }
ID id-oc-certificationAuthority-V2 }

6.19 CRL Distribution Point

The CRL Distribution Point object class is used in defining entries for object which act as CRL Distribution Points as defined in ITU X.509 | ISO/IEC 9594-8.

cRLDistributionPoint OBJECT-CLASS ::= {

SUBCLASS OF { top }

KIND structural

MUST CONTAIN { commonName }

MAY CONTAIN { certificateRevocationList |

authorityRevocationList |

deltaRevocationList }

ID id-oc-cRLDistributionPoint }

After clause 7.14 add the following clause:
7.15 CRL Distribution Point Name Form

The CRL Distribution Point name form specifies how entries of object class cRLDistributionPoint may be named.

cRLDistPtNameForm NAME-FORM ::= {

NAMES cRLDistributionPoint

WITH ATTRIBUTES { commonName}

ID id-nf-cRLDistPtNameForm }

After the ASN.1 definition for strongAuthenticatedUser in Annex A insert the following :

userSecurityInformation OBJECT-CLASS ::= {
SUBCLASS OF { top }
KIND auxiliary
MAY CONTAIN {supportedAlgorithms}
ID id-oc-userSecurityInformation }

cRLDistributionPoint OBJECT-CLASS ::= {

SUBCLASS OF { top }

KIND structural

MUST CONTAIN { commonName }

MAY CONTAIN { certificateRevocationList |

authorityRevocationList |

deltaRevocationList }

ID id-oc-cRLDistributionPoint }

After the ASN.1 definition for certificationAuthority in Annex A insert the following :

cRLDistPtNameForm NAME-FORM ::= {

NAMES cRLDistributionPoint

WITH ATTRIBUTES { commonName}

ID id-nf-cRLDistPtNameForm }

After the ASN.1 definition for id-oc-certificationAuthority in Annex A insert the following line:

id-oc-certificationAuthority-V2 OBJECT IDENTIFIER ::= {id-oc 16 2}

After the ASN.1 definition for id-oc-groupOfUniqueNames in Annex A insert the following lines:

id-oc-userSecurityInformation OBJECT IDENTIFIER ::= { id-oc 18 }

id-oc-cRLDistributionPoint OBJECT IDENTIFIER ::= { id-oc 19 }

After the ASN.1 definition for id-nf-deviceNameForm in Annex A insert the following line:

id-nf-cRLDistPtNameForm OBJECT IDENTIFIER ::= { id-nf 14 }

Amendment 1 to ITU Rec. X.509 (1993) | ISO/IEC 9594-8 : 1995

Information Technology — Open Systems Interconnection — The Directory: Authentication Framework

AMENDMENT 1: Certificate Extensions

Introduction
This clause provides an introduction to this amendment. The text in this clause is not intended for inclusion in ITU-T Rec. X.509 | ISO/IEC 9594-8.

This amendment specifies extensions to the definitions of certificates and certificate revocation lists (CRLs) in ITU-T Rec. X.509 | ISO/IEC 9594-8. These extensions are in the following areas:

a) extensions to certificates to convey additional information about the keys involved, including key identifiers for subject and issuer keys, indicators of intended or restricted key usage, and indicators of certificate policy;

b) extensions to certificates to convey alternative names, of various name forms for a certificate subject, a certificate issuer, or a CRL issuer, and additional attribute information about a certificate subject;

c) extensions to certificates to allow constraint specifications to be included in CA-certificates, i.e. certificates for CAs issued by other CAs, to facilitate the automated processing of certification paths when multiple certificate policies are involved, e.g. when policies vary for different applications in an environment or when interoperation with external environments occurs;

d) CRL extensions to allow a CRL to include indications of revocation reason, to provide for temporary suspension of a certificate, and to include CRL-issue sequence numbers to allow certificate users to detect missing CRLs in a sequence from one CRL issuer;

e) certificate and CRL extensions to allow the complete set of revocation information from one CA to be partitioned into separate CRLs to facilitate control of CRL sizes, and CRL extensions to support the use of partial CRLs indicating only changes since an earlier CRL issue;

f) additional matching rule definitions to facilitate the selection of certificates or CRLs with specific characteristics from multi-valued attributes holding multiple certificates or CRLs.

Add the following reference to subclause 2.1:

— ITU-T Recommendation X.411 | ISO/IEC 10021-4, Information Technology — Message Handling Systems — Message Transfer System: Abstract service definition and procedures.

Add the following subclause after subclause 2.2:
2.3 Other references

— ISO/IEC 11770-1, Information Technology — Security techniques — Key management: Introduction.

— D.H. Crocker, "Standard for the Format of ARPA Internet Text Messages", RFC 822, Internet Activities Board, 1982.

— P. Mockapetris, "Domain Names — Implementation and Specification," RFC 1035, Internet Activities Board, 1987.

— T. Berners-Lee, "Universal Resource Identifiers in WWW," RFC 1630, Internet Activities Board, 1994.

— J.B. Postel, "Internet Protocol,", RFC 791, Internet Activities Board, 1981.

3.3 Authentication framework definitions

Add the following at the end of the list:

o) CA-certificate: A certificate for one CA issued by another CA.

p) certificate policy: A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular certificate policy might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range.

q) certificate user: An entity that needs to know, with certainty, the public key of another entity.

r) certificate-using system: An implementation of those functions defined in this Directory Specification that are used by a certificate-user.

s) CRL distribution point: A directory entry or other distribution source for CRLs; a CRL distributed through a CRL distribution point may contain revocation entries for only a subset of the full set of certificates issued by one CA or may contain revocation entries for multiple CAs.

t) delta-CRL: A partial CRL indicating only changes since a prior CRL issue.

u) end entity: A certificate subject which uses its public key for purposes other than signing certificates.

v) key agreement: A method for negotiating a key value on-line without transferring the key, even in an encrypted form, e.g. the Diffie-Hellman technique (see ISO/IEC 11770-1 for more information on key agreement mechanisms).

w) policy mapping: Recognizing that, when a CA in one domain certifies a CA in another domain, a particular certificate policy in the second domain may be considered by the authority of the first domain to be equivalent (but not necessarily identical in all respects) to a particular certificate policy in the first domain.

4 Abbreviations

Insert the following after the first item:

CRL Certificate revocation list

8 Obtaining a user's public key

Insert the following at the end of the paragraph immediately before the ASN.1 defining the EXTENSION object class (added by Technical Corrigendum):

Standard extensions for certificates are defined in clause 12 of this Directory Specification.

In the ASN.1 ATTRIBUTE object definition for userCertificate insert, after the WITH SYNTAX line, the line:

EQUALITY MATCHING RULE certificateExactMatch

In the ASN.1 ATTRIBUTE object definition for cACertificate insert, after the WITH SYNTAX line, the line:

EQUALITY MATCHING RULE certificateExactMatch

In the ASN.1 ATTRIBUTE object definition for crossCertificatePair insert, after the WITH SYNTAX line, the line:

EQUALITY MATCHING RULE certificatePairExactMatch

11.2 Management of certificates

In the ASN.1 ATTRIBUTE object definition for certificateRevocationList insert, after the WITH SYNTAX line, the line:

EQUALITY MATCHING RULE certificateListExactMatch

In the ASN.1 ATTRIBUTE object definition for authorityRevocationList insert, after the WITH SYNTAX line, the line:

EQUALITY MATCHING RULE certificateListExactMatch

Insert the following as a third note after the CRL ASN.1 definition:

3 Standard extensions for CRLs are defined in clause 12 of this Directory Specification.

Add the following new clause:

12 Certificate and CRL extensions

12.1 Introduction

This clause specifies extensions in the following areas:

a) Key and policy information: These certificate and CRL extensions convey additional information about the keys involved, including key identifiers for subject and issuer keys, indicators of intended or restricted key usage, and indicators of certificate policy.

b) Subject and issuer attributes: These certificate and CRL extensions support alternative names, of various name forms, for a certificate subject, a certificate issuer, or a CRL issuer. These extensions can also convey additional attribute information about the certificate subject, to assist a certificate user in being confident that the certificate subject is a particular person or entity.

c) Certification path constraints: These certificate extensions allow constraint specifications to be included in CA-certificates, i.e.i.e., certificates for CAs issued by other CAs, to facilitate the automated processing of certification paths when multiple certificate policies are involved. Multiple certificate policies arise when policies vary for different applications in an environment or when interoperation with external environments occurs. The constraints may restrict the types of certificates that can be issued by the subject CA or that may occur subsequently in a certification path.

d) Basic CRL extensions: These CRL extensions allow a CRL to include indications of revocation reason, to provide for temporary suspension of a certificate, and to include CRL-issue sequence numbers to allow certificate users to detect missing CRLs in a sequence from one CRL issuer.

e) CRL distribution points and delta-CRLs: These certificate and CRL extensions allow the complete set of revocation information from one CA to be partitioned into separate CRLs and allow revocation information from multiple CAs to be combined in one CRL. These extensions also support the use of partial CRLs indicating only changes since an earlier CRL issue.

Inclusion of any extension in a certificate or CRL is at the option of the authority issuing that certificate or CRL.

In a certificate or CRL, an extension is flagged as being either critical or non-critical. If an extension is flagged critical and a certificate-using system does not recognize the extension field type or does not implement the semantics of the extension, then that system shall consider the certificate invalid. If an extension is flagged non-critical, a certificate-using system that does not recognize or implement that extension type may process the remainder of the certificate ignoring the extension. Extension type definitions in this Directory Specification indicate if the extension is always critical, always non-critical, or if criticality can be decided by the certificate or CRL issuer. The reason for requiring some extensions to be always non-critical is to allow certificate-using implementations which do not need to use such extensions to omit support for them without jeopardizing the ability to interoperate with all certification authorities

Note — A certificate-using system may require certain non-critical extensions to be present in a certificate in order for that certificate to be considered acceptable. The need for inclusion of such extensions may be implied by local policy rules of the certificate user or may be a CA policy rule indicated to the certificate-using system by inclusion of a particular certificate policy identifier in the certificate policies extension with that extension being flagged critical.

For all certificate extensions, CRL extensions, and CRL entry extensions defined in this Directory Specification, there shall be no more than one instance of each extension type in any certificate, CRL, or CRL entry, respectively.

This clause also defines matching rules to facilitate the selection of certificates or CRLs with specific characteristics from multi-valued attributes holding multiple certificates or CRLs.

12.2 Key and policy information

12.2.1 Requirements

The following requirements relate to key and policy information:

a) CA key pair updating can occur at regular intervals or in special circumstances. There is a need for a certificate field to convey an identifier of the public key to be used to verify the certificate signature. A certificate-using system can use such identifiers in finding the correct CA-certificate for validating the certificate issuer's public key.

b) In general, a certificate subject has different public keys and, correspondingly, different certificates for different purposes, e.g. digital signature and encipherment key agreement. A certificate field is needed to assist a certificate user in selecting the correct certificate for a given subject for a particular purpose or to allow a CA to stipulate that a certified key may only be used for a particular purpose.

c) Subject key pair updating can occur at regular intervals or in special circumstances. There is a need for a certificate field to convey an identifier to distinguish between different public keys for the same subject used at different points in time. A certificate-using system can use such identifiers in finding the correct certificate.

d) The private key corresponding to a certified public key is typically used over a different period from the validity of the public key. With digital signature keys, the usage period for the signing private key is typically shorter than that for the verifying public key. The validity period of the certificate indicates a period for which the public key may be used, which is not necessarily the same as the usage period of the private key. In the event of a private key compromise, the period of exposure can be limited if the signature verifier knows the legitimate use period for the private key. There is therefore a requirement to be able to indicate the usage period of the private key in a certificate.

e) Because certificates may be used in environments where multiple certificate policies apply, provision needs to be made for including certificate policy information in certificates.

f) When cross-certifying from one organization to another, it can sometimes be agreed that certain of the two organizations' policies can be considered equivalent. A CA-certificate needs to allow the certificate issuer to indicate that one of its own certificate policies is equivalent to another certificate policy in the subject CA's domain. This is known as policy mapping.

g) A user of an encipherment or digital signature system which uses certificates defined in this Directory Specification needs to be able to determine in advance the algorithms supported by other users.

12.2.2 Certificate and CRL extension fields

The following extension fields are defined:

a) Authority key identifier;

b) Subject key identifier;

c) Key usage;

d) Private key usage period;

e) Certificate policies;

f) Policy mappings.

These extension fields shall be used only as certificate extensions, except for authority key identifier which may also be used as a CRL extension. Unless noted otherwise, these extensions may be used in both CA-certificates and end-entity certificates.

In addition, a Directory attribute is defined to support the selection of an algorithm for use when communicating with a remote end entity using certificates as defined in this Directory Specification.

12.2.2.1 Authority key identifier field

This field, which may be used as either a certificate extension or CRL extension, identifies the public key to be used to verify the signature on this certificate or CRL. It enables distinct keys used by the same CA to be distinguished (e.g.e.g., as key updating occurs). This field is defined as follows:

authorityKeyIdentifier EXTENSION ::= {

SYNTAX AuthorityKeyIdentifier

IDENTIFIED BY id-ce-authorityKeyIdentifier }

AuthorityKeyIdentifier ::= SEQUENCE {

keyIdentifier [0] KeyIdentifier OPTIONAL,

authorityCertIssuer [1] GeneralNames OPTIONAL,

authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }

( WITH COMPONENTS {..., authorityCertIssuer PRESENT,

authorityCertSerialNumber PRESENT} |

WITH COMPONENTS {..., authorityCertIssuer ABSENT,

authorityCertSerialNumber ABSENT} )

KeyIdentifier ::= OCTET STRING

The key may be identified by an explicit key identifier in the keyIdentifier component, by identification of a certificate for the key (giving certificate issuer in the authorityCertIssuer component and certificate serial number in the authorityCertSerialNumber component), or by both explicit key identifier and identification of a certificate for the key. If both forms of identification are used then the certificate or CRL issuer shall ensure they are consistent. A key identifier shall be unique with respect to all key identifiers for the issuing authority for the certificate or CRL containing the extension. An implementation which supports this extension is not required to be able to process all name forms in the authorityCertIssuer component. (See 12.3.2.1 for details of the GeneralNames type.)

Certification authorities shall assign certificate serial numbers such that every (issuer, certificate serial number) pair uniquely identifies a sigle certificate.

This extension is always non-critical.

12.2.2.2 Subject key identifier field

This field identifies the public key being certified. It enables distinct keys used by the same subject to be differentiated (e.g. as key updating occurs). This field is defined as follows:

subjectKeyIdentifier EXTENSION ::= {

SYNTAX SubjectKeyIdentifier

IDENTIFIED BY id-ce-subjectKeyIdentifier }

SubjectKeyIdentifier ::= KeyIdentifier

A key identifier shall be unique with respect to all key identifiers for the subject with which it is used. This extension is always non-critical.

12.2.2.3 Key usage field

This field, which indicates the purpose for which the certified public key is used, is defined as follows:

keyUsage EXTENSION ::= {

SYNTAX KeyUsage

IDENTIFIED BY id-ce-keyUsage }

KeyUsage ::= BIT STRING {

digitalSignature (0),

nonRepudiation (1),

keyEncipherment (2),

dataEncipherment (3),

keyAgreement (4),

keyCertSign (5),

cRLSign (6) }

Bits in the KeyUsage type are as follows:

a) digitalSignature: for verifying digital signatures that have purposes other than those identified in b), f), or g) below;

b) nonRepudiation: for verifying digital signatures used in providing a nonrepudiation service which protects against the signing entity falsely denying some action (excluding certificate or CRL signing, as in f) or g) below);

c) keyEncipherment: for enciphering keys or other security information, e.g.e.g., for key transport;

d) dataEncipherment: for enciphering user data, but not keys or other security information as in c) above;

e) keyAgreement: for use as a public key agreement key;

f) keyCertSign: for verifying a CA’s signature on certificates;

g) cRLSign: for verifying a CA’s signature on CRLs.

The bits keyCertSign and cRLSign are for use in CA-certificates only, and if the basic constraints extension (see 12.4.2.1) is present in the same certificate the values in the subjectType field of that extension and in the key usage restriction shall not conflict. CAs may also use other of the defined key usage bits in KeyUsage, e.g. digitalSignature for providing authentication and integrity of on-line administration transactions.

This extension may, at the option of the certificate issuer, be either critical or non-critical.

If the extension is flagged critical, then the certificate shall be used only for a purpose for which the corresponding key usage bit is set to one.

If the extension if flagged non-critical, then it indicates the intended purpose or purposes of the key, and may be used in finding the correct key/certificate of an entity that has multiple keys/certificates. It is an advisory field and does not imply that usage of the key is restricted to the purpose indicated. A bit set to zero indicates that the key is not intended for that purpose. If all bits are zero, it indicates the key is intended for some purpose other than those listed.

12.2.2.4 Private key usage period field

This field indicates the period of use of the private key corresponding to the certified public key. It is applicable only for digital signature keys. This field is defined as follows:

privateKeyUsagePeriod EXTENSION ::= {

SYNTAX PrivateKeyUsagePeriod

IDENTIFIED BY id-ce-privateKeyUsagePeriod }

PrivateKeyUsagePeriod ::= SEQUENCE {

notBefore [0] GeneralizedTime OPTIONAL,

notAfter [1] GeneralizedTime OPTIONAL }

( WITH COMPONENTS {..., notBefore PRESENT} |

WITH COMPONENTS {..., notAfter PRESENT} )

The notBefore component indicates the earliest date and time at which the private key could be used for signing. If the notBefore component is not present, then no information is provided as to when the period of valid use of the private key commences. The notAfter component indicates the latest date and time at which the private key could be used for signing. If the notAfter component is not present then no information is provided as to when the period of valid use of the private key concludes.

This extension is always non-critical.

Notes

1 The period of valid use of the private key may be different from the certified validity of the public key as indicated by the certificate validity period. With digital signature keys, the usage period for the signing private key is typically shorter than that for the verifying public key.

2 If the verifier of a digital signature wants to check that the key has not been revoked, for example due to key compromise, up to the time of verification, then a valid certificate must still exist for the public key at verification time. After the certificate(s) for a public key have expired, a signature verifier cannot rely on compromises being notified via CRLs.

12.2.2.5 Certificate policies field

This field lists certificate policies, recognized by the issuing CA, that apply to the certificate, together with optional qualifier information pertaining to these certificate policies. Typically, different certificate policies will relate to different applications which may use the certified key. This field is defined as follows:

certificatePolicies EXTENSION ::= {

SYNTAX CertificatePoliciesSyntax

IDENTIFIED BY id-ce-certificatePolicies }

A value of the PolicyInformation type identifies and conveys qualifier information for one certificate policy. The component policyIdentifier contains an identifier of a certificate policy and the component policyQualifiers contains policy qualifier values for that element.

This extension may, at the option of the certificate issuer, be either critical or non-critical.

If the extension is flagged critical, it indicates that the certificate shall only be used for the purpose, and in accordance with the rules implied by one of the indicated certificate policies. The rules of a particular policy may require the certificate-using system to process the qualifier value in a particular way.

If the extension is flagged non-critical, use of this extension does not necessarily constrain use of the certificate to the policies listed. However, a certificate user may require a particular policy to be present in order to use the certificate (see 12.4.3). Policy qaulifiers may, at the option of the certirficate user, be processed or ignored.

Certificate policies and certificate policy qualifier types may be defined by any organization with a need. Object identifiers used to identify certificate policies and certificate policy qualifier types shall be assigned in accordance with CCITT Rec. X.660 | ISO/IEC 9834-1. The following ASN.1 object class is used in defining certificate policy qualifier types:

CERT-POLICY-QUALIFIER ::= CLASS {

&id OBJECT IDENTIFIER UNIQUE,

&Qualifier OPTIONAL }

WITH SYNTAX {

POLICY-QUALIFIER-ID &id

[QUALIFIER-TYPE &Qualifier] }

A definition of a policy qualifier type shall include:

— a statement of the semantics of the possible values; and

— an indication of whether the qualifier identifier may appear in a certificate policies extension without an accompanying value and, if so, the implied semantics in such a case.

Note — A qualifier may be specified as having any ASN.1 type. When the qualifier is anticipated to be used primarily with applications that do not have ASN.1 decoding functions, it is recommended that the type OCTET STRING be specified. The ASN.1 OCTET STRING value can then convey a qualifier value encoded according to any convention specified by the policy element defining organization.

12.2.2.6 Policy mappings field

This field, which shall be used in CA-certificates only, allows a certificate issuer to indicate that, for the purposes of the user of a certification path containing this certificate, one of the issuer's certificate policies can be considered equivalent to a different certificate policy used in the subject CA's domain. This field is defined as follows:

policyMappings EXTENSION ::= {

SYNTAX PolicyMappingsSyntax

IDENTIFIED BY id-ce-policyMappings }

PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {

issuerDomainPolicy CertPolicyId,

subjectDomainPolicy CertPolicyId }

The issuerDomainPolicy component indicates a certificate policy that is recognized in the issuing CA’s domain and that can be considered equivalent to the certificate policy indicated in the subjectDomainPolicy component that is recognized in the subject CA’s domain.

This extension is always non-critical.

Notes

1 An example of policy mapping is as follows. The U.S. government domain may have a policy called Canadian Trade and the Canadian government may have a policy called U.S. Trade. While the two policies are distinctly identified and defined, there may be an agreement between the two governments to accept certification paths extending cross-border within the rules implied by these policies for relevant purposes.

2 Policy mapping implies significant administrative overheads and the involvement of suitably diligent and authorized personnel in related decision-making. In general, it is preferable to agree upon more global use of common policies than it is to apply policy mapping. In the above example, it would be preferable for the U.S., Canada, and Mexico to agree upon a common policy for North American Trade.

3 It is anticipated that policy mapping will be practical only in limited environments in which policy statements are very simple.

12.2.2.7 Supported algorithms attribute

A Directory attribute is defined to support the selection of an algorithm for use when communicating with a remote end entity using certificates as defined in this Directory Specification. The following ASN.1 defines this (multi-valued) attribute:

supportedAlgorithms ATTRIBUTE ::= {

WITH SYNTAX SupportedAlgorithm

EQUALITY MATCHING RULE algorithmIdentifierMatch

ID id-at-supportedAlgorithms }

SupportedAlgorithm ::= SEQUENCE {

algorithmIdentifier AlgorithmIdentifier,

intendedUsage [0] KeyUsage OPTIONAL,

intendedCertificatePolicies [1] CertificatePoliciesSyntax OPTIONAL }

Each value of the multi-valued attribute shall have a distinct algorithmIdentifier value. The value of the intendedUsage component provides an indication of the intended usage of the algorithm (see12.2.2.3 for recognized uses). The value of the intendedCertificatePolicies component identifies the certificate policies and, optionally, certificate policy qualifiers with which the identified algorithm may be used.

12.3 Certificate subject and certificate issuer attributes

12.3.1 Requirements

The following requirements relate to certificate subject and certificate issuer attributes:

a) Certificates need to be usable by applications that employ a variety of name forms, including Internet electronic mail names, Internet domain names, X.400 originator/recipient addresses, and EDI party names. It is therefore necessary to be able to securely associate multiple names of a variety of name forms with a certificate subject or a certificate or CRL issuer.

b) A certificate user may need to securely know certain identifying information about a subject in order to have confidence that the subject is indeed the person or thing intended. For example, information such as postal address, position in a corporation, or a picture image may be required. Such information may be conveniently represented as directory attributes, but these attributes are not necessarily part of the distinguished name. A certificate field is therefore needed for conveying additional directory attributes beyond those in the distinguished name.

12.3.2 Certificate and CRL extension fields

The following extension fields are defined:

a) Subject alternative name;

b) Issuer alternative name;

c) Subject directory attributes.

These fields shall be used only as certificate extensions, except for issuer alternative name which may also be used as a CRL extension. As certificate extensions, they may be present in CA-certificates or end-entity certificates.

12.3.2.1 Subject alternative name field

This field contains one or more alternative names, using any of a variety of name forms, for the entity that is bound by the CA to the certified public key. This field is defined as follows:

subjectAltName EXTENSION ::= {

SYNTAX GeneralNames

IDENTIFIED BY id-ce-subjectAltName }

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {

otherName [0] INSTANCE OF OTHER-NAME,

rfc822Name [1] IA5String,

dNSName [2] IA5String,

x400Address [3] ORAddress,

directoryName [4] Name,

ediPartyName [5] EDIPartyName,

uniformResourceIdentifier [6] IA5String,

iPAddress [7] OCTET STRING,

registeredID [8] OBJECT IDENTIFIER }

OTHER-NAME ::= TYPE-IDENTIFIER

EDIPartyName ::= SEQUENCE {

nameAssigner [0] DirectoryString {ub-name} OPTIONAL,

partyName [1] DirectoryString {ub-name} }

The values in the alternatives of the GeneralName type are names of various forms as follows:

— otherName is a name of any form defined as an instance of the OTHER-NAME information object class;

— rfc822Name is an Internet electronic mail address defined in accordance with Internet RFC 822;

— dNSName is an Internet domain name defined in accordance with Internet RFC 1035;

— x400Address is an O/R address defined in accordance with ITU-T Rec. X.411 | ISO/IEC 10021-4;

— directoryName is a directory name defined in accordance with ITU-T Rec. X.501 | ISO/IEC 9594-2;

— ediPartyName is a name of a form agreed between communicating Electronic Data Interchange partners; the nameAssigner component identifies an authority that assigns unique values of names in the partyName component;

— uniformResourceIdentifier is a Uniform Resource Identifier for the World-Wide Web defined in accordance with Internet RFC 1630;

— iPAddress is an Internet Protocol address defined in accordance with Internet RFC 791, represented as a binary string.

— registeredID is an identifier of any registered object assigned in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.

For every name form used in the GeneralName type, there shall be a name registration system that ensures that any name used unambiguously identifies one entity to both certificate issuer and certificate users.

This extension may, at the option of the certificate issuer, be either critical or non-critical. An implementation which supports this extension is not required to be able to process all name forms. If the extension is flagged critical, at least one of the name forms that is present shall be recognized and processed, otherwise the certificate shall be considered invalid. Apart from the preceding restriction, a certificate-using system is permitted to ignore any name with an unrecognized or unsupported name form. It is recommended that, provided the subject field of the certificate contains a directory name that unambiguously identifies the subject, this field be flagged non-critical.

Notes

1 Use of the TYPE-IDENTIFIER class is described in Annexes A and C of ITU-T Rec. X.681 | ISO/IEC 8824-2.

2 If this extension field is present and is flagged critical, the subject field of the certificate may contain a null name (e.g.e.g., a sequence of zero relative distinguished names) in which case the subject is identified only by the name or names in this extension.

12.3.2.2 Issuer alternative name field

This field contains one or more alternative names, using any of a variety of name forms, for the certificate or CRL issuer. This field is defined as follows:

issuerAltName EXTENSION ::= {

SYNTAX GeneralNames

IDENTIFIED BY id-ce-issuerAltName }

This extension may, at the option of the certificate or CRL issuer, be either critical or non-critical. An implementation which supports this extension is not required to be able to process all name forms. If the extension is flagged critical, at least one of the name forms that is present must be recognized and processed, otherwise the certificate or CRL shall be considered invalid. Apart from the preceding restriction, a certificate-using system is permitted to ignore any name with an unrecognized or unsupported name form. It is recommended that, provided the issuer field of the certificate or CRL contains a directory name that unambiguously identifies the issuing authority, this field be flagged non-critical.

Note — If this extension field is present and is flagged critical, the issuer field of the certificate or CRL may contain a null name (e.g.e.g., a sequence of zero relative distinguished names) in which case the issuer is identified only by the name or names in this extension.

12.3.2.3 Subject directory attributes field

This field conveys any desired Directory attribute values for the subject of the certificate. This field is defined as follows:

subjectDirectoryAttributes EXTENSION ::= {

SYNTAX AttributesSyntax

IDENTIFIED BY id-ce-subjectDirectoryAttributes }

AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute

This extension is always non-critical.

12.4 Certification path constraints

12.4.1 Requirements

For certification path processing:

a) End-entity certificates need to be distinguishable from CA-certificates, to protect against end-entities establishing themselves as CAs without authorization. It also needs to be possible for a CA to limit the length of a subsequent chain resulting from a certified subject CA, e.g. to no more than one more certificate or no more than two more certificates.

b) A CA needs to be able to specify constraints which allow a certificate user to check that less-trusted CAs in a certification path (i.e. CAs further down the certification path from the CA with whose public key the certificate user starts) are not violating their trust by issuing certificates to subjects in an inappropriate name space. Adherence to these constraints needs to be automatically checkable by the certificate user.

c) Certification path processing needs to be implementable in an automated, self-contained module. This is necessary to permit trusted hardware or software modules to be implemented which perform the certification path processing functions.

d) It should be possible to implement certification path processing without depending upon real-time interactions with the local user.

e) It should be possible to implement certification path processing without depending upon the use of trusted local databases of policy-description information. (Some trusted local information—an initial public key, at least—is needed for certification path processing but the amount of such information should be minimized.)

f) Certification paths need to operate in environments in which multiple certificate policies are recognized. A CA needs to be able to stipulate which CAs in other domains it trusts and for which purposes. Chaining through multiple policy domains needs to be supported.

g) Complete flexibility in trust models is required. A strict hierarchical model which is adequate for a single organization is not adequate when considering the needs of multiple interconnected enterprises. Flexibility is required in selection of the first trusted CA in a certification path. In particular, it should be possible to require that the certification path start in the local security domain of the public-key user system.

h) Naming structures should not be constrained by the need to use names in certificates, i.e.i.e., Directory name structures considered natural for organizations or geographical areas shall not need adjustment in order to accommodate certification authority requirements.

i) Certificate extension fields need to be backward-compatible with the unconstrained certification path approach system as specified in earlier editions of ITU-T Rec. X.509 | ISO/IEC 9594-8.

j) A CA needs to be able to inhibit use of policy mapping and to require explicit certificate policy identifiers to be present in subsequent certificates in a certification path.

Note — In any certificate-using system, processing of a certification path requires an appropriate level of assurance. This Directory Specification defines functions that may be used in implementations that are required to conform to specific assurance statements. For example, an assurance requirement could state that certification path processing must be protected from subversion of the process (such as software-tampering or data modification). The level of assurance should be commensurate with business risk. For example:

a) processing internal to an appropriate cryptographic module may be required for public keys used to validate high value funds transfer; whereas

b) processing in software may be appropriate for home banking balance inquiries.

Consequently, certification path processing functions should be suitable for implementation in hardware cryptographic modules or cryptographic tokens as one option.

12.4.2 Certificate extension fields

The following extension fields are defined:

a) Basic constraints;

b) Name constraints;

c) Policy constraints.

These extension fields shall be used only as certificate extensions. Name constraints and policy constraints shall be used only in CA-certificates; basic constraints may also be used in end-entity certificates. Examples of the use of these extensions are given in Annex L.

12.4.2.1 Basic constraints field

This field indicates if the subject may act as a CA, with the certified public key being used to verify certificate signatures. If so, a certification path length constraint may also be specified. This field is defined as follows:

basicConstraints EXTENSION ::= {

SYNTAX BasicConstraintsSyntax

IDENTIFIED BY id-ce-basicConstraints }

BasicConstraintsSyntax ::= SEQUENCE {

cA BOOLEAN DEFAULT FALSE,

pathLenConstraint INTEGER (0..MAX) OPTIONAL }

The cA component indicates if the certified public key may be used to verify certificate signatures.

The pathLenConstraint component shall be present only if cA is set to true. It gives the maximum number of CA-certificates that may follow this certificate in a certification path. Value 0 indicates that the subject of this certificate may issue certificates only to end-entities and not to further CAs. If no pathLenConstraint field appears in any certificate of a certification path, there is no limit to the allowed length of the certification path.

This extension may, at the option of the certificate issuer, be either critical or non-critical. It is recommended that it be flagged critical, otherwise an entity which is not authorized to be a CA may issue certificates and a certificate-using system may unwittingly use such a certificate.

If this extension is present and is flagged critical then:

— if the value of cA is not set to true then the certified public key shall not be used to verify a certificate signature;

— if the value of cA is set to true and pathLenConstraint is present then the certificate-using system shall check that the certification path being processed is consistent with the value of pathLenConstraint.

Notes

1 If this extension is not present or is flagged non-critical and is not recognized by a certificate-using system, then that system should use other means to determine if the certified public key may be used to verify certificate signatures.

2 To constrain a certificate subject to being only an end entity, i.e.i.e., not a CA, the issuer can include this extension field containing only an empty SEQUENCE value.

12.4.2.2 Name constraints field

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-nameConstraints }

NameConstraintsSyntax ::= SEQUENCE {

permittedSubtrees [0] GeneralSubtrees OPTIONAL,

excludedSubtrees [1] GeneralSubtrees 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)

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, of all the certificates issued by the subject CA and subsequent CAs in the certification path, only those certificates with 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.

Of the name forms available through the GeneralName type, only those name forms that have a well-defined hierarchical structure may be used in these fields. The directoryName name form satisfies this requirement; when using this name form a naming subtree corresponds to a DIT subtree. Conformant implementations are not required to recognize all possible name forms. If the extension is flagged critical and a certificate-using implementation does not recognize a name form used in any base component, the certificate shall be handled as if an unrecognized critical extension had been encountered. If the extension is flagged non-critical and a certificate-using implementation does not recognize a name form used in any base component, then that subtree specification may be ignored. When a certificate subject has multiple names of the same name form (including, in the case of the directoryName name form, the name in the subject field of the certificate if non-null) then all such names shall be tested for consistency with a name constraint of that name form.

Note — When testing certificate subject names for consistency with a name constraint, names in non-critical subject alternative name extensions should be processed, not ignored.

The minimum field specifies the upper bound of the area within the subtree. All names whose final name component is above the level specified are not contained within the area. A value of minimum equal to zero (the default) corresponds to the base, i.e. the top node of the subtree. For example, if minimum is set to one, then the naming subtree excludes the base node but includes subordinate nodes.

The maximum field specifies the lower bound of the area within the subtree. All names whose last component is below the level specified are not contained within the area. A value of maximum of zero corresponds to the base, i.e. the top of the subtree. An absent maximum component indicates that no lower limit should be imposed on the area within the subtree. For example, if maximum is set to one, then the naming subtree excludes all nodes except the subtree base.

This extension may, at the option of the certificate issuer, be either critical or non-critical. It is recommended that it be flagged critical, otherwise a certificate user may not check that subsequent certificates in a certification path are located in the name space intended by the issuing CA.

If this extension is present and is flagged critical then a certificate-using system shall check that the certification path being processed is consistent with the value in this extension.

12.4.2.3 Policy constraints field

This field specifies constraints which may require explicit certificate policy identification or inhibit policy mapping for the remainder of the certification path. This field is defined as follows:

policyConstraints EXTENSION ::= {

SYNTAX PolicyConstraintsSyntax

IDENTIFIED BY id-ce-policyConstraints }

PolicyConstraintsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {

[0] CertPolicySet OPTIONAL,

requireExplicitPolicy [01] SkipCerts OPTIONAL,

inhibitPolicyMapping [12] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

CertPolicySet ::= SEQUENCE SIZE (1..MAX) OF CertPolicyId

The policySet component indicates those certificate policies to which the constraints apply. If this component is omitted, the constraints apply regardless of policy.

If the requireExplicitPolicy component is present, it indicates that, in all certificates starting from that issued by a nominated CA in the certification path until the end of the certification path, it is necessary for the certificate to contain, in the certificate policies extension, an acceptable policy identifier. An acceptable policy identifier is the identifier of the certificate policy required by the user of the certification path or the identifier of a policy which has been declared equivalent to it through policy mapping. The nominated CA is either the subject CA of the certificate containing this extension (if the value of requireExplicitPolicy is 0) or a CA which is the subject of a subsequent certificate in the certification path (as indicated by a non-zero value).

If the inhibitPolicyMapping component is present, it indicates that, in all certificates starting from a nominated CA in the certification path until the end of the certification path, policy mapping is not permitted. The nominated CA is either the subject CA of the certificate containing this extension (if the value of inhibitPolicyMapping is 0) or a CA which is the subject of a subsequent certificate in the certification path (as indicated by a non-zero value).

A value of type SkipCerts indicates the number of certificates in the certification path to skip before a constraint becomes effective.

This extension may, at the option of the certificate issuer, be either critical or non-critical. It is recommended that it be flagged critical, otherwise a certificate user may not correctly interpret the stipulation of the issuing CA.

12.4.3 Certification path processing procedure

Certification path processing is carried out in a system which needs to use the public key of a remote end entity, e.g. a system which is verifying a digital signature generated by a remote entity. The certificate policies, basic constraints, name constraints, and policy constraints extensions have been designed to facilitate automated, self-contained implementation of certification path processing logic.

Following is an outline of a procedure for validating certification paths. An implementation shall be functionally equivalent to the external behaviour resulting from this procedure. The algorithm used by a particular implementation to derive the correct output(s) from the given inputs is not standardized.

The inputs to the certification path processing procedure are:

a) a set of certificates comprising a certification path;

b) a trusted public key value or key identifier (if the key is stored internally to the certification path processing module), for use in verifying the first certificate in the certification path;

c) an initial-policy-set comprising one or more certificate policy identifiers, indicating that any one of these policies would be acceptable to the certificate user for the purposes of certification path processing; this input can also take the special value any-policy;

d) an initial-explicit-policy indicator value, which indicates if an acceptable policy identifier needs to explicitly appear in the certificate policies extension field of all certificates in the path;

e) an initial-policy-mapping-inhibit indicator value, which indicates if policy mapping is forbidden in the certification path; and

f) the current date/time (if not available internally to the certification path processing module).

The values of c), d), and e) will depend upon the policy requirements of the user-application combination that needs to use the certified end-entity public key.

The outputs of the procedure are:

a) an indication of success or failure of certification path validation;

b) if validation failed, a diagnostic code indicating the reason for failure;

c) if validation was successful, a set of policies constrained by the CAs in the certification path, together with all qualifiers for these policies encountered in the certification path, or the special value any-policy. Unless any-policy is returned, the certificate user shall only use the certificate in accordance with one of the identified policies and shall process all qualifiers for that policy present in the certification path.

d) if validation was successful and c) returned the value any-policy, the set of all policy element qualifiers encountered in the certification path.

e) details of any policy mapping that occurred in processing the certification path.

Note — If validation is successful, the certificate-using system may still choose not to use the certificate as a result of values of policy qualifiers or other information in the certificate.

The procedure makes use of the following set of state variables:

a) user-constrained-policy-set: A set of certificate policy identifiers comprising the policies currently considered acceptable to the certificate user; this state variable can also take the special value any-policy;

b) authority-constrained-policy-set: A set of certificate policy identifiers comprising the set of policies currently considered acceptable to the CAs in the certification path; this state variable can also take the special value any-policy;

c) permitted-subtrees: A set of subtree specifications defining subtrees within which all subject names in subsequent certificates in the certification path must fall, or may take the special value unbounded;

d) excluded-subtrees: A (possibly empty) set of subtree specifications (each comprising a subtree base name and maximum and minimum level indicators) defining subtrees within which no subject name in a subsequent certificate in the certification path may fall;

e) explicit-policy-indicator: Indicates if an acceptable policy needs to be explicitly identified in every certificate;

f) policy-mapping-inhibit-indicator: Indicates if policy mapping is inhibited;

g) pending-constraints: Details of explicit-policy and/or inhibit-policy-mapping constraints which have been stipulated but are yet to take effect. There are two one-bit indicators called explicit-policy-pending, and policy-mapping-inhibit-pending together with, for each, an integer called skip-certificates which gives the number of certificates yet to skip before the constraint takes effect.

The procedure involves an initialization step, followed by a series of certificate-processing steps. The initialization step comprises:

a) Initialize the user-constrained-policy-set variable to the value of initial-policy-set;

b) Initialize the authority-constrained-policy-set variable to the value any-policy;

c) Initialize the permitted-subtrees variable to unbounded;

d) Initialize the excluded-subtrees variable to an empty set;

e) Initialize the explicit-policy-indicator to the initial-explicit-policy value;

f) Initialize the policy-mapping-inhibit-indicator to the initial-policy-mapping-inhibit value;

g) Initialize the two pending-constraints indicators to unset.

Each certificate is then processed in turn, starting with the certificate signed using the input trusted public key. The last certificate is considered to be the end certificate; any other certificates are considered to be intermediate certificates.

The following checks are applied to a certificate:

a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked.

b) For an intermediate certificate, if the basic constraints extension field is present in the certificate, check that the cA component is present and set to true. If the pathLenConstraint component is present, check that the current certification path does not violate that constraint.

c) If explicit-policy-indicator is set and user-constrained-policy-set is not set to any-policy, check that the certificate policies extension is present and that at least one member of user-constrained-policy-set appears in the certificate policies field.

d) If the certificate policies extension is present and is flagged critical, compute the intersection of the policies in that extension and the authority-constrained-policy-set and put the result as the new value of authority-constrained-policy-set. Check that the intersection of authority-constrained-policy-set and user-constrained-policy-set is non-empty.

e) Check that the subject name is within the name-space given by the value of permitted-subtrees and is not within the name-space given by the value of excluded-subtrees.

If any of the above checks fails, the procedure terminates, returning a failure indication and an appropriate reason code. If none of the above checks fails on the end certificate, the procedure terminates, returning a success indication together with the set of policy identifiers from authority-constrained-policy-set, the required policy element qualifiers, and details of any policy mapping that may have occurred.

For an intermediate certificate, the following constraint recording actions are then performed, in order to correctly set up the state variables for the processing of the next certificate:

a) If the nameConstraints extension with a permittedSubtrees component is present in the certificate, set the permitted-subtrees state variable to the intersection of its previous value and the value indicated in the certificate extension.

b) If the nameConstraints extension with an excludedSubtrees component is present in the certificate, set the excluded-subtrees state variable to the union of its previous value and the value indicated in the certificate extension.

c) If explicit-policy-indicator is not set:

— if the explicit-policy-pending indicator is set, decrement the corresponding skip-certificates value and, if this value becomes zero, set explicit-policy-indicator.

— If the requireExplicitPolicy constraint is present in the certificate perform the following. For a SkipCerts value of 0, set explicit-policy-indicator. For any other SkipCerts value, set the explicit-policy-pending indicator, and set the corresponding skip-certificates value to the lesser of the SkipCerts value and the previous skip-certificates value (if the explicit-policy-pending indicator was already set).

e) If policy-mapping-inhibit-indicator is not set:

— process any policy mapping extension with respect to policies in the user-constrained-policy-set and add appropriate policy identifiers to the user-constrained-policy-set .

— process any policy mapping extension with respect to policies in the authority-constrained-policy-set and add appropriate policy identifiers to the authority-constrained-policy-set .

— if the policy-mapping-inhibit-pending indicator is set, decrement the corresponding skip-certificates value and, if this value becomes zero, set the policy-mapping-inhibit-indicator.

— If the inhibitPolicyMapping constraint is present in the certificate, perform the following. For a SkipCerts value of 0, set the policy-mapping-inhibit-indicator. For any other SkipCerts value, set the policy-mapping-inhibit-pending indicator, and set the corresponding skip-certificates value to the lesser of the SkipCerts value and the previous skip-certificates value (if the policy-mapping-inhibit-pending indicator was already set).

12.4.3 Certification path processing procedure

Certification path processing is carried out in a system which needs to use the public key of a remote end entity, e.g., a system which is verifying a digital signature generated by a remote entity. The certificate policies, basic constraints, name constraints, and policy constraints extensions have been designed to facilitate automated, self-contained implementation of certification path processing logic.

The inputs to the certification path processing procedure are:

a) a set of certificates comprising a certification path;

b) a trusted public key value or key identifier and associated public key parameters (if the key is stored internally to the certification path processing module), for use in verifying the first certificate in the certification path;

c) an initial-policy-set comprising identifiers of one or more certificate policies that are recognized in the domain of the certificate user and that would be acceptable to the certificate user for the purposes of certification path processing; this input can also take the special value any-policy;

e) an initial-policy-mapping-inhibit indicator value, which indicates if policy mapping is forbidden in the certification path; and

f) the current date/time (if not available internally to the certification path processing module).

The values of c), d), and e) will depend upon the policy requirements of the user-application combination that needs to use the certified end-entity public key.

The outputs of the procedure are:

a) an indication of success or failure of certification path validation;

b) if validation failed, a diagnostic code indicating the reason for failure;

c) if validation was successful, an indication of whether any CAs in the certification path require their certificates to be used only in accordance with particular certification policies; if so, the set of acceptable policies is output and the certificate user shall only use the certificates in accordance with one of the identified policies and shall process all qualifiers for that policy present in the certification path;

d) for each certificate policy considered acceptable to the certificate user and to all certification authorities in the certification path, the set of associated policy qualifiers;

e) details of any policy mapping that occurred in processing the certification path.

Note — If validation is successful, the certificate-using system may still choose not to use the certificate as a result of values of policy qualifiers or other information in the certificate.

The procedure makes use of the following set of state variables:

a) acceptable-policy-set: A set of certificate policy identifiers comprising the policies considered acceptable to the certificate user and to the CAs whose certificates have been processed thus far in certification path processing; this state variable can also take the special value any-policy;

b) mandated-policy-indicator: An indicator whether or not any CA in the certification path has mandated that the certification path only be used in accordance with one of the policies in acceptable-policy-set;

c) permitted-subtrees: A set of subtree specifications (each comprising a subtree base name and maximum and minimum level indicators) defining subtrees within which all subject names in subsequent certificates in the certification path must fall, or may take the special value unbounded;

e) explicit-policy-indicator: Indicates if an acceptable policy needs to be explicitly identified in every certificate;

f) policy-mapping-inhibit-indicator: Indicates if policy mapping is inhibited;

The procedure involves an initialization step, followed by a series of certificate-processing steps. The initialization step comprises:

a) Initialize the acceptable-policy-set variable to the value of initial-policy-set;

b) Initialize the mandated-policy-indicator to unset;

c) Initialize the permitted-subtrees variable to unbounded;

d) Initialize the excluded-subtrees variable to an empty set;

e) Initialize the explicit-policy-indicator to the initial-explicit-policy value;

f) Initialize the policy-mapping-inhibit-indicator to the initial-policy-mapping-inhibit value;

g) Initialize the two pending-constraints indicators to unset.

The following checks are applied to a certificate:

a) Check that the signature verifies, that dates are valid, that the certificate subject and certificate issuer names chain correctly, and that the certificate has not been revoked.

b) For an intermediate certificate, if the basic constraints extension field is present in the certificate, check that the cA component is present and is set to true. If the pathLenConstraint component is present, check that the current certification path does not violate that constraint.

c) If explicit-policy-indicator is set and acceptable-policy-set is not set to any-policy, check that the certificate policies extension is present and that at least one member of acceptable-policy-set appears in the certificate policies field.

d) If the certificate policies extension is present and is flagged critical, set mandated-policy-indicator, compute the intersection of the policies in that extension and the acceptable-policy-set, and store the result in acceptable-policy-set; check that the resultant set is non-empty.

e) Check that the subject name is within the name-space given by the value of permitted-subtrees and is not within the name-space given by the value of excluded-subtrees.

If any of the above checks fails, the procedure terminates, returning a failure indication and an appropriate reason code. If none of the above checks fails on the end certificate, the procedure terminates, returning a success indication together with the value of mandated-policy-indicator, the set of policy identifiers from acceptable-policy-set, and the set of policy element qualifiers encountered.

For an intermediate certificate, the following constraint recording actions are then performed, in order to correctly set up the state variables for the processing of the next certificate:

c) If explicit-policy-indicator is not set:

— if the explicit-policy-pending indicator is set, decrement the corresponding skip-certificates value and, if this value becomes zero, set explicit-policy-indicator.

e) If policy-mapping-inhibit-indicator is not set:

— process any policy mapping extension with respect to policies in the acceptable-policy-set and add appropriate policy identifiers to the acceptable-policy-set; preserve details of the mapping, to be output at the end of the procedure, if successful;

— if the policy-mapping-inhibit-pending indicator is set, decrement the corresponding skip-certificates value and, if this value becomes zero, set the policy-mapping-inhibit-indicator.

12.5 Basic CRL extensions

12.5.1 Requirements

The following requirements relate to CRLs:

a) Certificate users need to be able to track all CRLs issued from a CRL issuer or CRL distribution point (see 12.6) and be able to detect a missing CRL in the sequence. CRL sequence numbers are therefore required.

b) Some CRL users may wish to respond differently to a revocation, depending upon the reason for the revocation. There is therefore a requirement for a CRL entry to indicate the reason for revocation.

c) There is a requirement for a CA to be able to temporarily suspend validity of a certificate and subsequently either revoke or reinstate it. Possible reasons for such an action include:

— desire to reduce liability for erroneous revocation when a revocation request is unauthenticated and there is inadequate information to determine whether it is valid;

— other business needs, such as temporarily disabling the certificate of an entity pending an audit or investigation.

d) A CRL contains, for each revoked certificate, the date when the CA posted the revocation. Further information may be known as to when an actual or suspected key compromise occured, and this information may be valuable to a certificate user. The revocation date is insufficient to solve some disputes because, assuming the worst, all signatures issued during the validity period of the certificate have to be considered invalid. However, it may be important for a user that a signed document be recognized as valid even though the key used to sign the message was compromised after the signature was produced. To assist in solving this problem, a CRL entry can include a second date which indicates when it was known or suspected that the private key was compromised.

12.5.2 CRL and CRL entry extension fields

The following extension fields are defined:

a) CRL number;

b) Reason code;

c) Hold instruction code;

d) Invalidity date.

The CRL number field shall be used only as a CRL extension field and the other fields shall be used only as CRL entry extension fields.

12.5.2.1 CRL number field

This CRL extension field conveys a monotonically increasing sequence number for each CRL issued by a given CRL issuer through a given CA directory attribute or CRL distribution point. It allows a CRL user to detect whether CRLs issued prior to the one being processed were also seen and processed. This field is defined as follows:

cRLNumber EXTENSION ::= {

SYNTAX CRLNumber

IDENTIFIED BY id-ce-cRLNumber }

CRLNumber ::= INTEGER (0..MAX)

This extension is always non-critical.

12.5.2.2 Reason code field

This CRL entry extension field identifies a reason for the certificate revocation. The reason code may be used by applications to decide, based on local policy, how to react to posted revocations. This field is defined as follows:

reasonCode EXTENSION ::= {

SYNTAX CRLReason

IDENTIFIED BY id-ce-reasonCode }

CRLReason ::= ENUMERATED {

unspecified (0),

keyCompromise (1),

cACompromise (2),

affiliationChanged (3),

superseded (4),

cessationOfOperation (5),

certificateHold (6),

removeFromCRL (8) }

The following reason code values indicate why a certificate was revoked:

— keyCompromise is used in revoking an end-entity certificate; it indicates that it is known or suspected that the subject’s private key, or other aspects of the subject validated in the certificate, have been compromised;

— cACompromise is used in revoking a CA-certificate; it indicates that it is known or suspected that the subject’s private key, or other aspects of the subject validated in the certificate, have been compromised;

— affiliationChanged indicates that the subject’s name or other information in the certificate has been modified but there is no cause to suspect that the private key has been compromised;

— superseded indicates that the certificate has been superseded but there is no cause to suspect that the private key has been compromised;

— cessationOfOperation indicates that the certificate is no longer needed for the purpose for which it was issued but there is no cause to suspect that the private key has been compromised;

A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold notice may include an optional hold instruction code to convey additional information to certificate users (see 12.5.2.3). Once a hold has been issued, it may be handled in one of three ways:

a) remain on the CRL with no further action, causing users to reject transactions issued during the hold period;

b) be replaced by a (final) revocation for the same certificate, in which case the reason shall be one of the standard reasons for revocation, and the optional instruction code extension field shall not appear, or

c) be explicitly released and the entry removed from the CRL.

The removeFromCRL reason code is for use with delta-CRLs (see 12.6) only and indicates that an existing CRL entry should now be removed owing to certificate expiration or hold release. An entry with this reason code shall be used in delta-CRLs for which the corresponding base CRL contains an entry for the same certificate with reason code certificateHold.

This extension is always non-critical.

12.5.2.3 Hold instruction code field

This CRL entry extension field provides for inclusion of a registered instruction identifier to indicate the action to be taken on encountering a held certificate. It is applicable only in an entry having a certificateHold reason code. This field is defined as follows:

holdInstructionCode EXTENSION ::= {

SYNTAX HoldInstruction

IDENTIFIED BY id-ce-instructionCode }

HoldInstruction ::= OBJECT IDENTIFIER

This extension is always non-critical. No standard hold instruction codes are defined in this Directory Specification.

Note — Examples of hold instructions might be "please communicate with the CA" or "repossess the user’s token."

12.5.2.4 Invalidity date field

This CRL entry extension field indicates the date at which it is known or suspected that the private key was compromised or that the certificate should otherwise be considered invalid. This date may be earlier than the revocation date in the CRL entry, which is the date at which the CA processed the revocation. This field is defined as follows:

invalidityDate EXTENSION ::= {

SYNTAX GeneralizedTime

IDENTIFIED BY id-ce-invalidityDate }

This extension is always non-critical.

Notes

1 The date in this extension is not, by itself, sufficient for nonrepudiation purposes. For example, this date may be a date advised by the private key holder, and it is possible for such a person to fraudulently claim that a key was compromised some time in the past, in order to repudiate a validly-generated signature.

2 When a revocation is first posted by a CA in a CRL, the invalidity date may precede the date of issue of earlier CRLs. The revocation date should not precede the date of issue of earlier CRLs.

12.6 CRL distribution points and delta-CRLs

12.6.1 Requirements

As it is possible for revocation lists to become large and unwieldy, the ability to represent partial CRLs is required. Different solutions are needed for two different types of implementations that process CRLs.

The first type of implementation is in individual workstations, possibly in an attached cryptographic token. These implementations are likely to have limited, if any, trusted storage capacity. Therefore the entire CRL must be examined to determine if it is valid, and then to see if the certificate is valid. This processing could be lengthy if the CRL is long. Partitioning of CRLs is required to eliminate this problem for these implementations.

The second type of implementation is on high performance servers where a large volume of messages is processed, e.g. a transaction processing server. In this environment CRLs are typically processed as a background task where, after the CRL is validated, the contents of the CRL are stored locally in a representation which expedites their examination, e.g.e.g., one bit for each certificate indicating if it has been revoked. This representation is held in trusted storage. This type of server will typically require up-to-date CRLs for a large number of CAs. Since it already has a list of previously revoked certificates, it only needs to retrieve a list of newly revoked certificates. This list, called a delta-CRL, will be smaller and require fewer resources to retrieve and process than a complete CRL.

The following requirements therefore relate to CRL distribution points and delta-CRLs:

a) In order to control CRL sizes, it needs to be possible to assign subsets of the set of all certificates issued by one CA to different CRLs. This can be achieved by associating every certificate with a CRL distribution point which is either:

— a Directory entry whose CRL attribute will contain a revocation entry for that certificate, if it has been revoked; or

— a location such as an electronic mail address or Internet Uniform Resource Identifier from which the applicable CRL can be obtained.

b) For performance reasons, it is desirable to reduce the number of CRLs that need to be checked when validating multiple certficiates, e.g.e.g., a certification path. This can be achieved by having one CRL issuer sign and issue CRLs containing revocations from multiple CAs.

c) There is a requirement for separate CRLs covering revoked CA-certificates and revoked end-entity certificates. This facilitates processing of certification paths as the CRL for revoked CA-certificates can be expected to be very short (usually empty). The authorityRevocationList and certificateRevocationList attributes have been specified for this purpose. However, for this separation to be secure, it is necessary to have an indicator in a CRL identifying which list it is. Otherwise, illegitimate substitution of one list for the other cannot be detected.

d) Provision is needed for a different CRL to exist for potential compromise situations (when there is a significant risk of private key misuse) than that including all routine binding terminations (when there is no significant risk of private key misuse).

e) Provision is also needed for partial CRLs (known as delta-CRLs) which only contain entries for certificates that have been revoked since the issuance of a base CRL.

f) While requirements a) through e) may lead to optional revocation mechanisms, every CA shall, as a common fall-back approach, issue complete CRLs covering all certificates it issues.

12.6.2 Certificate extension fields

The CRL distribution points extension shall be used only as a certificate extension and may be used in both CA-certificates and end-entity certificates. This field identifies the CRL distribution point or points to which a certificate user should refer to ascertain if the certificate has been revoked. A certificate user can obtain a CRL from an applicable distribution point or it can obtain a current complete CRL from the CA directory entry. This field is defined as follows:

cRLDistributionPoints EXTENSION ::= {

SYNTAX CRLDistPointsSyntax

IDENTIFIED BY id-ce-cRLDistributionPoints }

CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {

distributionPoint [0] DistributionPointName OPTIONAL,

reasons [1] ReasonFlags OPTIONAL,

cRLIssuer [2] GeneralNames OPTIONAL }

DistributionPointName ::= CHOICE {

fullName [0] GeneralNames,

nameRelativeToCRLIssuer [1] RelativeDistinguishedName }

ReasonFlags ::= BIT STRING {

unused (0),

keyCompromise (1),

cACompromise (2),

affiliationChanged (3),

superseded (4),

cessationOfOperation (5),

certificateHold (6) }

The distributionPoint component identifies the location from which the CRL can be obtained. If this component is absent, the distribution point name defaults to the CRL issuer name.

When the fullName alternative is used or when the default applies, the distribution point name may have multiple name forms. The same name, in at least one of its name forms, shall be present in the distributionPoint field of the issuing distribution point extension of the CRL. A certificate-using system is not required to be able to process all name forms. It may use a distribution point provided at least one name form can be processed. If no name forms for a distribution point can be processed, a certificate-using system can still use the certificate provided requisite revocation information can be obtained from another source, e.g.e.g., another distribution point or the CA’s directory entry.

The nameRelativeToCRLIssuer component can be used only if the CRL distribution point is assigned a directory name that is directly subordinate to the directory name of the CRL issuer. In this case, the nameRelativeToCRLIssuer component conveys the relative distinguished name with respect to the CRL issuer directory name.

The reasons component indicates the revocation reasons covered by this CRL. If the reasons component is absent, the corresponding CRL distribution point distributes a CRL which will contain an entry for this certificate if this certificate has been revoked, regardless of revocation reason. Otherwise, the reasons value indicates which revocation reasons are covered by the corresponding CRL distribution point.

The cRLIssuer component identifies the authority that issues and signs the CRL. If this component is absent, the CRL issuer name defaults to the certificate issuer name.

This extension may, at the option of the certificate issuer, be either critical or non-critical. In the interests of interoperability, it is recommended that it be flagged non-critical. If the CRL distribution point extension is made critical, the CA shall ensure that the distribution points cover reason codes keyCompromise and/or cACompromise whichever is applicable.

If this extension is flagged critical then a certificate-using system shall not use the certificate without first retrieving and checking a CRL from one of the nominated distribution points covering, at a minimum, the reason code keyCompromise (for an end-entity certificate) or cACompromise (for a CA-certificate).

If this extension is flagged non-critical and a certificate-using system does not recognize the extension field type, then that system should only use the certificate if:

— it can acquire and check a complete CRL from the CA (that the latter CRL is complete is indicated by the absence of an issuing distribution point extension field in the CRL);

— revocation checking is not required under local policy; or

— revocation checking is accomplished by other means.

Note — It is possible to have CRLs issued by more than one CRL issuer for the one certificate. Coordination of these CRL issuers and the issuing CA is an aspect of CA policy.

12.6.3 CRL and CRL entry extension fields

The following CRL or CRL entry extension fields are defined:

a) Issuing distribution point;

b) Certificate issuer;

c) Delta CRL indicator.

Issuing distribution point and delta CRL indicator shall be used only as CRL extensions. Certificate issuer shall be used only as a CRL entry extension.

12.6.3.1 Issuing distribution point field

This CRL extension field identifies the CRL distribution point for this particular CRL, and indicates if the CRL is limited to revocations for end-entity certificates only, for CA-certificates only, or for a limited set of reasons only. The CRL is signed by the CRL issuer’s key — CRL distribution points do not have their own key pairs. However, for a CRL distributed via the Directory, the CRL is stored in the entry of the CRL distribution point, which may not be the directory entry of the CRL issuer. This field is defined as follows:

issuingDistributionPoint EXTENSION ::= {

SYNTAX IssuingDistPointSyntax

IDENTIFIED BY id-ce-issuingDistributionPoint }

IssuingDistPointSyntax ::= SEQUENCE {

distributionPoint [0] DistributionPointName OPTIONAL,

onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,

onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,

onlySomeReasons [3] ReasonFlags OPTIONAL,

indirectCRL [4] BOOLEAN DEFAULT FALSE }

The distributionPoint component contains the name of the distribution point in one or more name forms. If this field is absent, the CRL shall contain entries for all revoked unexpired certificates issued by the CRL issuer.

If onlyContainsUserCerts is true, the CRL only contains revocations for end-entity certificates. If onlyContainsCACerts is true, the CRL only contains revocations for CA-certificates. If onlySomeReasons is present, the CRL only contains revocations for the identified reason or reasons, otherwise the CRL contains revocations for all reasons.

If indirectCRL is true, then the CRL may contain revocation notifications from CAs other than the issuer of the CRL. The particular CA responsible for each entry is as indicated by the certificate issuer CRL entry extension in that entry or in accordance with the defaulting rules described in 12.6.3.2. In such a CRL, it is the responsibility of the CRL issuer to ensure that the CRL is complete in that it contains all revocation entries, consistent with onlyContainsUserCerts, onlyContainsCACerts, and onlySomeReasons indicators, from all CAs that identify this CRL issuer in their certificates.

For CRLs distributed via the Directory, the following rules regarding use of attributes apply. A CRL which has onlyContainsCACerts set shall be distributed via the authorityRevocationList attribute of the associated distribution point or, if no distribution point is identified, via the authorityRevocationList attribute of the CRL issuer entry. Otherwise the CRL shall be distributed via the certificateRevocationList attribute of the associated distribution point or, if no distribution point is identified, via the certificateRevocationList attribute of the CA entry.

This extension is always critical. A certificate user which does not understand this extension cannot assume that the CRL contains a complete list of revoked certificates of the identified CA. CRLs not containing critical extensions must contain all current CRL entries for the issuing CA, including entries for all revoked user certificates and CA certificates.

Notes

1 The means by which revocation information is communicated by CAs to CRL issuers is beyond the scope of this standard.

2 If a CA issues, from its own directory entry (i.e.i.e., not from a separately-named CRL distribution point), a CRL with onlyContainsUserCerts or onlyContainsCACerts set, then the CA should ensure that all certificates covered by this CRL contain the basicConstraints extension.

12.6.3.2 Certificate issuer field

This CRL entry extension identifies the certificate issuer associated with an entry in an indirect CRL, i.e.i.e., a CRL that has the indirectCRL indicator set in its issuing distribution point extension. If this extension is not present on the first entry in an indirect CRL, the certificate issuer defaults to the CRL issuer. On subsequent entries in an indirect CRL, if this extension is not present, the certificate issuer for the entry is the same as that for the preceding entry. This field is defined as follows:

certificateIssuer EXTENSION ::= {

SYNTAX GeneralNames

IDENTIFIED BY id-ce-certificateIssuer }

This extension is always critical. If an implementation ignored this extension it could not correctly attribute CRL entries to certificates.

12.6.3.3 Delta CRL indicator field

This CRL extension field identifies a CRL as being a delta-CRL only. This field is defined as follows:

deltaCRLIndicator EXTENSION ::= {

SYNTAX BaseCRLNumber

IDENTIFIED BY id-ce-deltaCRLIndicator }

BaseCRLNumber ::= CRLNumber

The value of type BaseCRLNumber identifies the CRL number of the base CRL that was used as the starting point in the generation of this delta-CRL, i.e. this delta-CRL contains the changes between the base CRL and the complete CRL issued along with this delta-CRL. It is the decision of a CA as to whether to provide delta-CRLs. However, a delta-CRL shall not be issued without a corresponding complete CRL being issued at the same time. The value of the CRL number, as conveyed in the CRL number extension field (if present), shall be identical for both the delta-CRL and the corresponding complete CRL.

The CRL user constructing a locally held CRL from delta-CRLs shall consider the constructed CRL incomplete and unusable if both the following conditions are true:

— the value of the CRLNumber of the received delta-CRL is more than one greater than that of the CRLNumber of the delta-CRL last processed; and

— the value of BaseCRLNumber of the received delta-crl has changed from the BaseCRLNumber of the delta-CRL last processed.

This extension is always critical. A certificate user that does not understand the use of delta-CRLs should not use a CRL containing this extension, as the CRL may not be as complete as the user expects. CRLs not containing critical extensions must contain all current CRL entries for the issuing CA, including entries for all revoked user certificates and CA certificates.

Note—It is the decision of the CA as to whether or not to distribute the CRLs issued between two base CRLs. For example, it may be the policy of the CA to distribute base CRLs via CD-ROM and delta-CRLs via an on-line service such as the Directory. Although the CA had issued its CRL with the associated delta-CRL, it may be the CA’s policy that the user shall construct the current CRL by applying the delta-CRL to the base CRL held on the CD-ROM.

12.6.4 Attribute type for delta-CRLs

The following attribute type is defined for holding a delta-CRL in a CA directory entry:

deltaRevocationList ATTRIBUTE ::= {

WITH SYNTAX CertificateList

EQUALITY MATCHING RULE certificateListExactMatch

ID id-at-deltaRevocationList }

12.7 Matching rules

This Directory Specification defines matching rules for use with attributes of type Certificate, CertificatePair, CertificateList, and SupportedAlgorithm, respectively.

12.7.1 Certificate exact match

The certificate exact match rule compares for equality a presented value with an attribute value of type Certificate. It uniquely selects a single certificate.

certificateExactMatch MATCHING-RULE ::= {
SYNTAX CertificateExactAssertion
ID id-mr-certificateExactMatch }

CertificateExactAssertion ::= SEQUENCE {

serialNumber CertificateSerialNumber,

issuer Name }

This matching rule returns TRUE if the components in the attribute value match those in the presented value.

12.7.2 Certificate match

The certificate match rule compares a presented value with an attribute value of type Certificate. It selects one or more certificates on the basis of various characteristics.

certificateMatch MATCHING-RULE ::= {
SYNTAX CertificateAssertion
ID id-mr-certificateMatch }

CertificateAssertion ::= SEQUENCE {

serialNumber [0] CertificateSerialNumber OPTIONAL,

issuer [1] Name OPTIONAL,

subjectKeyIdentifier [2] SubjectKeyIdentifier OPTIONAL,

authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL,

certificateValid [4] UTCTime OPTIONAL,

privateKeyValid [5] GeneralizedTime OPTIONAL,
subjectPublicKeyAlgID [6] OBJECT IDENTIFIER OPTIONAL,
keyUsage [7] KeyUsage OPTIONAL,
subjectAltName [8] AltNameType OPTIONAL,
policy [9] CertPolicySet OPTIONAL,
pathToName [10] Name OPTIONAL }

AltNameType ::= CHOICE {

builtinNameForm ENUMERATED {

rfc822Name (1),

dNSName (2),

x400Address (3),

directoryName (4),

ediPartyName (5),

uniformResourceIdentifier (6),

iPAddress (7),

registeredId (8) },

otherNameForm OBJECT IDENTIFIER }

This matching rule returns TRUE if all of the components that are present in the presented value match the corresponding components of the attribute value, as follows:

a) serialNumber matches if the value of this component in the attribute value equals that in the presented value;

b) issuer matches if the value of this component in the attribute value equals that in the presented value;

c) subjectKeyIdentifier matches if the value of this component in the stored attribute value equals that in the presented value; there is no match if the stored attribute value contains no subject key identifier extension;

d) authorityKeyIdentifier matches if the value of this component in the stored attribute value equals that in the presented value; there is no match if the stored attribute value contains no authority key identifier extension or if not all components in the presented value are present in the stored attribute value;

e) certificateValid matches if the presented value falls within the validity period of the stored attribute value;

f) privateKeyValid matches if the presented value falls within the period indicated by the private key usage period extension of the stored attribute value or if there is no private key usage period extension in the stored attribute value;

g) subjectPublicKeyAlgID matches if it is equal to the algorithm component of the algorithmIdentifier of the subjectPublicKeyInformation component of the stored attribute value;

h) keyUsage matches if all of the bits set in the presented value are also set in the key usage extension in the stored attribute value, or if there is no key usage extension in the stored attribute value;

i) subjectAltName matches if the stored attribute value contains the subject alternative name extension with an AltNames component of the same name type as indicated in the presented value;

j) policy matches if all of the policy elements identified in one of the presented values are contained in the set of policyElementIds in any of the policyInformation values in the certificate policies extension in the stored attribute value; there is no match if there is no certificate policies extension in the stored attribute value;

k) pathToName matches unless the certificate has a name constraints extension which inhibits the construction of a certification path to the presented name value.

12.7.3 Certificate pair exact match

The certificate pair exact match rule compares for equality a presented value with an attribute value of type CertificatePair. It uniquely selects a single cross-certificate pair.

certificatePairExactMatch MATCHING-RULE ::= {
SYNTAX CertificatePairExactAssertion
ID id-mr-certificatePairExactMatch }

CertificatePairExactAssertion ::= SEQUENCE {

forwardAssertion [0] CertificateExactAssertion OPTIONAL,

reverseAssertion [1] CertificateExactAssertion OPTIONAL }

( WITH COMPONENTS {..., forwardAssertion PRESENT} |

WITH COMPONENTS {..., reverseAssertion PRESENT} )

This matching rule returns TRUE if the components that are present in the forwardAssertion and reverseAssertion components of the presented value match the corresponding components of the forward and reverse components, respectively, in the stored attribute value.

12.7.4 Certificate pair match

The certificate pair match rule compares a presented value with an attribute value of type CertificatePair. It selects one or more cross-certificate pairs on the basis of various characteristics of either the forward or reverse certificate of the pair.

certificatePairMatch MATCHING-RULE ::= {
SYNTAX CertificatePairAssertion
ID id-mr-certificatePairMatch }

CertificatePairAssertion ::= SEQUENCE {

forwardAssertion [0] CertificateAssertion OPTIONAL,

reverseAssertion [1] CertificateAssertion OPTIONAL }

( WITH COMPONENTS {..., forwardAssertion PRESENT} |

WITH COMPONENTS {..., reverseAssertion PRESENT} )

This matching rule returns TRUE if all of the components that are present in the forwardAssertion and reverseAssertion components of the presented value match the corresponding components of the forward and reverse components, respectively, in the stored attribute value, using the rules given in 12.7.2.

12.7.5 Certificate list exact match

The certificate list exact match rule compares for equality a presented value with an attribute value of type CertificateList. It uniquely selects a single CRL.

certificateListExactMatch MATCHING-RULE ::= {
SYNTAX CertificateListExactAssertion
ID id-mr-certificateListExactMatch }

CertificateListExactAssertion ::= SEQUENCE {

issuer Name,

thisUpdate UTCTime,

distributionPoint DistributionPointName OPTIONAL }

The rule returns TRUE if the components in the stored attribute value match those in the presented value. If the distributionPoint component is present then it must match in at least one name form.

12.7.6 Certificate list match

The certificate list match rule compares a presented value with an attribute value of type CertificateList. It selects one or more CRLs on the basis of various characteristics.

certificateListMatch MATCHING-RULE ::= {

SYNTAX CertificateListAssertion
ID id-mr-certificateListMatch }

CertificateListAssertion ::= SEQUENCE {

issuer Name OPTIONAL,

minCRLNumber [0] CRLNumber OPTIONAL,
maxCRLNumber [1] CRLNumber OPTIONAL,
reasonFlags ReasonFlags OPTIONAL,
dateAndTime UTCTime OPTIONAL,

distributionPoint [2] DistributionPointName OPTIONAL }

The matching rule returns TRUE if all of the components that are present in the presented value match the corresponding components of the stored attribute value, as follows:

a) issuer matches if the value of this component in the attribute value equals that in the presented value;

b) minCRLNumber matches if its value is less than or equal to the value in the CRL number extension of the stored attribute value; there is no match if the stored attribute value contains no CRL number extension;

c) maxCRLNumber matches if its value is greater than or equal to the value in the CRL number extension of the stored attribute value; there is no match if the stored attribute value contains no CRL number extension;

d) reasonFlags matches if any of the bits that are are set in the presented value are also set in the onlySomeReasons components of the issuing distribution point extension of the stored attribute value; there is no match if the stored attribute value contains no issuing distribution point extension;

e) dateAndTime matches if the value is equal to or later than the value in the thisUpdate component of the stored attribute value and is earlier than the value in the nextUpdate component of the stored attribute value; there is no match if the stored attribute value contains no nextUpdate component;

f) distributionPoint matches if the stored attribute value contains an issuing distribution point extension and the value of this component in the presented value equals the corresponding value, in at least one name form, in that extension.

12.7.7 Algorithm identifier match

The algorithm identifier match rule compares for equality a presented value with an attribute value of type SupportedAlgorithm.

algorithmIdentifierMatch MATCHING-RULE ::= {
SYNTAX AlgorithmIdentifier
ID id-mr-algorithmIdentifierMatch }

The rule returns TRUE if the presented value is equal to the algorithmIdentifier component of the stored attribute value.

This completes the new clause 12.

Annex A: Authentication Framework in ASN.1

Change the introductory paragraph to:

This annex includes all of the ASN.1 type, value, and information object class definitions contained in this Directory Specification, in the form of the two ASN.1 modules AuthenticationFramework and CertificateExtensions.

In the ASN.1 ATTRIBUTE object definition for userCertificate insert, after the WITH SYNTAX line, the line:

EQUALITY MATCHING RULE certificateExactMatch

In the ASN.1 ATTRIBUTE object definition for cACertificate insert, after the WITH SYNTAX line, the line:

EQUALITY MATCHING RULE certificateExactMatch

In the ASN.1 ATTRIBUTE object definition for crossCertificatePair insert, after the WITH SYNTAX line, the line:

EQUALITY MATCHING RULE certificatePairExactMatch

In the ASN.1 ATTRIBUTE object definition for certificateRevocationList insert, after the WITH SYNTAX line, the line:

EQUALITY MATCHING RULE certificateListExactMatch

In the ASN.1 ATTRIBUTE object definition for authorityRevocationList insert, after the WITH SYNTAX line, the line:

EQUALITY MATCHING RULE certificateListExactMatch

At the end of the annex, add the following:

CertificateExtensions {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0}

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS

id-at, id-ce, id-mr, informationFramework, authenticationFramework,

selectedAttributeTypes, upperBounds

FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1)

usefulDefinitions(0) 2}

Name, RelativeDistinguishedName, ATTRIBUTE, Attribute,

MATCHING-RULE FROM InformationFramework informationFramework

CertificateSerialNumber, CertificateList, AlgorithmIdentifier,

EXTENSION

FROM AuthenticationFramework authenticationFramework

DirectoryString

FROM SelectedAttributeTypes selectedAttributeTypes

ub-name

FROM UpperBounds upperBounds

ORAddress

FROM MTSAbstractService {joint-iso-ccitt mhs(6) mts(3)

modules(0) mts-abstract-service(1) version-1994 (0) } ;

-- Unless explicitly noted otherwise, there is no significance to the ordering

-- of components of a SEQUENCE OF construct in this specification.

-- Key and policy information extensions --

authorityKeyIdentifier EXTENSION ::= {

SYNTAX AuthorityKeyIdentifier

IDENTIFIED BY { id-ce 35 } }

AuthorityKeyIdentifier ::= SEQUENCE {

keyIdentifier [0] KeyIdentifier OPTIONAL,

authorityCertIssuer [1] GeneralNames OPTIONAL,

authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }

( WITH COMPONENTS {..., authorityCertIssuer PRESENT,

authorityCertSerialNumber PRESENT} |

WITH COMPONENTS {..., authorityCertIssuer ABSENT,

authorityCertSerialNumber ABSENT} )

KeyIdentifier ::= OCTET STRING

subjectKeyIdentifier EXTENSION ::= {

SYNTAX SubjectKeyIdentifier

IDENTIFIED BY id-ce-subjectKeyIdentifier }

SubjectKeyIdentifier ::= KeyIdentifier

keyUsage EXTENSION ::= {

SYNTAX KeyUsage

IDENTIFIED BY id-ce-keyUsage }

KeyUsage ::= BIT STRING {

digitalSignature (0),

nonRepudiation (1),

keyEncipherment (2),

dataEncipherment (3),

keyAgreement (4),

keyCertSign (5),

cRLSign (6) }

privateKeyUsagePeriod EXTENSION ::= {

SYNTAX PrivateKeyUsagePeriod

IDENTIFIED BY id-ce-privateKeyUsagePeriod }

PrivateKeyUsagePeriod ::= SEQUENCE {

notBefore [0] GeneralizedTime OPTIONAL,

notAfter [1] GeneralizedTime OPTIONAL }

( WITH COMPONENTS {..., notBefore PRESENT} |

WITH COMPONENTS {..., notAfter PRESENT} )

certificatePolicies EXTENSION ::= {

SYNTAX CertificatePoliciesSyntax

IDENTIFIED BY id-ce-certificatePolicies }

CertificatePoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

PolicyInformation ::= SEQUENCE {

policyIdentifier CertPolicyId,

policyQualifiers SEQUENCE SIZE (1..MAX) OF

PolicyQualifierInfo OPTIONAL }

CertPolicyId ::= OBJECT IDENTIFIER

PolicyQualifierInfo ::= SEQUENCE {

policyQualifierId CERT-POLICY-QUALIFIER.&id

({SupportedPolicyQualifiers}),

qualifier CERT-POLICY-QUALIFIER.&Qualifier

({SupportedPolicyQualifiers}{@policyQualifierId})

OPTIONAL }

SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { ... }

CERT-POLICY-QUALIFIER ::= CLASS {

&id OBJECT IDENTIFIER UNIQUE,

&Qualifier OPTIONAL }

WITH SYNTAX {

POLICY-QUALIFIER-ID &id

[QUALIFIER-TYPE &Qualifier] }

policyMappings EXTENSION ::= {

SYNTAX PolicyMappingsSyntax

IDENTIFIED BY id-ce-policyMappings }

PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {

issuerDomainPolicy CertPolicyId,

subjectDomainPolicy CertPolicyId }

supportedAlgorithms ATTRIBUTE ::= {

WITH SYNTAX SupportedAlgorithm

EQUALITY MATCHING RULE algorithmIdentifierMatch

ID id-at-supportedAlgorithms }

SupportedAlgorithm ::= SEQUENCE {

algorithmIdentifier AlgorithmIdentifier,

intendedUsage [0] KeyUsage OPTIONAL,

intendedCertificatePolicies [1] CertificatePoliciesSyntax OPTIONAL }

-- Certificate subject and certificate issuer attributes extensions --

subjectAltName EXTENSION ::= {

SYNTAX GeneralNames

IDENTIFIED BY id-ce-subjectAltName }

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {

otherName [0] INSTANCE OF OTHER-NAME,

rfc822Name [1] IA5String,

dNSName [2] IA5String,

x400Address [3] ORAddress,

directoryName [4] Name,

ediPartyName [5] EDIPartyName,

uniformResourceIdentifier [6] IA5String,

iPAddress [7] OCTET STRING,

registeredID [8] OBJECT IDENTIFIER }

OTHER-NAME ::= TYPE-IDENTIFIER

EDIPartyName ::= SEQUENCE {

nameAssigner [0] DirectoryString {ub-name} OPTIONAL,

partyName [1] DirectoryString {ub-name} }

issuerAltName EXTENSION ::= {

SYNTAX GeneralNames

IDENTIFIED BY id-ce-issuerAltName }

subjectDirectoryAttributes EXTENSION ::= {

SYNTAX AttributesSyntax

IDENTIFIED BY id-ce-subjectDirectoryAttributes }

AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute

-- Certification path constraints extensions --

basicConstraints EXTENSION ::= {

SYNTAX BasicConstraintsSyntax

IDENTIFIED BY id-ce-basicConstraints }

BasicConstraintsSyntax ::= SEQUENCE {

cA BOOLEAN DEFAULT FALSE,

pathLenConstraint INTEGER (0..MAX) OPTIONAL }

nameConstraints EXTENSION ::= {

SYNTAX NameConstraintsSyntax

IDENTIFIED BY id-ce-nameConstraints }

NameConstraintsSyntax ::= SEQUENCE {

permittedSubtrees [0] GeneralSubtrees OPTIONAL,

excludedSubtrees [1] GeneralSubtrees 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)

policyConstraints EXTENSION ::= {

SYNTAX PolicyConstraintsSyntax

IDENTIFIED BY id-ce-policyConstraints }

PolicyConstraintsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {

policySet [0] CertPolicySet OPTIONAL,

requireExplicitPolicy [0] SkipCerts OPTIONAL,

inhibitPolicyMapping [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

CertPolicySet ::= SEQUENCE SIZE (1..MAX) OF CertPolicyId

-- Basic CRL extensions --

cRLNumber EXTENSION ::= {

SYNTAX CRLNumber

IDENTIFIED BY id-ce-cRLNumber }

CRLNumber ::= INTEGER (0..MAX)

reasonCode EXTENSION ::= {

SYNTAX CRLReason

IDENTIFIED BY id-ce-reasonCode }

CRLReason ::= ENUMERATED {

unspecified (0),

keyCompromise (1),

cACompromise (2),

affiliationChanged (3),

superseded (4),

cessationOfOperation (5),

certificateHold (6),

removeFromCRL (8) }

instructionCode EXTENSION ::= {

SYNTAX HoldInstruction

IDENTIFIED BY id-ce-instructionCode }

HoldInstruction ::= OBJECT IDENTIFIER

invalidityDate EXTENSION ::= {

SYNTAX GeneralizedTime

IDENTIFIED BY id-ce-invalidityDate }

-- CRL distribution points and delta-CRL extensions --

cRLDistributionPoints EXTENSION ::= {

SYNTAX CRLDistPointsSyntax

IDENTIFIED BY id-ce-cRLDistributionPoints }

CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {

distributionPoint [0] DistributionPointName OPTIONAL,

reasons [1] ReasonFlags OPTIONAL,

cRLIssuer [2] GeneralNames OPTIONAL }

DistributionPointName ::= CHOICE {

fullName [0] GeneralNames,

nameRelativeToCRLIssuer [1] RelativeDistinguishedName }

ReasonFlags ::= BIT STRING {

unused (0),

keyCompromise (1),

caCompromise (2),

affiliationChanged (3),

superseded (4),

cessationOfOperation (5),

certificateHold (6) }

issuingDistributionPoint EXTENSION ::= {

SYNTAX IssuingDistPointSyntax

IDENTIFIED BY id-ce-issuingDistributionPoint }

IssuingDistPointSyntax ::= SEQUENCE {

distributionPoint [0] DistributionPointName OPTIONAL,

onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,

onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,

onlySomeReasons [3] ReasonFlags OPTIONAL,

indirectCRL [4] BOOLEAN DEFAULT FALSE }

certificateIssuer EXTENSION ::= {

SYNTAX GeneralNames

IDENTIFIED BY id-ce-certificateIssuer }

deltaCRLIndicator EXTENSION ::= {

SYNTAX BaseCRLNumber

IDENTIFIED BY d-ce-deltaCRLIndicator }

BaseCRLNumber ::= CRLNumber

deltaRevocationList ATTRIBUTE ::= {

WITH SYNTAX CertificateList

EQUALITY MATCHING RULE certificateListExactMatch

ID id-at-deltaRevocationList }

-- Matching rules --

certificateExactMatch MATCHING-RULE ::= {
SYNTAX CertificateExactAssertion
ID id-mr-certificateExactMatch }

CertificateExactAssertion ::= SEQUENCE {

serialNumber CertificateSerialNumber,

issuer Name }

certificateMatch MATCHING-RULE ::= {
SYNTAX CertificateAssertion
ID id-mr-certificateMatch }

CertificateAssertion ::= SEQUENCE {

serialNumber [0] CertificateSerialNumber OPTIONAL,

issuer [1] Name OPTIONAL,

subjectKeyIdentifier [2] SubjectKeyIdentifier OPTIONAL,

authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL,

certificateValid [4] UTCTime OPTIONAL,

privateKeyValid [5] GeneralizedTime OPTIONAL,
subjectPublicKeyAlgID [6] OBJECT IDENTIFIER OPTIONAL,
keyUsage [7] KeyUsage OPTIONAL,
subjectAltName [8] AltNameType OPTIONAL,
policy [9] CertPolicySet OPTIONAL,
pathToName [10] Name OPTIONAL }

AltNameType ::= CHOICE {

builtinNameForm ENUMERATED {

rfc822Name (1),

dNSName (2),

x400Address (3),

directoryName (4),

ediPartyName (5),

uniformResourceIdentifier (6),

iPAddress (7),

registeredId (8) },

otherNameForm OBJECT IDENTIFIER }

certificatePairExactMatch MATCHING-RULE ::= {
SYNTAX CertificatePairExactAssertion
ID id-mr-certificatePairExactMatch }

CertificatePairExactAssertion ::= SEQUENCE {

forwardAssertion [0] CertificateExactAssertion OPTIONAL,

reverseAssertion [1] CertificateExactAssertion OPTIONAL }

( WITH COMPONENTS {..., forwardAssertion PRESENT} |

WITH COMPONENTS {..., reverseAssertion PRESENT} )

certificatePairMatch MATCHING-RULE ::= {
SYNTAX CertificatePairAssertion
ID id-mr-certificatePairMatch }

CertificatePairAssertion ::= SEQUENCE {

forwardAssertion [0] CertificateAssertion OPTIONAL,

reverseAssertion [1] CertificateAssertion OPTIONAL }

( WITH COMPONENTS {..., forwardAssertion PRESENT} |

WITH COMPONENTS {..., reverseAssertion PRESENT} )

certificateListExactMatch MATCHING-RULE ::= {
SYNTAX CertificateListExactAssertion
ID id-mr-certificateListExactMatch }

CertificateListExactAssertion ::= SEQUENCE {

issuer Name,

thisUpdate UTCTime,

distributionPoint DistributionPointName OPTIONAL }

certificateListMatch MATCHING-RULE ::= {

SYNTAX CertificateListAssertion
ID id-mr-certificateListMatch }

CertificateListAssertion ::= SEQUENCE {

issuer Name OPTIONAL,

minCRLNumber [0] CRLNumber OPTIONAL,
maxCRLNumber [1] CRLNumber OPTIONAL,
reasonFlags ReasonFlags OPTIONAL,
dateAndTime UTCTime OPTIONAL,

distributionPoint [2] DistributionPointName OPTIONAL }

algorithmIdentifierMatch MATCHING-RULE ::= {
SYNTAX AlgorithmIdentifier
ID id-mr-algorithmIdentifierMatch }

-- Object identifier assignments --

id-at-supportedAlgorithms OBJECT IDENTIFIER ::= {id-at 52}

id-at-deltaRevocationList OBJECT IDENTIFIER ::= {id-at 53}

id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= {id-ce 9}

id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 14}

id-ce-keyUsage OBJECT IDENTIFIER ::= {id-ce 15}

id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= {id-ce 16}

id-ce-subjectAltName OBJECT IDENTIFIER ::= {id-ce 17}

id-ce-issuerAltName OBJECT IDENTIFIER ::= {id-ce 18}

id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19}

id-ce-cRLNumber OBJECT IDENTIFIER ::= {id-ce 20}

id-ce-reasonCode OBJECT IDENTIFIER ::= {id-ce 21}

id-ce-instructionCode OBJECT IDENTIFIER ::= {id-ce 23}

id-ce-invalidityDate OBJECT IDENTIFIER ::= {id-ce 24}

id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= {id-ce 27}

id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= {id-ce 28}

id-ce-certificateIssuer OBJECT IDENTIFIER ::= {id-ce 29}

id-ce-nameConstraints OBJECT IDENTIFIER ::= {id-ce 30}

id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}

id-ce-certificatePolicies OBJECT IDENTIFIER ::= {id-ce 32}

id-ce-policyMappings OBJECT IDENTIFIER ::= {id-ce 33}
-- deprecated id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 34}
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 35}

id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 36}

id-mr-certificateExactMatch OBJECT IDENTIFIER ::= {id-mr 34}

id-mr-certificateMatch OBJECT IDENTIFIER ::= {id-mr 35}

id-mr-certificatePairExactMatch OBJECT IDENTIFIER ::= {id-mr 36}

id-mr-certificatePairMatch OBJECT IDENTIFIER ::= {id-mr 37}

id-mr-certificateListExactMatch OBJECT IDENTIFIER ::= {id-mr 38}

id-mr-certificateListMatch OBJECT IDENTIFIER ::= {id-mr 39}

id-mr-algorithmIdentifierMatch OBJECT IDENTIFIER ::= {id-mr 40}

-- The following OBJECT IDENTIFIERS are not used by this specification:

-- {id-ce 2}, {id-ce 3}, {id-ce 4}, {id-ce 5}, {id-ce 6}, {id-ce 7},

-- {id-ce 8}, {id-ce 10}, {id-ce 11}, {id-ce 12}, {id-ce 13},

-- {id-ce 22}, {id-ce 25}, {id-ce 26}

END

Add a new Annex K as follows:
Annex K: Bibliography

(This annex does not form an integral part of this Recommendation | International Standard)

S. Kent, "Privacy Enhancement for Internet Electronic Mail, Part II: Certificate-Based Key Management", RFC 1422, Internet Activities Board, 1993.

United Nations, "EDIFACT Security Implementation Guidelines", UN Economic and Social Council, TRADE/WP.4/R.1026, 7 February 1994. (To be incorporated in ISO 9735 EDIFACT Syntax.)

Add a new Annex L as follows:
Annex L: Examples of use of certification path constraints

(This annex does not form an integral part of this Recommendation | International Standard)

L.1 Example 1: Use of basic constraints

Suppose the Widget Corporation wants to cross-certify the central CA of the Acme Corporate Group, but only wants the Widget community to use end-entity certificates issued by that CA, not certificates issued by other CAs certified by that CA.

The Widget Corporation could satisfy this requirement by issuing a certificate for Acme's central CA, including the following extension field value:

Value of Basic Constraints Field:

{ cA TRUE, pathLenConstraint 0 }

L.2 Example 2: Use of name constraints

Suppose the Widget Corporation wants to cross-certify the central CA of the Acme Corporate Group, but only wants the Widget community to use Acme certificates for subjects that meet the following criteria:

— in Acme, Inc. in the U.S., all subjects are acceptable except for subjects in purchasing;

— in EuroAcme in France, only those subjects that are immediately subordinate to the EuroAcme headquarters are acceptable (this includes individuals reporting directly to headquarters but excludes those reporting to subordinate organizations); and

— in Acme Ltd. in the U.K., all subjects are acceptable except those reporting to organizations that are subordinate to the R&D organizational unit (this includes individuals reporting directly to R&D but excludes those reporting to subordinate units of R&D).

The Widget Corporation could satisfy these requirements by issuing a certificate for Acme's central CA, including the following extension field values:

Value of Basic Constraints Field:

{ cA TRUE }

Value of Name Constraints Field:

{ permittedSubtrees {{base --Country=US, Org=Acme Inc--},

{base --Country=France, Org=EuroAcme--, maximum 1},

{base --Country=UK, Org=Acme Ltd--}},

excludedSubtrees {{base --Country=US, Org=Acme Inc, Org. Unit=Purchasing-},

{base --Country=UK Org=Acme Ltd., Org. Unit=R&D--, minimum 2}}}

L.3 Example 3: Use of policy mapping and policy constraints

Suppose the following cross-certification scenario is required between the Canadian and U.S. governments:

a) a Canadian government CA wishes to certify use of U.S. government signatures with respect to a Canadian policy called Can/US-Trade;

b) the U.S. government has a policy called US/Can-Trade, which the Canadian government is prepared to consider equivalent to its Can/US-Trade policy;

c) the Canadian government wants to apply safeguards which require all U.S. certificates to explicitly state support for the policy and which inhibit mapping to other policies within the U.S. domain.

A Canadian government CA could issue a certificate for a U.S. government CA with the following extension field values:

Value of Certificate Policies Field:

{{ policyIdentifier -- object identifier for Can/US-Trade -- }}

Value of Policy Mappings Field:

{{ issuerDomainPolicy -- object identifier for Can/US-Trade -- ,

subjectDomainPolicy -- object identifier for US/Can-Trade -- }}

Value of PolicyConstraints Field:

{{ policySet { -- object identifier for Can/US-Trade -- }, requireExplicitPolicy (0),

inhibitPolicyMapping (0)}}

Title :	Final Text of Draft Amendments DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions

Source :	ISO/IEC JTC 1/SC 21/WG 4 and ITU-T Q15/7 Collaborative Editing Meeting on the Directory, Geneva, April 1996

Project:	21.29.18

Status :	Final Final draft (1 DecemberJune 30). This document will be distributed by the SC21 Secretariat and integrated into the 3rd edition

Requested Action :	Text forwarded to the JTC1 SC21 Secretariat for NB/LO circulation and eventual inclusion into the 3rd edition of ISO/IEC 9594.