ISO/IEC JTC 1/SC 6/WG 10 - Directory, ASN.1 and Registration

This document specifies the OID resolution system, including the overall architecture and a DNS-based resolution mechanism. It specifies the means for inserting any application-defined information associated with an OID node into the DNS (see clause 6) and the means of retrieval of that information using the ORS (see clause 7). It does not restrict the number of applications it can support. It specifies the required operation of an ORS client (see clause 7), including the mapping of an OID-IRI value by the ORS client into a DNS name to produce a DNS query for the specified application information and the processing of any returned information. The ORS has no role in the allocation or registration of OID nodes. The required behaviour of an ORS client is specified, but the interfaces to it are specified only in terms of the semantics of the interaction. A bit-level application program interface is platform and software dependent, and is not in the scope of this document. A special behaviour of an ORS client is specified to cache OID information in order to reduce the response time of OID resolution. This document also specifies a mechanism to resolve an OID node when one of its superior OID nodes is not ORS-supported. It does not include a tutorial or complete specification on the management of DNS zone files (for that, see IETF RFC 1035 and IETF RFC 3403); it specifies (only) the DNS resource records (see 6.3) that need to be inserted in the zone files in order to support ORS access to the information associated with an OID node. This document specifies required DNS zone file resource records, and prohibits the use of other resource records of a similar form but with different semantics (in DNS zone files in the ORS domain) – see 6.2. It does not otherwise restrict the general use of DNS zone files.

This document specifies a set of JavaScript Object Notation Encoding Rules (JER) that may be used to derive a transfer syntax for values of types defined in Rec. ITU-T X.680 | ISO/IEC 8824-1, Rec. ITU-T X.681 | ISO/IEC 8824-2, Rec. ITU-T X.682 | ISO/IEC 8824-3 and Rec. ITU-T X.683 | ISO/IEC 8824-4. It is implicit in the specification of these encoding rules that they are also to be used for decoding. The encoding rules specified in this document: – are used at the time of communication; – are intended for use in circumstances where interoperability with applications using JSON is the major concern in the choice of encoding rules; – allow the extension of an abstract syntax by addition of extra values for all forms of extensibility described in Rec. ITU-T X.680 | ISO/IEC 8824‑1. This document also specifies the syntax and semantics of JER encoding instructions, as well as the rules for their assignment and combination. JER encoding instructions can be used to control JER encoding for specific Abstract Syntax Notation One (ASN.1) types.

This document specifies a set of Packed Encoding Rules that may be used to derive a transfer syntax for values of types defined in Rec. ITU-T X.680 | ISO/IEC 8824-1. These Packed Encoding Rules are also to be applied for decoding such a transfer syntax in order to identify the data values being transferred. The encoding rules specified in this document : – are used at the time of communication; – are intended for use in circumstances where minimizing the size of the representation of values is the major concern in the choice of encoding rules; – allow the extension of an abstract syntax by addition of extra values, preserving the encodings of the existing values, for all forms of extension described in Rec. ITU-T X.680 | ISO/IEC 8824‑1; – can be modified in accordance with the provisions of Rec. ITU-T X.695 | ISO/IEC 8825‑6.

This document specifies a set of basic encoding rules that may be used to derive the specification of a transfer syntax for values of types defined using the notation specified in Rec. ITU-T X.680 | ISO/IEC 8824‑1, Rec. ITU-T X.681 | ISO/IEC 8824-2, Rec. ITU-T X.682 | ISO/IEC 8824-3, and Rec. ITU-T X.683 | ISO/IEC 8824-4, collectively referred to as Abstract Syntax Notation One or ASN.1. These basic encoding rules are also to be applied for decoding such a transfer syntax in order to identify the data values being transferred. It also specifies a set of canonical and distinguished encoding rules that restrict the encoding of values to just one of the alternatives provided by the basic encoding rules.

This document provides a standard notation called Abstract Syntax Notation One (ASN.1) that is used for the definition of data types, values, and constraints on data types. This document: – defines a number of simple types, with their tags, and specifies a notation for referencing these types and for specifying values of these types; – defines mechanisms for constructing new types from more basic types, and specifies a notation for defining such types and assigning them tags, and for specifying values of these types; – defines character sets (by reference to other Recommendations and/or International Standards) for use within ASN.1. The ASN.1 notation can be applied whenever it is necessary to define the abstract syntax of information. The ASN.1 notation is referenced by other standards which define encoding rules for the ASN.1 types.

This document is part of Abstract Syntax Notation One (ASN.1) and defines notation for parameterization of ASN.1 specifications.

