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

From: Stephen Farrell <[email-masked]>
Date: Wed, 8 Mar 2017 16:22:25 +0000

Hiya,

So I don't think we've yet resolved the issues raised
with this. And since the March 16th telechat will be my
last one I figure that the best thing to do is to ask
that this go back to the working group for resolution.

Once that's sorted out, then the WG can kick it over
to their new AD. Note that this need not add any major
delay - it'd be entirely possible to have it back on a
telechat agenda shortly after IETF98, all going well.

If nobody yells, I'll do that tomorrow.

If someone does yell, please do that now and accompany
your yell with the OLD/NEW changes that you claim resolve
the issues raised. (To be honest though, I think this
would benefit from more WG discussion so I'll not be so
easy to convince if someone does yell thusly;-)

Cheers,
S.

On 23/02/17 20:16, Stephen Farrell wrote:
> 
> 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:-)
> 
> 
>

---

From: Wei Chuang <[email-masked]>
Date: Wed, 8 Mar 2017 15:07:15 -0800

Hi Stephen,

Let me provide that yell to see if this draft resolves the last set of
concerns.
https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-07

The diff is here:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-07.txt

-Wei

On Wed, Mar 8, 2017 at 8:22 AM, Stephen Farrell <[email-masked]>
wrote:

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Mar 2017 18:27:55 -0500

> On Mar 8, 2017, at 6:07 PM, Wei Chuang <[email-masked]> wrote:
> 

This diff covers a lot more than just name constraints.  One oddity that
stands out is in section 5:

	3.  Ensure local-part is UTF-8.

I don't see how one would "ensure" such a thing, since no encoding
information is available for the localpart, is I would expect that
is always presumptively UTF-8 (if not us-ascii).

More importantly I don't believe that the name constraint issues are
adequately or correctly addressed in this revision.

Instead of prohibiting issuance of EE certs that HAVE SmtpUTF8Name SAN
elements via a cert chain that has a certificate with *just* rfc822Name
constraints, it attempts to require an unnecessary (and I think not
entirely robust) correspondence between the two types constraint, and
needlessly bans EE certs whose chains include just rfc822Name constraints
even in the absence of SmtpUTF8Name SAN elements.

