Subject: [lamps] draft-ietf-lamps-eai-addresses-10 full review Part 1

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 7 Jun 2017 04:57:25 +0000

On Fri, May 26, 2017 at 03:37:07PM -0400, Russ Housley wrote:

> This is the LAMPS WG Last Call for "Internationalized Email Addresses in
> X.509 Certificates� <draft-ietf-lamps-eai-addresses-10>.  Please review
> the document and send your comments to the list by 9 June 2017.

See below.

>    This document defines a new name form for inclusion in the otherName
>    field of an X.509 Subject Alternative Name and Issuer Alternate Name
>    extension that allows a certificate subject to be associated with an
>    Internationalized Email Address.

    s/Issuer Alternate Name/Issuer Alternative Name/

Is there actually a use-case for EAI email addresses in issuer
alternative names?  Are issuer alternative names used at all?

> 1.  Introduction
> 
>    [RFC5280] defines rfc822Name subjectAltName choice for representing

    s/rfc822Name subjectAltName choice/the rfc822Name subjectAltName name type/

>    [RFC5321] email addresses.  This form is restricted to a subset of

    s/This form/The syntax of rfc822Name/

>    US-ASCII characters and thus can't be used to represent
>    Internationalized Email addresses [RFC6531].  To facilitate use of
>    these Internationalized Email addresses with X.509 certificates, this

    s/these//

>    document specifies a new name form in otherName so that
>    subjectAltName and issuerAltName can carry them.  In addition this

	s/a new name form in otherName/a new otherName variant/
	s/so that subjectAltName and issuerAltName can carry them//

>    document calls for all email address domain in X.509 certificates to
>    conform to IDNA2008 [RFC5890].

	s/domain/domains/
	s/conform to IDNA2008 [RFC5890]/conform to IDNA2008 [RFC5890], with
          non-ASCII domains encoded in A-label form/

> 3.  Name Definitions
> 
>    The GeneralName structure is defined in [RFC5280], and supports many
>    different names forms including otherName for extensibility.  This

	s/names forms/name forms/

>    section specifies the SmtpUTF8Name name form of otherName, so that

Given that email certificates pertain (primarily) to email messages
and not email transport, perhaps SmtpUTF8Name is not the best term
to introduce here?  It is likely too late to suggest "UTF8MailboxName",
but if not, it is clear and removes the out of place connection to SMTP.

>    Internationalized Email addresses can appear in the subjectAltName of
>    a certificate, the issuerAltName of a certificate, or anywhere else
>    that GeneralName is used.

Well, not really *anywhere* else, since we're specifically excluding
this name type in the context of name constraints.  And it seems quite
unlikely that it will appear anywhere other than as a subjectAltName.

>    When the subjectAltName (or issuerAltName) extension contains an
>    Internationalized Email address, the address MUST be stored in the
>    SmtpUTF8Name name form of otherName.  The format of SmtpUTF8Name is

But addresses with an all-ASCII localpart and a non-ASCII domain will
be stored via rfc822Name with the domainpart converted to A-label form.
So the above is perhaps misleading...

>    defined as the ABNF rule SmtpUTF8Mailbox.  SmtpUTF8Mailbox is a
>    modified version of the Internationalized Mailbox which was defined
>    in Section 3.3 of [RFC6531] which was itself derived from SMTP
>    Mailbox from Section 4.1.2 of [RFC5321].  [RFC6531] defines the
>    following ABNF rules for Mailbox whose parts are modified for
>    internationalization: <Local-part>, <Dot-string>, <Quoted-string>,
>    <QcontentSMTP>, <Domain>, and <Atom>.  In particular, <Local-part>
>    was updated to also support UTF8-non-ascii.  UTF8-non-ascii was
>    described by Section 3.1 of [RFC6532].  Also, sub-domain was extended
>    to support U-label, as defined in [RFC5890].

This too seems to invite a name that is more like "UTF8MailboxName" than
"SmtpUTF8Name".

