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

Michael Ströder <michael@stroeder.com> Fri, 26 September 2014 16:04 UTC

Return-Path: <michael@stroeder.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 8A2601A894F for <ldapext@ietfa.amsl.com>; Fri, 26 Sep 2014 09:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.087
X-Spam-Level:
X-Spam-Status: No, score=-3.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_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 axVFH1WjRd54 for <ldapext@ietfa.amsl.com>; Fri, 26 Sep 2014 09:04:57 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3321A8A0E for <ldapext@ietf.org>; Fri, 26 Sep 2014 09:04:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id EA54460279; Fri, 26 Sep 2014 18:04:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7b0ORt9f3ZE; Fri, 26 Sep 2014 18:04:08 +0200 (CEST)
Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client CN "michael@stroeder.com", Issuer "StartCom Class 1 Primary Intermediate Client CA" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 1C3A660061; Fri, 26 Sep 2014 16:04:08 +0000 (UTC)
Message-ID: <54258E77.4010004@stroeder.com>
Date: Fri, 26 Sep 2014 18:04:07 +0200
From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26.1
MIME-Version: 1.0
To: Sean Leonard <dev+ietf@seantek.com>, ldapext@ietf.org
References: <20140926115934.25447.2865.idtracker@ietfa.amsl.com> <542558EB.4000709@stroeder.com> <5425848B.3040504@seantek.com>
In-Reply-To: <5425848B.3040504@seantek.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050802030109010302020001"
Archived-At: http://mailarchive.ietf.org/arch/msg/ldapext/t8NI_Cwbbob6dct_I64NZjD1T9c
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 16:04:59 -0000

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.