Return-Path: <ludovic.poitou@gmail.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 0724E1A6FFC
 for <ldapext@ietfa.amsl.com>; Fri, 26 Sep 2014 08:32:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001,
 SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 6fqchj-7T2DP for <ldapext@ietfa.amsl.com>;
 Fri, 26 Sep 2014 08:32:00 -0700 (PDT)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com
 [IPv6:2a00:1450:400c:c03::232])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id F345D1A6F56
 for <ldapext@ietf.org>; Fri, 26 Sep 2014 08:31:59 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id t60so9663083wes.23
 for <ldapext@ietf.org>; Fri, 26 Sep 2014 08:31:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 
 h=date:from:to:message-id:in-reply-to:references:subject:mime-version
 :content-type; bh=OSUqtSxJaniSem8VIR86DbWshj+Bq1lShPI+CXJR+mU=;
 b=NHL5z50DgCgojkGhQcxEQJCLTFQB3dHoQhDQYLWkSmuoO1goxklCkse6bLbLCUQs0T
 tkgfXaqrrhFnmlurvGegreH053oInwzFNwtzJvieJqzdPJEMJC0ma3zd1F/Kceni32BW
 D8tKCpxXWkhbxogDRpxu2Q8KdvvDN8RamzpXU0FeJcvIDtzfe7WRIpdLVlciVaA7tSKj
 FMbCOm8OpHQ+F4VCJQcMb75rh4pWhM2FSQ3for3nuhflMMVsKP/Ime3keKxm5mZr4g2+
 5YBr/RuLS+d15HxqdbXk69KlVuhmn8qpza7KxKR+TCsGatEyKWw02k01BHRbG4c5AoYc
 WBhg==
X-Received: by 10.194.80.71 with SMTP id p7mr24678566wjx.35.1411745518470;
 Fri, 26 Sep 2014 08:31:58 -0700 (PDT)
Received: from lpm.local ([46.218.40.139])
 by mx.google.com with ESMTPSA id t9sm6521214wjf.41.2014.09.26.08.31.57
 for <multiple recipients>
 (version=SSLv3 cipher=RC4-SHA bits=128/128);
 Fri, 26 Sep 2014 08:31:57 -0700 (PDT)
Date: Fri, 26 Sep 2014 17:31:57 +0200
From: Ludovic Poitou <ludovic.poitou@gmail.com>
To: ldapext@ietf.org, Sean Leonard <dev+ietf@seantek.com>
Message-ID: <etPan.542586ed.2443a858.48ca@lpm.local>
In-Reply-To: <5425848B.3040504@seantek.com>
References: <20140926115934.25447.2865.idtracker@ietfa.amsl.com>
 <542558EB.4000709@stroeder.com> <5425848B.3040504@seantek.com>
X-Mailer: Airmail Beta (258)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="542586ed_2d1d5ae9_48ca"
Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/D8d2KMnw-VO-vAk3QI-GzD6biiQ
Subject: Re: [ldapext] Fwd: New Version Notification for
 draft-stroeder-mailboxrelatedobject-06.txt
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>,
 <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>,
 <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Sep 2014 15:32:03 -0000

--542586ed_2d1d5ae9_48ca
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Sean,

DirectoryString is defined in R=46C4517 as :

3.3.6.  Directory String

   A value of the Directory String syntax is a string of one or more
   arbitrary characters from the Universal Character Set (UCS) =5BUCS=5D.=
  A
   zero-length character string is not permitted.  The LDAP-specific
   encoding of a value of this syntax is the UT=46-8 encoding =5BR=46C362=
9=5D of
   the character string.  Such encodings conform to the following ABN=46:=


      DirectoryString =3D 1*UT=468

   The <UT=468> rule is defined in =5BR=46C4512=5D.

I think it does correspond to the need of internationalised e-mail addres=
see.

Regards,

Ludovic.
--=C2=A0
Ludovic Poitou
http://ludopoitou.wordpress.com

On 26 Sep 2014 at 17:22:18, Sean Leonard (dev+ietf=40seantek.com) wrote:

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

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

As one example, security-related protocols such as PKIX certificate use =20
distinguished names as an integral part of the protocol. There are =20
already issues with the relationship between the =22emailAddress=22 =20
attribute and authentication of the e-mail address (namely the =20
rfc822Name component of a GeneralName); the fact that mail and =20
emailAddress are two separate attributes (with more-or-less the same =20
meaning) only makes matters worse. I can certainly envision applications =
=20
that display LDAP or security names, where adding this intlMailAddr =20
would serve to confuse or attack users. This makes me wonder if it is =20
better to extend the syntax of emailAddress so that it is a CHOICE of =20
IA5String or UT=468String. There are lots of reasons against that, but =20
there are lots of reasons for it too. =20

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