Instead of trying to import the ABNF from multiple documents, which
in turn import ABNF from yet more documents, ...  It is perhaps time
to consolidate the relevant definitions in place, with a single
set of named building blocks.

>    This document further refines Internationalized [RFC6531] Mailbox
>    ABNF rules and calls this SmtpUTF8Mailbox.

If not too late:  s/SmtpUTF8Mailbox/UTF8Mailbox/

>                                                In SmtpUTF8Mailbox, sub-
>    domain that encode non-ASCII characters SHALL use U-label Unicode
>    native character labels and MUST NOT use A-label [RFC5890].

What appears to be meant by "sub-domain" here is in fact a label.
It would be more clear to avoid additional terminology for the same
thing.  And why "encode"?  Better would be:

                                                 In SmtpUTF8Mailbox, 
     labels that include non-ASCII characters MUST be stored in
     U-label (rather than A-label) [RFC5890] form.

>    This
>    restriction prevents having to determine which label encoding A- or
>    U-label is present in the Domain.

    s/prevents/removes the need/

>                                       As per Section 2.3.2.1 of
>    [RFC5890], U-label use UTF-8 [RFC3629] with Normalization Form C and
>    other properties specified there.

	s/U-label use/U-labels are encoded as/
	s/with/in/

>                                       In SmtpUTF8Mailbox, sub-domain
>    that encode ASCII character labels SHALL use NR-LDH restrictions as
>    specified by section 2.3.1 of [RFC5890] and SHALL be restricted to
>    lower case letters.

	s/sub-domain/domains/
	s/encode/include/

It is not clear what the above is saying.  Is it talking about
all-ASCII labels?  Or ASCII characters generally, possibly in
U-labels?  What are "NR-LDH restrictions"?  I did not see any such
term defined in rfc5890.  What is defined is "NR-LDH label" (2.3.2.2).

>                         One suggested approach to apply these sub-
>    domains restriction is to restrict sub-domain so that labels not
>    start with two letters followed by two hyphen-minus characters.

This makes no sense at all, and should probably be removed.

>    Consistent with the treatment of rfc822Name in [RFC5280],
>    SmtpUTF8Name is an envelope <Mailbox> and has no phrase (such as a
>    common name) before it, has no comment (text surrounded in
>    parentheses) after it, and is not surrounded by "<" and ">".

Surely there's no need to drag in any mention of envelopes.  If
there is no ABNF construct elsewhere that gives just the desired
address part, define it here.  Trying to use ABNF by reference
makes this document contorted and unclear.

>    Due to operational reasons described shortly and name constraint

	s/described/to be described/

>    compatibility reasons described in its section,

	s/its section/<reference to section in question>/

>                                                    SmtpUTF8Name
>    subjectAltName MUST only be used when the local part of the email
>    address contains UTF-8.

UTF-8 is an encoding, not content:

	s/containts UTF-8/contains non-ASCII characters/

>                             When the local-part is ASCII, rfc822Name
>    subjectAltName MUST be used instead of SmtpUTF8Name.  The use of
>    rfc822Name rather than SmtpUTF8Name is currently more likely to be
>    supported.

The second sentence would be better as:

     This is compatible with legacy software that supports only
     rfc822Name (and not SmtpUTF8Name).

>                Also use of SmtpUTF8Name incurs higher byte
>    representation overhead due to encoding with otherName and the
>    additional OID needed.  This may be offset if domain requires non-
>    ASCII characters as SmtpUTF8Name supports U-label whereas rfc822Name
>    supports A-label.

This is not sufficiently compelling to be mentioned.  Please remove.

> 4.  IDNA2008
> 
>    To facilitate comparison between email addresses, all email address
>    domain in X.509 certificates MUST conform to IDNA2008 [RFC5890] (and
>    excludes any "mappings" mentioned in that document).

	s/domain/domains/
	s/excludes/avoid/

>                                                      Otherwise non-
>    conforming email address domains introduces the possibility of
>    conversion errors between alternate forms.

	s/Otherwise/Use of/