This document specifies a set of Basic Octet Encoding Rules (BASIC-OER) that may be used to derive a transfer syntax for values of the types defined in Rec. ITU-T X.680 | ISO/IEC 8824-1, Rec. ITU‑T X.681 | ISO/IEC 8824-2, Rec. ITU-T X.682 | ISO/IEC 8824-3, Rec. ITU-T X.683 | ISO/IEC 8824-4. This document also specifies a set of Canonical Octet Encoding Rules (CANONICAL-OER) which provides constraints on the Basic Octet Encoding Rules and produces a unique encoding for any given ASN.1 value. It is implicit in the specification of these encoding rules that they are also to be used for decoding. The encoding rules specified in this document: – are used at the time of communication; – are intended for use in circumstances where encoding/decoding speed is the major concern in the choice of encoding rules; – allow the extension of an abstract syntax by addition of extra values for all forms of extensibility described in Rec. ITU-T X.680 | ISO/IEC 8824‑1.

This document defines a notation for specifying encodings of ASN.1 types or of parts of types. It provides several mechanisms for such specification, including: – direct specification of the encoding using standardized notation; – specification of the encoding by reference to standardized encoding rules; – specification of the encoding of an ASN.1 type by reference to an encoding structure; – specification of the encoding using non-ECN notation. It also provides the means to link the specification of encodings to the type definitions to which they are to be applied. ECN does not currently provide any support for specifications using the OID internationalized resource identifier type or the relative OID internationalized resource identifier type (see Rec. ITU-T X.680 | ISO/IEC 8824-1), and these are not referred to further in this Standard.

This document specifies a set of basic XML Encoding Rules (BASIC-XER) that may be used to derive a transfer syntax for values of types defined in Rec. ITU-T X.680 | ISO/IEC 8824-1 and Rec. ITU-T X.681 | ISO/IEC 8824-2. This document also specifies a set of Canonical XML Encoding Rules (CXER) which provide constraints on the basic XML Encoding Rules and produce a unique encoding for any given ASN.1 value. This document further specifies a set of extended XML Encoding Rules (EXTENDED-XER) which adds further encoders options, and also allows the ASN.1 specifier to vary the encoding that would be produced by BASIC-XER. It is implicit in the specification of these encoding rules that they are also used for decoding. The encoding rules specified in this document : – are used at the time of communication; – are intended for use in circumstances where displaying of values and/or processing them using commonly available XML tools (such as browsers) is the major concern in the choice of encoding rules; – allow the extension of an abstract syntax by addition of extra values for all forms of extensibility described in Rec. ITU-T X.680 | ISO/IEC 8824‑1. This document also specifies the syntax and semantics of XER encoding instructions, and the rules for their assignment and combination. XER encoding instructions can be used to control the EXTENDED-XER encoding for specific ASN.1 types.

This document specifies two versions of a mapping from any XSD Schema into an Abstract Syntax Notation One (ASN.1) schema. The ASN.1 schema for both versions support the same semantics and validate the same set of XML documents. This document specifies the final XER encoding instructions that are to be applied as part of the defined mapping to ASN.1 types, but does not specify which syntactic form is to be used for the specification of those final XER encoding instructions, or the order or manner of their assignment. NOTE – Implementers of tools generating these mappings may choose any syntactic form or order of assignment that results in the specified final XER encoding instructions being applied. Examples in this document generally use the type prefix form, but use of an XER Encoding Control Section may be preferred for the mapping of a complete XSD Schema, as a matter of style. There are different ways (syntactically) of assigning XER encoding instructions for use in EXTENDED-XER encodings (e.g., use of ASN.1 type prefix encoding instructions or use of an XER encoding control section). The choice of these syntactic forms is a matter of style and lies outside the scope of this document.

This document: a) specifies the information needed and the format to be used for specifying PER encoding instructions; b) specifies the mechanisms for approving new PER encoding instructions from time to time and the operation of the Registration Authority for PER encoding instructions; c) specifies the means of associating a PER encoding instruction with an ASN.1 type using both type prefixes and an encoding control section.

This document is part of Abstract Syntax Notation One (ASN.1) and provides notation for specifying user-defined constraints, table constraints, and contents constraints.

This document is part of Abstract Syntax Notation One (ASN.1) and provides notation for specifying information object classes, information objects and information object sets.

