Re: [ldapext] Fwd: New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt

[Michael Ströder <[e-mail]>]

Sean Leonard wrote:
> Storing internationalized e-mail addresses in LDAP-related protocols raises a
> lot of novel issues that I do not think are adequately addressed by this
> draft. Accordingly, this work ought to be brought up to other IETF areas,
> namely the apps and security areas.

Please note that this simple draft focuses on LDAPv3. Nothing else.

Other protocols like PKIX, S/MIME or DAP do have to define their own
attributes and matching rules and maybe a more complex mapping if they want to
refer to this LDAP schema definition. Especially they have to define matching
rules if any security relevant decision is made within those protocols.

> There are already
> issues with the relationship between the "emailAddress" attribute and
> authentication of the e-mail address (namely the rfc822Name component of a
> GeneralName); the fact that mail and emailAddress are two separate attributes
> (with more-or-less the same meaning) only makes matters worse.

Personally I consider PKCS#9 to be seriously flawed. E.g. defining as
GeneralizedTime is bad design. Yuck!

> I can certainly
> envision applications that display LDAP or security names, where adding this
> intlMailAddr would serve to confuse or attack users.

Just like internationalized domain names can be used to trick users into traps
like with this example: Міϲrοѕоft Іnс

> This makes me wonder if
> it is better to extend the syntax of emailAddress so that it is a CHOICE of
> IA5String or UTF8String. There are lots of reasons against that, but there are
> lots of reasons for it too.

Could you please elaborate how to express that in a LDAPv3 attribute type
description?

> Furthermore, where there's a will, there's a way--since the security area has
> not yet standardized on how to integrate EAI into PKIX or other places, I can
> easily see people starting to stuff intlMailAddr into those protocols as a
> non-standard way to get what the market needs.

Glancing over draft-ietf-pkix-eai-addresses-00 (expired in 2011) I don't see
much conflict especially since it uses the otherName and does not define an
OID yet. IMHO both drafts can be be easily aligned. I'd even be willing to
name the attribute 'eaiMailbox'.

> This draft does not refer to the EAI work normatively, but the EAI work is
> normative with respect to the format of e-mail addresses.

BTW: IIRC A. Melnikov already reviewed draft-stroeder-mailboxrelatedobject.
Maybe he should speak up here if he sees any major problems.

> EAI also probably
> has some say in how to compare e-mail addresses for equality (which has a
> cascading effect on application protocols such as LDAP, in addition to
> security protocols).

It does not necessarily has an effect. But one could define similar matching
rules for LDAPv3 too (currently out-of-scope). Feel free to propose text or
write a separate draft.

> Finally, I assume that the choice of DirectoryString is for convenience, since
> "most" LDAP implementations will pick DirectoryString by default. But EAI
> exclusively defines the encoding of an internationalized e-mail address as
> UTF-8, which means that the repetoire of EAI is virtually all Unicode
> characters.

Again I don't see any conflict. Could you please elaborate on what you regard
being an issue?

Ciao, Michael.