This draft does not refer to the EAI work normatively, but the EAI work =20
is normative with respect to the format of e-mail addresses. EAI also =20
probably has some say in how to compare e-mail addresses for equality =20
(which has a cascading effect on application protocols such as LDAP, in =20
addition to security protocols). =20

=46inally, I assume that the choice of DirectoryString is for convenience=
, =20
since =22most=22 LDAP implementations will pick DirectoryString by defaul=
t. =20
But EAI exclusively defines the encoding of an internationalized e-mail =20
address as UT=46-8, which means that the repetoire of EAI is virtually al=
l =20
Unicode characters. It puts considerable additional burden on =20
implementations to take a DirectoryString in one of the less-used =20
formats, such as TeletexString, and parse it into Unicode. (The =20
character sets that can be encoded in TeletexString may not be bijective =
=20
with respect to Unicode, introducing exploitable ambiguities.)* =20
Therefore, I think that the value should be UT=468String alone. =20

Sean =20

*In 2011 I wrote =22ASN.1 Teletexer=22, an ISO C implementation that =20
converts TeletexString to Unicode. =20
<https://www.seantek.com/asn1teletexer/> So I'm pretty familiar with =20
this minefield. =20

On 9/26/2014 5:15 AM, Michael Str=C3=B6der wrote: =20
> HI=21 =20
> =20
> I've sent this draft to the R=46C editor for review. =20
> Anyone here willing to act as reviewer=3F =20
> =20
> Still sorting out some idnits issues for next version but those are onl=
y minor =20
> details. =20
> =20
> Ciao, Michael. =20
> =20
> -------- =46orwarded Message -------- =20
> Subject: New Version Notification for draft-stroeder-mailboxrelatedobje=
ct-06.txt =20
> Date: =46ri, 26 Sep 2014 04:59:34 -0700 =20
> =46rom: internet-drafts=40ietf.org =20
> To: Michael Stroeder <michael=40stroeder.com>, Michael Stroeder =20
> <michael=40stroeder.com> =20
> =20
> =20
> A new version of I-D, draft-stroeder-mailboxrelatedobject-06.txt =20
> has been successfully submitted by Michael Stroeder and posted to the =20
> IET=46 repository. =20
> =20
> Name:	 draft-stroeder-mailboxrelatedobject =20
> Revision:	06 =20
> Title:	 Lightweight Directory Access Protocol (LDAP): Auxiliary Object =
Class =20
> 'mailboxRelatedObject' =20
> Document date:	2014-09-26 =20
> Group:	 Individual Submission =20
> Pages:	 5 =20
> URL: =20
> http://www.ietf.org/internet-drafts/draft-stroeder-mailboxrelatedobject=
-06.txt =20
> Status: =20
> https://datatracker.ietf.org/doc/draft-stroeder-mailboxrelatedobject/ =20
> Htmlized: http://tools.ietf.org/html/draft-stroeder-mailboxrelatedobjec=
t-06 =20
> Diff: =20
> http://www.ietf.org/rfcdiff=3Furl2=3Ddraft-stroeder-mailboxrelatedobjec=
t-06 =20
> =20
> Abstract: =20
> This document defines the auxiliary object class =20
> 'mailboxRelatedObject' that can be used to associate an arbitrary =20
> object with an Internet mail address. =46urthermore an attribute =20
> 'intlMailAdr' is defined for storing fully internationalized Internet =20
> mail addresses. =20
> =20
> =20
> =20
> =20
> Please note that it may take a couple of minutes from the time of submi=
ssion =20
> until the htmlized version and diff are available at tools.ietf.org. =20
> =20
> The IET=46 Secretariat =20
> =20
> =20
> =20
> =20
> =20
> =20
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20
> Ldapext mailing list =20
> Ldapext=40ietf.org =20
> https://www.ietf.org/mailman/listinfo/ldapext =20

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20
Ldapext mailing list =20
Ldapext=40ietf.org =20
https://www.ietf.org/mailman/listinfo/ldapext =20

--542586ed_2d1d5ae9_48ca
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<html><head><style>body=7Bfont-family:Helvetica,Arial;font-size:13px=7D</=
style></head><body style=3D=22word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;=22><div id=3D=22bloop=5Fcust=
omfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; color: r=
gba(0,0,0,1.0); margin: 0px; line-height: auto;=22>Hi Sean,</div><div id=3D=
=22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size=
:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22><br></d=
iv><div id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Ar=
ial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: aut=
o;=22>DirectoryString is defined in R=46C4517 as :</div><div id=3D=22bloo=
p=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;font-size:13px; =
color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22><br></div><div=
 id=3D=22bloop=5Fcustomfont=22 style=3D=22font-family:Helvetica,Arial;fon=
