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

[Sean Leonard <[e-mail]>]

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 ([e-mail] 
> <mailto:[e-mail]>) 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: [e-mail]
>> > To: Michael Stroeder <[e-mail]>, Michael Stroeder
>> > <[e-mail]>
>> >
>> >
>> > 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ldapext
>>
>> _______________________________________________
>> Ldapext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ldapext