This section contains a brief and very superficial overview of ASN.1 SYNTAX sufficient to allow understanding of component expressions. In general, there is little need to drop down to this level of detail unless one is genetically pre-disposed to do so. There are many excellent and free resources ASN.1 resources which a dedicated reader will find endlessly fascinating and jolly good fun. Less dedicated readers may have to lie down after even a casual glance at this stuff.
If you need, or even want, to know more about ASN.1 (and DER) then try this Survival Guide. Be warned - it's not fun stuff.
An ASN.1 OID when traced to its authoritative definition will contain a textual description and some ASN.1 SYNTAX (or gobblydegook) which formally defines the object. ASN.1 syntax is brutally complex and this overview focuses on only 5 types SEQUENCE OF, SEQUENCE, SET OF, SET and CHOICE which figure significantly in component matching. The quick, working definition of these elements is:
SEQUENCE OF | An ordered list of instances of the same type. The order is fixed and only contains one type (or attribute in the LDAP context) |
SET OF | An unordered list of instances of the same types. The order is not fixed (only fixed at run-time) but only contains one type (or attribute in the LDAP context) |
SEQUENCE | An ordered list of instances of different types. The order is fixed and contains multiple types (or attributes in the LDAP context) |
SET | An unordered list of instances of different types. The order is not fixed (only fixed at run-time) and contains multiple types (or attributes in the LDAP context) |
CHOICE | Defines a single instance which may be any one of the types defined in the ordered list. |
This guide separates component matching into simple and complex categories. Simple component matching, as defined by this guide, is only used with attributes defined by SEQUENCE OF and SET OF constructs - essentially these constructs define multiple instances each of which is of the same type. For example DistinguishedName is a SEQUENCE OF and has, according to X.501, the following ASN.1 definition:
Note: The capitalization is visually significant when used for ASN.1 definitions, thus, distinguishedName is the name of the attribute and DistinguishedName is the name of the attribute definition.
# definition from X.501 DistinguishedName ::= RDNSequence # DistinguishedName aliased to RDNSequence RDNSequence ::= SEQUENCE OF RelativeDistinguishedName # defines RDNSequence as an ordered list (SEQUENCE OF) # of instances of RelativeDistinguishedName RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue # this defines the composition of each # RelativeDistinguishedName as a SET (unordered list) of # AttributeTypeAndValue each of which is comprised of a # SEQUENCE (ordered list) of type and value entries as # defined below AttributeTypeAndValue ::= SEQUENCE { type AttributeType ({SupportedAttributes}), value AttributeValue ({SupportedAttributes}{@type}) } AttributeType ::= ATTRIBUTE.&id AttributeValue ::= ATTRIBUTE.&Type
Since all the instances are of the same type it is enough in any component matching to identify the number of the instance, for example instance "1" which using component matching's positive number selection would be the first item in the list (in the case of a DN positive numbers start from the RIGHT). Examples of attributes using DistinguishedName are DistinguishedName (2.5.4.49), member ( 2.5.4.31 ), seeAlso (2.5.4.34), owner (2.5.4.32), roleOccupant (2.5.4.33).
Complex component matching is applied to SEQUENCE and SET syntaxes and these constructs define multiple values each of which may be of a different type. For example uniqueMember (2.5.4.50) has the following ASN.1 notation:
# definition from X.520 uniqueMember ATTRIBUTE ::= { WITH SYNTAX NameAndOptionalUID EQUALITY MATCHING RULE uniqueMemberMatch ID id-at-uniqueMember } # points to the ASN.1 definition of NameAndOptionalUID # which is a SEQUENCE NameAndOptionalUID ::= SEQUENCE { dn DistinguishedName, uid UniqueIdentifier OPTIONAL } # in turn UniqueIdentifier is defined in X.520 as uniqueIdentifier ATTRIBUTE ::= { WITH SYNTAX UniqueIdentifier EQUALITY MATCHING RULE bitStringMatch ID id-at-uniqueIdentifier } UniqueIdentifier ::= BIT STRING # DistinguishedName is defined in previous example
Since each instance in the attribute is different, and since SET allows the instances to appear in any order, any componet extraction must reference the instance by, say, its left-hand name or some other characteristic.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
Contents
tech info
guides home
intro
contents
1 objectives
big picture
2 concepts
3 ldap objects
quickstart
4 install ldap
5 samples
6 configuration
7 replica & refer
reference
8 ldif
9 protocol
10 ldap api
operations
11 howtos
12 trouble
13 performance
14 ldap tools
security
15 security
appendices
notes & info
ldap resources
rfc's & x.500
glossary
ldap objects
change log
This work is licensed under a
Creative Commons License.
If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox
Search
Share
Page
Resources
Systems
FreeBSD
NetBSD
OpenBSD
DragonFlyBSD
Linux.org
Debian Linux
Software
LibreOffice
OpenOffice
Mozilla
GitHub
GNU-Free SW Foundation
get-dns
Organizations
Open Source Initiative
Creative Commons
Misc.
Ibiblio - Library
Open Book Project
Open Directory
Wikipedia
Site
Copyright © 1994 - 2024 ZyTrax, Inc. All rights reserved. Legal and Privacy |
site by zytrax hosted by javapipe.com |
web-master at zytrax Page modified: February 04 2022. |