>                                                This applies to
>    SmtpUTF8Mailbox and rfc822Name in subjectAltName, issuerAltName and
>    anywhere else that GeneralName is used.

	s/SmtpUTF8Mailbox/SmtpUTF8Name/
	s/GeneralName is/these are/

> 5.  Matching of Internationalized Email Addresses in X.509 certificates
> 
>    In equivalence comparison with SmtpUTF8Name, there may be some setup
>    work to enable the comparison i.e. processing of the SmtpUTF8Name
>    content or the email address that is being compared against.

This is a lot of words to say very little or nothing at all.   Delete
or clarify.

>                                                                  The
>    process for setup for comparing with SmtpUTF8Name is split into
>    domain steps and local- part steps.

The phrase "process for setup for comparing" is exceedingly convoluted,
please fix.  How about just: "Comparing SmtpUTF8Names consists of a 
domain-part step and a local-part step".

>                                         The comparison form for local-
>    part always is UTF-8.  The comparison form for domain depends on
>    context.

	s/local-part/local-parts/
	s/domain/domain-parts/

>    Comparison of two SmtpUTF8Name is straightforward with no setup work
>    needed.  They are considered equivalent if there is an exact octet-
>    for-octet match.

What is expected to be compared are not two "SmtpUTF8Name" objects,
but such an object with an email address, or such an object with
an rfc822Name constraint.  And, with NR-LDH labels, case insensitive
comparison may be required.  Why are we descibing comparisons that
don't happen?

>                      Comparison with other email address forms such as

SmtpUTF8Name is not an "email address form", it is a GeneralName form.
So "other email address forms" is not correct.

>    Internationalized email address or rfc822Name requires additional
>    setup steps.  Domain setup is particularly important for forms that
>    may contain A- or U-label such as International email address, or
>    A-label only forms such as rfc822Name.

Clarify or delete.

>                                            This document specifies the
>    process to transform the domain to U-label.  (To convert the domain
>    to A-label, follow the process specified in section 7.5 and 7.2 in
>    [RFC5280])

Why the parenthetical comment?  And we don't specify the process
of transforming to U-label form.  Rather we require such conversion
when one of the addresses being compared employs A-labels.

>    The first step is to detect A-label by using section 5.1
>    of [RFC5891].

	s/A-label/use of A-labels/

>    Next if necessary, transform the A-label to U-label
>    Unicode as specified in section 5.2 of [RFC5891].  Finally if
>    necessary convert the Unicode to UTF-8 as specified in section 3 of
>    [RFC3629].  

	s/the A-label/any A-labels/
	s/U-label/U-labels/

Nobody will convert to UTF-8 in two separate steps.  In practice
a library will be used that converts from A-label form to UTF-8
encoded Unicode.

>    For ASCII NR-LDH labels, upper case letters are converted
>    to lower case letters.  

Fine.

>    In setup for SmtpUTF8Mailbox, the email
>    address local-part MUST conform to the requirements of [RFC6530] and
>    [RFC6531], including being a string in UTF-8 form.  In particular,

Given the below, I don't see any need for the above.

>    the local-part MUST NOT be transformed in any way, such as by doing
>    case folding or normalization of any kind.  The <Local-part> part of
>    an Internationalized email address is already in UTF-8.

>    To summarize non-normatively, the comparison steps including setup
>    are:
> 
>    1.  If the domain contains A-labels, transform them to U-label.

    s/U-label/U-labels/

>    2.  If the domain contains ASCII NR-LDH labels, lowercase them.
> 
>    3.  Ensure local-part is UTF-8.

Since the local-part of email addressees is not accompanied by any
encoding information, it is *presumptively* UTF-8, and there is
nothing to do (or that can be done) in this step.

>    4.  Compare strings octet-for-octet for equivalence.

>    This specification expressly does not define any wildcards characters

    s/wildcards/wildcard/

>    and SmtpUTF8Name comparison implementations MUST NOT interpret any
>    character as wildcards.  Instead, to specify multiple email addresses
>    through SmtpUTF8Name, the certificate SHOULD use multiple

	s/SHOULD/MUST/

