[lamps] draft-ietf-lamps-eai-addresses-10 full review Part 2

[Viktor Dukhovni <[e-mail]>]

> 6.  Name constraints in path validation
> 
>    This section updates [RFC5280] name constraints defined in section
>    4.2.1.10 to work with SmtpUTF8Name subjectAltName.

Better something along the lines of:

     This section updates section 4.2.1.10 of [RFC5280] to extend
     rfc822Name name constraints to SmtpUTF8Name subjectAltNames.


>                                                        The following
>    specifies that a SmtpUTF8Name aware CA use a compatible name
>    constraint representation.

What's a "compatible name constraint representation"?  Either
clarify or delete...

>                                Similarly a SmtpUTF8Name aware path
>    validators MUST be able to apply name constraint comparison to the
>    subject distinguished name and both forms of subject alternative name
>    rfc822Name and SmtpUTF8Name.

It is I think long past time to end support for extracting DNS-ID
names and email email addresses from the certificate subject DN.
We should consider updating 5280 to drop support for matching
"emailAddress" in the subject DN when no rfc822name subject
alternative names are present.  If so, perhaps there should be no
mention of enforcing email name constraints against the subject DN.

Also, it is not clear what the "MUST" here means.  It seems to me
that this sentence is design rationale, not a protocol requirement.

>    The SmtpUTF8Name aware email address name constraint form is
>    specified to be rfc822Name motivated by compatibility considerations
>    with legacy systems that already understand that form.

Better:

     Both rfc822Name and SmtpUTF8Name subject alternative names
     represent the same underlying email address namespace.  Since
     legacy CAs constrained to issue certificates for a specific
     set of domains would lack corresponding UTF-8 constraints,
     this specification modifies and extends rfc822Name name
     constraints to cover SmtpUTF8Name subject alternative names.
     This ensures that the introduction of SmtpUTF8Name does not
     violate existing name constraints.

>                                                            This
>    specification modifies [RFC5280] name constraint to only require with
>    MAY that it represents all addresses at a host or all mailboxes in a
>    domain, and require with MAY NOT that it represent a particular
>    mailbox.

Better:

     Since it is not valid to include non-ASCII UTF-8 characters
     in the local-part of rfc822Name name constraints, and since
     name constraints that include a local-part are rarely, if at
     all, used in practice, this specification modifies [RFC5280]
     name constraints to only admit the forms represent all addresses
     at a host or all mailboxes in a domain, and deprecates rfc822Name
     name constraints that represent a particular mailbox.  That is,
     rfc822Name constraints with a local-part MUST NOT be used.

>              For context, [RFC5280] Section 4.2.1.10 specifies with MAY
>    that name constraint represent a particular mailbox, all addresses at
>    a host, or all mailboxes in a domain by specifying the complete email
>    address, a host name, or a domain.  The change is due to rfc822Name
>    name constraints inability to represent a specific mailbox with a
>    UTF-8 email local part email address.  CA certificate issuers should
>    be aware of this lessened support.

Delete.

>    Constraint comparison with SmtpUTF8Name subjectAltName starts with
>    the setup steps defined by Section 5.  The setup applies to the
>    inputs of the comparison which is one of a subject distinguished name
>    or a rfc822Name or SmtpUTF8Name subjectAltName, and one of a
>    rfc822Name name constraint.

Delete, and instead describe the actual process.


>                                 Non-normatively the setup will convert
>    any domain A-label to U-label in the rfc822Name name constraint, and
>    to lower case any domain NR-LDH label in both the name constraint and
>    the subject.

