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

Sean Leonard <> Fri, 26 September 2014 15:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C62F81A897B for <>; Fri, 26 Sep 2014 08:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ql4BZtBnNx5l for <>; Fri, 26 Sep 2014 08:22:07 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 80AA41A8951 for <>; Fri, 26 Sep 2014 08:22:07 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6670450AB9 for <>; Fri, 26 Sep 2014 11:22:06 -0400 (EDT)
Message-ID: <>
Date: Fri, 26 Sep 2014 08:21:47 -0700
From: Sean Leonard <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [ldapext] Fwd: New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Sep 2014 15:22:14 -0000

Since I'm new to this list, I searched and noticed that this 
draft has not gotten a lot of discussion. If my search was inaccurate, I 
apologize in advance for bringing up previously discussed issues.

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.

As one example, security-related protocols such as PKIX certificate use 
distinguished names as an integral part of the protocol. 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. I can certainly envision applications 
that display LDAP or security names, where adding this intlMailAddr 
would serve to confuse or attack users. 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.

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.

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

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. It puts considerable additional burden on 
implementations to take a DirectoryString in one of the less-used 
formats, such as TeletexString, and parse it into Unicode. (The 
character sets that can be encoded in TeletexString may not be bijective 
with respect to Unicode, introducing exploitable ambiguities.)* 
Therefore, I think that the value should be UTF8String alone.


*In 2011 I wrote "ASN.1 Teletexer", an ISO C implementation that 
converts TeletexString to Unicode. 
<> So I'm pretty familiar with 
this minefield.

On 9/26/2014 5:15 AM, Michael Ströder wrote:
> HI!
> I've sent this draft to the RFC editor for review.
> Anyone here willing to act as reviewer?
> Still sorting out some idnits issues for next version but those are only minor
> details.
> Ciao, Michael.
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt
> Date: Fri, 26 Sep 2014 04:59:34 -0700
> From:
> To: Michael Stroeder <>om>, Michael Stroeder
> <>
> A new version of I-D, draft-stroeder-mailboxrelatedobject-06.txt
> has been successfully submitted by Michael Stroeder and posted to the
> IETF repository.
> Name:		draft-stroeder-mailboxrelatedobject
> Revision:	06
> Title:		Lightweight Directory Access Protocol (LDAP): Auxiliary Object Class
> 'mailboxRelatedObject'
> Document date:	2014-09-26
> Group:		Individual Submission
> Pages:		5
> URL:
> Status:
> Htmlized:
> Diff:
> Abstract:
>     This document defines the auxiliary object class
>     'mailboxRelatedObject' that can be used to associate an arbitrary
>     object with an Internet mail address.  Furthermore an attribute
>     'intlMailAdr' is defined for storing fully internationalized Internet
>     mail addresses.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> The IETF Secretariat
> _______________________________________________
> Ldapext mailing list