Re: LDAP ISSUE

["Tom Gindin" <tgindin@xxxxxxxxxx>]

      IMHO this is fairly important.  I think that both the standardization
of names for further attributes beyond those mentioned in RFC 2253 section
2.3, both ITU terms such as serialNumber and attributes from other
standards groups such as rfc822Mailbox, is important and has no real
disadvantages.  I also believe that permitting installations to define
their own user-friendly attribute names and have them mapped at the server
rather  than in each client is desirable, but this opinion is less strongly
held because of the possible confusion which could result if different
servers defined the same abbreviation for attributes with different syntax
or semantics.  The use of the abbreviation MAIL for rfc822Mailbox, BTW, is
an example of the mapping at the server.

            Tom Gindin

David Chadwick <d.w.chadwick@xxxxxxxxxxxxx>@mail.imc.org on 07/18/2002
02:36:20 AM

Sent by:    owner-ietf-pkix@xxxxxxxxxxxx


To:    PKIX <ietf-pkix@xxxxxxx>
cc:
Subject:    LDAP ISSUE



There was one LDAP item missed out of the agenda yesterday due to lack
of time. This concerns the use of user friendly strings in LDAP DNs. It
is not an issue of how DNs are encoded in certificates (as these are
ASN.1 DER), but rather how DNs are encoded in the LDAP protocol when
asking to retrieve or store a certificate. LDAP uses user friendly
strings to refer to attribute types, but can use OIDs if no user
friendly strings are known. In the case of DNs, a list of 9 attribute
type user friendly strings are published in RFC 2253 (e.g. C, O, OU
etc.). The revision of LDAPv3 is currently stating that no further
strings can be defined for Internet use (earlier versions allowed for
other strings to be defined e.g. registered with IANA, but no one had
ever bothered to register any further strings). The PKIX group has
specified a larger set of attribute types in its Qualified Certificates
profile RFC 3039. In practical terms this means that the applications
using LDAP APIs will be able to pass user friendly strings for some of
the attributes but not for others e.g. CN=David Chadwick +
SerialNumber=12345 would need to be passed to the LDAP API as CN=David
Chadwick + 2.5.4.5=12345.

The PKIX draft <draft-ietf-pkix-dnstrings-00.txt> defines strings for
PKIX used attribute types so that a consistent call can be made to the
LDAP API. This might be useful for example where users type in DNs at
the user interface level, or they are read in from configuration files.
Without this change the application will need
to have a table of which attributes can be sent to LDAP as strings and
which will need to be sent as OIDs. (You clearly cannot expect user's to
type in OIDs). Some in the LDAP group are opposed to the PKIX group
publishing
this ID, as they dont want to possibly open the floodgates to lots of
other strings being registered.

So the question that the PKIX group needs to answer is "Do we care or
not". Silence on the list implies that PKI application providers dont
really care, as they are happy to pass either a mixture of OIDs and user
friendly strings, or all OIDs (the latter is not ruled out), to their
LDAP APIs.
If you think it is important to be able to pass all user friendly
strings to
the LDAP API, then please respond now.

thankyou

David

--
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@xxxxxxxxxxxxx
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************