Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01

[Sean Leonard <[e-mail]>]

> On May 21, 2016, at 1:51 PM, Alexey Melnikov <[e-mail]> wrote:
> 
> Hi Jim,
> 
> On 14/05/2016 06:25, Jim Schaad wrote:
>> 1.  This document has been expired for some time and thus should be
>> republished if we are planning to use it as a starting point.  (If this is
>> done the name would also need to be adjusted.)
> 
> Yes, I will post draft-melnikov-spasm-...-00.
> 
> 
>> 2.  The text about the format of an eaiMailbox name seems to be strange.
>> Specifically, the text about what it does not have deals with display
>> formats of an eaiMailbox and not it's format.
> 
> This is trying to make the point that the syntax is as used in SMTP
> protocol and not as used in similar slots in From/To/Cc/Bcc header
> fields. Suggestions how to make this clear are welcome.
> 
> If you think just deleting extra text is Ok, I can do that.

Actually (as the author of the new draft-seantek-mail-regexen-00) I disagree (fairly strongly) with this change.

rfc822Name is defined in terms of RCC 822 etc., not RFC 821 etc.

RFC 5321 imposes several restrictions on e-mail addresses, such as no C0 control characters (among other things), that are not present in RFC 5322 etc. The difference is that there are “e-mail addresses” and there are “deliverable e-mail addresses”. “Deliverable” in my definition means those that strictly conform to RFC 5321 etc., i.e., the “modern SMTP infrastructure”. But e-mail addresses as a class of identifiers, can include any character, including U+0000 NULL.

Actually however, a mail server *can* accept e-mail addresses outside the range of DEAs, as can systems that consume e-mail address identifiers for non-SMTP-mailing purposes (username identifiers, X.400 systems, etc.). In some cases it may be desirable to certify/use non-deliverable e-mail addresses for other purposes (compare, for example, with a PGP key with an e-mail address that an organization or individual uses “internally”, without any intent to receive e-mail at that address).

It is reasonable for a certificate to include the full range of e-mail addresses, not just “DEAs”. This is exactly analogous to the IP address fields in GeneralName: you can specify 0.0.0.0 or 255.255.255.255, even though those addresses are not “deliverable” (i.e., deliverable to a specific endpoint on the network). E-mail addresses that do not conform to RFC 5321, but do conform to RFC 5322, really should therefore be allowed.

I do agree with a restriction that says that e-mail addresses should be in simplified form, namely, have no extraneous whitespace and no comments. (RFC 5322 allows these but RFC 5321 does not; they do not add to the semantics of the identifier.)

Sean