300 likes | 370 Vues
News from the wonderful world of directories. Erik Andersen Denmark. Agenda. The position of X.500/LDAP X.500 enhancements Concept of Friends Attributes Paging on the DSP Maximum alignment with LDAP Enhancements to Public-key and Attribute certificates Enhancements to E.115
E N D
News from the wonderful world of directories Erik Andersen Denmark
Agenda • The position of X.500/LDAP • X.500 enhancements • Concept of Friends Attributes • Paging on the DSP • Maximum alignment with LDAP • Enhancements to Public-key and Attribute certificates • Enhancements to E.115 • Functional enhancements • XML access
The X.500/LDAP Directory • An LDAP or X.500 directory is a general purpose directory • Gives a set of specifications for: • how objects are represented by entries in a directory • how objects represented in a directory are named • how information about objects is created, organised, interrogated, updated and deleted • A directory can be distributed allowing: • the establishment of a global Directory • information to be maintained by the owner of information • a separation between public and private domains • possibility for replication of information
Relationship between X.500 and LDAP (Lightweight Directory Access Protocol) X.500 LDAP • LDAP originally developed for X.500 access • Later developed own server specifications • Uses the X.500 model • Identical in many ways, except for syntax • X.500: Full use of ASN.1 • LDAP: Simple ASN.1 and Augmented Backus-Naur Form (ABNF) • Most X.500 implementations support LDAP • LDAP widely implemented and used
Editions of X.500 Directory Specifications • Developed by ISO/IEC and ITU-T (former CCITT) as: • ISO/IEC 9594 multi-part International Standard • ITU-T X.500 Series of Recommendations • Four editions so far: • Edition 2: ISO/IEC 9594:1995 | ITU-T X.500 (1993) • Edition 1: ISO/IEC 9594:1990 | CCITT X.500 (1988) • Edition 3: ISO/IEC 9594:1998 | ITU-T X.500 (1997) • Edition 4: ISO/IEC 9594:2001 | ITU-T X.500 (2001)
X.500 5th edition enhancements • Concept of Friends Attributes • Paging on the DSP • Maximum alignment with LDAP • Enhancements to Public-key and Attribute certificates Expected publication: During 2005
Friend attributes Attribute subtyping – same syntax: name givenName commonName surname localityName url (RFC 1738 syntax) email (RFC 822 syntax) Friend attributes – possibly different syntaxes: commAddress telephoneNumber (E.164 syntax)
Paged results on the DSP User DSP paged result Bound-DSA paged result DUA DSP DSA DSP DAP DSP DSP Bound DSA DSP DSP DSA DSA
Relationship between X.500 and LDAP (Lightweight Directory Access Protocol) X.500 LDAP
Relationship between X.500 and LDAP with maximum alignment X.500 LDAP
Maximum X.500 alignment with LDAP NOTE – One way alignment • Alignment of concepts – add LDAP concepts to make LDAP concepts a subset of X.500 concepts. • Simplify specifications – removal of dependency of lower layer documentation • Alignment of operations (replace value) • Multiple namespaces (Directory Information Trees) • Directory consisting of LDAP and X.500 server mix • ISO 10646 (UTF-8) matching • Component matching
A distributed directory LDAPserver User DUA DSA DAP LDAP DSA DSP A directory DSP LDAP client User DSA DSA DUA LDAP
Matching problem Certificate 2 keyUsage = dataEncipherment certificatePolicies = { … policyIdentifier = { a.b.d}} Filter keyUsage = digitalSignature And policyIndentifier = { a b d } Directory entry Attribute Certificate 1 keyUsage = digitalSignature certificatePolicies = { … policyIdentifier = { a.b.c}}
Component matching rule ComponentMatch against component n Attribute value Component m Component n Component o • Evaluate to TRUE if match • Can be combined by AND, OR and NOT operations in any combination and nesting level onto a particular attribute value of a particular attribute type • Evaluates to TRUE if just one attribute value of the attribute type evaluates to TRUE
DirectoryString DirectoryString { INTEGER : maxSize } ::= CHOICE { teletexString TeletexString (SIZE (1..maxSize)), printableString PrintableString (SIZE (1..maxSize)), bmpString BMPString (SIZE (1..maxSize)), universalString UniversalString (SIZE (1..maxSize)), uTF8String UTF8String (SIZE (1..maxSize)) }
ISO/IEC 10646The base character set standard • ISO/IEC 10646 - Universal Multiple-Octet Coded Character Set (UCS) • Every character is coded in 4 octets • Allows encoding of all characters used by written languages all over the world • The practical realisation is specified in the Unicode standard (produced by a consortium) • Supports multiple encoding formats: • UTF-8 - octet oriented • BMP (UCS-2) - half word oriented • UTF-16 - half word oriented • UCS-4 (UTF-32) - word oriented
UCS Transformation Format 8(UTF-8) • Defined in Annex D of ISO/IEC 10646-1 : 2003, Universal Multiple-Octet Coded Character Set (UCS) • Required by (almost) all Internet specifications
First problem • We need to compare names and values • Some characters may be represented in several ways It is not possible to do a simple bitwise comparison to check if two names or values are equal!
Second problem Comparison is most often done disregarding case differences All upper case letters have to be converted to lower case letters before comparison
String preparation Text string 1 Transcoding Transcoded string 1 Mapping Mapped string 1 Normalise Normalised string 1 Octet wise comparison Text string 2 Transcoding Transcoded string 2 Mapping Mapped string 2 Normalise Normalised string 2
X.509 enhancements • Notice of future revocation • Notice of revoked group of entries • Expired certificates on CRLs • Advanced certificate matching rule • XML encoded privilege information • Clarifications • Misc. enhancements to PMI • Etc.
E.115 - Computerized directory assistance User International server E.115 protocol Operator Local server
ITU-T Rec. E.115 (2005)Computerized Directory Assistance • OSI stack removed • Home grown TCP/IP support integrated in text • Specifies two versions of the protocol • Version 1: • The 1995 edition + all agreed extensions • All keywords specified in Annex • Complete rewrite and restructuring of 1995 edition • Added clarifications • ASN.1 BER encoding • Support mandatory • Version 2: • Keywords replaced by new fields – keyword concept no longer used • Several new enhancements • ASN.1 BER and XML (or ASN.1 XER) encoding • Future extensions using ITU-T procedure
Version 2 design criteria • Keep backward compatibility • Unchanged fields use same tag • Tags reserved for obsolete fields • Common text for unchanged fields • Keep ASN.1 and XML Schema Definitions (XSD) aligned • ASN.1 XER encoding will produce same encoding as the XSD • ASN.1 EXTENDED-XER encoding instruction used
Example of ASN.1 specification InquiryPart1 ::= [ TAG: APPLICATION 0 ] IMPLICIT SET { messageIndicators [ATTRIBUTE] [TAG: 0] IMPLICIT E115String (SIZE(4)), internationalIndicator [ATTRIBUTE] [TAG: 1] IMPLICIT E115NumericString (SIZE(8)), originatingTerminalCode [ATTRIBUTE] [TAG: 2] IMPLICIT E115String (SIZE(8)), dateAndTime [ATTRIBUTE] [TAG: 3] IMPLICIT E115NumericString (SIZE(12))OPTIONAL, messageNumber [ATTRIBUTE] [TAG: 4] IMPLICIT E115String (SIZE(4)) OPTIONAL }