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

From: Michael Ströder <[email-masked]>
Date: Fri, 26 Sep 2014 14:15:39 +0200

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-masked]
To: Michael Stroeder <[email-masked]>, Michael Stroeder
<[email-masked]>

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

---

From: Sean Leonard <[email-masked]>
Date: Fri, 26 Sep 2014 07:10:10 -0700

Couple of nits:

Nit:
Why is the attribute named "intlMailAdr", instead of "intlMailAddr"?

Nit: 1. @2   (means Section 1. at page 2)

"Therefore this documents defines" ->
"Therefore this document defines"

Nit: 1. @2
"Often there is a need to associate a, most times non-personal, Internet 
mail address with an arbitrary object" ->
"Often the need arises to associate an Internet mail address (which most 
times is not personal) with an arbitrary object"

Nit: 1. @2
"so applications can lookup where" ->
"so application can look up where"

Nit: 1. @2
"It allows to add an Internet mail address" ->
"It allows adding an Internet mail address"

There are also a couple of bigger things...which I will post in a 
separate e-mail.

Sean

On 9/26/2014 5:15 AM, Michael Ströder wrote:
> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext

---

From: Michael Ströder <[email-masked]>
Date: Fri, 26 Sep 2014 17:06:03 +0200

Sean,

thanks for your review.

Fixes of nits herein will be in -07.

> Why is the attribute named "intlMailAdr", instead of "intlMailAddr"?

Because of me being a native German speaker.
English "address" is "Adresse" in German. ;-)

Fixed.

> "Therefore this document defines"

Fixed.

> Nit: 1. @2
> "Often there is a need to associate a, most times non-personal, Internet mail
> address with an arbitrary object" ->
> "Often the need arises to associate an Internet mail address (which most times
> is not personal) with an arbitrary object"

Fixed.

> "so application can look up where"

Fixed.

> "It allows adding an Internet mail address"

Fixed.

> There are also a couple of bigger things...which I will post in a separate
> e-mail.

Looking forward to your comments.

Ciao, Michael.

---

From: Sean Leonard <[email-masked]>
Date: Fri, 26 Sep 2014 08:21:47 -0700

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.

---

From: Ludovic Poitou <[email-masked]>
Date: Fri, 26 Sep 2014 17:31:57 +0200

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-masked]) wrote:

Sean

---

From: Ludovic Poitou <[email-masked]>
Date: Fri, 26 Sep 2014 17:35:42 +0200

Sorry for the messed signature, and bold text in my response… which is an issue with my email composer.

Regards,

Ludovic.

On 26 Sep 2014 at 17:31:57, Ludovic Poitou ([email-masked]) wrote:

Regards,

Ludovic.

---