t-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;=22><=
pre class=3D=22newpage=22 style=3D=22font-size: 1em; margin-top: 0px; mar=
gin-bottom: 0px; page-break-before: always;=22><span class=3D=22h4=22 sty=
le=3D=22line-height: 0pt; display: inline; font-size: 1em; font-weight: b=
old;=22><h4 style=3D=22line-height: 0pt; display: inline; font-size: 1em;=
=22><a class=3D=22selflink=22 name=3D=22section-3.3.6=22 href=3D=22http:/=
/tools.ietf.org/html/rfc4517=23section-3.3.6=22 style=3D=22color: black; =
text-decoration: none;=22>3.3.6</a>.  Directory String</h4></span>

   A value of the Directory String syntax is a string of one or more
   arbitrary characters from the Universal Character Set (UCS) =5B<a href=
=3D=22http://tools.ietf.org/html/rfc4517=23ref-UCS=22>UCS</a>=5D.  A
   zero-length character string is not permitted.  The LDAP-specific
   encoding of a value of this syntax is the UT=46-8 encoding =5B<a href=3D=
=22http://tools.ietf.org/html/rfc3629=22 title=3D=22&quot;UT=46-8, a tran=
sformation format of ISO 10646&quot;=22>R=46C3629</a>=5D of
   the character string.  Such encodings conform to the following ABN=46:=


      DirectoryString =3D 1*UT=468

   The &lt;UT=468&gt; rule is defined in =5B<a href=3D=22http://tools.iet=
f.org/html/rfc4512=22 title=3D=22&quot;Lightweight Directory Access Proto=
col (LDAP): Directory Information Models&quot;=22>R=46C4512</a>=5D.
</pre></div> <div><br></div>I think it does correspond to the need of int=
ernationalised e-mail addressee.<div><br></div><div>Regards,</div><div><b=
r></div><div>Ludovic.<br> <div id=3D=22bloop=5Fsign=5F1411745432748443136=
=22 class=3D=22bloop=5Fsign=22><div style=3D=22font-family:helvetica,aria=
l;font-size:13px=22>--&nbsp;<br>Ludovic Poitou</div><div style=3D=22font-=
family:helvetica,arial;font-size:13px=22>http://ludopoitou.wordpress.com<=
/div></div> <br><p style=3D=22color:=23000;=22>On 26 Sep 2014 at 17:22:18=
, Sean Leonard (<a href=3D=22mailto:dev+ietf=40seantek.com=22>dev+ietf=40=
seantek.com</a>) wrote:</p> <blockquote type=3D=22cite=22 class=3D=22clea=
n=5Fbq=22><span><div><div></div><div>Since I'm new to this list, I search=
ed ietf.org and noticed that this =20
<br>draft has not gotten a lot of discussion. If my search was inaccurate=
, I =20
<br>apologize in advance for bringing up previously discussed issues.
<br>
<br>Storing internationalized e-mail addresses in LDAP-related protocols =
=20
<br>raises a lot of novel issues that I do not think are adequately =20
<br>addressed by this draft. Accordingly, this work ought to be brought u=
p =20
<br>to other IET=46 areas, namely the apps and security areas.
<br>
<br>As one example, security-related protocols such as PKIX certificate u=
se =20
<br>distinguished names as an integral part of the protocol. There are =20
<br>already issues with the relationship between the =22emailAddress=22 =20
<br>attribute and authentication of the e-mail address (namely the =20
<br>rfc822Name component of a GeneralName); the fact that mail and =20
<br>emailAddress are two separate attributes (with more-or-less the same =
=20
<br>meaning) only makes matters worse. I can certainly envision applicati=
ons =20
<br>that display LDAP or security names, where adding this intlMailAddr =20
<br>would serve to confuse or attack users. This makes me wonder if it is=
 =20
<br>better to extend the syntax of emailAddress so that it is a CHOICE of=
 =20
<br>IA5String or UT=468String. There are lots of reasons against that, bu=
t =20
<br>there are lots of reasons for it too.
<br>
<br>=46urthermore, where there's a will, there's a way--since the securit=
y =20
<br>area has not yet standardized on how to integrate EAI into PKIX or ot=
her =20
<br>places, I can easily see people starting to stuff intlMailAddr into =20
<br>those protocols as a non-standard way to get what the market needs.
<br>
<br>This draft does not refer to the EAI work normatively, but the EAI wo=
rk =20
<br>is normative with respect to the format of e-mail addresses. EAI also=
 =20
<br>probably has some say in how to compare e-mail addresses for equality=
 =20
