News from the wonderful world of directories

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