The changes in this revision seem to me to be too extensive, and not
yet finished. :-(

-- 
	Viktor.

---

From: Wei Chuang <[email-masked]>
Date: Wed, 8 Mar 2017 17:17:15 -0800

Okay.  I think the direction then is to have SmtpUTF8Name respect
rfc822Name name constraints and vice versa.

-Wei

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Mar 2017 22:19:20 -0500

> On Mar 8, 2017, at 8:17 PM, Wei Chuang <[email-masked]> wrote:
> 
> Okay.  I think the direction then is to have SmtpUTF8Name respect rfc822Name name constraints and vice versa.

Well, no, the simplest proposal on the table is for SmtpUTF8Name to
be *prohibited* when rfc822Name constraints are present and SmtpUTF8Name
constraints are not.  When both present, they can operate independently.

The verifier logic is then:

	1. If neither rfc822Name constraints nor SmtpUTF8Name constraints
           are present in any CA certificate in the chain, any mixture of
           rfc822Name and SmtpUTF8Name SAN elements is valid.

	2. If some certificate in the chain contains *only* rfc822Name
	   constraints, then these apply to rfc822Name SAN elements, but
	   all SmtpUTF8Names are prohibited.

	3. When both types of constraints are present in all CA certificates
           that have either type, then constraints for each SAN type are
	   exclusively based on just the corresponding constraint type.

	4. If some certificate in the chain contains only SmtpUTF8Name
 	   constraints then those are unavoidably at risk of bypass via
           rfc822Name SAN elements when processed by legacy verifiers.
	   Therefore, this should be avoided, and the CA needs to
 	   publish rfc822Name constraints that prevent bypass.  Such
	   constraints *need not* be equivalent (not always possible)
	   to the desired SmtpUTF8Name constraints.  Rather, it suffices
	   to not permit rfc822Name elements that would be prohibited
	   if they were simply cut/pasted (with no A-label to U-label
           conversions) as SmtpUTF8Name elements.  It is not necessary
	   for these to permit everything that SmtpUTF8Name permits.

Thus for example, if SmtpUtf8Name only permits addresses in the non NR-LDH
domain "духовный.org" (or a specific set of addresses in such a domain),
then the corresponding rfc822Name constraint could just permit "." (or the
reserved "invalid" TLD if that's preferable) which is not a usable email
domain.  This ensures that only the permitted SmtpUTF8Name SANs are used
and no rfc822Name SANs are used.

If, instead the Smtp8Name constraints are excluded non-ASCII address forms,
then since these have no literal rfc822Name equivalents, the rfc822Name
constraints can be omitted with the same effect.

Only when the intention is to permit NR-LDH domains with either ASCII or
UTF-8 localparts (or an all-ASCII full address) do the rfc822Name and
SmtpUTF8Name constraints need to be fully equivalent.  This is of course
trivial to do.  Just cut/paste the same string into both types of
constraint.

-- 
	Viktor.

---

From: Wei Chuang <[email-masked]>
Date: Sun, 12 Mar 2017 14:40:45 -0700

The latest draft 08 is up:
https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08

The diff is:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-08.txt

This draft attempts to capture Viktor's name constraint verifier logic, and
illustrate the examples in the diagrams.

-Wei

On Thu, Mar 9, 2017 at 10:22 AM, Wei Chuang <[email-masked]> wrote:

> There seems to be a consensus here and internally to the changes that
> Viktor proposes.  We can put that in the next draft update.
>
> -Wei
>
> On Thu, Mar 9, 2017 at 1:34 AM, tom p. <[email-masked]> wrote:
>
>> ----- Original Message -----
>> From: "Viktor Dukhovni" <[email-masked]>
>> To: <[email-masked]>; "IETF general list" <[email-masked]>
>> Sent: Thursday, March 09, 2017 3:19 AM
>> <tp>
>> Getting security right can be tricky as the legion of failed attempts
>> that make it to RFC testify but what you are proposing here seems so
>> simple, so obviously the right thing to do that I am puzzled, bewildered
>> even, that anyone can disagree with you.
>>
>> Tom Petch
>>
>> domain "духовный.org <http://xn--b1adqpd3ao5c.org>" (or a specific set
>> of addresses in such a domain),

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Mar 2017 10:44:32 -0400

These changes were made in response to an IETF Last Call comment.  Please review them.  The vast bulk of the changes are in Section 6.  Please speak promptly if you think this is the word technical solution.

Russ

> On Mar 12, 2017, at 5:40 PM, Wei Chuang <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 <https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08>
> 
> The diff is:
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-08.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-08.txt>
> 
> This draft attempts to capture Viktor's name constraint verifier logic, and illustrate the examples in the diagrams.
> 
> -Wei
>  
> 
> On Thu, Mar 9, 2017 at 10:22 AM, Wei Chuang <[email-masked] <mailto:[email-masked]>> wrote:
> There seems to be a consensus here and internally to the changes that Viktor proposes.  We can put that in the next draft update.
> 
> -Wei
> 
> On Thu, Mar 9, 2017 at 1:34 AM, tom p. <[email-masked] <mailto:[email-masked]>> wrote:
> From: "Viktor Dukhovni" <[email-masked] <mailto:[email-masked]>>
> To: <[email-masked] <mailto:[email-masked]>>; "IETF general list" <[email-masked] <mailto:[email-masked]>>
> > On Mar 8, 2017, at 8:17 PM, Wei Chuang <[email-masked] <mailto:[email-masked]>> wrote:
> >
> domain "духовный.org <http://xn--b1adqpd3ao5c.org/>" (or a specific set of addresses in such a domain),

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Mar 2017 11:14:11 -0400

It appears that autocorrect made a typo much worse.  I meant so say...

These changes were made in response to an IETF Last Call comment.  Please review them.  The vast bulk of the changes are in Section 6.  Please speak promptly if you think this is the wrong technical solution.

Russ

> From: Russ Housley [mailto:[email-masked] <mailto:[email-masked]>] 
Sent: Monday, March 13, 2017 10:45 AM
To: SPASM
Subject: Re: [Spasm] Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

Russ

On Mar 12, 2017, at 5:40 PM, Wei Chuang <[email-masked] <mailto:[email-masked]>> wrote:
 
The latest draft 08 is up:
https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dlamps-2Deai-2Daddresses-2D08&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=1MWONujUfB8F3GUGv6AW8UGwQuNDq0G3TEAGmYYij6I&s=bRu_sJbqhowJkrhC9p2CRMvk6nCfIJUndl7MrfSRMk0&e=>
 
The diff is:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-08.txt <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dlamps-2Deai-2Daddresses-2D08.txt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=1MWONujUfB8F3GUGv6AW8UGwQuNDq0G3TEAGmYYij6I&s=PKrOrXVJsbBO0wcBMB-rgIRT7iOO4OFjgtoR64Bf9Wg&e=>

-Wei

-Wei
 
----- Original Message -----
From: "Viktor Dukhovni" <[email-masked] <mailto:[email-masked]>>
To: <[email-masked] <mailto:[email-masked]>>; "IETF general list" <[email-masked] <mailto:[email-masked]>>
Sent: Thursday, March 09, 2017 3:19 AM

<tp>

Tom Petch

1. If neither rfc822Name constraints nor SmtpUTF8Name constraints
           are present in any CA certificate in the chain, any mixture
of
           rfc822Name and SmtpUTF8Name SAN elements is valid.

Thus for example, if SmtpUtf8Name only permits addresses in the non
NR-LDH
domain "духовный.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__xn-2D-2Db1adqpd3ao5c.org_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=1MWONujUfB8F3GUGv6AW8UGwQuNDq0G3TEAGmYYij6I&s=Oe17K7ooNPBDUmFvzu-ND8age2YROKJisOoK3yEMDGE&e=>" (or a specific set of addresses in such a domain),
then the corresponding rfc822Name constraint could just permit "." (or
the
reserved "invalid" TLD if that's preferable) which is not a usable email
domain.  This ensures that only the permitted SmtpUTF8Name SANs are used
and no rfc822Name SANs are used.

If, instead the Smtp8Name constraints are excluded non-ASCII address
forms,
then since these have no literal rfc822Name equivalents, the rfc822Name
constraints can be omitted with the same effect.

--
Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Mar 2017 13:43:53 +0000

Hi Russ, all,

So I've thought about this a bit and chatted with a few
folks, and I'm just not quite convinced that we've had
enough time or eyeballs to process the perfectly reasonable
looking (but significant) changes that were made during
and since the end of IETF LC by this Thursday's IESG
telechat. So I've taken this document off that agenda.

Apologies that that'll cause a bit more delay due to the
handover of ADs around IETF98 but I hope that that won't
be a bad delay.

I guess these LC changes are ones that it'd be good to go
over in Chicago as well, just to be sure that we've landed
in a good place.

Note that after Chicago, the new AD can re-inject the
document back into the process at IESG evaluation again
if that's the right thing to do, so this change does not
mean that a new IETF last call will be needed. Though of
course if there are further changes that might end up
being the right thing to do. In any case, for those who
like process minutiae, I've left this in the "waiting
for writeup" state but just taken it off this week's
agenda.

Cheers, and sorry again for being a cause of delay,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Mar 2017 14:49:02 +0000

On Mon, Mar 13, 2017 at 10:44:32AM -0400, Russ Housley wrote:

> > This draft attempts to capture Viktor's name constraint verifier logic,
> > and illustrate the examples in the diagrams.
>
> These changes were made in response to an IETF Last Call comment.  Please
> review them.  The vast bulk of the changes are in Section 6.  Please speak
> promptly if you think this is the word technical solution.

I think that while the new section 6 is technically on track, that
it still needs a bit more effort to improve clarity.

The design would be more clear if the rationale were stated clearly
and concisely up-front.  Therefore, after the second paragraph, I
would like to see something along the lines of (please improve as
needed):

    Some legacy actors (either CAs or relying parties)
    support only rfc822Name SANs and rfc822Name constraints.
    While limits on the new SmtpUTF8Name SANs will be
    expressed via new SmtpUTF8Name constraints defined in
    this document, these will not be generated or understood
    by the above legacy actors.

    When a legacy CA has only rfc822Name constraints, with
    the intent of limiting the scope of email addresses
    allowed in end-entity certificates it can issue, there
    would be a potential constraint bypass risk, if as a
    result all SmtpUTF8Name SANs were allowed to be used
    for lack of corresponding constraints.

    When a non-legacy CA has only SMTPUTF8Name constraints,
    with the intent of limiting the scope of allowed
    addresses to particular UTF8 forms, there is again a
    risk of bypass when a legacy relying party remains unaware
    of this intent.

    To avoid the above constraint bypass issues, we obligate
    SmtpUTF8Name-aware relying parties to disallow SmtpUTF8Name
    SANS in end-entity certificates whose chain includes
    (presumed) legacy CAs that have only rfc822Name
    constraints.

    Similarly, we obligate SmtpUTF8-aware CAs issuing
    constrained CA certificates, to also include sufficient
    rfc822Name constraints so that the set of email addresses
    acceptable in end-entity certificates is not unintentionally
    larger for legacy SmtpUTF8-unaware relying parties.

I also think that the text below points 1--4 could be more clear.
Instead of a single explosion of text that tries to explain all
the diagrams, it is perhaps better to interleave the diagrams
with corresponding explanatory text.

Also there could be a better explanation of how to craft rfc822Name
constraints to avoid constraint bypass against legacy relying
parties.  That is, the paragraph:

   If the issuer wishes to represent the name constraint asymmetrically,
   with either rfc822Name or SmtpUTF8Name to respectively represent some
   A-label or U-label in the domain or host, the alternate name
   constraint form must still be present.  If nothing needs be
   represented by the alternate form, then empty name constraint can
   described by the "invalid" TLD that helps initialize the name
   constraint path validation set.  Or alternatively it may be omitted
   if some other name constraint pair, provides a name constraint of
   that form.  In particular this initialization may be needed when
   SmtpUTF8Name is used to represent an email address name constraint
   with an UTF-8 local-part and rfc822Name cannot represent such a email
   address constraint.

may be too concise.  With luck the suggested rationale additions may
help readers figure out an appropriate strategy that meets the same
goals, but this text could probably be improved.

-- 
	Viktor.

---

From: Wei Chuang <[email-masked]>
Date: Thu, 30 Mar 2017 11:31:07 -0500

Thanks for the comments.  Reply inline below:

>     larger for legacy SmtpUTF8-unaware relying parties.

How about the following language to represent the above:

This specification pays particular attention to interaction between legacy
and SmtpUTF8Name
aware systems as there is the risk of name constraint bypass through these
interactions.  More
specifically the risk is between legacy CA and SmtpUTF8Name aware path
verifiers, and between
SmtpUTF8Name aware CA and legacy path verifiers.  A legacy CA is only aware
of rfc822Name
subjectAltName and name constraints, and GeneralName subject.  While a
legacy CA may intend to limit
the scope of all email addresses through rfc822Name name constraint, a
SmtpUTF8Name aware path
verifier may mistakenly interpret the path as only constraining rfc822Name
subjectAltName names and
not SmtpUTF8Name subjectAltName names.  The following section requires that
the SmtpUTF8Name aware
verifier protect against this scenario in the following section (as bullet
2).  Similarly there is a
bypass risk when a legacy path verifier is only aware of the legacy
rfc822Name name constraints and
subject name forms, and a SmtpUTF8Name aware CA intends to contrains all
email addresses including
SmtpUTF8Name form.  The bypass in this scenario is prevented by the <xref
target='RFC5280'/>
compliant path verifier that sees the unknown SmtpUTF8Name subjectAltName
name and name constraint
whose extensions are marked critical, then fails the verification.

The referred to bullet 2 is

If issuer CA certificates contain only rfc822Name name constraints, then
those constraints
 apply to rfc822Name subject alternative name in children certificates.
SmtpUTF8Name
 subject alternative name are prohibited in those same certificates, that
is those
  certificates MUST be rejected by the path verifier

> with corresponding explanatory text.

I've put the example text next to the respective diagram of which there
three.  The largest blob still looks like:

The name constraint requirement with SmtpUTF8Name subject alternative name
is illustrated in the
non-normative diagram <xref target="example_permitted_matched_constraint"
/> with several examples.
The example numbering corresponding to the above rule numbering.
(3a) shows an issuer constraining a NR-LDH hostname with rfc822Name and
SmtpUTF8Name so that they
can issue ASCII and UTF-8 local-name email addresses certificates.  (3b)
shows an issuer
constraining a hostname containing a non-ASCII label for u+5C0Fu+5B66
(elementary school).  (3c)
demonstrates that a hostname constraint with an rfc822Name is
distinguishable from its SmtpUTF8Name
constraint, and that only the rfc822Name form is permitted.  No 'invalid'
SmtpUTF8Name constraint is
needed since other SmtpUTF8Name constraints are present.  (3d) similarly
demonstrates this
capability to restrict a name constraint to SmtpUTF8Name only.  (3e) shows
that a non-ASCII local-
part email address can also be constrained to be permitted using
SmtpUTF8Name.  It too does not need
an 'invalid' rfc822Name as other rfc822Name constrains are present.

<artwork>
  +-------------------------------------------------------------------+
  |  Root CA Cert                                                     |
  +-------------------------------------------------------------------+
                                    |
                                    v
  +-------------------------------------------------------------------+
  |  Intermediate CA Cert                                             |
  |      Permitted                                                    |
  |        rfc822Name: nr.ldh.host.example.com (3a)                   |
  |        SmtpUTF8Name: nr.ldh.host.example.com (3a)                 |
  |                                                                   |
  |        rfc822Name: u+5C0Fu+5B66.host.example.com (3b)             |
  |        SmtpUTF8Name: xn--48s3o.host.example.com (3b)              |
  |                                                                   |
  |        rfc822Name: xn--pss25c.a.label.example.com (3c)            |
  |                                                                   |
  |        SmtpUTF8Name: u+4E2Du+5B66.u.label.example.com (3d)        |
  |                                                                   |
  |        SmtpUTF8Name: [email-masked] (3e)     |
  +-------------------------------------------------------------------+
                                    |
                                    v
  +-------------------------------------------------------------------+
  |  Entity Cert (w/explicitly permitted subjects)                    |
  |    SubjectAltName Extension                                       |
  |      rfc822Name: [email-masked] (3a)             |
  |      SmtpUTF8Name: [email-masked] (3a)      |
  |                                                                   |
  |      rfc822Name: student@u+5C0Fu+5B66.host.example.com (3b)       |
  |      SmtpUTF8Name: [email-masked] (3b)   |
  |                                                                   |
  |      rfc822Name: [email-masked] (3c)      |
  |                                                                   |
  |      SmtpUTF8Name: student@u+4E2Du+5B66.u.label.example.com (3d)  |
  |                                                                   |
  |      SmtpUTF8Name: [email-masked] (3e)       |
  +-------------------------------------------------------------------+
</artwork>

Are you suggesting to break this up further?

> goals, but this text could probably be improved.

What about:

The issuer may wish to distinguish the features of the two different name
constraint forms as
well as they can represents names differently.  For example the issuer may
wish to constraint a name
with A-label differently than U-label.  Another example is constraining a
UTF-8 local-part email
address via SmtpUTF8Name that rfc822Name cannot do.  If the intent is to
allow SmtpUTF8Name
subjectAltName, then both name constraint forms, rfc822Name and
SmtpUTF8Name, must be present though
with some caveats.  If nothing needs be represented by the alternate form,
then the empty name
constraint can be described by the "invalid" TLD that helps initialize the
name constraint path
validation set.  Or alternatively it may be omitted if some other name
constraint pair, provides a
name constraint of that form.

-Wei