1 2 3 4 5 6 7 Network Working Group S. Legg 8 Request for Comments: 3727 Adacel Technologies 9 Category: Standards Track February 2004 10 11 12 ASN.1 Module Definition for the 13 LDAP and X.500 Component Matching Rules 14 15 Status of this Memo 16 17 This document specifies an Internet standards track protocol for the 18 Internet community, and requests discussion and suggestions for 19 improvements. Please refer to the current edition of the "Internet 20 Official Protocol Standards" (STD 1) for the standardization state 21 and status of this protocol. Distribution of this memo is unlimited. 22 23 Copyright Notice 24 25 Copyright (C) The Internet Society (2004). All Rights Reserved. 26 27 Abstract 28 29 This document updates the specification of the component matching 30 rules for Lightweight Directory Access Protocol (LDAP) and X.500 31 directories (RFC3687) by collecting the Abstract Syntax Notation One 32 (ASN.1) definitions of the component matching rules into an 33 appropriately identified ASN.1 module so that other specifications 34 may reference the component matching rule definitions from within 35 their own ASN.1 modules. 36 37 1. Introduction 38 39 The structure or data type of data held in an attribute of a 40 Lightweight Directory Access Protocol (LDAP) [LDAP] or X.500 [X500] 41 directory is described by the attribute's syntax. Attribute syntaxes 42 range from simple data types, such as text string, integer, or 43 boolean, to complex data types, for example, the syntaxes of the 44 directory schema operational attributes. RFC 3687 [CMR] defines a 45 generic way of matching user selected components in a directory 46 attribute value of any arbitrarily complex attribute syntax. 47 48 This document updates RFC 3687 by collecting the Abstract Syntax 49 Notation One (ASN.1) [ASN1] definitions of RFC 3687 into an 50 appropriately identified ASN.1 module so that other specifications 51 may reference these definitions from within their own ASN.1 modules. 52 53 54 55 56 57 58 Legg Standards Track [Page 1] 59 61 RFC 3727 Module for Component Matching February 2004 62 63 64 2. Module Definition for Component Matching 65 66 ComponentMatching 67 {iso(1) 2 36 79672281 xed(3) module(0) component-matching(4)} 68 69 -- Copyright (C) The Internet Society (2004). This version of 70 -- this ASN.1 module is part of RFC 3727; see the RFC itself 71 -- for full legal notices. 72 73 DEFINITIONS 74 EXPLICIT TAGS 75 EXTENSIBILITY IMPLIED ::= BEGIN 76 77 IMPORTS 78 MATCHING-RULE, 79 RelativeDistinguishedName 80 FROM InformationFramework 81 {joint-iso-itu-t ds(5) module(1) 82 informationFramework(1) 4} ; 83 84 ComponentAssertion ::= SEQUENCE { 85 component ComponentReference (SIZE(1..MAX)) OPTIONAL, 86 useDefaultValues BOOLEAN DEFAULT TRUE, 87 rule MATCHING-RULE.&id, 88 value MATCHING-RULE.&AssertionType } 89 90 ComponentReference ::= UTF8String 91 92 ComponentFilter ::= CHOICE { 93 item [0] ComponentAssertion, 94 and [1] SEQUENCE OF ComponentFilter, 95 or [2] SEQUENCE OF ComponentFilter, 96 not [3] ComponentFilter } 97 98 componentFilterMatch MATCHING-RULE ::= { 99 SYNTAX ComponentFilter 100 ID { 1 2 36 79672281 1 13 2 } } 101 102 allComponentsMatch MATCHING-RULE ::= { 103 ID { 1 2 36 79672281 1 13 6 } } 104 105 directoryComponentsMatch MATCHING-RULE ::= { 106 ID { 1 2 36 79672281 1 13 7 } } 107 108 109 -- Additional Useful Matching Rules -- 110 111 rdnMatch MATCHING-RULE ::= { 112 113 114 115 Legg Standards Track [Page 2] 116 118 RFC 3727 Module for Component Matching February 2004 119 120 121 SYNTAX RelativeDistinguishedName 122 ID { 1 2 36 79672281 1 13 3 } } 123 124 presentMatch MATCHING-RULE ::= { 125 SYNTAX NULL 126 ID { 1 2 36 79672281 1 13 5 } } 127 128 END 129 130 The InformationFramework ASN.1 module from which the MATCHING-RULE 131 and RelativeDistinguishedName definitions are imported is defined in 132 X.501 [X501]. 133 134 The object identifiers used in this document have been assigned for 135 use in specifying the component matching rules by Adacel 136 Technologies, under an arc assigned to Adacel by Standards Australia. 137 138 3. Security Considerations 139 140 This document collects together the ASN.1 definitions of the 141 component matching rules into an ASN.1 module, but does not modify 142 those definitions in any way. See RFC 3687 [CMR] for the security 143 considerations of using the component matching rules. 144 145 4. References 146 147 4.1. Normative References 148 149 [CMR] Legg, S., "Lightweight Directory Access Protocol (LDAP) and 150 X.500 Component Matching Rules", RFC 3687, February 2004. 151 152 [X501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, 153 Information Technology - Open Systems Interconnection - The 154 Directory: Models 155 156 [ASN1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, 157 Information technology - Abstract Syntax Notation One 158 (ASN.1): Specification of basic notation 159 160 4.2. Informative References 161 162 [LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access 163 Protocol (v3): Technical Specification", RFC 3377, September 164 2002. 165 166 [X500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, 167 Information Technology - Open Systems Interconnection - The 168 Directory: Overview of concepts, models and services 169 170 171 172 Legg Standards Track [Page 3] 173 175 RFC 3727 Module for Component Matching February 2004 176 177 178 5. Author's Address 179 180 Steven Legg 181 Adacel Technologies Ltd. 182 250 Bay Street 183 Brighton, Victoria 3186 184 AUSTRALIA 185 186 Phone: +61 3 8530 7710 187 Fax: +61 3 8530 7888 188 EMail: steven.legg (a] adacel.com.au 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 Legg Standards Track [Page 4] 230 232 RFC 3727 Module for Component Matching February 2004 233 234 235 6. Full Copyright Statement 236 237 Copyright (C) The Internet Society (2004). This document is subject 238 to the rights, licenses and restrictions contained in BCP 78 and 239 except as set forth therein, the authors retain all their rights. 240 241 This document and the information contained herein are provided on an 242 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 243 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 244 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 245 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 246 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 247 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 248 249 Intellectual Property 250 251 The IETF takes no position regarding the validity or scope of any 252 Intellectual Property Rights or other rights that might be claimed 253 to pertain to the implementation or use of the technology 254 described in this document or the extent to which any license 255 under such rights might or might not be available; nor does it 256 represent that it has made any independent effort to identify any 257 such rights. Information on the procedures with respect to 258 rights in RFC documents can be found in BCP 78 and BCP 79. 259 260 Copies of IPR disclosures made to the IETF Secretariat and any 261 assurances of licenses to be made available, or the result of an 262 attempt made to obtain a general license or permission for the use 263 of such proprietary rights by implementers or users of this 264 specification can be obtained from the IETF on-line IPR repository 265 at http://www.ietf.org/ipr. 266 267 The IETF invites any interested party to bring to its attention 268 any copyrights, patents or patent applications, or other 269 proprietary rights that may cover technology that may be required 270 to implement this standard. Please address the information to the 271 IETF at ietf-ipr (a] ietf.org. 272 273 Acknowledgement 274 275 Funding for the RFC Editor function is currently provided by the 276 Internet Society. 277 278 279 280 281 282 283 284 285 286 Legg Standards Track [Page 5] 287 289
Indexes created Mon Sep 14 00:24:24 UTC 2026