1 2 3 4 5 6 7Network Working Group S. Legg 8Request for Comments: 3727 Adacel Technologies 9Category: Standards Track February 2004 10 11 12 ASN.1 Module Definition for the 13 LDAP and X.500 Component Matching Rules 14 15Status 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 23Copyright Notice 24 25 Copyright (C) The Internet Society (2004). All Rights Reserved. 26 27Abstract 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 371. 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 58Legg Standards Track [Page 1] 59 60RFC 3727 Module for Component Matching February 2004 61 62 632. Module Definition for Component Matching 64 65 ComponentMatching 66 {iso(1) 2 36 79672281 xed(3) module(0) component-matching(4)} 67 68 -- Copyright (C) The Internet Society (2004). This version of 69 -- this ASN.1 module is part of RFC 3727; see the RFC itself 70 -- for full legal notices. 71 72 DEFINITIONS 73 EXPLICIT TAGS 74 EXTENSIBILITY IMPLIED ::= BEGIN 75 76 IMPORTS 77 MATCHING-RULE, 78 RelativeDistinguishedName 79 FROM InformationFramework 80 {joint-iso-itu-t ds(5) module(1) 81 informationFramework(1) 4} ; 82 83 ComponentAssertion ::= SEQUENCE { 84 component ComponentReference (SIZE(1..MAX)) OPTIONAL, 85 useDefaultValues BOOLEAN DEFAULT TRUE, 86 rule MATCHING-RULE.&id, 87 value MATCHING-RULE.&AssertionType } 88 89 ComponentReference ::= UTF8String 90 91 ComponentFilter ::= CHOICE { 92 item [0] ComponentAssertion, 93 and [1] SEQUENCE OF ComponentFilter, 94 or [2] SEQUENCE OF ComponentFilter, 95 not [3] ComponentFilter } 96 97 componentFilterMatch MATCHING-RULE ::= { 98 SYNTAX ComponentFilter 99 ID { 1 2 36 79672281 1 13 2 } } 100 101 allComponentsMatch MATCHING-RULE ::= { 102 ID { 1 2 36 79672281 1 13 6 } } 103 104 directoryComponentsMatch MATCHING-RULE ::= { 105 ID { 1 2 36 79672281 1 13 7 } } 106 107 108 -- Additional Useful Matching Rules -- 109 110 rdnMatch MATCHING-RULE ::= { 111 112 113 114Legg Standards Track [Page 2] 115 116RFC 3727 Module for Component Matching February 2004 117 118 119 SYNTAX RelativeDistinguishedName 120 ID { 1 2 36 79672281 1 13 3 } } 121 122 presentMatch MATCHING-RULE ::= { 123 SYNTAX NULL 124 ID { 1 2 36 79672281 1 13 5 } } 125 126 END 127 128 The InformationFramework ASN.1 module from which the MATCHING-RULE 129 and RelativeDistinguishedName definitions are imported is defined in 130 X.501 [X501]. 131 132 The object identifiers used in this document have been assigned for 133 use in specifying the component matching rules by Adacel 134 Technologies, under an arc assigned to Adacel by Standards Australia. 135 1363. Security Considerations 137 138 This document collects together the ASN.1 definitions of the 139 component matching rules into an ASN.1 module, but does not modify 140 those definitions in any way. See RFC 3687 [CMR] for the security 141 considerations of using the component matching rules. 142 1434. References 144 1454.1. Normative References 146 147 [CMR] Legg, S., "Lightweight Directory Access Protocol (LDAP) and 148 X.500 Component Matching Rules", RFC 3687, February 2004. 149 150 [X501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, 151 Information Technology - Open Systems Interconnection - The 152 Directory: Models 153 154 [ASN1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, 155 Information technology - Abstract Syntax Notation One 156 (ASN.1): Specification of basic notation 157 1584.2. Informative References 159 160 [LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access 161 Protocol (v3): Technical Specification", RFC 3377, September 162 2002. 163 164 [X500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, 165 Information Technology - Open Systems Interconnection - The 166 Directory: Overview of concepts, models and services 167 168 169 170Legg Standards Track [Page 3] 171 172RFC 3727 Module for Component Matching February 2004 173 174 1755. Author's Address 176 177 Steven Legg 178 Adacel Technologies Ltd. 179 250 Bay Street 180 Brighton, Victoria 3186 181 AUSTRALIA 182 183 Phone: +61 3 8530 7710 184 Fax: +61 3 8530 7888 185 EMail: steven.legg@adacel.com.au 186 187 188 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 226Legg Standards Track [Page 4] 227 228RFC 3727 Module for Component Matching February 2004 229 230 2316. Full Copyright Statement 232 233 Copyright (C) The Internet Society (2004). This document is subject 234 to the rights, licenses and restrictions contained in BCP 78 and 235 except as set forth therein, the authors retain all their rights. 236 237 This document and the information contained herein are provided on an 238 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 239 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 240 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 241 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 242 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 243 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 244 245Intellectual Property 246 247 The IETF takes no position regarding the validity or scope of any 248 Intellectual Property Rights or other rights that might be claimed 249 to pertain to the implementation or use of the technology 250 described in this document or the extent to which any license 251 under such rights might or might not be available; nor does it 252 represent that it has made any independent effort to identify any 253 such rights. Information on the procedures with respect to 254 rights in RFC documents can be found in BCP 78 and BCP 79. 255 256 Copies of IPR disclosures made to the IETF Secretariat and any 257 assurances of licenses to be made available, or the result of an 258 attempt made to obtain a general license or permission for the use 259 of such proprietary rights by implementers or users of this 260 specification can be obtained from the IETF on-line IPR repository 261 at http://www.ietf.org/ipr. 262 263 The IETF invites any interested party to bring to its attention 264 any copyrights, patents or patent applications, or other 265 proprietary rights that may cover technology that may be required 266 to implement this standard. Please address the information to the 267 IETF at ietf-ipr@ietf.org. 268 269Acknowledgement 270 271 Funding for the RFC Editor function is currently provided by the 272 Internet Society. 273 274 275 276 277 278 279 280 281 282Legg Standards Track [Page 5] 283 284