This document specifies the Directory Access Protocol, the Directory System Protocol, the Directory Information Shadowing Protocol, and the Directory Operational Binding Management Protocol which fulfil the abstract services specified in Rec. ITU-T X.511 | ISO/IEC 9594-3, Rec. ITU-T X.518 | ISO/IEC 9594-4, Rec. ITU‑T X.525 | ISO/IEC 9594-9, and Rec. ITU-T X.501 | ISO/IEC 9594-2.

This document provides the directory capabilities required by many application layer standards and telecommunication services. Among the capabilities which it provides are those of "user-friendly naming", whereby objects can be referred to by names which are suitable for citing by human users (though not all objects need have user-friendly names); and "name-to-address mapping" which allows the binding between objects and their locations to be dynamic. The latter capability allows networks, for example, to be "self-configuring" in the sense that addition, removal and the changes of object location do not affect network operation. The Directory is not intended to be a general-purpose database system, although it may be built on such systems. It is assumed, for instance, that, as is typical with communication directories, there is a considerably higher frequency of "queries" than of updates. The rate of updates is expected to be governed by the dynamics of people and organizations, rather than, for example, the dynamics of networks. There is also no need for instantaneous global commitment of updates; transient conditions, where both old and new versions of the same information are available, are quite acceptable. It is a characteristic of the Directory that, except as a consequence of differing access rights or un-propagated updates, the results of directory queries will not be dependent on the identity or location of the inquirer. This characteristic renders the Directory unsuitable for some telecommunication applications, for example some types of routing. For cases where the results are dependent on the identity of the inquirer, access to directory information and updates of the Directory may be denied.

This document addresses some of the security requirements in the areas of authentication and other security services through the provision of a set of frameworks upon which full services can be based. Specifically, this Recommendation | International Standard defines frameworks for: ? public-key certificates; and ? attribute certificates. The public-key certificate framework defined in this Recommendation | International Standard specifies the information objects and data types for a public-key infrastructure (PKI), including public-key certificates, certificate revocation lists (CRLs), trust broker and authorization and validation lists (AVLs). The attribute certificate framework specifies the information objects and data types for a privilege management infrastructure (PMI), including attribute certificates, and attribute certificate revocation lists (ACRLs). This Recommendation | International Standard also provides the framework for issuing, managing, using and revoking certificates. An extensibility mechanism is included in the defined formats for both certificate types and for all revocation list schemes. This Recommendation | International Standard also includes a set of extensions, which is expected to be generally useful across a number of applications of PKI and PMI. The schema components (including object classes, attribute types and matching rules) for storing PKI and PMI information in a directory, are included in this Recommendation | International Standard. This Recommendation | International Standard specifies the framework for strong authentication, involving credentials formed using cryptographic techniques. It is not intended to establish this as a general framework for authentication, but it can be of general use for applications which consider these techniques adequate. Authentication (and other security services) can only be provided within the context of a defined security policy. It is a matter for users of an application to define their own security policy.

This document defines a number of attribute types and matching rules which may be found useful across a range of applications of the Directory. Attribute types and matching rules fall into three categories, as described below. Some attribute types and matching rules are used by a wide variety of applications or are understood and/or used by the Directory itself. NOTE 1 ? It is recommended that an attribute type or matching rule defined in this Recommendation | International Standard be used, in preference to the generation of a new one, whenever it is appropriate for the application. NOTE 2 ? The attribute and context types definitions by this Recommendation | International Standard have some associated semantics. Such specifications should not be used in situations where these semantics do not apply. Some attribute types and matching rules are internationally standardized, but are application‑specific. These are defined in the standards associated with the application concerned. Any administrative authority can define its own attribute types and matching rules for any purpose. These are not internationally standardized, and are available to others beyond the administrative authority which created them only through bilateral agreement.

This document defines a number of object classes and name forms which may be found useful across a range of applications of the Directory. The definition of an object class involves listing a number of attribute types which are relevant to objects of that class. The definition of a name form involves naming the object class to which it applies and listing the attributes to be used in forming names for objects of that class. These definitions are used by the administrative authority which is responsible for the management of the directory information. Any administrative authority can define its own object classes or subclasses and name forms for any purpose. NOTE 1 ? Those definitions may or may not use the notation specified in Rec. ITU-T X.501 | ISO/IEC 9594-2. NOTE 2 ? It is recommended that an object class defined in this Recommendation | International Standard, or a subclass derived from one, or a name form defined in this Recommendation | International Standard, be used in preference to the generation of a new one, whenever the semantics is appropriate for the application. Administrative authorities may support some or all the selected object classes and name forms, and may also add additional ones. All administrative authorities shall support the object classes which the directory uses for its own purpose (the top, alias and Directory system agent (DSA) object classes).

