Okay. I think the direction then is to have SmtpUTF8Name respect rfc822Name name constraints and vice versa.
-Wei
On Wed, Mar 8, 2017 at 3:27 PM, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
> On Mar 8, 2017, at 6:07 PM, Wei Chuang <weihaw@xxxxxxxxxx> wrote:
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps- eai-addresses-07.txt
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.
_______________________________________________
Spasm mailing list
Spasm@xxxxxxxx
https://www.ietf.org/mailman/listinfo/spasm
<<attachment: smime.p7s>>