<br>(which has a cascading effect on application protocols such as LDAP, =
in =20
<br>addition to security protocols).
<br>
<br>=46inally, I assume that the choice of DirectoryString is for conveni=
ence, =20
<br>since =22most=22 LDAP implementations will pick DirectoryString by de=
fault. =20
<br>But EAI exclusively defines the encoding of an internationalized e-ma=
il =20
<br>address as UT=46-8, which means that the repetoire of EAI is virtuall=
y all =20
<br>Unicode characters. It puts considerable additional burden on =20
<br>implementations to take a DirectoryString in one of the less-used =20
<br>formats, such as TeletexString, and parse it into Unicode. (The =20
<br>character sets that can be encoded in TeletexString may not be biject=
ive =20
<br>with respect to Unicode, introducing exploitable ambiguities.)* =20
<br>Therefore, I think that the value should be UT=468String alone.
<br>
<br>Sean
<br>
<br>*In 2011 I wrote =22ASN.1 Teletexer=22, an ISO C implementation that =
=20
<br>converts TeletexString to Unicode. =20
<br>&lt;https://www.seantek.com/asn1teletexer/&gt; So I'm pretty familiar=
 with =20
<br>this minefield.
<br>
<br>On 9/26/2014 5:15 AM, Michael Str=C3=B6der wrote:
<br>&gt; HI=21
<br>&gt;
<br>&gt; I've sent this draft to the R=46C editor for review.
<br>&gt; Anyone here willing to act as reviewer=3F
<br>&gt;
<br>&gt; Still sorting out some idnits issues for next version but those =
are only minor
<br>&gt; details.
<br>&gt;
<br>&gt; Ciao, Michael.
<br>&gt;
<br>&gt; -------- =46orwarded Message --------
<br>&gt; Subject: New Version Notification for draft-stroeder-mailboxrela=
tedobject-06.txt
<br>&gt; Date: =46ri, 26 Sep 2014 04:59:34 -0700
<br>&gt; =46rom: internet-drafts=40ietf.org
<br>&gt; To: Michael Stroeder &lt;michael=40stroeder.com&gt;, Michael Str=
oeder
<br>&gt; &lt;michael=40stroeder.com&gt;
<br>&gt;
<br>&gt;
<br>&gt; A new version of I-D, draft-stroeder-mailboxrelatedobject-06.txt=

<br>&gt; has been successfully submitted by Michael Stroeder and posted t=
o the
<br>&gt; IET=46 repository.
<br>&gt;
<br>&gt; Name:		draft-stroeder-mailboxrelatedobject
<br>&gt; Revision:	06
<br>&gt; Title:		Lightweight Directory Access Protocol (LDAP): Auxiliary =
Object Class
<br>&gt; 'mailboxRelatedObject'
<br>&gt; Document date:	2014-09-26
<br>&gt; Group:		Individual Submission
<br>&gt; Pages:		5
<br>&gt; URL:
<br>&gt; http://www.ietf.org/internet-drafts/draft-stroeder-mailboxrelate=
dobject-06.txt
<br>&gt; Status:
<br>&gt; https://datatracker.ietf.org/doc/draft-stroeder-mailboxrelatedob=
ject/
<br>&gt; Htmlized:       http://tools.ietf.org/html/draft-stroeder-mailbo=
xrelatedobject-06
<br>&gt; Diff:
<br>&gt; http://www.ietf.org/rfcdiff=3Furl2=3Ddraft-stroeder-mailboxrelat=
edobject-06
<br>&gt;
<br>&gt; Abstract:
<br>&gt;     This document defines the auxiliary object class
<br>&gt;     'mailboxRelatedObject' that can be used to associate an arbi=
trary
<br>&gt;     object with an Internet mail address.  =46urthermore an attr=
ibute
<br>&gt;     'intlMailAdr' is defined for storing fully internationalized=
 Internet
<br>&gt;     mail addresses.
<br>&gt;
<br>&gt;
<br>&gt;
<br>&gt;
<br>&gt; Please note that it may take a couple of minutes from the time o=
f submission
<br>&gt; until the htmlized version and diff are available at tools.ietf.=
org.
<br>&gt;
<br>&gt; The IET=46 Secretariat
<br>&gt;
<br>&gt;
<br>&gt;
<br>&gt;
<br>&gt;
<br>&gt;
<br>&gt; =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=

<br>&gt; Ldapext mailing list
<br>&gt; Ldapext=40ietf.org
<br>&gt; https://www.ietf.org/mailman/listinfo/ldapext
<br>
<br>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
<br>Ldapext mailing list
<br>Ldapext=40ietf.org
<br>https://www.ietf.org/mailman/listinfo/ldapext
<br></div></div></span></blockquote></div></body></html>
--542586ed_2d1d5ae9_48ca--