1 / 30

News from the wonderful world of directories

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

Download Presentation

News from the wonderful world of directories

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. News from the wonderful world of directories Erik Andersen Denmark

  2. 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

  3. 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

  4. 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

  5. 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)

  6. 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

  7. 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)

  8. 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

  9. Relationship between X.500 and LDAP (Lightweight Directory Access Protocol) X.500 LDAP

  10. Relationship between X.500 and LDAP with maximum alignment X.500 LDAP

  11. 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

  12. A distributed directory LDAPserver User DUA DSA DAP LDAP DSA DSP A directory DSP LDAP client User DSA DSA DUA LDAP

  13. 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}}

  14. 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

  15. 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)) }

  16. 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

  17. 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

  18. Format of octets in a UTF-8 sequence

  19. 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!

  20. Second problem Comparison is most often done disregarding case differences All upper case letters have to be converted to lower case letters before comparison

  21. 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

  22. 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.

  23. EIDQ Association

  24. Members (30 as at 17 Feb 2004)

  25. E.115 - Computerized directory assistance User International server E.115 protocol Operator Local server

  26. 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

  27. 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

  28. 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 }

  29. Proximity search

  30. END

More Related