rfc-3727

ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules

S. Legg
date2004-02 streamIETF wgnon working group statusPROPOSED STANDARD pages5 canonicalhttps://www.rfc-editor.org/rfc/rfc3727 doi10.17487/RFC3727
This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One (ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules. [STANDARDS-TRACK]

Extracted elements (12)

design-rationale §2

The object identifiers used in the ComponentMatching module were assigned by Adacel Technologies under an arc assigned to Adacel by Standards Australia, rather than being assigned through IANA. This reflects the pre-existing OID assignments from RFC 3687 that this document consolidates without modification.

ldap, registry

design-rationale §1

This document updates RFC 3687 by collecting all ASN.1 definitions of the component matching rules into a single, appropriately identified ASN.1 module. The motivation is to allow other specifications to reference the component matching rule definitions from within their own ASN.1 modules, which was not possible before this consolidation.

ldap

protocol-element §2

allComponentsMatch is a MATCHING-RULE with OID { 1 2 36 79672281 1 13 6 }, defined without an explicit SYNTAX clause. It is used to match against all components of an attribute value.

ldap

protocol-element §2

ComponentAssertion is a SEQUENCE with an optional ComponentReference field (SIZE 1..MAX), a useDefaultValues BOOLEAN defaulting to TRUE, a rule field of type MATCHING-RULE.&id, and a value field of type MATCHING-RULE.&AssertionType. It represents a single component-level assertion against a directory attribute value.

ldap

protocol-element §2

ComponentFilter is a CHOICE type supporting four alternatives: item [0] ComponentAssertion (a leaf assertion), and [1] SEQUENCE OF ComponentFilter (conjunction), or [2] SEQUENCE OF ComponentFilter (disjunction), and not [3] ComponentFilter (negation). This enables Boolean combinations of component assertions.

ldap

protocol-element §2

componentFilterMatch is a MATCHING-RULE with SYNTAX ComponentFilter and OID { 1 2 36 79672281 1 13 2 }. It is the primary matching rule for evaluating ComponentFilter expressions against attribute values.

ldap

protocol-element §2

ComponentReference is defined as a UTF8String, used to identify a specific component within a complex attribute value for matching purposes.

ldap

protocol-element §2

directoryComponentsMatch is a MATCHING-RULE with OID { 1 2 36 79672281 1 13 7 }, defined without an explicit SYNTAX clause. It provides matching for directory-typed components of attribute values.

ldap

protocol-element §2

presentMatch is an additional useful MATCHING-RULE with SYNTAX NULL and OID { 1 2 36 79672281 1 13 5 }. It tests whether a component is present within an attribute value.

ldap

protocol-element §2

rdnMatch is an additional useful MATCHING-RULE with SYNTAX RelativeDistinguishedName and OID { 1 2 36 79672281 1 13 3 }. It supports matching against RDN-typed components within attribute values.

ldap

protocol-element §2

The ComponentMatching ASN.1 module is identified by OID {iso(1) 2 36 79672281 xed(3) module(0) component-matching(4)}. It uses EXPLICIT TAGS and EXTENSIBILITY IMPLIED, and imports MATCHING-RULE and RelativeDistinguishedName from the InformationFramework module defined in X.501.

ldap

security-consideration §3

This document makes no changes to the component matching rule definitions; it only collects them into an ASN.1 module. All security considerations are inherited from RFC 3687, which implementors must consult for the security implications of using component matching rules.

ldap, security