From: Sean Leonard <[email-masked]>
Date: Fri, 26 Sep 2014 08:38:55 -0700

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:
>         3.3.6 <http://tools.ietf.org/html/rfc4517#section-3.3.6>.
>         Directory String
>
>
>
>     arbitrary characters from the Universal Character Set (UCS) [UCS  <http://tools.ietf.org/html/rfc4517#ref-UCS>].  A
>     encoding of a value of this syntax is the UTF-8 encoding [RFC3629  <http://tools.ietf.org/html/rfc3629>] of
>     The <UTF8> rule is defined in [RFC4512  <http://tools.ietf.org/html/rfc4512>].
>
> On 26 Sep 2014 at 17:22:18, Sean Leonard ([email-masked] 
> <mailto:[email-masked]>) wrote:
>
>> > Subject: New Version Notification for 
>> draft-stroeder-mailboxrelatedobject-06.txt
>> > Htmlized: 
>> http://tools.ietf.org/html/draft-stroeder-mailboxrelatedobject-06
>> > Diff:
>> >

---

From: Michael Ströder <[email-masked]>
Date: Fri, 26 Sep 2014 18:04:07 +0200

Sean Leonard wrote:
> 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.

Please note that this simple draft focuses on LDAPv3. Nothing else.

Other protocols like PKIX, S/MIME or DAP do have to define their own
attributes and matching rules and maybe a more complex mapping if they want to
refer to this LDAP schema definition. Especially they have to define matching
rules if any security relevant decision is made within those protocols.

> 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.

Personally I consider PKCS#9 to be seriously flawed. E.g. defining as
GeneralizedTime is bad design. Yuck!

> I can certainly
> envision applications that display LDAP or security names, where adding this
> intlMailAddr would serve to confuse or attack users.

Just like internationalized domain names can be used to trick users into traps
like with this example: Міϲrοѕоft Іnс

> 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.

Could you please elaborate how to express that in a LDAPv3 attribute type
description?

> 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.

Glancing over draft-ietf-pkix-eai-addresses-00 (expired in 2011) I don't see
much conflict especially since it uses the otherName and does not define an
OID yet. IMHO both drafts can be be easily aligned. I'd even be willing to
name the attribute 'eaiMailbox'.

> 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.

BTW: IIRC A. Melnikov already reviewed draft-stroeder-mailboxrelatedobject.
Maybe he should speak up here if he sees any major problems.

> 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).

It does not necessarily has an effect. But one could define similar matching
rules for LDAPv3 too (currently out-of-scope). Feel free to propose text or
write a separate draft.

> 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.

Again I don't see any conflict. Could you please elaborate on what you regard
being an issue?

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 26 Sep 2014 18:06:38 +0200

> See the rest of 3.3.6:

The section you've cited is about how LDAP-DAP gateways have to deal with
DirectoryString.

=> I don't consider this to be relevant for this LDAP related draft.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 26 Sep 2014 18:08:08 +0200

> GeneralizedTime is bad design. Yuck!

Should have been: "defining dateOfBirth as GeneralizedTime"
                	    ^^^^^^^^^^^

Ciao, Michael.

---

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 26 Sep 2014 11:56:53 -0700

Just for the record, the Independent Submission Editor contacted me regarding this draft.  As I'm not terribly active in the LDAP community these days, I suggested he seek review elsewhere such as on this list.

I also noted a couple of things which the IESG might want to consider when the I-D comes before them as an independent submission.
a) Defining an auxiliary object class simply allows 'mail' to be present on entries belong to that class would likely be non-contentious and not terribly likely to create inter-op issues with use of 'mail' as described in standard track documents.

b) How to deal with Internationalized email address in LDAP however is likely far more contentious and far more likely to create inter-op issues with use of 'mail' as described in standard track documents.

That is, I basically hinted that the progressing an independent submission for a simple aux class that allowed for 'mail', and only 'mail', to be present in entries of the class is likely not something that would step on IETF toes... but that doing anything with Internationalized Email Addresses likely would.   However, as I don't have an iron in this fire, I suggested ISE ask an Apps AD early as to what parts of this I-D do step on the IETF toes (one could argue that as there's little LDAP activity in the IETF that none of this does).

Michael, I note that while independent submission is restricted to Informational and Experimental, one doesn't need a WG to pursue standard track.  The IETF processes does allow for individual submissions to be considered for standards track.  (note: independent submission != individual submission). 

Regarding Directory String, I note that while can transfer a BER encoded DirectoryString value, and that would indicate a CHOICE, aside from more commonly transferred using the LDAP syntax (1*UTF8), transfer of BER doesn't imply preservation of the CHOICE.   The general LDAP value preservation rules allows, for instance, a server to return Universal String (in ;binary transfer if they support it for the attribute) even though the value added was a Printable String (when added using ;binary).

Lastly, regarding standardizing Password Policy...  at one time the IETF had before multiple I-Ds here and no clear consensus on which to pursue.  Now there's multiple flavors of password policy in the wild... as well as an X.500 specific password policy spec.    Maybe with different players consensus can be achieved... but I suspect that if the IETF were to pursue this again, especially by forming a WG, that it would likely flounder again due to lack of consensus on various issues.   One might get further by writing an informational RFC which simply documented what some set of implementations do.

-- Kurt