This document specifies a shadow service which Directory system agents (DSAs) may use to replicate Directory information. The service allows Directory information to be replicated among DSAs to improve service to Directory users. The shadowed information is updated, using the defined protocol, thereby improving the service provided to users of the Directory.

This document defines in an abstract way the externally visible service provided by the Directory. This document does not specify individual implementations or products.

This document specifies the behaviour of DSAs taking part in a distributed directory consisting of multiple Directory systems agents (DSAs) and/or LDAP servers with at least one DSA. The allowed behaviour has been designed to ensure a consistent service given a wide distribution of the DIB across a distributed directory. Only the behaviour of DSAs taking part in a distributed directory is specified. The behaviour of LDAP servers are specified in relevant LDAP specifications. There are no special requirements on an LDAP server beyond those given by the LDAP specifications. The Directory is not intended to be a general purpose database system, although it may be built on such systems. It is assumed that there is a considerably higher frequency of queries than of updates.

This document provides a conceptual and terminological framework for the other ITU-T X.500-series Recommendations | parts of ISO/IEC 9594 which define various aspects of the Directory. The functional and administrative authority models define ways in which the Directory can be distributed, both functionally and administratively. Generic Directory System Agent (DSA) and DSA information models and an Operational Framework are also provided to support Directory distribution. The generic Directory Information Models describe the logical structure of the Directory Information Base (DIB) from the perspective of Directory and Administrative Users. In these models, the fact that the Directory is distributed, rather than centralized, is not visible. This Recommendation | International Standard provides a specialization of the generic Directory Information Models to support Directory Schema administration. The other ITU-T Recommendations in the X.500 series | parts of ISO/IEC 9594 make use of the concepts defined in this Recommendation | International Standard to define specializations of the generic information and DSA models to provide specific information, DSA and operational models supporting particular directory capabilities (e.g., Replication): a) the service provided by the Directory is described (in Rec. ITU-T X.511 | ISO/IEC 9594-3) in terms of the concepts of the information framework: this allows the service provided to be somewhat independent of the physical distribution of the DIB; b) the distributed operation of the Directory is specified (in Rec. ITU-T X.518 | ISO/IEC 9594-4) so as to provide that service, and therefore maintain that logical information structure, given that the DIB is in fact highly distributed; c) replication capabilities offered by the component parts of the Directory to improve overall Directory performance are specified (in Rec. ITU-T X.525 | ISO/IEC 9594-9). The security model establishes a framework for the specification of access control mechanisms. It provides a mechanism for identifying the access control scheme in effect in a particular portion of the Directory Information Tree (DIT), and it defines three flexible, specific access control schemes which are suitable for a wide variety of applications and styles of use. The security model also provides a framework for protecting the confidentiality and integrity of directory operations using mechanisms such as encryption and digital signatures. This makes use of the framework for authentication defined in Rec. ITU-T X.509 | ISO/IEC 9594-8 as well as generic upper layers security tools defined in Rec. ITU-T X.830 | ISO/IEC 11586-1. DSA models establish a framework for the specification of the operation of the components of the Directory. Specifically: a) the Directory functional model describes how the Directory is manifested as a set of one or more components, each being a DSA; b) the Directory distribution model describes the principals according to which the DIB entries and entry‑copies may be distributed among DSAs; c) the DSA information model describes the structure of the Directory user and operational information held in a DSA; d) the DSA operational framework describes the means by which the definition of specific forms of cooperation between DSAs to achieve particular objectives (e.g., shadowing) is structured.

ISO/IEC 8825-5:2015 specifies two Versions of a mapping from any XSD Schema into an ASN.1 schema. The ASN.1 schema for both Versions support the same semantics and validate the same set of XML documents. ISO/IEC 8825-5:2015 specifies the final XER encoding instructions that are to be applied as part of the defined mapping to ASN.1 types, but does not specify which syntactic form is to be used for the specification of those final XER encoding instructions, or the order or manner of their assignment. NOTE ? Implementers of tools generating these mappings may choose any syntactic form or order of assignment that results in the specified final XER encoding instructions being applied. Examples in this Recommendation | International Standard generally use the type prefix form, but use of an XER Encoding Control Section may be preferred for the mapping of a complete XSD Schema, as a matter of style. There are different ways (syntactically) of assigning XER encoding instructions for use in EXTENDED-XER encodings (for example, use of ASN.1 type prefix encoding instructions or use of an XER encoding control section). The choice of these syntactic forms is a matter of style and is outside the scope of this Recommendation | International Standard.