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
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.
3.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 [15], 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 <select> form of ComponentId may be used to identify one
of these permissible types in an open type. Subcomponents of that
type can then be identified with further ComponentIds.
The other components constraining the open type are termed the
referenced components [15]. The <select> 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 permissible types of the
open type.
Where the open type is constrained by a component relation
constraint, there is a <Value> in the <select> form for each of the
referenced components in the component relation constraint, appearing
in the same order. The ASN.1 type of each of these values is the
same as the ASN.1 type of the corresponding referenced component.
The type of a referenced component is potentially any ASN.1 type
however it is typically an OBJECT IDENTIFIER or INTEGER, which means
that the <Value> in the <select> form of ComponentId will nearly
always be an <ObjectIdentifierValue> or <IntegerValue> [9].
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 <select> form can be used.
If an instance of <select> 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.
3.1.6.1. Open Type Referencing Example
The ASN.1 type AttributeTypeAndValue [10] 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 <select> form of ComponentId is used
to identify attribute values of specific attribute types it will
contain a single OBJECT IDENTIFIER value.
The component reference "value" on AttributeTypeAndValue refers to
the open type.
One of the X.500 standard attributes is facsimileTelephoneNumber
[12], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is
defined to have the following syntax.
FacsimileTelephoneNumber ::= SEQUENCE {
telephoneNumber PrintableString(SIZE(1..ub-telephone-number)),
parameters G3FacsimileNonBasicParameters OPTIONAL }
The component reference "value.(2.5.4.23)" on AttributeTypeAndValue
specifies an attribute value with the FacsimileTelephoneNumber
syntax.
The component reference "value.(2.5.4.23).telephoneNumber" on
AttributeTypeAndValue identifies the telephoneNumber component of a
facsimileTelephoneNumber attribute value. The component reference
"value.(facsimileTelephoneNumber)" is equivalent to
"value.(2.5.4.23)".
If the AttributeTypeAndValue ASN.1 value contains an attribute type
other than facsimileTelephoneNumber then there are no corresponding
component values for the component references "value.(2.5.4.23)" and
"value.(2.5.4.23).telephoneNumber".
3.1.7. Referencing Contained Types
Sometimes the contents of a BIT STRING or OCTET STRING value are
required to be the encodings of other ASN.1 values of specific ASN.1
types. For example, the extnValue component of the Extension type
component in the Certificate type [11] is an OCTET STRING that is
required to contain a Distinguished Encoding Rules (DER) [17]
encoding of a certificate extension value. It is useful to be able
to refer to the embedded encoded value and its components. An
embedded encoded value is here referred to as a contained value and
its associated type as the contained type.
If the ASN.1 type is a BIT STRING or OCTET STRING type containing
encodings of other ASN.1 values then the <content> form of
ComponentId may be used to identify the contained type.
Subcomponents of that type can then be identified with further
ComponentIds.
The contained type may be (effectively) an open type, constrained by
some other component in an outer enclosing type (e.g., in a
certificate Extension, extnValue is constrained by the chosen
extnId). In these cases the next ComponentId, if any, MUST be of the
<select> 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 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.
3.1.7.1. Contained Type Referencing Example
The Extension ASN.1 type [11] 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 [11] 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 }
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.
3.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 necessarily 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 3.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 a matching rule applies to more than one attribute syntax (e.g.,
objectIdentifierFirstComponentMatch [12]) then the minimum number of
substitutions required to conform to any one of those syntaxes is
performed. If a matching rule can apply to any attribute syntax
(e.g., the allComponentsMatch rule defined in Section 6.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.
The ComponentAssertion is Undefined if:
a) the matching rule in the ComponentAssertion is not known to the
evaluating procedure,
b) 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) some part of the component reference identifies an open type in
the tested value that 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).
3.2.1. Applicability of Existing Matching Rules
3.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 [9], 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,
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 GSER [9] 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.
3.2.1.2. Telephone Number Matching
Early editions of X.520 [12] 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.
3.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.
3.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].
3.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 Relative Distinguished Names (RDNs) in a Distinguished Name
(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 <RelativeDistinguishedNameValue> rule [9].
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".
3.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 )
( 1.2.36.79672281.1.5.1 DESC ’NULL’ )
The LDAP-specific encoding for a value of the NULL syntax is given by
the <NullValue> rule [9].
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 <count> 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.
3.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 3.2.1, and the new matching rules
defined in Section 3.2.2.
+================================+==============================+
| 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 |
+--------------------------------+------------------------------+
| uTCTimeMatch | UTCTime |
| uTCTimeOrderingMatch | |
+--------------------------------+------------------------------+
Note that the allComponentsMatch matching rule defined in Section 6.2