From 044b39f4ec38ed45aab6383a3bb3a5f63e36e8b6 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Mon, 23 Sep 2002 04:35:05 +0000 Subject: [PATCH] Add Steven's I-Ds on LDAP/X.500 admin models Correct naming of older drafts --- ...-01.txt => draft-leach-uuids-guids-xx.txt} | 0 doc/drafts/draft-legg-ldap-acm-admin-xx.txt | 451 ++++ doc/drafts/draft-legg-ldap-admin-xx.txt | 395 +++ doc/drafts/draft-legg-ldap-gser-abnf-xx.txt | 619 +++++ doc/drafts/draft-legg-ldap-gser-xx.txt | 899 +++++++ ...aft-legg-ldapext-component-matching-xx.txt | 2299 +++++++++++++++++ ...-02.txt => draft-zeilenga-ldap-t-f-xx.txt} | 0 7 files changed, 4663 insertions(+) rename doc/drafts/{draft-leach-uuids-guids-01.txt => draft-leach-uuids-guids-xx.txt} (100%) create mode 100644 doc/drafts/draft-legg-ldap-acm-admin-xx.txt create mode 100644 doc/drafts/draft-legg-ldap-admin-xx.txt create mode 100644 doc/drafts/draft-legg-ldap-gser-abnf-xx.txt create mode 100644 doc/drafts/draft-legg-ldap-gser-xx.txt create mode 100644 doc/drafts/draft-legg-ldapext-component-matching-xx.txt rename doc/drafts/{draft-zeilenga-ldap-t-f-02.txt => draft-zeilenga-ldap-t-f-xx.txt} (100%) diff --git a/doc/drafts/draft-leach-uuids-guids-01.txt b/doc/drafts/draft-leach-uuids-guids-xx.txt similarity index 100% rename from doc/drafts/draft-leach-uuids-guids-01.txt rename to doc/drafts/draft-leach-uuids-guids-xx.txt diff --git a/doc/drafts/draft-legg-ldap-acm-admin-xx.txt b/doc/drafts/draft-legg-ldap-acm-admin-xx.txt new file mode 100644 index 0000000000..a4d4660823 --- /dev/null +++ b/doc/drafts/draft-legg-ldap-acm-admin-xx.txt @@ -0,0 +1,451 @@ + + + + + + +INTERNET-DRAFT S. Legg +draft-legg-ldap-acm-admin-01.txt Adacel Technologies +Intended Category: Standards Track September 18, 2002 + + + Access Control Administration in LDAP + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + Status of this Memo + + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress". + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Distribution of this document is unlimited. Comments should be sent + to the LDUP working group mailing list or to the + author. + + This Internet-Draft expires on 18 March 2003. + + +1. Abstract + + This document adapts the X.500 directory administrative model, as it + pertains to access control administration, for use by the Lightweight + Directory Access Protocol. The administrative model partitions the + Directory Information Tree for various aspects of directory data + administration, e.g. subschema, access control and collective + attributes. This document provides the particular definitions that + support access control administration, but does not define a + particular access control scheme. + + + +Legg Expires 18 March 2003 [Page 1] + +INTERNET-DRAFT Access Control Administration September 18, 2002 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + +2. Table of Contents + + 1. Abstract .................................................... 1 + 2. Table of Contents ........................................... 2 + 3. Introduction ................................................ 2 + 4. Access Control Administrative Areas ......................... 3 + 5. Access Control Scheme Indication ............................ 3 + 6. Access Control Information .................................. 4 + 7. Access Control Subentries ................................... 4 + 8. Applicable Access Control Information ....................... 5 + 9. Security Considerations ..................................... 5 + 10. Acknowledgements ........................................... 6 + 11. Normative References ....................................... 6 + 12. Informative References ..................................... 6 + 13. Copyright Notice ........................................... 7 + 14. Author's Address ........................................... 7 + + +3. Introduction + + This document adapts the X.500 directory administrative model [X501], + as it pertains to access control administration, for use by the + Lightweight Directory Access Protocol (LDAP) [RFC2251]. + + The administrative model [ADMIN] partitions the Directory Information + Tree (DIT) for various aspects of directory data administration, e.g. + subschema, access control and collective attributes. The parts of + the administrative model that apply to every aspect of directory data + administration are described in [ADMIN]. This document describes the + administrative framework for access control. + + An access control scheme describes the means by which access to + directory information, and potentially to access rights themselves, + may be controlled. This document describes the framework for + employing access control schemes but does not define a particular + access control scheme. Two access control schemes known as Basic + Access Control and Simplified Access Control are defined by [BAC]. + Other access control schemes MAY be defined by other documents. + + Schema definitions are provided using LDAP description formats + [RFC2252]. Note that the LDAP descriptions have been rendered with + additional white-space and line breaks for the sake of readability. + + + + +Legg Expires 18 March 2003 [Page 2] + +INTERNET-DRAFT Access Control Administration September 18, 2002 + + + This document is derived from, and duplicates substantial portions + of, Sections 4 and 8 of [X501]. + + +4. Access Control Administrative Areas + + The specific administrative area [ADMIN] for access control is termed + an Access Control Specific Area (ACSA). The root of the ACSA is + termed an Access Control Specific Point (ACSP) and is represented in + the DIT by an administrative entry [ADMIN] which includes + accessControlSpecificArea as a value of its administrativeRole + operational attribute [SUBENTRY]. + + An ACSA MAY be partitioned into subtrees termed inner administrative + areas [ADMIN]. Each such inner area is termed an Access Control + Inner Area (ACIA). The root of the ACIA is termed an Access Control + Inner Point (ACIP) and is represented in the DIT by an administrative + entry which includes accessControlInnerArea as a value of its + administrativeRole operational attribute. + + An administrative entry can never be both an ACSP and an ACIP. The + corresponding values can therefore never be present simultaneously in + the administrativeRole attribute. + + Each entry necessarily falls within one and only one ACSA. Each such + entry may also fall within one or more ACIAs nested inside the ACSA + containing the entry. + + An ACSP or ACIP has zero, one or more subentries that contain Access + Control Information (ACI). + + +5. Access Control Scheme Indication + + The access control scheme (e.g. Basic Access Control [BAC]) in force + in an ACSA is indicated by the accessControlScheme operational + attribute contained in the administrative entry for the relevant + ACSP. + + The LDAP description [RFC2252] for the accessControlScheme + operational attribute is: + + ( 2.5.24.1 NAME 'accessControlScheme' + EQUALITY objectIdentifierMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 + SINGLE-VALUE USAGE directoryOperation ) + + An access control scheme conforming to the access control framework + + + +Legg Expires 18 March 2003 [Page 3] + +INTERNET-DRAFT Access Control Administration September 18, 2002 + + + described in this document MUST define a distinct OBJECT IDENTIFIER + value to identify it through the accessControlScheme attribute. + + Only administrative entries for ACSPs are permitted to contain an + accessControlScheme attribute. If the accessControlScheme attribute + is absent from a given ACSP, the access control scheme in force in + the corresponding ACSA, and its effect on operations, results and + errors, is implementation defined. + + Any entry or subentry in an ACSA is permitted to contain ACI if and + only if such ACI is permitted by, and consistent with, the access + control scheme identified by the value of the accessControlScheme + attribute of the ACSP. + + +6. Access Control Information + + There are three categories of Access Control Information (ACI): + entry, subentry and prescriptive. + + Entry ACI applies to only the entry or subentry in which it appears, + and the contents thereof. Subject to the access control scheme, any + entry or subentry MAY hold entry ACI. + + Subentry ACI applies to only the subentries of the administrative + entry in which it appears. Subject to the access control scheme, any + administrative entry, for any aspect of administration, MAY hold + subentry ACI. + + Prescriptive ACI applies to all the entries within a subtree or + subtree refinement of an administrative area (either an ACSA or an + ACIA), as defined by the subtreeSpecification attribute of the + subentry in which it appears. Prescriptive ACI is only permitted in + subentries of an ACSP or ACIP. Prescriptive ACI in the subentries of + a particular administrative point never applies to the same or any + other subentry of that administrative point, but does apply to the + subentries of subordinate administrative points, where those + subentries are within the subtree or subtree refinement. + + +7. Access Control Subentries + + Each subentry which contains prescriptive ACI MUST have + accessControlSubentry as a value of its objectClass attribute. Such + a subentry is called an access control subentry. + + The LDAP description [RFC2252] for the accessControlSubentry + auxiliary object class is: + + + +Legg Expires 18 March 2003 [Page 4] + +INTERNET-DRAFT Access Control Administration September 18, 2002 + + + ( 2.5.17.1 NAME 'accessControlSubentry' AUXILIARY ) + + A subentry of this object class MUST contain at least one + prescriptive ACI attribute of a type consistent with the value of the + accessControlScheme attribute of the corresponding ACSP. + + The subtree or subtree refinement for an access control subentry is + termed a Directory Access Control Domain (DACD). A DACD can contain + zero entries, and can encompass entries that have not yet been added + to the DIT, but does not extend beyond the scope of the ACSA or ACIA + with which it is associated. + + Since a subtreeSpecification may define a subtree refinement, DACDs + within a given ACSA may arbitrarily overlap. + + +8. Applicable Access Control Information + + Although particular items of ACI may specify attributes or values as + the protected items, ACI is logically associated with entries. + + The ACI that is considered in access control decisions regarding an + entry includes: + + (1) Entry ACI from that particular entry. + + (2) Prescriptive ACI from access control subentries whose DACDs + contain the entry. Each of these access control subentries is + necessarily either a subordinate of the ACSP for the ACSA + containing the entry, or a subordinate of the ACIP for an ACIA + that contains the entry. + + The ACI that is considered in access control decisions regarding a + subentry includes: + + (1) Entry ACI from that particular subentry. + + (2) Prescriptive ACI from access control subentries whose DACDs + contain the subentry, excluding those belonging to the same + administrative point as the subentry for which the decision is + being made. + + (3) Subentry ACI from the administrative point associated with the + subentry. + + +9. Security Considerations + + + + +Legg Expires 18 March 2003 [Page 5] + +INTERNET-DRAFT Access Control Administration September 18, 2002 + + + This document defines a framework for employing an access control + scheme, i.e. the means by which access to directory information and + potentially to access rights themselves may be controlled, but does + not itself define any particular access control scheme. The degree + of protection provided, and any security risks, are determined by the + provisions of the access control schemes (defined elsewhere) making + use of this framework. + + Security considerations that apply to directory administration in + general [ADMIN] also apply to access control administration. + + +10. Acknowledgements + + This document is derived from, and duplicates substantial portions + of, Sections 4 and 8 of [X501]. + + +11. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute + Syntax Definitions", RFC 2252, December 1997. + + [ADMIN] Legg, S., "Directory Administrative Model in LDAP", + draft-legg-ldap-admin-xx.txt, a work in progress, + September 2002. + + [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP", + draft-zeilenga-ldap-subentry-xx.txt, a work in progress, + August 2002. + + +12. Informative References + + [BAC] Legg, S., "Basic and Simplified Access Control in LDAP", + draft-legg-ldap-acm-bac-xx.txt, a work in progress, + September 2002. + + [COLLECT] Zeilenga, K., "Collective Attributes in LDAP", + draft-zeilenga-ldap-collective-xx.txt, a work in progress, + August 2002. + + + +Legg Expires 18 March 2003 [Page 6] + +INTERNET-DRAFT Access Control Administration September 18, 2002 + + + [X501] ITU-T Recommendation X.501 (02/2001), Information + technology - Open Systems Interconnection - The Directory: + Models + + +13. Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +14. Author's Address + + Steven Legg + Adacel Technologies Ltd. + 405-409 Ferntree Gully Road + Mount Waverley, Victoria 3149 + AUSTRALIA + + Phone: +61 3 9451 2107 + Fax: +61 3 9541 2121 + EMail: steven.legg@adacel.com.au + + +15. Appendix A - Changes From Previous Drafts + + + +Legg Expires 18 March 2003 [Page 7] + +INTERNET-DRAFT Access Control Administration September 18, 2002 + + +15.1 Changes in Draft 01 + + Section 4 has been extracted to become a separate Internet draft, + draft-legg-ldap-admin-00.txt. The subsections of Section 5 have + become the new Sections 4 to 8. Editorial changes have been made to + accommodate this split. No technical changes have been introduced. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Legg Expires 18 March 2003 [Page 8] + diff --git a/doc/drafts/draft-legg-ldap-admin-xx.txt b/doc/drafts/draft-legg-ldap-admin-xx.txt new file mode 100644 index 0000000000..1ccd27c48c --- /dev/null +++ b/doc/drafts/draft-legg-ldap-admin-xx.txt @@ -0,0 +1,395 @@ + + + + + + +INTERNET-DRAFT S. Legg +draft-legg-ldap-admin-00.txt Adacel Technologies +Intended Category: Standards Track September 18, 2002 + + + Directory Administrative Model in LDAP + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + Status of this Memo + + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress". + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Distribution of this document is unlimited. Comments should be sent + to the LDUP working group mailing list or to the + author. + + This Internet-Draft expires on 18 March 2003. + + +1. Abstract + + This document adapts the X.500 directory administrative model for use + by the Lightweight Directory Access Protocol. The administrative + model partitions the Directory Information Tree for various aspects + of directory data administration, e.g. subschema, access control and + collective attributes. The generic framework that applies to every + aspect of administration is described in this document. The + definitions that apply for a specific aspect of administration, e.g. + access control administration, are described in other documents. + + + +Legg Expires 18 March 2003 [Page 1] + +INTERNET-DRAFT Directory Administrative Model September 18, 2002 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + +2. Table of Contents + + 1. Abstract .................................................... 1 + 2. Table of Contents ........................................... 2 + 3. Introduction ................................................ 2 + 4. Administrative Areas ........................................ 2 + 5. Autonomous Administrative Areas ............................. 3 + 6. Specific Administrative Areas ............................... 3 + 7. Inner Administrative Areas .................................. 4 + 8. Administrative Entries ...................................... 5 + 9. Security Considerations ..................................... 5 + 10. Acknowledgements ........................................... 5 + 11. Normative References ....................................... 5 + 12. Informative References ..................................... 6 + 13. Copyright Notice ........................................... 6 + 14. Author's Address ........................................... 6 + + +3. Introduction + + This document adapts the X.500 directory administrative model [X501] + for use by the Lightweight Directory Access Protocol (LDAP) + [RFC2251]. The administrative model partitions the Directory + Information Tree (DIT) for various aspects of directory data + administration, e.g. subschema, access control and collective + attributes. This document provides the definitions for the generic + parts of the administrative model that apply to every aspect of + directory data administration. + + Sections 4 to 8, in conjunction with [SUBENTRY], describe the means + by which administrative authority is aportioned and exercised in the + DIT. + + Aspects of administration that conform to the administrative model + described in this document are detailed elsewhere, e.g. access + control administration is described in [ACA] and collective attribute + administration is described in [COLLECT]. + + This document is derived from, and duplicates substantial portions + of, Sections 4 and 8 of [X501]. + + +4. Administrative Areas + + + +Legg Expires 18 March 2003 [Page 2] + +INTERNET-DRAFT Directory Administrative Model September 18, 2002 + + + An administrative area is a subtree of the DIT considered from the + perspective of administration. The root entry of the subtree is an + administrative point. An administrative point is represented by an + entry holding an administrativeRole attribute [SUBENTRY]. The values + of this attribute identify the kind of administrative point. + + +5. Autonomous Administrative Areas + + The DIT may be partitioned into one or more non-overlapping subtrees + termed autonomous administrative areas. It is expected that the + entries in an autonomous administrative area are all administered by + the same administrative authority. + + An administrative authority may be responsible for several autonomous + administrative areas in separated parts of the DIT but it SHOULD NOT + arbitrarily partition the collection of entries under its control + into autonomous administrative areas (thus creating adjacent + autonomous areas administered by the same authority). + + The root entry of an autonomous administrative area's subtree is + called an autonomous administrative point. An autonomous + administrative area extends from its autonomous administrative point + downwards until another autonomous administrative point is + encountered, at which point another autonomous administrative area + begins. + + +6. Specific Administrative Areas + + Entries in an administrative area may be considered in terms of a + specific administrative function. When viewed in this context, an + administrative area is termed a specific administrative area. + + Examples of specific administrative areas are subschema specific + administrative areas, access control specific areas and collective + attribute specific areas. + + An autonomous administrative area may be considered as implicitly + defining a single specific administrative area for each specific + aspect of administration. In this case, there is a precise + correspondence between each such specific administrative area and the + autonomous administrative area. + + Alternatively, for each specific aspect of administration, the + autonomous administrative area may be partitioned into + non-overlapping specific administrative areas. + + + + +Legg Expires 18 March 2003 [Page 3] + +INTERNET-DRAFT Directory Administrative Model September 18, 2002 + + + If so partitioned for a particular aspect of administration, each + entry of the autonomous administrative area is contained in one and + only one specific administrative area for that aspect, i.e. specific + administrative areas do not overlap. + + The root entry of a specific administrative area's subtree is called + a specific administrative point. A specific administrative area + extends from its specific administrative point downwards until + another specific administrative point of the same administrative + aspect is encountered, at which point another specific administrative + area begins. Specific administrative areas are always bounded by the + autonomous administrative area they partition. + + Where an autonomous administrative area is not partitioned for a + specific aspect of administration, the specific administrative area + for that aspect coincides with the autonomous administrative area. + In this case, the autonomous administrative point is also the + specific administrative point for this aspect of administration. A + particular administrative point may be the root of an autonomous + administrative area and may be the root of one or more specific + administrative areas for different aspects of administration. + + It is not necessary for an administrative point to represent each + specific aspect of administrative authority. For example, there + might be an administrative point, subordinate to the root of the + autonomous administrative area, which is used for access control + purposes only. + + +7. Inner Administrative Areas + + For some aspects of administration, e.g. access control or collective + attributes, inner administrative areas may be defined within the + specific administrative areas, to allow a limited form of delegation, + or for administrative or operational convenience. + + An inner administrative area may be nested within another inner + administrative area. The rules for nested inner areas are defined as + part of the definition of the specific administrative aspect for + which they are allowed. + + The root entry of an inner administrative area's subtree is called an + inner administrative point. An inner administrative area (within a + specific administrative area) extends from its inner administrative + point downwards until a specific administrative point of the same + administrative aspect is encountered. An inner administrative area + is bounded by the specific administrative area within which it is + defined. + + + +Legg Expires 18 March 2003 [Page 4] + +INTERNET-DRAFT Directory Administrative Model September 18, 2002 + + +8. Administrative Entries + + An entry located at an administrative point is an administrative + entry. Administrative entries MAY have subentries [SUBENTRY] as + immediate subordinates. The administrative entry and its associated + subentries are used to control the entries encompassed by the + associated administrative area. Where inner administrative areas are + used, the scopes of these areas may overlap. Therefore, for each + specific aspect of administrative authority, a definition is required + of the method of combination of administrative information when it is + possible for entries to be included in more than one subtree or + subtree refinement associated with an inner area defined for that + aspect. + + +9. Security Considerations + + This document defines a generic framework for employing policy of + various kinds, e.g. access controls, to entries in the DIT. Such + policy can only be correctly enforced at a directory server holding a + replica of a portion of the DIT if the administrative entries for + administrative areas that overlap the portion of the DIT being + replicated, and the subentries of those administrative entries + relevant to any aspect of policy that is required to be enforced at + the replica, are included in the replicated information. + + Administrative entries and subentries SHOULD be protected from + unauthorized examination or changes by appropriate access controls. + + +10. Acknowledgements + + This document is derived from, and duplicates substantial portions + of, Sections 4 and 8 of [X501]. + + +11. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP", + draft-zeilenga-ldap-subentry-xx.txt, a work in progress, + August 2002. + + + + +Legg Expires 18 March 2003 [Page 5] + +INTERNET-DRAFT Directory Administrative Model September 18, 2002 + + +12. Informative References + + [ACA] Legg, S., "Access Control Administration in LDAP", + draft-legg-ldap-acm-admin-xx.txt, a work in progress, + September 2002. + + [COLLECT] Zeilenga, K., "Collective Attributes in LDAP", + draft-zeilenga-ldap-collective-xx.txt, a work in progress, + August 2002. + + [X501] ITU-T Recommendation X.501 (02/2001), Information + technology - Open Systems Interconnection - The Directory: + Models + + +13. Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +14. Author's Address + + Steven Legg + Adacel Technologies Ltd. + + + +Legg Expires 18 March 2003 [Page 6] + +INTERNET-DRAFT Directory Administrative Model September 18, 2002 + + + 405-409 Ferntree Gully Road + Mount Waverley, Victoria 3149 + AUSTRALIA + + Phone: +61 3 9451 2107 + Fax: +61 3 9541 2121 + EMail: steven.legg@adacel.com.au + + +15. Appendix A - Changes From Previous Drafts + + This document reproduces Section 4 from + draft-legg-ldap-acm-admin-00.txt as a standalone document. All + changes made are purely editorial. No technical changes have been + introduced. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Legg Expires 18 March 2003 [Page 7] + diff --git a/doc/drafts/draft-legg-ldap-gser-abnf-xx.txt b/doc/drafts/draft-legg-ldap-gser-abnf-xx.txt new file mode 100644 index 0000000000..fec416fb22 --- /dev/null +++ b/doc/drafts/draft-legg-ldap-gser-abnf-xx.txt @@ -0,0 +1,619 @@ + + + + + + +INTERNET-DRAFT S. Legg +draft-legg-ldap-gser-abnf-04.txt Adacel Technologies +Intended Category: Informational August 19, 2002 + + + Common Elements of GSER Encodings + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + Status of this Memo + + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress". + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Distribution of this document is unlimited. Comments should be sent + to the LDAPEXT working group mailing list + or to the author. + + This Internet-Draft expires on 19 February 2002. + + +1. Abstract + + The Generic String Encoding Rules (GSER) describe a human readable + text encoding for an ASN.1 value of any ASN.1 type. Specifications + making use of GSER may wish to provide an equivalent ABNF description + of the GSER encoding for a particular ASN.1 type as a convenience for + implementors. This document supports such specifications by + providing equivalent ABNF for the GSER encodings for ASN.1 types + commonly occuring in Lightweight Directory Access Protocol (LDAP) + syntaxes. + + + +Legg Expires 19 February 2002 [Page 1] + +INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002 + + +2. Table of Contents + + 1. Abstract .................................................... 1 + 2. Table of Contents ........................................... 2 + 3. Introduction ................................................ 2 + 4. Conventions ................................................. 2 + 5. Separators .................................................. 2 + 6. ASN.1 Built-in Types ........................................ 3 + 7. ASN.1 Restricted String Types ............................... 7 + 8. Directory ASN.1 Types ....................................... 8 + 9. Security Considerations ..................................... 9 + 10. Normative References ....................................... 10 + 11. Informative References ..................................... 10 + 12. Copyright Notice ........................................... 10 + 13. Author's Address ........................................... 11 + + +3. Introduction + + The Generic String Encoding Rules (GSER) defined in [9] define a + human readable text encoding, based on ASN.1 [7] value notation, for + an ASN.1 value of any ASN.1 type. Specifications making use of GSER + may wish to provide a non-normative equivalent ABNF [3] description + of the GSER encoding for a particular ASN.1 type as a convenience for + implementors unfamiliar with ASN.1. This document supports such + specifications by providing equivalent ABNF for the GSER encodings + for ASN.1 types commonly occuring in LDAP [8] or X.500 [10] attribute + and assertion syntaxes, as well as equivalent ABNF for the GSER + encodings for the ASN.1 built-in types. + + The ABNF given in this document does not replace or alter GSER in any + way. If there is a discrepancy between the ABNF specified here and + the encoding defined by GSER in [9] then [9] is to be taken as + definitive. + + +4. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + +5. Separators + + Certain separators are commonly used in constructing equivalent ABNF + for SET and SEQUENCE types. + + + + +Legg Expires 19 February 2002 [Page 2] + +INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002 + + + sp = *%x20 ; zero, one or more space characters + msp = 1*%x20 ; one or more space characters + + sep = [ "," ] + + The rule is used in the ABNF description of the encoding for + ASN.1 SET or SEQUENCE types where all the components are either + OPTIONAL or DEFAULT. It encodes to an empty string if and only if + the immediately preceding character in the encoding is "{", i.e. it + is only empty for the first optional component actually present in + the SET or SEQUENCE value being encoded. + + +6. ASN.1 Built-in Types + + This section describes the GSER encoding of values of the ASN.1 + built-in types, except for the restricted character string types. + + The rule describes the GSER encoding of values of the + BIT STRING type without a named bit list. + + BIT-STRING = bstring / hstring + + If the number of bits in a BIT STRING value is a multiple of four the + form of MAY be used. The form of + is used otherwise. The rule encodes each bit + as the character "0" or "1" in order from the first bit to the last + bit. The rule encodes each group of four bits as a + hexadecimal number where the first bit is the most significant. An + odd number of hexadecimal digits is permitted. + + hstring = squote *hexadecimal-digit squote %x48 ; '...'H + hexadecimal-digit = %x30-39 / ; "0" to "9" + %x41-46 ; "A" to "F" + + bstring = squote *binary-digit squote %x42 ; '...'B + binary-digit = "0" / "1" + + squote = %x27 ; ' (single quote) + + The rule describes the GSER encoding of values of the + BOOLEAN type. + + BOOLEAN = %x54.52.55.45 / ; "TRUE" + %x46.41.4C.53.45 ; "FALSE" + + The rule describes the GSER encoding of values of + the associated type for the unrestricted CHARACTER STRING type. + + + +Legg Expires 19 February 2002 [Page 3] + +INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002 + + + CHARACTER-STRING = "{" sp id-identification msp Identification "," + sp id-data-value msp OCTET-STRING + sp "}" + + id-identification = %x69.64.65.6E.74.69.66.69.63.61.74.69.6F.6E + ; "identification" + id-data-value = %x64.61.74.61.2D.76.61.6C.75.65 ; "data-value" + + Identification = ( id-syntaxes ":" Syntaxes ) / + ( id-syntax ":" OBJECT-IDENTIFIER ) / + ( id-presentation-context-id ":" INTEGER ) / + ( id-context-negotiation ":" + ContextNegotiation ) / + ( id-transfer-syntax ":" OBJECT-IDENTIFIER ) / + ( id-fixed ":" NULL ) + + id-syntaxes = %x73.79.6E.74.61.78.65.73 + ; "syntaxes" + id-syntax = %x73.79.6E.74.61.78 ; "syntax" + id-presentation-context-id = %x70.72.65.73.65.6E.74.61.74.69.6F.6E + %x2D.63.6F.6E.74.65.78.74.2D.69.64 + ; "presentation-context-id" + id-context-negotiation = %x63.6F.6E.74.65.78.74.2D.6E.65.67.6F + %x74.69.61.74.69.6F.6E + ; "context-negotiation" + id-transfer-syntax = %x74.72.61.6E.73.66.65.72.2D.73.79.6E + %x74.61.78 ; "transfer-syntax" + id-fixed = %x66.69.78.65.64 ; "fixed" + + Syntaxes = "{" sp id-abstract msp OBJECT-IDENTIFIER "," + sp id-transfer msp OBJECT-IDENTIFIER + sp "}" + id-abstract = %x61.62.73.74.72.61.63.74 ; "abstract" + id-transfer = %x74.72.61.6E.73.66.65.72 ; "transfer" + + ContextNegotiation = "{" sp id-presentation-context-id msp + INTEGER "," + sp id-transfer-syntax msp + OBJECT-IDENTIFIER + sp "}" + + The rule describes the GSER encoding of values of the + INTEGER type without a named number list. The rule + describes the GSER encoding of values of the constrained type INTEGER + (0..MAX). The rule describes the GSER encoding of + values of the constrained type INTEGER (1..MAX). + + INTEGER = "0" / positive-number / ("-" positive-number) + + + +Legg Expires 19 February 2002 [Page 4] + +INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002 + + + INTEGER-0-MAX = "0" / positive-number + INTEGER-1-MAX = positive-number + positive-number = non-zero-digit *decimal-digit + decimal-digit = %x30-39 ; "0" to "9" + non-zero-digit = %x31-39 ; "1" to "9" + + The rule describes the GSER encoding of values of the + associated type for the EMBEDDED PDV type. + + EMBEDDED-PDV = "{" sp id-identification msp Identification + [ "," sp id-data-value-descriptor msp + ObjectDescriptor ] + "," sp id-data-value msp OCTET-STRING + sp "}" + + id-data-value-descriptor = %x64.61.74.61.2D.76.61.6C.75.65.2D.64 + %x65.73.63.72.69.70.74.6F.72 + ; "data-value-descriptor" + + The rule describes the GSER encoding of values of the + associated type for the EXTERNAL type. + + EXTERNAL = "{" sp id-identification msp E-Identification + [ "," sp id-data-value-descriptor msp + ObjectDescriptor ] + "," sp id-data-value msp OCTET-STRING + sp "}" + + E-Identification = ( id-syntax ":" OBJECT-IDENTIFIER ) / + ( id-presentation-context-id ":" INTEGER ) / + ( id-context-negotiation ":" + ContextNegotiation ) + + The rule describes the GSER encoding of values of the NULL + type. + + NULL = %x4E.55.4C.4C ; "NULL" + + The rule describes the GSER encoding of values of + the OBJECT IDENTIFIER type. + + OBJECT-IDENTIFIER = numeric-oid / descr + numeric-oid = oid-component 1*( "." oid-component ) + oid-component = "0" / positive-number + + An OBJECT IDENTIFIER value is encoded using either the dotted decimal + representation or an object descriptor name, i.e. . The + rule is described in [4]. An object descriptor name is + + + +Legg Expires 19 February 2002 [Page 5] + +INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002 + + + potentially ambiguous and should be used with care. + + The rule describes the GSER encoding of values of the + OCTET STRING type. + + OCTET-STRING = hstring + + The octets are encoded in order from the first octet to the last + octet. Each octet is encoded as a pair of hexadecimal digits where + the first digit corresponds to the four most significant bits of the + octet. If the hexadecimal string does not have an even number of + digits the four least significant bits in the last octet are assumed + to be zero. + + The rule describes the GSER encoding of values of the REAL + type. + + REAL = "0" ; zero + / PLUS-INFINITY ; positive infinity + / MINUS-INFINITY ; negative infinity + / realnumber ; positive base 10 REAL value + / ( "-" realnumber ) ; negative base 10 REAL value + / real-sequence-value ; non-zero base 2 or 10 REAL value + + PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59 + ; "PLUS-INFINITY" + MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59 + ; "MINUS-INFINITY" + + realnumber = mantissa exponent + mantissa = (positive-number [ "." *decimal-digit ]) + / ( "0." *("0") positive-number ) + exponent = "E" ( "0" / ([ "-" ] positive-number)) + + real-sequence-value = "{" sp id-mantissa msp INTEGER "," + sp id-base msp ( "2" / "10" ) "," + sp id-exponent msp INTEGER sp "}" + id-mantissa = %x6D.61.6E.74.69.73.73.61 ; "mantissa" + id-base = %x62.61.73.65 ; "base" + id-exponent = %x65.78.70.6F.6E.65.6E.74 ; "exponent" + + A value of the REAL type MUST be encoded as "0" if it is zero. + + The rule describes the GSER encoding of values of the + RELATIVE-OID type. + + RELATIVE-OID = oid-component *( "." oid-component ) + + + + +Legg Expires 19 February 2002 [Page 6] + +INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002 + + +7. ASN.1 Restricted String Types + + This section describes the GSER encoding of values of the ASN.1 + restricted character string types. The characters of a value of a + restricted character string type are always encoded as a UTF8 + character string between double quotes. For some of the ASN.1 string + types this requires a translation to or form the UTF8 encoding. Some + of the ASN.1 string types permit only a subset of the characters + representable in UTF8. Any double quote characters in the character + string, where allowed by the character set, are escaped by being + repeated. + + The rule describes the GSER encoding of values of the + UTF8String type. The characters of this string type do not require + any translation before being encoded. + + UTF8String = StringValue + StringValue = dquote *SafeUTF8Character dquote + + dquote = %x22 ; " (double quote) + + SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote + dquote dquote / ; escaped double quote + %xC0-DF %x80-BF / ; 2 byte UTF8 character + %xE0-EF 2(%x80-BF) / ; 3 byte UTF8 character + %xF0-F7 3(%x80-BF) / ; 4 byte UTF8 character + %xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character + %xFC-FD 5(%x80-BF) ; 6 byte UTF8 character + + The , , , + , , and rules + describe the GSER encoding of values of the correspondingly named + ASN.1 types. The characters of these string types are compatible + with UTF8 and do not require any translation before being encoded. + The GeneralizedTime and UTCTime types use the VisibleString character + set, but have a strictly defined format. + + NumericString = dquote *(decimal-digit / space) dquote + space = %x20 + + PrintableString = dquote *PrintableCharacter dquote + PrintableCharacter = decimal-digit / space + / %x41-5A ; A to Z + / %x61-7A ; a to z + / %x27-29 ; ' ( ) + / %x2B-2F ; + , - . / + / %x3A ; : + / %x3D ; = + + + +Legg Expires 19 February 2002 [Page 7] + +INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002 + + + / %x3F ; ? + + ISO646String = VisibleString + VisibleString = dquote *SafeVisibleCharacter dquote + SafeVisibleCharacter = %x20-21 + / %x23-7E ; printable ASCII minus dquote + / dquote dquote ; escaped double quote + + IA5String = dquote *SafeIA5Character dquote + SafeIA5Character = %x00-21 / %x23-7F ; ASCII minus dquote + / dquote dquote ; escaped double quote + + UTCTime = dquote 10(decimal-digit) [2(decimal-digit)] + [ "Z" / u-differential ] dquote + u-differential = ( "-" / "+" ) 4(decimal-digit) + GeneralizedTime = dquote 10(decimal-digit) + *2(2(decimal-digit)) + fraction [ "Z" / g-differential ] dquote + fraction = ( "." / "," ) 1*decimal-digit + g-differential = ( "-" / "+" ) 1*2(2(decimal-digit)) + + The and rules describe the GSER + encoding of values of the BMPString and UniversalString types + respectively. BMPString (UCS-2) and UniversalString (UCS-4) values + are translated into UTF8 [6] character strings before being encoded + according to . + + BMPString = StringValue + UniversalString = StringValue + + The , , , , + and rules describe the GSER + encoding of values of the correspondingly named ASN.1 types. Values + of these string types are translated into UTF8 character strings + before being encoded according to . The + ObjectDescriptor type uses the GraphicString character set. + + TeletexString = StringValue + T61String = StringValue + VideotexString = StringValue + GraphicString = StringValue + GeneralString = StringValue + ObjectDescriptor = GraphicString + + +8. Directory ASN.1 Types + + This section describes the GSER encoding of values of selected ASN.1 + + + +Legg Expires 19 February 2002 [Page 8] + +INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002 + + + types defined for LDAP and X.500. The ABNF rule names beginning with + uppercase letters describe the GSER encoding of values of the ASN.1 + type with the same name. + + AttributeType = OBJECT-IDENTIFIER + + The characters of a DirectoryString are translated into UTF8 + characters as required before being encoded between double quotes + with any embedded double quotes escaped by being repeated. + + DirectoryString = dquote *SafeUTF8Character dquote + + The rule describes the GSER encoding of values of the + RDNSequence type, which is syntactically equivalent to the + DistinguishedName and LocalName types. The rule + encodes a name as an LDAPDN character string between double quotes. + The character string is first derived according to the + rule in Section 3 of [5], and then it is encoded + between double quotes with any embedded double quotes escaped by + being repeated. + + DistinguishedName = RDNSequence + LocalName = RDNSequence + RDNSequence = dquote *SafeUTF8Character dquote + + The rule describes the GSER encoding of + values of the RelativeDistinguishedName type that are not part of an + RDNSequence value. The rule encodes an + RDN as a double quoted string containing the RDN as it would appear + in an LDAPDN character string. The character string is first derived + according to the rule in Section 3 of [6], and then + any embedded double quote characters are escaped by being repeated. + This resulting string is output between double quotes. + + RelativeDistinguishedName = dquote *SafeUTF8Character dquote + + The rule encodes an X.400 address as an IA5 character + string between double quotes. The character string is first derived + according to Section 4.1 of [2], and then any embedded double quotes + are escaped by being repeated. This resulting string is output + between double quotes. + + ORAddress = dquote *SafeIA5Character dquote + + +9. Security Considerations + + GSER, and therefore the ABNF encodings described in this document, do + + + +Legg Expires 19 February 2002 [Page 9] + +INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002 + + + not necessarily enable the exact octet encoding of values of the + TeletexString, VideotexString, GraphicString or GeneralString types + to be reconstructed, so a transformation from DER to GSER and back to + DER may not reproduce the original DER encoding. This has + consequences for the verification of digital signatures. + + +10. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping + between X.400 and RFC 822/MIME", RFC 2156, January 1998. + + [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight + Directory Access Protocol (v3): Attribute Syntax Definitions", + RFC 2252, December 1997. + + [5] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished + Names", RFC 2253, December 1997. + + [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + [7] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998 + Information Technology - Abstract Syntax Notation One (ASN.1): + Specification of basic notation + + +11. Informative References + + [8] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access + Protocol (v3)", RFC 2251, December 1997. + + [9] Legg, S., "Generic String Encoding Rules for ASN.1 Types", + draft-legg-ldap-gser-xx.txt, a work in progress, August 2002. + + [10] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, + Information Technology - Open Systems Interconnection - The + Directory: Overview of concepts, models and services + + +12. Copyright Notice + + + +Legg Expires 19 February 2002 [Page 10] + +INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002 + + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +13. Author's Address + + Steven Legg + Adacel Technologies Ltd. + 405-409 Ferntree Gully Road + Mount Waverley, Victoria 3149 + AUSTRALIA + + Phone: +61 3 9451 2107 + Fax: +61 3 9541 2121 + EMail: steven.legg@adacel.com.au + + + + + + + + + + + + + +Legg Expires 19 February 2002 [Page 11] + diff --git a/doc/drafts/draft-legg-ldap-gser-xx.txt b/doc/drafts/draft-legg-ldap-gser-xx.txt new file mode 100644 index 0000000000..6a34445acc --- /dev/null +++ b/doc/drafts/draft-legg-ldap-gser-xx.txt @@ -0,0 +1,899 @@ + + + + + + +INTERNET-DRAFT S. Legg +draft-legg-ldap-gser-01.txt Adacel Technologies +Intended Category: Standard Track August 19, 2002 + + + Generic String Encoding Rules for ASN.1 Types + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + Status of this Memo + + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress". + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Distribution of this document is unlimited. Comments should be sent + to the LDAPEXT working group mailing list + or to the author. + + This Internet-Draft expires on 19 February 2002. + + +1. Abstract + + This document defines a set of Abstract Syntax Notation One (ASN.1) + encoding rules, called the Generic String Encoding Rules, that + produce a human readable text encoding for values of any given ASN.1 + data type. + + + + + + + +Legg Expires 19 February 2002 [Page 1] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + +2. Table of Contents + + 1. Abstract ...................................................... 1 + 2. Table of Contents ............................................. 2 + 3. Introduction .................................................. 2 + 4. Conventions ................................................... 3 + 5. Generic String Encoding Rules ................................. 3 + 5.1 Type Referencing Notations ................................ 4 + 5.2 Restricted Character String Types ......................... 4 + 5.3 ChoiceOfStrings Types ..................................... 5 + 5.4 Identifiers ............................................... 7 + 5.5 BIT STRING ................................................ 7 + 5.6 BOOLEAN ................................................... 8 + 5.7 ENUMERATED ................................................ 8 + 5.8 INTEGER ................................................... 8 + 5.9 NULL ...................................................... 8 + 5.10 OBJECT IDENTIFIER and RELATIVE-OID ....................... 9 + 5.11 OCTET STRING ............................................. 9 + 5.12 CHOICE ................................................... 9 + 5.13 SEQUENCE and SET ......................................... 10 + 5.14 SEQUENCE OF and SET OF ................................... 11 + 5.15 CHARACTER STRING ......................................... 11 + 5.16 EMBEDDED PDV ............................................. 11 + 5.17 EXTERNAL ................................................. 11 + 5.18 INSTANCE OF .............................................. 12 + 5.19 REAL ..................................................... 12 + 5.20 Variant Encodings ........................................ 12 + 6. GSER Transfer Syntax .......................................... 13 + 7. Security Considerations ....................................... 13 + 8. Normative References .......................................... 13 + 9. Informative References ........................................ 14 + 10. Copyright Notice ............................................. 15 + 11. Author's Address ............................................. 15 + + +3. Introduction + + This document defines a set of ASN.1 [8] encoding rules, called the + Generic String Encoding Rules or GSER, that produce a human readable + UTF8 [6] character string encoding of ASN.1 values of any given + arbitrary ASN.1 type. + + Note that "ASN.1 value" does not mean a BER [17] encoded value. The + ASN.1 value is an abstract concept that is independent of any + particular encoding. BER is just one possible encoding of an ASN.1 + value. + + GSER is based on ASN.1 value notation [8], with changes to + + + +Legg Expires 19 February 2002 [Page 2] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + accommodate the notation's use as a transfer syntax, and to support + well established ad-hoc string encodings for LDAP [13] directory data + types. + + Though primarily intended for defining the LDAP-specific encoding of + new LDAP attribute syntaxes and assertion syntaxes, these encoding + rules could also be used in other domains where human readable + renderings of ASN.1 values would be useful. + + Referencing the Generic String Encoding Rules (GSER) is sufficient to + define a human readable text encoding for values of a specific ASN.1 + type, however other specifications may wish to provide a customized + ABNF [3] description, independent of the ASN.1, as a convenience for + the implementor (equivalent ABNF for the GSER encodings for ASN.1 + types commonly occuring in LDAP syntaxes is provided in [14]). Such + a specification SHOULD state that if there is a discrepancy between + the customized ABNF and the GSER encoding defined by this document, + that the GSER encoding takes precedence. + + +4. Conventions + + Throughout this document "type" shall be taken to mean an ASN.1 type, + and "value" shall be taken to mean an ASN.1 value. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + +5. Generic String Encoding Rules + + The GSER encoding of a value of any ASN.1 type is described by the + following ABNF [3]: + + Value = BitStringValue / + BooleanValue / + CharacterStringValue / + ChoiceValue / + EmbeddedPDVValue / + EnumeratedValue / + ExternalValue / + GeneralizedTimeValue / + IntegerValue / + InstanceOfValue / + NullValue / + ObjectDescriptorValue / + ObjectIdentifierValue / + + + +Legg Expires 19 February 2002 [Page 3] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + OctetStringValue / + RealValue / + RelativeOIDValue / + SequenceOfValue / + SequenceValue / + SetOfValue / + SetValue / + StringValue / + UTCTimeValue / + VariantEncoding + + The ABNF for each of the above rules is given in the following + sections. + + +5.1 Type Referencing Notations + + A value of a type with a defined type name is encoded according to + the type definition on the right hand side of the type assignment for + the type name. + + A value of a type denoted by the use of a parameterized type with + actual parameters is encoded according to the parameterized type with + the DummyReferences [12] substituted with the actual parameters. + + A value of a tagged or constrained type is encoded as a value of the + type without the tag or constraint, respectively. Tags do not appear + in the string encodings defined by this document. See [8] and [11] + for the details of ASN.1 constraint notation. + + A value of an open type denoted by an ObjectClassFieldType (Clause 14 + of [10]) is encoded according to the specific type of the value. + + A value of a fixed type denoted by an ObjectClassFieldType is encoded + according to that fixed type. + + A value of a selection type is encoded according to the type + referenced by the selection type. + + A value of a type described by TypeFromObject notation (Clause 15 of + [10]) is encoded according to the denoted type. + + A value of a type described by ValueSetFromObjects notation (Clause + 15 of [10]) is encoded according to the governing type. + + +5.2 Restricted Character String Types + + + + +Legg Expires 19 February 2002 [Page 4] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + The contents of a string value are encoded as a UTF8 character string + between double quotes, regardless of the ASN.1 string type. + Depending on the ASN.1 string type, and an application's internal + representation of that string type, a translation to or from the UTF8 + character encoding may be required. NumericString, PrintableString, + IA5String, VisibleString (ISO646String) are compatible with UTF8 and + do not require any translation. BMPString (UCS-2) and + UniversalString (UCS-4) have a direct mapping to and from UTF8 [6]. + For the remaining string types see [8]. Any embedded double quotes + in the resulting UTF8 character string are escaped by repeating the + double quote characters. + + A value of the NumericString, PrintableString, TeletexString + (T61String), VideotexString, IA5String, GraphicString, VisibleString + (ISO646String), GeneralString, BMPString, UniversalString or + UTF8String type is encoded according to the rule. + + StringValue = dquote *SafeUTF8Character dquote + + dquote = %x22 ; " (double quote) + + SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote + dquote dquote / ; escaped double quote + %xC0-DF %x80-BF / ; 2 byte UTF8 character + %xE0-EF 2(%x80-BF) / ; 3 byte UTF8 character + %xF0-F7 3(%x80-BF) / ; 4 byte UTF8 character + %xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character + %xFC-FD 5(%x80-BF) ; 6 byte UTF8 character + + A value of the GeneralizedTime type, UTCTime type or ObjectDescriptor + type is encoded as a string value. GeneralizedTime and UTCTime use + the VisibleString character set so the conversion to UTF8 is trivial. + ObjectDescriptor uses the GraphicString type. + + GeneralizedTimeValue = StringValue + UTCTimeValue = StringValue + ObjectDescriptorValue = StringValue + + +5.3 ChoiceOfStrings Types + + It is not uncommon for ASN.1 specifications to define types that are + a CHOICE between two or more alternative ASN.1 string types, where + the particular alternative chosen carries no semantic significance + (DirectoryString [7] being a prime example). Such types are defined + to avoid having to use a complicated character encoding for all + values when most values could use a simpler string type, or to deal + with evolving requirements that compel the use of a broader character + + + +Legg Expires 19 February 2002 [Page 5] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + set while still maintaining backward compatibility. + + GSER encodes values of all the ASN.1 string types as UTF8 character + strings so the alternative chosen in a purely syntactic CHOICE of + string types makes no material difference to the final encoding of + the string value. + + While there are certain ASN.1 constructs that betray the semantic + significance of the alternatives within a CHOICE type, the absence of + those constructs does not necessarily mean a CHOICE type is purely + syntactic. Therefore, it is necessary for specifications to declare + the purely syntactic CHOICE types so that they may be more compactly + encoded (see Section 5.12). These declared CHOICE types are referred + to as ChoiceOfStrings types. + + To be eligible to be declared a ChoiceOfStrings type an ASN.1 type + MUST satisfy the following conditions. + + a) The type is a CHOICE type. + + b) The component type of each alternative is one of the following + ASN.1 restricted string types: NumericString, PrintableString, + TeletexString (T61String), VideotexString, IA5String, + GraphicString, VisibleString (ISO646String), GeneralString, + BMPString, UniversalString or UTF8String. + + c) All the alternatives are of different restricted string types, + i.e. no two alternatives have the same ASN.1 restricted string + type. + + d) Either none of the alternatives has a constraint, or all of the + alternatives have exactly the same constraint. + + Tagging on the alternative types is ignored. + + Consider the ASN.1 parameterized type definition of DirectoryString. + + DirectoryString { INTEGER : maxSize } ::= CHOICE { + teletexString TeletexString (SIZE (1..maxSize)), + printableString PrintableString (SIZE (1..maxSize)), + bmpString BMPString (SIZE (1..maxSize)), + universalString UniversalString (SIZE (1..maxSize)), + uTF8String UTF8String (SIZE (1..maxSize)) } + + Any use of the DirectoryString parameterized type with an actual + parameter defines a ASN.1 type that satisfies the above conditions. + Recognising that the alternative within a DirectoryString carries no + semantic significance, this document declares (each and every use of) + + + +Legg Expires 19 February 2002 [Page 6] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + DirectoryString{} to be a ChoiceOfStrings type. + + Other specifications MAY declare other types satisfying the above + conditions to be ChoiceOfStrings types. The declaration SHOULD be + made at the point where the ASN.1 type is defined, otherwise it + SHOULD be made at the point where it is introduced as, or in, an LDAP + attribute or assertion syntax. + + +5.4 Identifiers + + An conforms to the definition of an identifier in ASN.1 + notation (Clause 11.3 of [8]). It begins with a lowercase letter and + is followed by zero or more letters, digits, and hyphens. A hyphen + is not permitted to be the last character and a hyphen is not + permitted to be followed by another hyphen. The case of letters in + an identifier is always significant. + + identifier = lowercase *alphanumeric *(hyphen 1*alphanumeric) + alphanumeric = uppercase / lowercase / decimal-digit + uppercase = %x41-5A ; "A" to "Z" + lowercase = %x61-7A ; "a" to "z" + decimal-digit = %x30-39 ; "0" to "9" + hyphen = "-" + + +5.5 BIT STRING + + A value of the BIT STRING type is encoded according to the + rule. If the definition of the BIT STRING type + includes a named bit list, the form of + rule MAY be used. If the number of bits in a BIT STRING value is a + multiple of four the form of MAY be used. + The form of is used otherwise. + + BitStringValue = bstring / hstring / bit-list + + The rule encodes the one bits in the bit string value as a + comma separated list of identifiers. Each MUST be one + of those in the named bit list. An MUST NOT appear more + than once in the same . The rule encodes each + bit as the character "0" or "1" in order from the first bit to the + last bit. The rule encodes each group of four bits as a + hexadecimal number where the first bit is the most significant. An + odd number of hexadecimal digits is permitted. + + bit-list = "{" [ sp identifier + *( "," sp identifier ) ] sp "}" + + + +Legg Expires 19 February 2002 [Page 7] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + hstring = squote *hexadecimal-digit squote %x48 ; '...'H + hexadecimal-digit = %x30-39 / ; "0" to "9" + %x41-46 ; "A" to "F" + + bstring = squote *binary-digit squote %x42 ; '...'B + binary-digit = "0" / "1" + + sp = *%x20 ; zero, one or more space characters + squote = %x27 ; ' (single quote) + + +5.6 BOOLEAN + + A value of the BOOLEAN type is encoded according to the + rule. + + BooleanValue = %x54.52.55.45 / ; "TRUE" + %x46.41.4C.53.45 ; "FALSE" + + +5.7 ENUMERATED + + A value of the ENUMERATED type is encoded according to the + rule. The MUST be one of those in the + list of enumerations in the definition of the ENUMERATED type. + + EnumeratedValue = identifier + + +5.8 INTEGER + + A value of the INTEGER type is encoded according to the + rule. If the definition of the INTEGER type includes + a named number list, the form of MAY be + used, in which case the MUST be one of those in the + named number list. + + IntegerValue = "0" / + positive-number / + ("-" positive-number) / + identifier + + positive-number = non-zero-digit *decimal-digit + non-zero-digit = %x31-39 ; "1" to "9" + + +5.9 NULL + + + + +Legg Expires 19 February 2002 [Page 8] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + A value of the NULL type is encoded according to the + rule. + + NullValue = %x4E.55.4C.4C ; "NULL" + + +5.10 OBJECT IDENTIFIER and RELATIVE-OID + + A value of the OBJECT IDENTIFIER type is encoded according to the + rule. The rule + allows either a dotted decimal representation of the OBJECT + IDENTIFIER value or an object descriptor name, i.e. . The + rule is described in [4]. An object descriptor name is + potentially ambiguous and should be used with care. + + ObjectIdentifierValue = numeric-oid / descr + numeric-oid = oid-component 1*( "." oid-component ) + oid-component = "0" / positive-number + + A value of the RELATIVE-OID [9] type is encoded according to the + rule. + + RelativeOIDValue = oid-component *( "." oid-component ) + + +5.11 OCTET STRING + + A value of the OCTET STRING type is encoded according to the + rule. The octets are encoded in order from the + first octet to the last octet. Each octet is encoded as a pair of + hexadecimal digits where the first digit corresponds to the four most + significant bits of the octet. If the hexadecimal string does not + have an even number of digits the four least significant bits in the + last octet are assumed to be zero. + + OctetStringValue = hstring + + +5.12 CHOICE + + A value of a CHOICE type is encoded according to the + rule. The encoding MAY be used if the + corresponding CHOICE type has been declared a ChoiceOfStrings type. + This document declares DirectoryString to be a ChoiceOfStrings type + (see Section 5.3). The form of + is used otherwise. + + ChoiceValue = IdentifiedChoiceValue / + + + +Legg Expires 19 February 2002 [Page 9] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + ChoiceOfStringsValue + + IdentifiedChoiceValue = identifier ":" Value + ChoiceOfStringsValue = StringValue + + For implementations that recognise the internal structure of the + DirectoryString CHOICE type (e.g. X.500 directories [15]), if the + character string between the quotes in a contains only + characters that are permitted in a PrintableString the + DirectoryString is assumed to use the printableString alternative, + otherwise it is assumed to use the uTF8String alternative. The + rule MAY be used for a value of type + DirectoryString to indicate a different alternative to the one that + would otherwise be assumed from the string contents. No matter what + alternative is chosen, the will still be a UTF8 encoded + character string, however it is a syntax error if the characters in + the UTF8 string cannot be represented in the string type of the + chosen alternative. + + Implementations that don't care about the internal structure of a + DirectoryString value MUST be able to parse the + form for a DirectoryString value, though the + particular identifier found will be of no interest. + +5.13 SEQUENCE and SET + + A value of a SEQUENCE type is encoded according to the + rule. The rule encodes a comma + separated list of the particular component values present in the + SEQUENCE value, where each component value is preceded by the + corresponding identifier from the SEQUENCE type definition. The + components are encoded in the order of their definition in the + SEQUENCE type. + + SequenceValue = ComponentList + + ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}" + NamedValue = identifier msp Value + msp = 1*%x20 ; one or more space characters + + A value of a SET type is encoded according to the rule. + The components are encoded in the order of their definition in + the SET type (i.e. just like a SEQUENCE value). + This is a deliberate departure from ASN.1 value notation where + the components of a SET can be written in any order. + + SetValue = ComponentList + + + + +Legg Expires 19 February 2002 [Page 10] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + SEQUENCE and SET type definitions are sometimes extended by the + inclusion of additional component types, so an implementation SHOULD + be capable of skipping over any encoding with an + identifier that is not recognised, on the assumption that the sender + is using a more recent definition of the SEQUENCE or SET type. + + +5.14 SEQUENCE OF and SET OF + + A value of a SEQUENCE OF type is encoded according to the + rule, as a comma separated list of the instances in + the value. Each instance is encoded according to the component type + of the SEQUENCE OF type. + + SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}" + + A value of a SET OF type is encoded according to the + rule, as a list of the instances in the value. Each instance is + encoded according to the component type of the SET OF type. + + SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}" + + +5.15 CHARACTER STRING + + A value of the unrestricted CHARACTER STRING type is encoded + according to the corresponding SEQUENCE type defined in Clause 39.5 + of [8] (see [14] for equivalent ABNF). + + CharacterStringValue = SequenceValue + + +5.16 EMBEDDED PDV + + A value of the EMBEDDED PDV type is encoded according to the + corresponding SEQUENCE type defined in Clause 32.5 of [8] (see [14] + for equivalent ABNF). + + EmbeddedPDVValue = SequenceValue + + +5.17 EXTERNAL + + A value of the EXTERNAL type is encoded according to the + corresponding SEQUENCE type defined in Clause 33.5 of [8] (see [14] + for equivalent ABNF). + + ExternalValue = SequenceValue + + + +Legg Expires 19 February 2002 [Page 11] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + +5.18 INSTANCE OF + + A value of the INSTANCE OF type is encoded according to the + corresponding SEQUENCE type defined in Annex C of [10]. + + InstanceOfValue = SequenceValue + + +5.19 REAL + + A value of the REAL type MUST be encoded as "0" if it is zero, + otherwise it is encoded as either the special value , + the special value , an optionally signed + (based on the extended value notation for REAL from [16]) or as a + value of the corresponding SEQUENCE type for REAL defined in Clause + 20.5 of [8] (see [14] for equivalent ABNF). + + RealValue = "0" ; zero REAL value + / PLUS-INFINITY ; positive infinity + / MINUS-INFINITY ; negative infinity + / realnumber ; positive base 10 REAL value + / "-" realnumber ; negative base 10 REAL value + / SequenceValue ; non-zero REAL value, base 2 or 10 + realnumber = mantissa exponent + mantissa = (positive-number [ "." *decimal-digit ]) + / ( "0." *("0") positive-number ) + exponent = "E" ( "0" / ([ "-" ] positive-number)) + + PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59 + ; "PLUS-INFINITY" + MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59 + ; "MINUS-INFINITY" + + +5.20 Variant Encodings + + The values of some named complex ASN.1 types have special string + encodings. These special encodings are always used instead of the + encoding that would otherwise apply based on the ASN.1 type + definition. + + VariantEncoding = RDNSequenceValue / + RelativeDistinguishedNameValue / + ORAddressValue + + A value of the RDNSequence type, i.e. a distinguished name, is + encoded according to the rule, as a quoted LDAPDN + character string. The character string is first derived according to + + + +Legg Expires 19 February 2002 [Page 12] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + the rule in Section 3 of [5], and then it is + encoded as if it were a UTF8String value, i.e. between double quotes + with any embedded double quotes escaped by being repeated. + + RDNSequenceValue = StringValue + + A RelativeDistinguishedName value that is not part of an RDNSequence + value is encoded according to the + rule as a quoted character string. The character string is first + derived according to the rule in Section 3 of [5], + and then it is encoded as if it were a UTF8String value. + + RelativeDistinguishedNameValue = StringValue + + A value of the ORAddress type is encoded according to the + rule as a quoted character string. The character + string is first derived according to the textual representation of + MTS.ORAddress from [2], and then it is encoded as if it were an + IA5String value. + + ORAddressValue = StringValue + + +6. GSER Transfer Syntax + + The following OBJECT IDENTIFIER has been assigned to identify the + Generic String Encoding Rules: + + { 1 2 36 79672281 0 0 } + + This OBJECT IDENTIFIER would be used, for example, to describe the + transfer syntax for a GSER encoded data-value in an EXTERNAL or + EMBEDDED PDV value. + + +7. Security Considerations + + The Generic String Encoding Rules do not necessarily enable the exact + octet encoding of values of the TeletexString, VideotexString, + GraphicString or GeneralString types to be reconstructed, so a + transformation from DER to GSER and back to DER may not reproduce the + original DER encoding. This has consequences for the verification of + digital signatures. + + +8. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + + + +Legg Expires 19 February 2002 [Page 13] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + Levels", BCP 14, RFC 2119, March 1997. + + [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping + between X.400 and RFC 822/MIME", RFC 2156, January 1998. + + [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight + Directory Access Protocol (v3): Attribute Syntax Definitions", + RFC 2252, December 1997. + + [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished + Names", RFC 2253, December 1997. + + [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + [7] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, + Information Technology - Open Systems Interconnection - The + Directory: Selected attribute types + + [8] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998 + Information Technology - Abstract Syntax Notation One (ASN.1): + Specification of basic notation + + [9] ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC + 8824-1:1998/Amd 1:2000 Relative object identifiers + + [10] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998 + Information Technology - Abstract Syntax Notation One (ASN.1): + Information object specification + + [11] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998 + Information Technology - Abstract Syntax Notation One (ASN.1): + Constraint specification + + [12] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998 + Information Technology - Abstract Syntax Notation One (ASN.1): + Parameterization of ASN.1 specifications + + +9. Informative References + + [13] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access + Protocol (v3)", RFC 2251, December 1997. + + + + +Legg Expires 19 February 2002 [Page 14] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + [14] Legg, S., "Common Elements of GSER Encodings", + draft-legg-ldap-gser-abnf-xx.txt, a work in progress, August + 2002. + + [15] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, + Information Technology - Open Systems Interconnection - The + Directory: Overview of concepts, models and services + + [16] ITU-T Recommendation X.680 - Corrigendum 3 (02/2001) + + [17] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998 + Information Technology - ASN.1 encoding rules: Specification of + Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and + Distinguished Encoding Rules (DER) + + +10. Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +11. Author's Address + + Steven Legg + + + +Legg Expires 19 February 2002 [Page 15] + +INTERNET-DRAFT Generic String Encoding Rules August 19, 2002 + + + Adacel Technologies Ltd. + 405-409 Ferntree Gully Road + Mount Waverley, Victoria 3149 + AUSTRALIA + + Phone: +61 3 9451 2107 + Fax: +61 3 9541 2121 + EMail: steven.legg@adacel.com.au + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Legg Expires 19 February 2002 [Page 16] + diff --git a/doc/drafts/draft-legg-ldapext-component-matching-xx.txt b/doc/drafts/draft-legg-ldapext-component-matching-xx.txt new file mode 100644 index 0000000000..e308c46740 --- /dev/null +++ b/doc/drafts/draft-legg-ldapext-component-matching-xx.txt @@ -0,0 +1,2299 @@ + + + + + + +INTERNET-DRAFT S. Legg +draft-legg-ldapext-component-matching-08.txt Adacel Technologies +Intended Category: Standard Track April 19, 2002 + + + LDAP & X.500 Component Matching Rules + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + Status of this Memo + + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress". + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Distribution of this document is unlimited. Comments should be sent + to the LDAPEXT working group mailing list + or to the author. + + This Internet-Draft expires on 19 October 2002. + + +1. Abstract + + The syntaxes of attributes in a Lightweight Directory Access Protocol + or X.500 directory range from simple data types, such as text string, + integer, or boolean, to complex structured data types, such as the + syntaxes of the directory schema operational attributes. The + matching rules defined for the complex syntaxes, if any, usually only + provide the most immediately useful matching capability. This + document defines generic matching rules that can match any user + selected component parts in an attribute value of any arbitrarily + + + +Legg Expires 19 October 2002 [Page 1] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + complex attribute syntax. + + +2. Table of Contents + + 1. Abstract ...................................................... 1 + 2. Table of Contents ............................................. 2 + 3. Introduction .................................................. 2 + 4. Conventions ................................................... 4 + 5. ComponentAssertion ............................................ 5 + 5.1 Component Reference ....................................... 5 + 5.1.1 Component Type Substitutions ......................... 7 + 5.1.2 Referencing SET, SEQUENCE and CHOICE Components ...... 8 + 5.1.3 Referencing SET OF and SEQUENCE OF Components ........ 9 + 5.1.4 Referencing Components of Parameterized Types ........ 10 + 5.1.5 Component Referencing Example ........................ 10 + 5.1.6 Referencing Components of Open Types ................. 11 + 5.1.6.1 Open Type Referencing Example ................... 12 + 5.1.7 Referencing Contained Types .......................... 13 + 5.1.7.1 Contained Type Referencing Example .............. 14 + 5.2 Matching of Components .................................... 15 + 5.2.1 Applicability of Existing Matching Rules ............. 16 + 5.2.1.1 String Matching ................................. 16 + 5.2.1.2 Telephone Number Matching ....................... 17 + 5.2.1.3 Distinguished Name Matching ..................... 17 + 5.2.2 Additional Useful Matching Rules ..................... 17 + 5.2.2.1 The rdnMatch Matching Rule ...................... 18 + 5.2.2.2 The presentMatch Matching Rule .................. 18 + 5.2.3 Summary of Useful Matching Rules ..................... 19 + 6. ComponentFilter ............................................... 21 + 7. The componentFilterMatch Matching Rule ........................ 22 + 8. Equality Matching of Complex Components ....................... 23 + 8.1 The OpenAssertionType Syntax .............................. 24 + 8.2 The allComponentsMatch Matching Rule ...................... 25 + 8.3 Deriving Component Equality Matching Rules ................ 27 + 8.4 The directoryComponentsMatch Matching Rule ................ 28 + 9. Component Matching Examples ................................... 29 + 10. Security Considerations ...................................... 36 + 11. Acknowledgements ............................................. 36 + 12. Normative References ......................................... 36 + 13. Informative References ....................................... 37 + 14. Intellectual Property Notice ................................. 38 + 15. Copyright Notice ............................................. 38 + 16. Author's Address ............................................. 39 + + +3. Introduction + + + + +Legg Expires 19 October 2002 [Page 2] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + The structure or data type of data held in an attribute of an LDAP + [3] or X.500 [18] directory is described by the attribute's syntax. + Attribute syntaxes range from simple data types, such as text string, + integer, or boolean, to complex data types, for example, the syntaxes + of the directory schema operational attributes. + + In X.500, the attribute syntaxes are explicitly described by ASN.1 + [11] type definitions. ASN.1 type notation has a number of simple + data types (e.g. PrintableString, INTEGER, BOOLEAN), and combining + types (i.e. SET, SEQUENCE, SET OF, SEQUENCE OF, and CHOICE) for + constructing arbitrarily complex data types from simpler component + types. In LDAP, the attribute syntaxes are usually described by ABNF + [2] though there is an implied association between the LDAP attribute + syntaxes and the X.500 ASN.1 types. To a large extent, the data + types of attribute values in either an LDAP or X.500 directory are + described by ASN.1 types. This formal description can be exploited + to identify component parts of an attribute value for a variety of + purposes. This document addresses attribute value matching. + + With any complex attribute syntax there is normally a requirement to + partially match an attribute value of that syntax by matching only + selected components of the value. Typically, matching rules specific + to the attribute syntax are defined to fill this need. These highly + specific matching rules usually only provide the most immediately + useful matching capability. Some complex attribute syntaxes don't + even have an equality matching rule let alone any additional matching + rules for partial matching. This document defines a generic way of + matching user selected components in an attribute value of any + arbitrarily complex attribute syntax, where that syntax is described + using ASN.1 type notation. All of the type notations defined in [11] + are supported. + + Section 5 describes the ComponentAssertion, a testable assertion + about the value of a component of an attribute value of any complex + syntax. + + Section 6 introduces the ComponentFilter assertion, which is an + expression of ComponentAssertions. The ComponentFilter enables more + powerful filter matching of components in an attribute value. + + Section 7 defines the componentFilterMatch matching rule, which + enables a ComponentFilter to be evaluated against attribute values. + + Section 8 defines matching rules for component-wise equality matching + of attribute values of any syntax described by an ASN.1 type + definition. + + Examples showing the usage of componentFilterMatch are in Section 9. + + + +Legg Expires 19 October 2002 [Page 3] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + For a new attribute syntax, the Generic String Encoding Rules [7] and + the specifications in sections 5 to 8 of this document make it + possible to fully and precisely define, the LDAP-specific encoding, + the LDAP and X.500 binary encoding (and possibly other encodings in + the future, e.g. XML via XER), a suitable equality matching rule, and + a comprehensive collection of component matching capabilities, by + simply writing down an ASN.1 type definition for the syntax. These + implicit definitions are also automatically extended if the ASN.1 + type is later extended. The algorithmic relationship between the + ASN.1 type definition, the various encodings and the component + matching behaviour makes directory server implementation support for + the component matching rules amenable to automatic code generation + from ASN.1 type definitions. + + Schema designers have the choice of storing related items of data as + a single attribute value of a complex syntax in some entry, or as a + subordinate entry where the related data items are stored as separate + attribute values of simpler syntaxes. The inability to search + component parts of a complex syntax has been used as an argument for + favouring the subordinate entries approach. The component matching + rules provide the analogous matching capability on an attribute value + of a complex syntax that a search filter has on a subordinate entry. + + Most LDAP syntaxes have corresponding ASN.1 type definitions, though + they are usually not reproduced or referenced alongside the formal + definition of the LDAP syntax. Syntaxes defined with only a + character string encoding, i.e. without an explicit or implied + corresponding ASN.1 type definition, cannot use the component + matching capabilities described in this document unless and until a + semantically equivalent ASN.1 type definition is defined for them. + + +4. Conventions + + Throughout this document "type" shall be taken to mean an ASN.1 type + unless explicitly qualified as an attribute type, and "value" shall + be taken to mean an ASN.1 value unless explicitly qualified as an + attribute value. + + Note that "ASN.1 value" does not mean a BER [19] encoded value. The + ASN.1 value is an abstract concept that is independent of any + particular encoding. BER is just one possible encoding of an ASN.1 + value. The component matching rules operate at the abstract level + without regard for the possible encodings of a value. + + Attribute type and matching rule definitions in this document are + provided in both the X.500 [8] and LDAP [4] description formats. Note + that the LDAP descriptions have been rendered with additional + + + +Legg Expires 19 October 2002 [Page 4] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + white-space and line breaks for the sake of readability. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + +5. ComponentAssertion + + A ComponentAssertion is an assertion about the presence, or values + of, components within an ASN.1 value, i.e. an instance of an ASN.1 + type. The ASN.1 value is typically an attribute value, where the + ASN.1 type is the syntax of the attribute. However a + ComponentAssertion may also be applied to a component part of an + attribute value. The assertion evaluates to either TRUE, FALSE or + undefined for each tested ASN.1 value. + + A ComponentAssertion is described by the following ASN.1 type + (assumed to be defined with "EXPLICIT TAGS" in force): + + ComponentAssertion ::= SEQUENCE { + component ComponentReference, + useDefaultValues BOOLEAN DEFAULT TRUE, + rule MATCHING-RULE.&id, + value MATCHING-RULE.&AssertionType } + + ComponentReference ::= UTF8String + + MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching + rule. MATCHING-RULE.&AssertionType is an open type (formally known + as the ANY type). + + The "component" field of a ComponentAssertion identifies which + component part of a value of some ASN.1 type is to be tested, the + "useDefaultValues" field indicates whether DEFAULT values are to be + substituted for absent component values, the "rule" field indicates + how the component is to be tested, and the "value" field is an + asserted ASN.1 value against which the component is tested. The + ASN.1 type of the asserted value is determined by the chosen rule. + + The fields of a ComponentAssertion are described in detail in the + following sections. + + +5.1 Component Reference + + The component field in a ComponentAssertion is a UTF8 character + string [6] whose textual content is a component reference, + + + +Legg Expires 19 October 2002 [Page 5] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + identifying a component part of some ASN.1 type or value. A + component reference conforms to the following ABNF [2], which extends + the notation defined in Clause 14 of [11]: + + component-reference = ComponentId *( "." ComponentId ) + ComponentId = identifier / + from-beginning / + count / + from-end / ; extends Clause 14 + content / ; extends Clause 14 + select / ; extends Clause 14 + all + + identifier = lowercase *alphanumeric + *(hyphen 1*alphanumeric) + alphanumeric = uppercase / lowercase / decimal-digit + uppercase = %x41-5A ; "A" to "Z" + lowercase = %x61-7A ; "a" to "z" + hyphen = "-" + + from-beginning = positive-number + count = "0" + from-end = "-" positive-number + content = %x63.6F.6E.74.65.6E.74 ; "content" + select = "(" Value *( "," Value ) ")" + all = "*" + + + positive-number = non-zero-digit *decimal-digit + + decimal-digit = %x30-39 ; "0" to "9" + non-zero-digit = %x31-39 ; "1" to "9" + + An conforms to the definition of an identifier in ASN.1 + notation (Clause 11.3 of [11]). It begins with a lowercase letter + and is followed by zero or more letters, digits, and hyphens. A + hyphen is not permitted to be the last character and a hyphen is not + permitted to be followed by another hyphen. + + The rule is described in [7]. + + A component reference is a sequence of one or more ComponentIds where + each successive ComponentId identifies either an inner component at + the next level of nesting of an ASN.1 combining type, i.e. SET, + SEQUENCE, SET OF, SEQUENCE OF, or CHOICE, or a specific type within + an ASN.1 open type. + + A component reference is always considered in the context of a + + + +Legg Expires 19 October 2002 [Page 6] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + particular complex ASN.1 type. When applied to the ASN.1 type the + component reference identifies a specific component type. When + applied to a value of the ASN.1 type a component reference identifies + zero, one or more component values of that component type. The + component values are potentially in a DEFAULT value if + useDefaultValues is TRUE. The specific component type identified by + the component reference determines what matching rules are capable of + being used to match the component values. + + An empty string for a component reference, which would identify the + whole ASN.1 value, is NOT supported since assertions about a whole + value are already possible by the direct application of a matching + rule to an attribute value. + + A valid component reference for a particular complex ASN.1 type is + constructed by starting with the outermost combining type and + repeatedly selecting one of the permissible forms of ComponentId to + identify successively deeper nested components. A component + reference MAY identify a component with a complex ASN.1 type, i.e. it + is NOT required that the component type identified by a component + reference be a simple ASN.1 type. + + +5.1.1 Component Type Substitutions + + ASN.1 type notation has a number of constructs for referencing other + defined types, and constructs that are irrelevant for matching + purposes. These constructs are not represented in a component + reference in any way and substitutions of the component type are + performed to eliminate them from further consideration. These + substitutions automatically occur prior to each ComponentId, whether + constructing or interpreting a component reference, but do not occur + after the last ComponentId, except as allowed by Section 5.2. + + If the ASN.1 type is an ASN.1 type reference then the component type + is taken to be the actual definition on the right hand side of the + type assignment for the referenced type. + + If the ASN.1 type is a tagged type then the component type is taken + to be the type without the tag. + + If the ASN.1 type is a constrained type (see [11] and [14] for the + details of ASN.1 constraint notation) then the component type is + taken to be the type without the constraint. + + If the ASN.1 type is an ObjectClassFieldType (Clause 14 of [13]) that + denotes a specific ASN.1 type (e.g. MATCHING-RULE.&id denotes the + OBJECT IDENTIFIER type) then the component type is taken to be the + + + +Legg Expires 19 October 2002 [Page 7] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + denoted type. Section 5.1.6 describes the case where the + ObjectClassFieldType denotes an open type. + + If the ASN.1 type is a selection type other than one used in the list + of components for a SET or SEQUENCE type then the component type is + taken to be the selected alternative type from the named CHOICE. + + If the ASN.1 type is a TypeFromObject (Clause 15 of [13]) then the + component type is taken to be the denoted type. + + If the ASN.1 type is a ValueSetFromObjects (Clause 15 of [13]) then + the component type is taken to be the governing type of the denoted + values. + + +5.1.2 Referencing SET, SEQUENCE and CHOICE Components + + If the ASN.1 type is a SET or SEQUENCE type then the + form of ComponentId MAY be used to identify the component type within + that SET or SEQUENCE having that identifier. If + references an OPTIONAL component type and that component is not + present in a particular value then there are no corresponding + component values. If references a DEFAULT component + type and useDefaultValues is TRUE (the default setting for + useDefaultValues) and that component is not present in a particular + value then the component value is taken to be the default value. If + references a DEFAULT component type and useDefaultValues + is FALSE and that component is not present in a particular value then + there are no corresponding component values. + + If the ASN.1 type is a CHOICE type then the form of + ComponentId MAY be used to identify the alternative type within that + CHOICE having that identifier. If references an + alternative other than the one used in a particular value then there + are no corresponding component values. + + The COMPONENTS OF notation in Clause 24 of [11] augments the defined + list of components in a SET or SEQUENCE type by including all the + components of another defined SET or SEQUENCE type respectively. + These included components are referenced directly by identifier as + though they were defined in-line in the SET or SEQUENCE type + containing the COMPONENTS OF notation. + + The SelectionType (Clause 29 of [11]), when used in the list of + components for a SET or SEQUENCE type, includes a single component + from a defined CHOICE type. This included component is referenced + directly by identifier as though it was defined in-line in the SET or + SEQUENCE type. + + + +Legg Expires 19 October 2002 [Page 8] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + The REAL type is treated as though it is the SEQUENCE type defined in + Clause 20.5 of [11]. + + The EMBEDDED PDV type is treated as though it is the SEQUENCE type + defined in Clause 32.5 of [11]. + + The EXTERNAL type is treated as though it is the SEQUENCE type + defined in Clause 33.5 of [11]. + + The unrestricted CHARACTER STRING type is treated as though it is the + SEQUENCE type defined in Clause 39.5 of [11]. + + The INSTANCE OF type is treated as though it is the SEQUENCE type + defined in Annex C of [13]. + + The form MUST NOT be used on any other ASN.1 type. + + +5.1.3 Referencing SET OF and SEQUENCE OF Components + + If the ASN.1 type is a SET OF or SEQUENCE OF type then the + , , and forms of ComponentId + can be used. + + The form of ComponentId MAY be used to identify one + instance (i.e. value) of the component type of the SET OF or SEQUENCE + OF type (e.g. if Foo ::= SET OF Bar, then Bar is the component type), + where the instances are numbered from one upwards. If + references a higher numbered instance than the last + instance in a particular value of the SET OF or SEQUENCE OF type then + there is no corresponding component value. + + The form of ComponentId MAY be used to identify one + instance of the component type of the SET OF or SEQUENCE OF type, + where "-1" is the last instance, "-2" is the second last instance, + and so on. If references a lower numbered instance than + the first instance in a particular value of the SET OF or SEQUENCE OF + type then there is no corresponding component value. + + The form of ComponentId identifies a notional count of the + number of instances of the component type in a value of the SET OF or + SEQUENCE OF type. This count is not explicitly represented but for + matching purposes it has an assumed ASN.1 type of INTEGER (0..MAX). + A ComponentId of the form MUST be the last ComponentId in a + component reference. + + The form of ComponentId MAY be used to simultaneously identify + all instances of the component type of the SET OF or SEQUENCE OF + + + +Legg Expires 19 October 2002 [Page 9] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + type. It is through the form that a component reference can + identify more than one component value. However, if a particular + value of the SET OF or SEQUENCE OF type is an empty list there are no + corresponding component values. + + Where multiple component values are identified, the remaining + ComponentIds in the component reference, if any, can identify zero, + one or more subcomponent values for each of the higher level + component values. + + The corresponding ASN.1 type for the , , + and forms of ComponentId is the component type of the SET OF or + SEQUENCE OF type. + + The , , and forms MUST NOT be + used on ASN.1 types other than SET OF or SEQUENCE OF. + + +5.1.4 Referencing Components of Parameterized Types + + A component reference cannot be formed for a parameterized type + unless the type has been used with actual parameters, in which case + the type is treated as though the DummyReferences [15] have been + substituted with the actual parameters. + + +5.1.5 Component Referencing Example + + Consider the following ASN.1 type definitions. + + ExampleType ::= SEQUENCE { + part1 [0] INTEGER, + part2 [1] ExampleSet, + part3 [2] SET OF OBJECT IDENTIFIER, + part4 [3] ExampleChoice } + + ExampleSet ::= SET { + option PrintableString, + setting BOOLEAN } + + ExampleChoice ::= CHOICE { + eeny-meeny BIT STRING, + miney-mo OCTET STRING } + + Following are component references constructed with respect to the + type ExampleType. + + The component reference "part1" identifies a component of a value of + + + +Legg Expires 19 October 2002 [Page 10] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + ExampleType having the ASN.1 tagged type [0] INTEGER. + + The component reference "part2" identifies a component of a value of + ExampleType having the ASN.1 type of [1] ExampleSet + + The component reference "part2.option" identifies a component of a + value of ExampleType having the ASN.1 type of PrintableString. A + ComponentAssertion could also be applied to a value of ASN.1 type + ExampleSet, in which case the component reference "option" would + identify the same kind of information. + + The component reference "part3" identifies a component of a value of + ExampleType having the ASN.1 type of [2] SET OF OBJECT IDENTIFIER. + + The component reference "part3.2" identifies the second instance of + the part3 SET OF. The instance has the ASN.1 type of OBJECT + IDENTIFIER. + + The component reference "part3.0" identifies the count of the number + of instances in the part3 SET OF. The count has the corresponding + ASN.1 type of INTEGER (0..MAX). + + The component reference "part3.*" identifies all the instances in the + part3 SET OF. Each instance has the ASN.1 type of OBJECT IDENTIFIER. + + The component reference "part4" identifies a component of a value of + ExampleType having the ASN.1 type of [3] ExampleChoice. + + The component reference "part4.miney-mo" identifies a component of a + value of ExampleType having the ASN.1 type of OCTET STRING. + + +5.1.6 Referencing Components of Open Types + + If a sequence of ComponentIds identifies an ObjectClassFieldType + denoting an open type (e.g. ATTRIBUTE.&Type denotes an open type) + then the ASN.1 type of the component varies. An open type is + typically constrained by some other component(s) in an outer + enclosing type, either formally through the use of a component + relation constraint [14], or informally in the accompanying text, so + the actual ASN.1 type of a value of the open type will generally be + known. The constraint will also limit the range of permissible + types. The + + + +Legg Expires 19 October 2002 [Page 11] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + form contains a list of one or more values which take the place of + the value(s) of the referenced component(s) to uniquely identify one + of the permissable types of the open type. + + Where the open type is constrained by a component relation + constraint, there is a in the form of ComponentId will nearly + always be an or (see [7]). + Furthermore, component relation constraints typically have only one + referenced component. + + Where the open type is not constrained by a component relation + constraint, the specification introducing the syntax containing the + open type SHOULD explicitly nominate the referenced components and + their order, so that the contains a value other than the value of + the referenced component used in a particular value of the outer + enclosing type then there are no corresponding component values for + the open type. + + +5.1.6.1 Open Type Referencing Example + + The ASN.1 type AttributeTypeAndValue from [8] describes a single + attribute value of a nominated attribute type. + + AttributeTypeAndValue ::= SEQUENCE { + type ATTRIBUTE.&id ({SupportedAttributes}), + value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) } + + ATTRIBUTE.&id denotes an OBJECT IDENTIFIER and + ({SupportedAttributes}) constrains the OBJECT IDENTIFIER to be a + supported attribute type. + + ATTRIBUTE.&Type denotes an open type, in this case an attribute + value, and ({SupportedAttributes}{@type}) is a component relation + constraint that constrains the open type to be of the attribute + syntax for the attribute type. The component relation constraint + references only the "type" component, which has the ASN.1 type of + OBJECT IDENTIFIER, thus if the form. + + For the purpose of building component references, the content of the + extnValue OCTET STRING in the Extension type is assumed to be an open + type having a notional component relation constraint with the extnId + component as the single referenced component, i.e. + + EXTENSION.&ExtnType ({ExtensionSet}{@extnId}) + + The data-value component of the associated types for the EXTERNAL, + EMBEDDED PDV and CHARACTER STRING types is an OCTET STRING containing + the encoding of a data value described by the identification + component. For the purpose of building component references, the + content of the data-value OCTET STRING in these types is assumed to + be an open type having a notional component relation constraint with + the identification component as the single referenced component. + + +5.1.7.1 Contained Type Referencing Example + + The Extension ASN.1 type from [9] describes a single certificate + extension value of a nominated extension type. + + Extension ::= SEQUENCE { + extnId EXTENSION.&id ({ExtensionSet}), + critical BOOLEAN DEFAULT FALSE, + extnValue OCTET STRING + -- contains a DER encoding of a value of type &ExtnType + -- for the extension object identified by extnId -- } + + EXTENSION.&id denotes an OBJECT IDENTIFIER and ({ExtensionSet}) + constrains the OBJECT IDENTIFIER to be the identifier of a supported + certificate extension. + + The component reference "extnValue" on Extension refers to a + component type of OCTET STRING. The corresponding component values + will be OCTET STRING values. The component reference + "extnValue.content" on Extension refers to the type of the contained + type, which in this case is an open type. + + One of the X.509 [X.509] standard extensions is basicConstraints, + which is identified with the OBJECT IDENTIFIER 2.5.29.19 and is + defined to have the following syntax. + + BasicConstraintsSyntax ::= SEQUENCE { + cA BOOLEAN DEFAULT FALSE, + pathLenConstraint INTEGER (0..MAX) OPTIONAL } + + + + +Legg Expires 19 October 2002 [Page 14] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + The component reference "extnValue.content.(2.5.29.19)" on Extension + specifies a BasicConstraintsSyntax extension value and the component + reference "extnValue.content.(2.5.29.19).cA" identifies the cA + component of a BasicConstraintsSyntax extension value. + + +5.2 Matching of Components + + The rule in a ComponentAssertion specifies how the zero, one or more + component values identified by the component reference are tested by + the assertion. Attribute matching rules are used to specify the + semantics of the test. + + Each matching rule has a notional set of attribute syntaxes + (typically one), defined as ASN.1 types, to which it may be applied. + When used in a ComponentAssertion these matching rules apply to the + same ASN.1 types, only in this context the corresponding ASN.1 values + are not complete attribute values. + + Note that the referenced component type may be a tagged and/or + constrained version of the expected attribute syntax (e.g. [0] + INTEGER, whereas integerMatch would expect simply INTEGER), or an + open type. Additional type substitutions of the kind described in + Section 5.1.1 are performed as required to reduce the component type + to the same type as the attribute syntax expected by the matching + rule. If an open type is encountered the actual ASN.1 type of the + component value is substituted before continuing. + + If a matching rule applies to more than one attribute syntax (e.g. + objectIdentifierFirstComponentMatch [10]) then the minimum number of + substitutions required to conform to any one of those syntaxes are + performed. If a matching rule can apply to any attribute syntax + (e.g. the allComponentsMatch rule defined in Section 8.2) then the + referenced component type is used as is, with no additional + substitutions. + + The value in a ComponentAssertion will be of the assertion syntax + (i.e. ASN.1 type) required by the chosen matching rule. Note that + the assertion syntax of a matching rule is not necessarily the same + as the attribute syntax(es) to which the rule may be applied. + + Some matching rules do not have a fixed assertion syntax (e.g. + allComponentsMatch). The required assertion syntax is determined in + each instance of use by the syntax of the attribute type to which the + matching rule is applied. For these rules the ASN.1 type of the + referenced component is used in place of an attribute syntax to + decide the required assertion syntax. + + + + +Legg Expires 19 October 2002 [Page 15] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + The ComponentAssertion is undefined if: + + a) the matching rule in the ComponentAssertion is not known to the + evaluating procedure, + + b) if no part of the component reference identifies an open type and + the matching rule is not applicable to the referenced component + type, even with the additional type substitutions, + + c) the value in the ComponentAssertion does not conform to the + assertion syntax defined for the matching rule, + + d) an open type in the tested value cannot be decoded, or + + e) the implementation does not support the particular combination of + component reference and matching rule. + + If the ComponentAssertion is not undefined then the + ComponentAssertion evaluates to TRUE if there is at least one + component value for which the matching rule applied to that component + value returns TRUE, and evaluates to FALSE otherwise (which includes + the case where there are no component values). + + If some part of the component reference identifies an open type and + the matching rule is not applicable to the referenced component type + the ComponentAssertion evaluates to FALSE. + + +5.2.1 Applicability of Existing Matching Rules + +5.2.1.1 String Matching + + ASN.1 has a number of built in restricted character string types with + different character sets and/or different character encodings. A + directory user generally has little interest in the particular + character set or encoding used to represent a character string + component value, and some directory server implementations make no + distinction between the different string types in their internal + representation of values. So rather than define string matching + rules for each of the restricted character string types, the existing + case ignore and case exact string matching rules are extended to + apply to component values of any of the restricted character string + types and any ChoiceOfStrings type [7], in addition to component + values of the DirectoryString type. This extension is only for the + purposes of component matching described in this document. + + The relevant string matching rules are: caseIgnoreMatch, + caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch, + + + +Legg Expires 19 October 2002 [Page 16] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + caseExactOrderingMatch and caseExactSubstringsMatch. The relevant + restricted character string types are: NumericString, + PrintableString, VisibleString, IA5String, UTF8String, BMPString, + UniversalString, TeletexString, VideotexString, GraphicString and + GeneralString. A ChoiceOfStrings type is a purely syntactic CHOICE + of these ASN.1 string types. Note that [7] declares each and every + use of the DirectoryString{} parameterized type to be a + ChoiceOfStrings type. + + The assertion syntax of the string matching rules is still + DirectoryString regardless of the string syntax of the component + being matched. Thus an implementation will be called upon to compare + a DirectoryString value to a value of one of the restricted character + string types, or a ChoiceOfStrings type. As is the case when + comparing two DirectoryStrings where the chosen alternatives are of + different string types, the comparison proceeds so long as the + corresponding characters are representable in both character sets. + Otherwise matching returns FALSE. + + +5.2.1.2 Telephone Number Matching + + Early editions of X.520 [10] gave the syntax of the telephoneNumber + attribute as a constrained PrintableString. The fourth edition of + X.520 equates the ASN.1 type name TelephoneNumber to the constrained + PrintableString and uses TelephoneNumber as the attribute and + assertion syntax. For the purposes of component matching, + telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted + to be applied to any PrintableString value, as well as to + TelephoneNumber values. + + +5.2.1.3 Distinguished Name Matching + + The DistinguishedName type is defined by assignment to be the same as + the RDNSequence type, however RDNSequence is sometimes directly used + in other type definitions. For the purposes of component matching, + distinguishedNameMatch is also permitted to be applied to values of + the RDNSequence type. + + +5.2.2 Additional Useful Matching Rules + + This section defines additional matching rules that may prove useful + in ComponentAssertions. These rules MAY also be used in + extensibleMatch search filters [3]. + + + + + +Legg Expires 19 October 2002 [Page 17] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + +5.2.2.1 The rdnMatch Matching Rule + + The distinguishedNameMatch matching rule can match whole + distinguished names but it is sometimes useful to be able to match + specific RDNs in a DN without regard for the other RDNs in the DN. + The rdnMatch matching rule allows component RDNs of a DN to be + tested. + + The LDAP-style definitions for rdnMatch and its assertion syntax are: + + ( 1.2.36.79672281.1.13.3 NAME 'rdnMatch' + SYNTAX 1.2.36.79672281.1.5.0 ) + + ( 1.2.36.79672281.1.5.0 DESC 'RDN' ) + + The LDAP-specific encoding for a value of the RDN syntax is given by + the rule in [7]. + + The X.500-style definition for rdnMatch is: + + rdnMatch MATCHING-RULE ::= { + SYNTAX RelativeDistinguishedName + ID { 1 2 36 79672281 1 13 3 } } + + The rdnMatch rule evaluates to true if the component value and + assertion value are the same RDN, using the same RDN comparison + method as distinguishedNameMatch. + + When using rdnMatch to match components of DNs it is important to + note that the LDAP-specific encoding of a DN [5] reverses the order + of the RDNs. So for the DN represented in LDAP as "cn=Steven + Legg,o=Adacel,c=AU", the RDN "cn=Steven Legg" corresponds to the + component reference "3", or alternatively, "-1". + + +5.2.2.2 The presentMatch Matching Rule + + At times it would be useful to test not if a specific value of a + particular component is present, but whether any value of a + particular component is present. The presentMatch matching rule + allows the presence of a particular component value to be tested. + + The LDAP-style definitions for presentMatch and its assertion syntax + are: + + ( 1.2.36.79672281.1.13.5 NAME 'presentMatch' + SYNTAX 1.2.36.79672281.1.5.1 ) + + + + +Legg Expires 19 October 2002 [Page 18] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + ( 1.2.36.79672281.1.5.1 DESC 'NULL' ) + + The LDAP-specific encoding for a value of the NULL syntax is given by + the rule in [7]. + + The X.500-style definition for presentMatch is: + + presentMatch MATCHING-RULE ::= { + SYNTAX NULL + ID { 1 2 36 79672281 1 13 5 } } + + When used in a extensible match filter item, presentMatch behaves + like the "present" case of a regular search filter. In a + ComponentAssertion, presentMatch evaluates to TRUE if and only if the + component reference identifies one or more component values, + regardless of the actual component value contents. Note that if + useDefaultValues is TRUE then the identified component values may be + (part of) a DEFAULT value. + + The notional count referenced by the form of ComponentId is + taken to be present if the SET OF value is present, and absent + otherwise. Note that in ASN.1 notation an absent SET OF value is + distinctly different from a SET OF value that is present but empty. + It is up to the specification using the ASN.1 notation to decide + whether the distinction matters. Often an empty SET OF component and + an absent SET OF component are treated as semantically equivalent. + If a SET OF value is present, but empty, a presentMatch on the SET OF + component SHALL return TRUE and the notional count SHALL be regarded + as present and equal to zero. + + +5.2.3 Summary of Useful Matching Rules + + The following is a non-exhaustive list of useful matching rules and + the ASN.1 types to which they can be applied, taking account of all + the extensions described in Section 5.2.1, and the new matching rules + defined in Section 5.2.2. + + + + + + + + + + + + + + +Legg Expires 19 October 2002 [Page 19] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + +================================+==============================+ + | Matching Rule | ASN.1 Type | + +================================+==============================+ + | bitStringMatch | BIT STRING | + +--------------------------------+------------------------------+ + | booleanMatch | BOOLEAN | + +--------------------------------+------------------------------+ + | caseIgnoreMatch | NumericString | + | caseIgnoreOrderingMatch | PrintableString | + | caseIgnoreSubstringsMatch | VisibleString (ISO646String) | + | caseExactMatch | IA5String | + | caseExactOrderingMatch | UTF8String | + | caseExactSubstringsMatch | BMPString (UCS-2, UNICODE) | + | | UniversalString (UCS-4) | + | | TeletexString (T61String) | + | | VideotexString | + | | GraphicString | + | | GeneralString | + | | any ChoiceOfStrings type | + +--------------------------------+------------------------------+ + | caseIgnoreIA5Match | IA5String | + | caseExactIA5Match | | + +--------------------------------+------------------------------+ + | distinguishedNameMatch | DistinguishedName | + | | RDNSequence | + +--------------------------------+------------------------------+ + | generalizedTimeMatch | GeneralizedTime | + | generalizedTimeOrderingMatch | | + +--------------------------------+------------------------------+ + | integerMatch | INTEGER | + | integerOrderingMatch | | + +--------------------------------+------------------------------+ + | numericStringMatch | NumericString | + | numericStringOrderingMatch | | + | numericStringSubstringsMatch | | + +--------------------------------+------------------------------+ + | objectIdentifierMatch | OBJECT IDENTIFIER | + +--------------------------------+------------------------------+ + | octetStringMatch | OCTET STRING | + | octetStringOrderingMatch | | + | octetStringSubstringsMatch | | + +--------------------------------+------------------------------+ + | presentMatch | any ASN.1 type | + +--------------------------------+------------------------------+ + | rdnMatch | RelativeDistinguishedName | + +--------------------------------+------------------------------+ + | telephoneNumberMatch | PrintableString | + | telephoneNumberSubstringsMatch | TelephoneNumber | + + + +Legg Expires 19 October 2002 [Page 20] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + +--------------------------------+------------------------------+ + | uTCTimeMatch | UTCTime | + | uTCTimeOrderingMatch | | + +--------------------------------+------------------------------+ + + Note that the allComponentsMatch matching rule defined in Section 8.2 + can be used for equality matching of values of the ENUMERATED, NULL, + REAL and RELATIVE-OID ASN.1 types, among other things. + + +6. ComponentFilter + + The ComponentAssertion allows the value(s) of any one component type + in a complex ASN.1 type to be matched, but there is often a desire to + match the values of more than one component type. A ComponentFilter + is an assertion about the presence, or values of, multiple components + within an ASN.1 value. + + The ComponentFilter assertion, an expression of ComponentAssertions, + evaluates to either TRUE, FALSE or undefined for each tested ASN.1 + value. + + A ComponentFilter is described by the following ASN.1 type (assumed + to be defined with "EXPLICIT TAGS" in force): + + ComponentFilter ::= CHOICE { + item [0] ComponentAssertion, + and [1] SEQUENCE OF ComponentFilter, + or [2] SEQUENCE OF ComponentFilter, + not [3] ComponentFilter } + + Note: despite the use of SEQUENCE OF instead of SET OF for the "and" + and "or" alternatives in ComponentFilter, the order of the component + filters is not significant. + + A ComponentFilter that is a ComponentAssertion evaluates to TRUE if + the ComponentAssertion is TRUE, evaluates to FALSE if the + ComponentAssertion is FALSE, and evaluates to undefined otherwise. + + The "and" of a sequence of component filters evaluates to TRUE if the + sequence is empty or if each component filter evaluates to TRUE, + evaluates to FALSE if at least one component filter is FALSE, and + evaluates to undefined otherwise. + + The "or" of a sequence of component filters evaluates to FALSE if the + sequence is empty or if each component filter evaluates to FALSE, + evaluates to TRUE if at least one component filter is TRUE, and + evaluates to undefined otherwise. + + + +Legg Expires 19 October 2002 [Page 21] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + The "not" of a component filter evaluates to TRUE if the component + filter is FALSE, evaluates to FALSE if the component filter is TRUE, + and evaluates to undefined otherwise. + + +7. The componentFilterMatch Matching Rule + + The componentFilterMatch matching rule allows a ComponentFilter to be + applied to an attribute value. The result of the matching rule is + the result of applying the ComponentFilter to the attribute value. + + The LDAP-style definitions for componentFilterMatch and its assertion + syntax are: + + ( 1.2.36.79672281.1.13.2 NAME 'componentFilterMatch' + SYNTAX 1.2.36.79672281.1.5.2 ) + + ( 1.2.36.79672281.1.5.2 DESC 'ComponentFilter' ) + + The LDAP-specific encoding for the ComponentFilter assertion syntax + is specified by the Generic String Encoding Rules in [7]. + + As a convenience to implementors, an equivalent ABNF description of + the GSER encoding for ComponentFilter is provided here. In the event + that there is a discrepancy between this ABNF and the encoding + determined by [7], [7] is to be taken as definitive. The GSER + encoding of a ComponentFilter is described by the following + equivalent ABNF: + + ComponentFilter = filter-item / + and-filter / + or-filter / + not-filter + + filter-item = item-chosen ComponentAssertion + and-filter = and-chosen SequenceOfComponentFilter + or-filter = or-chosen SequenceOfComponentFilter + not-filter = not-chosen ComponentFilter + + item-chosen = %x69.74.65.6D.3A ; "item:" + and-chosen = %x61.6E.64.3A ; "and:" + or-chosen = %x6F.72.3A ; "or:" + not-chosen = %x6E.6F.74.3A ; "not:" + + SequenceOfComponentFilter = "{" [ sp ComponentFilter + *( "," sp ComponentFilter) ] sp "}" + + ComponentAssertion = "{" sp component "," + + + +Legg Expires 19 October 2002 [Page 22] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + [ sp useDefaultValues "," ] + sp rule "," + sp assertion-value sp "}" + component = component-label msp + dquote component-reference dquote + useDefaultValues = use-defaults-label msp BooleanValue + rule = rule-label msp ObjectIdentifierValue + assertion-value = value-label msp Value + + component-label = %x63.6F.6D.70.6F.6E.65.6E.74 ; "component" + use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75 + %x65.73 ; "useDefaultValues" + rule-label = %x72.75.6C.65 ; "rule" + value-label = %x76.61.6C.75.65 ; "value" + + sp = *%x20 ; zero, one or more space characters + msp = 1*%x20 ; one or more space characters + dquote = %x22 ; " (double quote) + + The ABNF for , and is + defined in [7]. + + The ABNF descriptions of LDAP-specific encodings for attribute + syntaxes typically do not clearly or consistently delineate the + component parts of an attribute value. A regular and uniform + character string encoding for arbitrary component data types is + needed to encode the assertion value in a ComponentAssertion. The + rule from [7] provides a human readable text encoding for a + component value of any arbitrary ASN.1 type. + + The X.500-style definition [8] for componentFilterMatch is: + + componentFilterMatch MATCHING-RULE ::= { + SYNTAX ComponentFilter + ID { 1 2 36 79672281 1 13 2 } } + + A ComponentAssertion can potentially use any matching rule, including + componentFilterMatch, so componentFilterMatch MAY be nested. The + component references in a nested componentFilterMatch are relative to + the component corresponding to the containing ComponentAssertion. In + Section 9, an example search on the seeAlso attribute shows this + usage. + + +8. Equality Matching of Complex Components + + It is possible to test if an attribute value of a complex ASN.1 + syntax is the same as some purported (i.e. assertion) value by using + + + +Legg Expires 19 October 2002 [Page 23] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + a complicated ComponentFilter that tests if corresponding components + are the same. However, it would be more convenient to be able to + present a whole assertion value to a matching rule that could do the + component-wise comparison of an attribute value with the assertion + value for any arbitrary attribute syntax. Similarly, the ability to + do a straightforward equality comparison of a component value that is + itself of a complex ASN.1 type would also be convenient. + + It would be difficult to define a single matching rule that + simultaneously satisfies all notions of what the equality matching + semantics should be. For example, in some instances a case sensitive + comparison of string components may be preferable to a case + insensitive comparison. Therefore a basic equality matching rule, + allComponentsMatch, is defined in Section 8.2, and the means to + derive new matching rules from it with slightly different equality + matching semantics are described in Section 8.3. + + The directoryComponentsMatch defined in Section 8.4 is a derivation + of allComponentsMatch that suits typical uses of the directory. + Other specifications are free to derive new rules from + allComponentsMatch or directoryComponentsMatch, that suit their usage + of the directory. + + The allComponentsMatch rule, the directoryComponentsMatch rule and + any matching rules derived from them are collectively called + component equality matching rules. + + +8.1 The OpenAssertionType Syntax + + The component equality matching rules have a variable assertion + syntax. In X.500 this is indicated by omitting the optional SYNTAX + field in the MATCHING-RULE information object. The assertion syntax + then defaults to the target attribute's syntax in actual usage, + unless the description of the matching rule says otherwise. The + SYNTAX field in the LDAP-specific encoding of a + MatchingRuleDescription is mandatory, so the OpenAssertionType syntax + is defined to fill the same role. That is, the OpenAssertionType + syntax is semantically equivalent to an omitted SYNTAX field in an + X.500 MATCHING-RULE information object. OpenAssertionType MUST NOT + be used as the attribute syntax in an attribute type definition. + + Unless explicitly varied by the description of a particular matching + rule, if an OpenAssertionType assertion value appears in a + ComponentAssertion its LDAP-specific encoding is described by the + rule in [7], otherwise its LDAP-specific encoding is the + encoding defined for the syntax of the attribute type to which the + matching rule with the OpenAssertionType assertion syntax is applied. + + + +Legg Expires 19 October 2002 [Page 24] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + The LDAP definition for the OpenAssertionType syntax is: + + ( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' ) + + +8.2 The allComponentsMatch Matching Rule + + The LDAP-style definition for allComponentsMatch is: + + ( 1.2.36.79672281.1.13.6 NAME 'allComponentsMatch' + SYNTAX 1.2.36.79672281.1.5.3 ) + + The X.500-style definition for allComponentsMatch is: + + allComponentsMatch MATCHING-RULE ::= { + ID { 1 2 36 79672281 1 13 6 } } + + When allComponentsMatch is used in a ComponentAssertion the assertion + syntax is the same as the ASN.1 type of the identified component. + Otherwise, the assertion syntax of allComponentsMatch is the same as + the attribute syntax of the attribute to which the matching rule is + applied. + + Broadly speaking, this matching rule evaluates to true if and only if + corresponding components of the assertion value and the attribute or + component value are the same. + + In detail, equality is determined by the following cases applied + recursively. + + a) Two values of a SET or SEQUENCE type are the same if and only if, + for each component type, the corresponding component values are + either, + + 1) both absent, + + 2) both present and the same, or + + 3) absent or the same as the DEFAULT value for the component, if a + DEFAULT value is defined. + + Values of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER + STRING, or INSTANCE OF type are compared according to their + respective SEQUENCE type (see Section 5.1.2). + + b) Two values of a SEQUENCE OF type are the same if and only if, the + values have the same number of (possibly duplicated) instances and + corresponding instances are the same. + + + +Legg Expires 19 October 2002 [Page 25] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + c) Two values of a SET OF type are the same if and only if, the + values have the same number of instances and each distinct + instance occurs in both values the same number of times, i.e. both + values have the same instances, including duplicates, but in any + order. + + d) Two values of a CHOICE type are the same if and only if, both + values are of the same chosen alternative and the component values + are the same. + + e) Two BIT STRING values are the same if and only if the values have + the same number of bits and corresponding bits are the same. If + the BIT STRING type is defined with a named bit list then trailing + zero bits in the values are treated as absent for the purposes of + this comparison. + + f) Two BOOLEAN values are the same if and only if both are TRUE or + both are FALSE. + + g) Two values of a string type are the same if and only if the values + have the same number of characters and corresponding characters + are the same. Letter case is significant. For the purposes of + allComponentsMatch, the string types are NumericString, + PrintableString, TeletexString (T61String), VideotexString, + IA5String, GraphicString, VisibleString (ISO646String), + GeneralString, UniversalString, BMPString, UTF8String, + GeneralizedTime, UTCTime and ObjectDescriptor. + + h) Two INTEGER values are the same if and only if the integers are + equal. + + i) Two ENUMERATED values are the same if and only if the enumeration + item identifiers are the same (equivalently, if the integer values + associated with the identifiers are equal). + + j) Two NULL values are always the same, unconditionally. + + k) Two OBJECT IDENTIFIER values are the same if and only if the + values have the same number of arcs and corresponding arcs are the + same. + + l) Two OCTET STRING values are the same if and only if the values + have the same number of octets and corresponding octets are the + same. + + m) Two REAL values are the same if and only if they are both the same + special value, or neither is a special value and they have the + same base and represent the same real number. The special values + + + +Legg Expires 19 October 2002 [Page 26] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + for REAL are zero, PLUS-INFINITY and MINUS-INFINITY. + + n) Two RELATIVE-OID [12] values are the same if and only if the + values have the same number of arcs and corresponding arcs are the + same. The respective starting nodes for the RELATIVE-OID values + are disregarded in the comparison, i.e. they are assumed to be the + same. + + o) Two values of an open type are the same if and only if both are of + the same ASN.1 type and are the same according to that type. + + Tags and constraints, being part of the type definition and not part + of the abstract values, are ignored for matching purposes. + + The allComponentsMatch rule MAY be used as the defined equality + matching rule for an attribute. + + +8.3 Deriving Component Equality Matching Rules + + A new component equality matching rule with more refined matching + semantics MAY be derived from allComponentsMatch, or any other + component equality matching rule, using the convention described in + this section. + + The matching behaviour of a derived component equality matching rule + is specified by nominating, for each of one or more identified + components, a commutative equality matching rule that will be used to + match values of that component. This overrides the matching that + would otherwise occur for values of that component using the base + rule for the derivation. These overrides can be conveniently + represented as rows in a table of the following form. + + Component | Matching Rule + ============+=============== + | + | + + Usually, all component values of a particular ASN.1 type are to be + matched the same way. An ASN.1 type reference (e.g. + DistinguishedName) or an ASN.1 built-in type name (e.g. INTEGER) in + the Component column of the table specifies that the nominated + equality matching rule is to be applied to all values of the named + type, regardless of context. + + An ASN.1 type reference with a component reference appended + (separated by a ".") specifies that the nominated matching rule + applies only to the identified components of values of the named + + + +Legg Expires 19 October 2002 [Page 27] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + type. Other component values that happen to be of the same ASN.1 + type are not selected. + + Additional type substitutions as described in Section 5.2 are assumed + to be performed to align the component type with the matching rule + assertion syntax. + + Conceptually, the rows in a table for the base rule are appended to + the rows in the table for a derived rule for the purpose of deciding + the matching semantics of the derived rule. Notionally, + allComponentsMatch has an empty table. + + A row specifying values of an outer containing type (e.g. + DistinguishedName) takes precedence over a row specifying values of + an inner component type (e.g. RelativeDistinguishedName), regardless + of their order in the table. Specifying a row for component values + of an inner type is only useful if a value of the type can also + appear on its own, or as a component of values of a different outer + type. For example, if there is a row for DistinguishedName then a + row for RelativeDistinguishedName can only ever apply to + RelativeDistinguishedName component values that are not part of a + DistinguishedName. A row for values of an outer type in the table + for the base rule takes precedence over a row for values of an inner + type in the table for the derived rule. + + Where more than one row applies to a particular component value the + earlier row takes precedence over the later row. Thus rows in the + table for the derived rule take precedence over any rows for the same + component in the table for the base rule. + + +8.4 The directoryComponentsMatch Matching Rule + + The directoryComponentsMatch matching rule is derived from the + allComponentsMatch matching rule. + + The LDAP-style definition for directoryComponentsMatch is: + + ( 1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch' + SYNTAX 1.2.36.79672281.1.5.3 ) + + The X.500-style definition for directoryComponentsMatch is: + + directoryComponentsMatch MATCHING-RULE ::= { + ID { 1 2 36 79672281 1 13 7 } } + + The matching semantics of directoryComponentsMatch are described by + the following table, using the convention described in Section 8.3. + + + +Legg Expires 19 October 2002 [Page 28] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + ASN.1 Type | Matching Rule + =========================================+======================== + RDNSequence | distinguishedNameMatch + RelativeDistinguishedName | rdnMatch + TelephoneNumber | telephoneNumberMatch + FacsimileTelephoneNumber.telephoneNumber | telephoneNumberMatch + NumericString | numericStringMatch + GeneralizedTime | generalizedTimeMatch + UTCTime | uTCTimeMatch + DirectoryString{} | caseIgnoreMatch + BMPString | caseIgnoreMatch + GeneralString | caseIgnoreMatch + GraphicString | caseIgnoreMatch + IA5String | caseIgnoreMatch + PrintableString | caseIgnoreMatch + TeletexString | caseIgnoreMatch + UniversalString | caseIgnoreMatch + UTF8String | caseIgnoreMatch + VideotexString | caseIgnoreMatch + VisibleString | caseIgnoreMatch + + Notes. + + 1) The DistinguishedName type is defined by assignment to be the same + as the RDNSequence type. Some types (e.g. Name and LocalName) + directly reference RDNSequence rather than DistinguishedName. + Specifying RDNSequence captures all these DN-like types. + + 2) A RelativeDistinguishedName value is only matched by rdnMatch if + it is not part of an RDNSequence value. + + 3) The telephone number component of the FacsimileTelephoneNumber + ASN.1 type [10] is defined as a constrained PrintableString. + PrintableString component values that are part of a + FacsimileTelephoneNumber value can be identified separately from + other components of PrintableString type by the specifier + FacsimileTelephoneNumber.telephoneNumber, so that + telephoneNumberMatch can be selectively applied. The fourth + edition of X.520 defines the telephoneNumber component of + FacsimileTelephoneNumber to be of the type TelephoneNumber, making + the row for FacsimileTelephoneNumber.telephoneNumber components + redundant. + + The directoryComponentsMatch rule MAY be used as the defined equality + matching rule for an attribute. + + +9. Component Matching Examples + + + +Legg Expires 19 October 2002 [Page 29] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + This section contains examples of search filters using the + componentFilterMatch matching rule. The filters are described using + the string representation of LDAP search filters from [17]. Note + that [17] requires asterisks to be escaped in assertion values (in + these examples the assertion values are all + encodings). The asterisks have not been escaped in these examples + for the sake of clarity, and to avoid confusing the LDAP protocol + representation of search filter assertion values, where such escaping + does not apply. Line breaks and indenting have been added only as an + aid to readability. + + The example search filters are all single extensible match filter + items, though there is no reason why componentFilterMatch can't be + used in more complicated search filters. + + The first examples describe searches over the objectClasses schema + operational attribute, which has an attribute syntax described by the + ASN.1 type ObjectClassDescription [8], and holds the definitions of + the object classes known to a directory server. The definition of + ObjectClassDescription is as follows: + + ObjectClassDescription ::= SEQUENCE { + identifier OBJECT-CLASS.&id, + name SET OF DirectoryString {ub-schema} OPTIONAL, + description DirectoryString {ub-schema} OPTIONAL, + obsolete BOOLEAN DEFAULT FALSE, + information [0] ObjectClassInformation } + + ObjectClassInformation ::= SEQUENCE { + subclassOf SET OF OBJECT-CLASS.&id OPTIONAL, + kind ObjectClassKind DEFAULT structural, + mandatories [3] SET OF ATTRIBUTE.&id OPTIONAL, + optionals [4] SET OF ATTRIBUTE.&id OPTIONAL } + + ObjectClassKind ::= ENUMERATED { + abstract (0), + structural (1), + auxiliary (2) } + + OBJECT-CLASS.&id and ATTRIBUTE.&id are equivalent to the OBJECT + IDENTIFIER ASN.1 type. A value of OBJECT-CLASS.&id is an OBJECT + IDENTIFIER for an object class. A value of ATTRIBUTE.&id is an + OBJECT IDENTIFIER for an attribute type. + + The following search filter finds the object class definition for the + object class identified by the OBJECT IDENTIFIER 2.5.6.18: + + (objectClasses:componentFilterMatch:= + + + +Legg Expires 19 October 2002 [Page 30] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + item:{ component "identifier", + rule objectIdentifierMatch, value 2.5.6.18 }) + + A match on the "identifier" component of objectClasses values is + equivalent to the objectIdentifierFirstComponentMatch matching rule + applied to attribute values of the objectClasses attribute type. The + componentFilterMatch matching rule subsumes the functionality of the + objectIdentifierFirstComponentMatch, integerFirstComponentMatch and + directoryStringFirstComponentMatch matching rules. + + The following search filter finds the object class definition for the + object class called foobar: + + (objectClasses:componentFilterMatch:= + item:{ component "name.*", + rule caseIgnoreMatch, value "foobar" }) + + An object class definition can have multiple names and the above + filter will match an objectClasses value if any one of the names is + "foobar". + + The component reference "name.0" identifies the notional count of the + number of names in an object class definition. The following search + filter finds object class definitions with exactly one name: + + (objectClasses:componentFilterMatch:= + item:{ component "name.0", rule integerMatch, value 1 }) + + The "description" component of an ObjectClassDescription is defined + to be an OPTIONAL DirectoryString. The following search filter finds + object class definitions that have descriptions, regardless of the + contents of the description string: + + (objectClasses:componentFilterMatch:= + item:{ component "description", + rule presentMatch, value NULL }) + + The presentMatch returns TRUE if the description component is present + and FALSE otherwise. + + The following search filter finds object class definitions that don't + have descriptions: + + (objectClasses:componentFilterMatch:= + not:item:{ component "description", + rule presentMatch, value NULL }) + + The following search filter finds object class definitions with the + + + +Legg Expires 19 October 2002 [Page 31] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + word "bogus" in the description: + + (objectClasses:componentFilterMatch:= + item:{ component "description", + rule caseIgnoreSubstringsMatch, + value { any:"bogus" } }) + + The assertion value is of the SubstringAssertion syntax, i.e. + + SubstringAssertion ::= SEQUENCE OF CHOICE { + initial [0] DirectoryString {ub-match}, + any [1] DirectoryString {ub-match}, + final [2] DirectoryString {ub-match} } + + The "obsolete" component of an ObjectClassDescription is defined to + be DEFAULT FALSE. An object class is obsolete if the "obsolete" + component is present and set to TRUE. The following search filter + finds all obsolete object classes: + + (objectClasses:componentFilterMatch:= + item:{ component "obsolete", rule booleanMatch, value TRUE }) + + An object class is not obsolete if the "obsolete" component is not + present, in which case it defaults to FALSE, or is present but is + explicitly set to FALSE. The following search filter finds all non- + obsolete object classes: + + (objectClasses:componentFilterMatch:= + item:{ component "obsolete", rule booleanMatch, value FALSE }) + + The useDefaultValues flag in the ComponentAssertion defaults to TRUE + so the componentFilterMatch rule treats an absent "obsolete" + component as being present and set to FALSE. The following search + filter finds only object class definitions where the "obsolete" + component has been explicitly set to FALSE, rather than implicitly + defaulting to FALSE: + + (objectClasses:componentFilterMatch:= + item:{ component "obsolete", useDefaultValues FALSE, + rule booleanMatch, value FALSE }) + + With the useDefaultValues flag set to FALSE, if the "obsolete" + component is absent the component reference identifies no component + value and the matching rule will return FALSE. The matching rule can + only return TRUE if the component is present and set to FALSE. + + The "information.kind" component of the ObjectClassDescription is an + ENUMERATED type. The allComponentsMatch matching rule can be used to + + + +Legg Expires 19 October 2002 [Page 32] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + match values of an ENUMERATED type. The following search filter + finds object class definitions for auxiliary object classes: + + (objectClasses:componentFilterMatch:= + item:{ component "information.kind", + rule allComponentsMatch, value auxiliary }) + + The following search filter finds auxiliary object classes with + commonName (cn or 2.5.4.3) as a mandatory attribute: + + (objectClasses:componentFilterMatch:=and:{ + item:{ component "information.kind", + rule allComponentsMatch, value auxiliary }, + item:{ component "information.mandatories.*", + rule objectIdentifierMatch, value cn } }) + + The following search filter finds auxiliary object classes with + commonName as a mandatory or optional attribute: + + (objectClasses:componentFilterMatch:=and:{ + item:{ component "information.kind", + rule allComponentsMatch, value auxiliary }, + or:{ + item:{ component "information.mandatories.*", + rule objectIdentifierMatch, value cn }, + item:{ component "information.optionals.*", + rule objectIdentifierMatch, value cn } } }) + + Extra care is required when matching optional SEQUENCE OF or SET OF + components because of the distinction between an absent list of + instances and a present, but empty, list of instances. The following + search filter finds object class definitions with less than three + names, including object class definitions with a present but empty + list of names, but does not find object class definitions with an + absent list of names: + + (objectClasses:componentFilterMatch:= + item:{ component "name.0", + rule integerOrderingMatch, value 3 }) + + If the "name" component is absent the "name.0" component is also + considered to be absent and the ComponentAssertion evaluates to + FALSE. If the "name" component is present, but empty, the "name.0" + component is also present and equal to zero, so the + ComponentAssertion evaluates to TRUE. To also find the object class + definitions with an absent list of names the following search filter + would be used: + + + + +Legg Expires 19 October 2002 [Page 33] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + (objectClasses:componentFilterMatch:=or:{ + not:item:{ component "name", rule presentMatch, value NULL }, + item:{ component "name.0", + rule integerOrderingMatch, value 3 } }) + + Distinguished names embedded in other syntaxes can be matched with a + componentFilterMatch. The uniqueMember attribute type has an + attribute syntax described by the ASN.1 type NameAndOptionalUID. + + NameAndOptionalUID ::= SEQUENCE { + dn DistinguishedName, + uid UniqueIdentifier OPTIONAL } + + The following search filter finds values of the uniqueMember + attribute containing the author's DN: + + (uniqueMember:componentFilterMatch:= + item:{ component "dn", + rule distinguishedNameMatch, + value "cn=Steven Legg,o=Adacel,c=AU" }) + + The DistinguishedName and RelativeDistinguishedName ASN.1 types are + also complex ASN.1 types so the component matching rules can be + applied to their inner components. + + DistinguishedName ::= RDNSequence + + RDNSequence ::= SEQUENCE OF RelativeDistinguishedName + + RelativeDistinguishedName ::= SET SIZE (1..MAX) OF + AttributeTypeAndValue + + AttributeTypeAndValue ::= SEQUENCE { + type AttributeType ({SupportedAttributes}), + value AttributeValue ({SupportedAttributes}{@type}) } + + AttributeType ::= ATTRIBUTE.&id + + AttributeValue ::= ATTRIBUTE.&Type + + ATTRIBUTE.&Type is an open type. A value of ATTRIBUTE.&Type is + constrained by the type component of AttributeTypeAndValue to be of + the attribute syntax of the nominated attribute type. Note: the + fourth edition of X.500 extends and renames the AttributeTypeAndValue + SEQUENCE type. + + The seeAlso attribute has the DistinguishedName syntax. The + following search filter finds seeAlso attribute values containing the + + + +Legg Expires 19 October 2002 [Page 34] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + RDN, "o=Adacel", anywhere in the DN: + + (seeAlso:componentFilterMatch:= + item:{ component "*", rule rdnMatch, value "o=Adacel" }) + + The following search filter finds all seeAlso attribute values with + "cn=Steven Legg" as the RDN of the named entry (i.e. the "first" RDN + in an LDAPDN or the "last" RDN in an X.500 DN): + + (seeAlso:componentFilterMatch:= + item:{ component "-1", + rule rdnMatch, value "cn=Steven Legg" }) + + The following search filter finds all seeAlso attribute values naming + entries in the DIT subtree of "o=Adacel,c=AU": + + (seeAlso:componentFilterMatch:=and:{ + item:{ component "1", rule rdnMatch, value "c=AU" }, + item:{ component "2", rule rdnMatch, value "o=Adacel" } }) + + The following search filter finds all seeAlso attribute values + containing the naming attribute types commonName (cn) and + telephoneNumber in the same RDN: + + (seeAlso:componentFilterMatch:= + item:{ component "*", rule componentFilterMatch, + value and:{ + item:{ component "*.type", + rule objectIdentifierMatch, value cn }, + item:{ component "*.type", + rule objectIdentifierMatch, + value telephoneNumber } } }) + + The following search filter would find all seeAlso attribute values + containing the attribute types commonName and telephoneNumber, but + not necessarily in the same RDN: + + (seeAlso:componentFilterMatch:=and:{ + item:{ component "*.*.type", + rule objectIdentifierMatch, value cn }, + item:{ component "*.*.type", + rule objectIdentifierMatch, value telephoneNumber } }) + + The following search filter finds all seeAlso attribute values + containing the word "Adacel" in any organizationalUnitName (ou) + attribute value in any AttributeTypeAndValue of any RDN: + + (seeAlso:componentFilterMatch:= + + + +Legg Expires 19 October 2002 [Page 35] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + item:{ component "*.*.value.(2.5.4.11)", + rule caseIgnoreSubstringsMatch, + value { any:"Adacel" } }) + + The component reference "*.*.value" identifies an open type, in this + case an attribute value. In a particular AttributeTypeAndValue, if + the attribute type is not organizationalUnitName then the + ComponentAssertion evaluates to FALSE. Otherwise the substring + assertion is evaluated against the attribute value. + + +10. Security Considerations + + The component matching rules described in this document allow for a + compact specification of matching capabilities that could otherwise + have been defined by a plethora of specific matching rules, i.e. + despite their expressiveness and flexibility the component matching + rules do not behave in a way uncharacteristic of other matching + rules, so the security issues for component matching rules are no + different than for any other matching rule. However, because the + component matching rules are applicable to any attribute syntax, + support for them in a directory server may allow searching of + attributes that were previously unsearchable by virtue of there not + being a suitable matching rule. Such attribute types ought to be + properly protected with appropriate access controls. + + +11. Acknowledgements + + The author would like to thank Tom Gindin for private email + discussions that clarified and refined the ideas presented in this + document. + + +12. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access + Protocol (v3)", RFC 2251, December 1997. + + [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight + Directory Access Protocol (v3): Attribute Syntax Definitions", + RFC 2252, December 1997. + + + +Legg Expires 19 October 2002 [Page 36] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished + Names", RFC 2253, December 1997. + + [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC + 2279, January 1998. + + [7] Legg, S., "Generic String Encoding Rules for ASN.1 Types", + draft-legg-ldap-gser-xx.txt, a work in progress, March 2002. + + [8] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, + Information Technology - Open Systems Interconnection - The + Directory: Models + + [9] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998, + Information Technology - Open Systems Interconnection - The + Directory: Authentication Framework + + [10] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, + Information Technology - Open Systems Interconnection - The + Directory: Selected attribute types + + [11] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998 + Information Technology - Abstract Syntax Notation One (ASN.1): + Specification of basic notation + + [12] ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC + 8824-1:1998/Amd 1:2000 Relative object identifiers + + [13] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998 + Information Technology - Abstract Syntax Notation One (ASN.1): + Information object specification + + [14] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998 + Information Technology - Abstract Syntax Notation One (ASN.1): + Constraint specification + + [15] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998 + Information Technology - Abstract Syntax Notation One (ASN.1): + Parameterization of ASN.1 specifications + + +13. Informative References + + [16] Hovey, R. and S. Bradner, "The Organizations Involved in the + IETF Standards Process", BCP 11, RFC 2028, October 1996. + + [17] Howes, T., "The String Representation of LDAP Search Filters", + + + +Legg Expires 19 October 2002 [Page 37] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + RFC 2254, December 1997. + + [18] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, + Information Technology - Open Systems Interconnection - The + Directory: Overview of concepts, models and services + + [19] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998 + Information Technology - ASN.1 encoding rules: Specification of + Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and + Distinguished Encoding Rules (DER) + + +14. Intellectual Property Notice + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. [16] Copies + of claims of rights made available for publication and any assurances + of licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +15. Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + + + +Legg Expires 19 October 2002 [Page 38] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +16. Author's Address + + Steven Legg + Adacel Technologies Ltd. + 405-409 Ferntree Gully Road + Mount Waverley, Victoria 3149 + AUSTRALIA + + Phone: +61 3 9451 2107 + Fax: +61 3 9541 2121 + EMail: steven.legg@adacel.com.au + + +17. Appendix A - Changes From Previous Drafts + +17.1 Changes in Draft 01 + + Section 4.1.7 (now 5.1.7) was added to enable component matching of + values embedded in encoded form into BIT STRINGs or OCTET STRINGs. + In particular, this is to allow component matching of values in + Certificate extensions. The rule was added in Section 4.1 + (now 5.1) to allow the OCTET STRING contents to be treated as either + raw octets or as an embedded value. + + References to a companion document summarizing the ASN.1 types of + LDAP syntaxes were removed to avoid holding up this document. + + The OpenType syntax was renamed to OpenAssertionType. + + Object identifiers for the new syntax and matching rule definitions + have been allocated from an arc belonging to Adacel Technologies Ltd. + + + + +Legg Expires 19 October 2002 [Page 39] + +INTERNET-DRAFT LDAP & X.500 Component Matching Rules April 19, 2002 + + +17.2 Changes in Draft 02 + + The context specific tagging in the ComponentAssertion ASN.1 type was + unnecessary and has been removed. + + The encoding of OpenAssertionType assertion values outside of + ComponentAssertions has been clarified, and the description of + OpenAssertionType has been promoted to its own section. + +17.3 Changes in Draft 03 + + The default matching by allComponentsMatch of component values of BIT + STRING types with named bit lists has been changed to ignore trailing + zero bits. + + Typographical errors in the rule have been fixed. + +17.4 Changes in Draft 04 + + When the matching rule in a ComponentAssertion has a variable + assertion syntax it is not possible to determine the syntax of the + value component from the ComponentAssertion alone when the associated + component reference has referenced through an open type. Deducing + what that syntax should be from inspection of the other + ComponentAssertions in a ComponentFilter is difficult to implement in + any comprehensive way. The