>    subjectAltNames or issuerAltNames to explicitly carry those email
>    addresses.

    s/those/any additional/

More to follow.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 14 Jun 2017 04:24:51 +0000

> 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: [email-masked] (1)         |
>    |      SmtpUTF8Name: [email-masked] (1) |
>    |                                                                   |
>    |      rfc822Name: [email-masked] (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.

---

From: Wei Chuang <[email-masked]>
Date: Mon, 19 Jun 2017 12:51:27 -0700

Part 2 to follow.

>     s/Issuer Alternate Name/Issuer Alternative Name/

Done.

> alternative names?  Are issuer alternative names used at all?

Russ called for including this during in one of the earlier edits comment
period.

>     s/rfc822Name subjectAltName choice/the rfc822Name subjectAltName name

Done

>     s/This form/The syntax of rfc822Name/

Done

> >    these Internationalized Email addresses with X.509 certificates, this

Done

>         s/a new name form in otherName/a new otherName variant/

Done

>         s/so that subjectAltName and issuerAltName can carry them//

Done

> >    conform to IDNA2008 [RFC5890].

Done

>           non-ASCII domains encoded in A-label form/

This turn out to be confusing though correct.  I haven't added this.

>         s/names forms/name forms/

Done

> but if not, it is clear and removes the out of place connection to SMTP.

The original name for this type was eaiName which is close to what you're
suggesting.  There was a suggestion that this type is tied to email header
addresses and that name this SmtpUTF8.  I'd agree that its late now to
rehash a new name type.

> unlikely that it will appear anywhere other than as a subjectAltName.

The original document just only specified subjectAltName.  Russ Housley
suggested including issuerAltName to be thorough.

> So the above is perhaps misleading...

Done

> If not too late:  s/SmtpUTF8Mailbox/UTF8Mailbox/

Alas, see above.

>      U-label (rather than A-label) [RFC5890] form.

Done

>     s/prevents/removes the need/

Done

>         s/U-label use/U-labels are encoded as/

Done

>         s/with/in/

Done

> >    specified by section 2.3.1 of [RFC5890] and SHALL be restricted to

Done

>         s/encode/include/

Done

> all-ASCII labels?

Yes.

> Or ASCII characters generally, possibly in
> U-labels?

ASCII + UTF8 would interpret that as a U-label

> What are "NR-LDH restrictions"?  I did not see any such

The reference is for section 2.3.1.  There NR-LDH stands for Non-Reserved
Letters Digits Hyphen which is intended to exclude A-label and like
encodings.  I've spelled out NR-LDH and make mention of the intent.

> This makes no sense at all, and should probably be removed.

I've tried to clean up the intent here, which is to say that two

> Surely there's no need to drag in any mention of envelopes.

It seems there is IETF history here on envelope vs RFC822 email addresses,
and rather than revisit this, this document tries keeps the intent of the
rfc822Name as precedence.

> If there is no ABNF construct elsewhere that gives just the desired

I think the intent is more clear adopting existing ABNF.  What do other
folks think?

>         s/described/to be described/

Done

>         s/its section/<reference to section in question>/

Done

>         s/containts UTF-8/contains non-ASCII characters/

Done

>      rfc822Name (and not SmtpUTF8Name).

Done

> This is not sufficiently compelling to be mentioned.  Please remove.

Done

> >    excludes any "mappings" mentioned in that document).

Done

>         s/excludes/avoid/

Done

> Done

>         s/SmtpUTF8Mailbox/SmtpUTF8Name/

Done

>         s/GeneralName is/these are/

Done

> This is a lot of words to say very little or nothing at all.   Delete

Done

> domain-part step and a local-part step".

Done

>         s/local-part/local-parts/

Done

>         s/domain/domain-parts/

Done

> comparison may be required.

Enforcing insensitivity is done by lower casing the NR-LDH labels mentioned
in Section 3.