Instead of "non-normatively", specify that comparison MUST be equivalent
to:

    0.  CA certificates which include rfc822Name name constraints
	with a local-part are now invalid for issuing end-entity
	email certificates.  Equivalently, such CA certificates
	now exclude all rfc822Name and SmtpUTF8Name subject
	alternative names in the end-entity certificate.

    1.  Strip the local-part and "@" separator from each rfc822Name and
	SmtpUTF8Name, leaving just the domain-part.

    2.  Decoding any A-labels in the rfc822Name name constraint to U-labels.

    3.  Converting any NR-LDH labels in the rfc822Name name constraint to
	lower case.

    4.  Decoding any A-labels in the domain-part of each rfc822Name
        or SmtpUTF8Name subject alternative name to U-labels.

    5.  Converting any NR-LDH labels in the domain-part of each
	rfc822Name or SmtpUTF8Name subject alternative name to
	lower case.

    6.  If the resulting name constraint domain starts with a "."
	character, then for the name constraint to match, a suffix
	of the resulting subject alternative name domain MUST match
	the name constraint (including the leading ".") octet for octet.

    7.  If the resulting name constraint domain does not start with a "."
	character, then for the name constraint to match, the entire
	resulting subject alternative name domain MUST match the
	name constraint octet for octet.

>                  After setup, this follows the comparison steps defined
>    in 4.2.1.10 of [RFC5280] with some modifications as follows.  The
>    comparison process starts by determining the name constraint
>    representation i.e. email host name or domain part, then comparing
>    the name constraint against the corresponding part in the email
>    address using a byte for byte comparison.  This document suggests
>    that name constraint comparison with subject distinguished name or
>    rfc822Name subjectAltName also follow these setup and comparisons
>    steps as well.

Delete.

There should be some discussion of what CAs are expected to do when
issuing constrained intermediate subsidiary CAs (accept only IDNA2008
conformant names with no mappings, converting to A-labels in
rfc822Name subject alternative names and name constraints).

>    The name constraint requirement with SmtpUTF8Name subject alternative
>    name is illustrated in the non-normative diagram Figure 1.  The first
>    example (1) illustrates a permitted rfc822Name ASCII only hostname
>    name constraint, and the corresponding valid rfc822Name
>    subjectAltName and SmtpUTF8Name subjectAltName email addresses.  The
>    second example (2) illustrates a permitted rfc822Name hostname name
>    constraint with A-label, and the corresponding valid rfc822Name
>    subjectAltName and SmtpUTF8Name subjectAltName email addresses.
>

I would here re-iterate the requirement to use an A-label domain-part
encoding in an rfc822Name subject alternative name when the local-part
is all-ASCII.

>    +-------------------------------------------------------------------+
>    |  Root CA Cert                                                     |
>    +-------------------------------------------------------------------+
>                                      v
>    +-------------------------------------------------------------------+
>    |  Intermediate CA Cert                                             |
>    |      Permitted                                                    |
>    |        rfc822Name: elementary.school.example.com (1)              |
>    |        rfc822Name: xn--pss25c.example.com (2)                     |
>    +-------------------------------------------------------------------+
>                                      v
>    +-------------------------------------------------------------------+
>    |  Entity Cert (w/explicitly permitted subjects)                    |
>    |    SubjectAltName Extension                                       |
>    |      rfc822Name: [e-mail] (1)         |
>    |      SmtpUTF8Name: [e-mail] (1) |
>    |                                                                   |
>    |      rfc822Name: [e-mail] (2)               |
>    |      SmtpUTF8Name: u+533Bu+751F@u+5927u+5B66.example.com (2)      |
>    +-------------------------------------------------------------------+
> 
>    Name constraints with SmtpUTF8Name and rfc822Name
> 
>                                  Figure 1

> 7.  Security Considerations
> 
>    Use for SmtpUTF8Name for certificate subjectAltName (and
>    issuerAltName) will incur many of the same security considerations of
>    Section 8 in [RFC5280] but is further complicated by permitting non-
>    ASCII characters in the email address local-part.

	s/Use for/Use of/
	s/of Section 8/as in Section 8/
	s/but is further complicated/, but introduces a new issue/

>                                                       This complication,
>    as mentioned in Section 4.4 of [RFC5890] and in Section 4 of
>    [RFC6532], is that use of Unicode introduces the risk of visually
>    similar and identical characters which can be exploited to deceive
>    the recipient.

	s/This complication/The issue/

-- 
	Viktor.