Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 11 February 2017 19:56 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E8C12944F for <ietf@ietfa.amsl.com>; Sat, 11 Feb 2017 11:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2NOaLdL-ccXc for <ietf@ietfa.amsl.com>; Sat, 11 Feb 2017 11:56:11 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A35812943C for <ietf@ietf.org>; Sat, 11 Feb 2017 11:56:11 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id ECEE9284E4C; Sat, 11 Feb 2017 19:56:09 +0000 (UTC)
Date: Sat, 11 Feb 2017 19:56:09 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Message-ID: <20170211195609.GH28349@mournblade.imrryr.org>
References: <CAAFsWK0p5Zjj73Av3Z=TpjRmpJwFekfj9N+4zdcE_fFDcw65dA@mail.gmail.com> <20170206182023.GN28349@mournblade.imrryr.org> <20170208051311.GP28349@mournblade.imrryr.org> <CAAFsWK3xY35+yD5drtmUJUNMaAA8pRUwM3h22rvm+k7g5W8uKg@mail.gmail.com> <20170208151943.GQ28349@mournblade.imrryr.org> <CAAFsWK20Sf51W+cRUBET8-U5XXO+Z1ixOt3dgu70ad99FPsrWg@mail.gmail.com> <20170209175737.GV28349@mournblade.imrryr.org> <EB04BFE1-6A74-4697-9D4F-67A356B107DE@vigilsec.com> <20170209223951.GW28349@mournblade.imrryr.org> <B10DA49E-9562-42FF-A2B6-352EA7527167@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B10DA49E-9562-42FF-A2B6-352EA7527167@vigilsec.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/7z8GwgAAttR0Lh_9i0hFCz-0nQQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: ietf@ietf.org
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Feb 2017 19:56:13 -0000

On Sat, Feb 11, 2017 at 01:42:02PM -0500, Russ Housley wrote:

> Wei is arguing that the two (ffc822Name and SmtpMUtf8Name) should be
> completely separate.

This introduces a means to evade name constraints placed on existing
(intermediate) CAs whose issuer (parent CA) was/is not SmtpUtf8 aware.
Software that introduces such bypass mechanisms would rate a CVE.
OpenSSL will not implement the proposal in its current form.

Once again, a CA with *ONLY* rfc822Name constraints should not be
able to able issue EE certificates with SmtpUtf8Name altNames that
conflict with its rfc822Name constraints.

Once again, I am not concerned about A-labels, U-labels, etc.,
rather, if a CA is constrained to example.com (an ordinary LDH
domain) email addresses via rfc822Name, and no SmtpUtf8Name
constraints are present, then the CA in question MUST NOT be able
to bypass that constraint via SmtpUtf8Name altnames with a domain
part of "example.com".

> You are arguing for some crossover, but I do not understand how A-labels
> in the rfc822Name are handled in your proposal.

So far, I've said nothing about about A-labels in rfc822Name
constraints.  Now that you ask, my view is that in the absence of
SmtpUtf8 constraints, an rfc822Name constraint that restricts a CA
to issue EE altnames with a domain part of xn--b1adqpd3ao5c.org
means that the CA should only be only issue rfc822Name altnames with
that verbatim A-label form only.  Thus, that same hypotheical CA would
not be able to issue SmtpUtf8Names with a domain part of духовный.org,
because that UTF-8 name does not match the literal rfc822Name constraint.

> If rfc822Name permits 'xn--fa-hia.de’ then it would need to be translated
> to 'faß.de’ for comparison in SmtpUtf8Name.

I did not want to conflate the rfc822Name constraint bypass issue
with the issue of A-label/U-label conversions.  My take is still
that conversions are not a good idea, and that a reference identifier
should be found verbatim in the certificate as a matching presented
identifier with no conversions.  With that a 'faß.de' SmtpUtf8Name
altname would not be allowed for a CA constrained to just
'xn--fa-hia.de'.

A CA that wants to start issuing 'faß.de' altnames can use a
suitable new intermediate certificate with appropriate additional
SmtpUtf8 constraints.

Requiring conversions from rfc822Name constraints that are A-labels
to correspoding U-label constraints would IMHO be a mistake, and
would require the introduction into OpenSSL and other X.509 stacks
of code that converts from A-labels to U-labels.  I think such
complexity is unwarranted, and I'd very much like to avoid the
need for any such conversions.

-- 
	Viktor.