Re: Fwd: New Version Notification for draft-stroeder-mailboxrelatedobject-06.txt
Sean Leonard <[email protected]> Fri, 26 Sep 2014 08:38:55 -0700
| Newsgroups | gmane.ietf.ldapext |
|---|---|
| Message-ID | <[email protected]> |
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 ([email protected]
> <mailto:[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