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

[Wei Chuang <[e-mail]>]

Thanks for the comments.  Reply inline below:

On Tue, Mar 14, 2017 at 9:49 AM, Viktor Dukhovni <[e-mail]>
wrote:

> On Mon, Mar 13, 2017 at 10:44:32AM -0400, Russ Housley wrote:
>
> > > On Mar 12, 2017, at 5:40 PM, Wei Chuang <[e-mail]> wrote:
> > >
> > > 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.
> >
> > 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.
>


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



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

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: [e-mail] (3e)     |
  +-------------------------------------------------------------------+
                                    |
                                    v
  +-------------------------------------------------------------------+
  |  Entity Cert (w/explicitly permitted subjects)                    |
  |    SubjectAltName Extension                                       |
  |      rfc822Name: [e-mail] (3a)             |
  |      SmtpUTF8Name: [e-mail] (3a)      |
  |                                                                   |
  |      rfc822Name: student@u+5C0Fu+5B66.host.example.com (3b)       |
  |      SmtpUTF8Name: [e-mail] (3b)   |
  |                                                                   |
  |      rfc822Name: [e-mail] (3c)      |
  |                                                                   |
  |      SmtpUTF8Name: student@u+4E2Du+5B66.u.label.example.com (3d)  |
  |                                                                   |
  |      SmtpUTF8Name: [e-mail] (3e)       |
  +-------------------------------------------------------------------+
</artwork>


Are you suggesting to break this up further?


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

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