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

From: Wei Chuang <[email-masked]>
Date: Wed, 1 Feb 2017 12:29:27 -0800

I wanted to forward Viktor's proposal below (actually the second proposal)
to the Lamps WG for comments.

I believe Viktor is proposing minimizing conversion by having PKIX
certificates specify the different internationalized forms of email
addresses in the same certificate.  There's nothing preventing this in the
draft, and in fact a similar approach is mentioned for naming constraints.
Practically speaking the draft recommends SMTPUTF8 for use with non-ASCII
local-part addresses, and rfc822Name for all other email addresses.
 rfc822Name domain parts support A-label but not U-label. In other words,
following recommendation, there isn't much overlap between the two
representations.  So I don't know if its practical to explicitly call out
this suggestion in the draft.  Comments?

-Wei

---------- Forwarded message ----------
From: John C Klensin <[email-masked]>
Date: Mon, Jan 23, 2017 at 10:05 PM
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt>
(Internationalized Email Addresses in X.509 certificates) to Proposed
Standard
To: [email-masked]

--On Tuesday, January 24, 2017 05:42 +0000 Viktor Dukhovni
<[email-masked]> wrote:

>...
>> I can argue for the choice of A-labels rather than U-labels
>> (or vice versa), but the choice is a matter of taste and I'm
>> happy to accept the WG's analysis and decision.
>
> I also agree that having a single normal form in the
> certificate has some merit.  I must say that the choice of
> U-label as that form is somewhat unexpected given the use of
> an A-label normal form with DNS subjectAltNames.  Consistency
> might have been preferable, though of course the local part
> offers no similar representation, and so perhaps the
> compelling argument in favour of U-labels is using a
> consistent encoding for both parts.

Personal opinion: if one gives priority to consistency with DNS
subjectAltNames, then it would be best to go with A-labels.  If
one gives priority to consistency with SMTPUTF8 addresses,
especially those containing local-parts with characters in them
that lie outside the ASCII repertoire, then one goes with
U-labels.  If the principal desire is to be consistent with
SMTPUTF8 recommendations, then one goes with U-labels too
because those specs are fairly clear about not involving email
users with A-labels if it can be avoided.

As I said, I can argue it either way, but am happy to defer to
the WG on this (especially since I strongly suspect they got it
right).

> This does mean one one will not be able to obtain a useful
> certificate for addresses like [email-masked],
> which is what Apple's Mail.app (even in the latest MacOS
> Sierra) emits when I configure a sender address in the unicode
> form of that domain.  My MTA delivers both the U-label and
> A-label forms to the same mailbox, but my other (not Mutt) MUA
> only sends A-labels.
>
> Which leads me to the observation that verification software
> will already have the message "From:" (or other purported)
> signer address in hand, which it will be comparing with the
> associated certificate. So it seems far more natural to use
> *that* address *verbatim* as the reference identifier to seek
> in the certificate.
>
> One might then obtain a certificates with two email
> subjectAltNames:
>
>     * [email-masked]
>     * [email-masked]
>
> which will work regardless of which form is seen in the message
> headers, and would not require any conversions by the verifier.
>
> In other words, check the certificate for whichever address
> form appears in the message headers.  If that's how the
> sending system knows the author, then perhaps it ought to be
> good enough in the certificate too!

This is a more interesting argument.  On the other hand, if that
application is ever going to fully support and conform to
SMTPUTF8, including local parts that are not entirely in ASCII
and non-ASCII header field contents, they are going to need to
get over the A-label preference/requirement.  What you describe
is a plain, ordinary, traditional, use of IDNA by an application
that doesn't understand it, not some type of partial SMTPUTF8
implementation.    I hope the WG has thought about the two cert
option, or will soon, but, if two certificates (potentially
issued to different parties unless the CAs are really careful)
for what the email system considers the same address poses an
attack risk, perhaps "no certs for domains containing any IDN
labels" until the relevant mail systems are upgraded" might be a
reasonable decision.

As Patrik commented about another aspect of the issue, the
document really needs to be very clear about these decisions
and, ideally, the rationale for them when they might seem
questionable... and needs to do it in really clear English.

     john

> This would dramatically simply the implementation, the
> application provides the X.509 library with the verbatim
> author address and this either matches or does not match the
> certificate without any conversions.

---

From: Wei Chuang <[email-masked]>
Date: Wed, 1 Feb 2017 15:18:40 -0800

Just to be sure that the Lamps WG sees this, I'm forwarding for comments.

In particular this notes a missing step in the existing document to do a
case insensitive comparison for the ASCII NR-LDH domain part.  This should
be added to the document, as should some sort of clarifying domain part
setup instructions.

-Wei

---------- Forwarded message ----------
From: John Levine <[email-masked]>
Date: Tue, Jan 24, 2017 at 11:31 AM
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt>
Cc: [email-masked]

>> I reread the spec, which was a good idea.  It says the domain
>> names can contain U-labels and NR-LDH ASCII labels, which
>> seems correct.  That forbids both A-labels and dodgy stuff
>> that looks like A-labels but isn't.
>
>Thanks.  That is consistent with my impression.   My concern is
>that the language and terminology won't make it clear about what
>is being specified unless someone is _really_ familiar with IDNA
>and the "EAI" specs.   It meshes with Patrik's concern that the
>wording of the spec won't be clear to someone who is not _very_
>good with English.
>
>My impression is that there is little problem with the intended
>underlying spec, but the document text needs some tuning.

Agreed.  The subsequent section on comparing names would likely
benefit from clearer instructions, e.g.

a) if the domain contains A-labels, turn them into U-labels
b) if the domain still contains R-LDH labels, stop, not a valid name.
c) if the domain contains NR-LDH labels, make them all the same case
d) do a straight byte comparison of the addresses

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Feb 2017 20:16:40 +0000

Folks,

I've just reviewed the IETF LC for this draft. Thanks all for
the comments and discussion which I think have thrown up some
real issues.

As of now, it is not clear to me that we have finished the
work with this one, at least the issues to do with name
constraints seem to me to call for some more WG consideration.

I think Russ (as lamps WG chair) has a similar opinion
that we're not done yet.

That said, I had put this on the March 16th IESG telechat
for consideration. If we do manage to reach a clear enough
consensus on a published revision to the draft in say the
next week then that schedule should still be fine. So I'd
encourage the authors and others who've commented to try
again and see if, in that timeframe, we can get to where
we're happy that the issues raised have been handled well
enough.

But, if it looks (as it does to me today) as if this'll take
a bit longer to figure out, then I figure the right thing to
do will be to let the lamps WG figure out how to proceed.
(And that'll mean that my successor as the responsible AD
for the lamps WG will handle further actions with the doc.)

Bottom line: if this isn't settled in the next week or so,
I'll take it off the March 16th IESG telechat and let the WG
continue the discussion.

Cheers,
S.

PS: To add to the name constraints discussion, I did wonder
if anyone really wants to use those. So for example, if we
defined the new name form so that certificate chains with
any name constraints at all and one of those names anywhere
are always treated as invalid, then would that cause any
real breakage? (It certainly would cause theoretical breakage,
but if that's all then I'd be ok with that:-)