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

Hi Sean,

DirectoryString is defined in RFC4517 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) [UCS].  A
   zero-length character string is not permitted.  The LDAP-specific
   encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of
   the character string.  Such encodings conform to the following ABNF:

      DirectoryString = 1*UTF8

   The <UTF8> rule is defined in [RFC4512].

I think it does correspond to the need of internationalised e-mail addressee.

Regards,

Ludovic.
-- 
Ludovic Poitou
http://ludopoitou.wordpress.com

On 26 Sep 2014 at 17:22:18, Sean Leonard ([email protected]) wrote:

Since I'm new to this list, I searched ietf.org 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.  

Sean  

*In 2011 I wrote "ASN.1 Teletexer", an ISO C implementation that  
converts TeletexString to Unicode.  
<https://www.seantek.com/asn1teletexer/> 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: [email protected]  
> To: Michael Stroeder <[email protected]>, Michael Stroeder  
> <[email protected]>  
>  
>  
> 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:  
> http://www.ietf.org/internet-drafts/draft-stroeder-mailboxrelatedobject-06.txt  
> Status:  
> https://datatracker.ietf.org/doc/draft-stroeder-mailboxrelatedobject/  
> Htmlized: http://tools.ietf.org/html/draft-stroeder-mailboxrelatedobject-06  
> Diff:  
> http://www.ietf.org/rfcdiff?url2=draft-stroeder-mailboxrelatedobject-06  
>  
> 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 tools.ietf.org.  
>  
> The IETF Secretariat  
>  
>  
>  
>  
>  
>  
> _______________________________________________  
> Ldapext mailing list  
> [email protected]  
> https://www.ietf.org/mailman/listinfo/ldapext  

_______________________________________________  
Ldapext mailing list  
[email protected]  
https://www.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext