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

Sean Leonard <dev+ietf@seantek.com> Fri, 26 September 2014 15:39 UTC

Return-Path: <dev+ietf@seantek.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 AE2871A89B3 for <ldapext@ietfa.amsl.com>; Fri, 26 Sep 2014 08:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 1qIhkgJf_Htp for <ldapext@ietfa.amsl.com>; Fri, 26 Sep 2014 08:39:16 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712961A89AF for <ldapext@ietf.org>; Fri, 26 Sep 2014 08:39:16 -0700 (PDT)
Received: from [192.168.123.7] (unknown [23.240.242.6]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0834E50A73; Fri, 26 Sep 2014 11:39:14 -0400 (EDT)
Message-ID: <5425888F.1050906@seantek.com>
Date: Fri, 26 Sep 2014 08:38:55 -0700
From: Sean Leonard <dev+ietf@seantek.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Ludovic Poitou <ludovic.poitou@gmail.com>, ldapext@ietf.org
References: <20140926115934.25447.2865.idtracker@ietfa.amsl.com> <542558EB.4000709@stroeder.com> <5425848B.3040504@seantek.com> <etPan.542586ed.2443a858.48ca@lpm.local>
In-Reply-To: <etPan.542586ed.2443a858.48ca@lpm.local>
Content-Type: multipart/alternative; boundary="------------060707030702080507020803"
Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/w3rWvhSdb6fd3Sy1V32HarvScik
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:39:19 -0000

Hi Ludovic,

See the rest of 3.3.6:

    The LDAP definition for the Directory String syntax is:

       ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )

    This syntax corresponds to the DirectoryString parameterized ASN.1
    type from [X.520  <http://tools.ietf.org/html/rfc4517#ref-X.520>].

    *The DirectoryString ASN.1 type allows a choice between the
    TeletexString, PrintableString, or UniversalString ASN.1 types from
    [**ASN.1  <http://tools.ietf.org/html/rfc4517#ref-ASN.1>**].  However, note that the chosen alternative is not indicated
    in the LDAP-specific encoding of a Directory String value.*

    Implementations that convert Directory String values from the LDAP-
    specific encoding to the BER encoding used by X.500 must choose an
    alternative that permits the particular characters in the string and
    must convert the characters from the UTF-8 encoding into the
    character encoding of the chosen alternative.*When converting
    Directory String values from the BER encoding to the LDAP-specific
    encoding, the characters must be converted from the character
    encoding of the chosen alternative into the UTF-8 encoding.*   These
    conversions SHOULD be done in a manner consistent with the Transcode
    step of the string preparation algorithms [RFC4518  <http://tools.ietf.org/html/rfc4518>] for LDAP.


(bold is my emphasis)

Best regards,

Sean

On 9/26/2014 8:31 AM, Ludovic Poitou wrote:
> Hi Sean,
>
> DirectoryString is defined in RFC4517 as :
>
>
>         3.3.6 <http://tools.ietf.org/html/rfc4517#section-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  <http://tools.ietf.org/html/rfc4517#ref-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  <http://tools.ietf.org/html/rfc3629>] of
>     the character string.  Such encodings conform to the following ABNF:
>
>        DirectoryString = 1*UTF8
>
>     The <UTF8> rule is defined in [RFC4512  <http://tools.ietf.org/html/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 (dev+ietf@seantek.com 
> <mailto:dev+ietf@seantek.com>) 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: internet-drafts@ietf.org
>> > To: Michael Stroeder <michael@stroeder.com>om>, Michael Stroeder
>> > <michael@stroeder.com>
>> >
>> >
>> > 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
>> > Ldapext@ietf.org
>> > https://www.ietf.org/mailman/listinfo/ldapext
>>
>> _______________________________________________
>> Ldapext mailing list
>> Ldapext@ietf.org
>> https://www.ietf.org/mailman/listinfo/ldapext