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

[Viktor Dukhovni <[e-mail]>]

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.

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.