> Why are we descibing comparisons that
> don't happen?
>

Agreed but as you point out out next there are a number of scenarios.  As
you mention, this is meant to cover SmtpUTF8Name comparison to EAI header
email address, and comparison of certificate to certificate whose email
addresses may be in three different forms.  This intentionally looks for
content differences (as opposed to format differences) to be sure there is
in fact a difference.

> So "other email address forms" is not correct.

Changed to "Comparison with email addresses"

> >    A-label only forms such as rfc822Name.

Simplified.

> Why the parenthetical comment?

This serves two purposes- 1) points to a A-label normalization form setup
in case that's desired 2) documents the 5280 normalization.  The later is
the only part that I believe is necessary.  I  see your point about
confusion, so I've pull the reference into the previous paragraph where it
acts as a more specific reference.

> And we don't specify the process

Done

>         s/the A-label/any A-labels/

Done

>         s/U-label/U-labels/

Done

> Given the below, I don't see any need for the above.

An earlier review comment requested citing those documents to provide
context.

> >    1.  If the domain contains A-labels, transform them to U-label.

Done

> nothing to do (or that can be done) in this step.

Done

> >    This specification expressly does not define any wildcards characters

Done

> >    through SmtpUTF8Name, the certificate SHOULD use multiple

Done

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

---

From: Wei Chuang <[email-masked]>
Date: Mon, 19 Jun 2017 12:51:31 -0700

Thanks Viktor for the detailed review.

-Wei

Done

> What's a "compatible name constraint representation"?  Either

Deleted

> mention of enforcing email name constraints against the subject DN.

I do agree that dropping subject DN is a good idea.  Other opinions?  (I
left in for now)

> that this sentence is design rationale, not a protocol requirement.

Its defining a "SmtpUTF8Name aware path validator".

Done

>      rfc822Name constraints with a local-part MUST NOT be used.

Done, thought the MUST NOT is changed to SHOULD NOT to allow a transition.
I am worried that there may have been some use of name constraint w/local
part email address, and this would cause unforeseen breakage.

Done

> Delete, and instead describe the actual process.

Expanded.

>         alternative names in the end-entity certificate.

Noted above.

Done

Done.

Done

Done

Done

Done

---

From: Russ Housley <[email-masked]>
Date: Fri, 30 Jun 2017 12:28:48 -0400

With the posting of draft-ietf-lamps-eai-addresses-12, I believe that all WG Last Call comments have bee resolved.  I will notify our Area Director that the document is ready.

Russ

> On May 26, 2017, at 3:37 PM, Russ Housley <[email-masked]> wrote:
> 
> This is the LAMPS WG Last Call for "Internationalized Email Addresses in X.509 Certificates” <draft-ietf-lamps-eai-addresses-10>.  Please review the document and send your comments to the list by 9 June 2017. 
> 
> Thanks,
> Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 30 Jun 2017 19:18:51 +0000

On Fri, Jun 30, 2017 at 12:28:48PM -0400, Russ Housley wrote:

> With the posting of draft-ietf-lamps-eai-addresses-12, I believe that all
> WG Last Call comments have bee resolved.  I will notify our Area Director
> that the document is ready.

Indeed, grammar issues aside, which I expect will be addressed by
the RFC editor, looks largely done to me.  It'll soon be time to
resume work to support the new name type in OpenSSL.  This time
with rfc822Name name constraints applied to both rfc822Name and
SMTPUtf8Name subjectAltNames.

My only technical quibble is that I'd have preferred to also see
deprecation of support for email addresses in the subject DN,
subject altnames have been broadly supported for a long time.  This
is a non-critical issue.  If there's not broad support for doing
that at this time, I have no substantial issues with the -12 draft.

-- 
	Viktor.

---

From: Russ Housley <[email-masked]>
Date: Fri, 30 Jun 2017 15:21:23 -0400

> that at this time, I have no substantial issues with the -12 draft.

If you can get some CAs to support that position on list, then I think we can work on an update to RFC 5280 in that direction.

Russ