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

From: "Jim Schaad" <[email-masked]>
Date: Fri, 13 May 2016 22:25:35 -0700

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.)

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.

3.  A section on name constraints is needed in this document similar to the
text in section 4.2.1.10 in rfc 5280

Jim

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 May 2016 10:42:42 -0400

> text in section 4.2.1.10 in rfc 5280

Yes, indeed.  I think it is pretty clear what needs to be there, but it does need to be added.

Russ

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 21 May 2016 21:51:41 +0100

Hi Jim,

> done the name would also need to be adjusted.)

Yes, I will post draft-melnikov-spasm-...-00.

> 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.

> text in section 4.2.1.10 in rfc 5280

So are you suggesting something like the following:

   A name constraint for Internationalized Email addresses MAY specify a
   particular mailbox, all addresses at a particular host, or all
   mailboxes in a domain.  To indicate a particular mailbox, the
   constraint is the complete mail address.  For example,
   "[email-masked]" indicates the root mailbox on the host
   "example.com".  To indicate all Internationalized Email addresses on
   a particular host, the constraint is specified as the host name.  For
   example, the constraint "example.com" is satisfied by any mail
   address at the host "example.com".  To specify any address within a
   domain, the constraint is specified with a leading period (as with
   URIs).  For example, ".example.com" indicates all the
   Internationalized Email addresses in the domain "example.com",
   but not Internationalized Email addresses on the host "example.com".

Or is it possible to just say that name constrainst for Internet Email
addresses just apply to Internationalized Email addresses?

Or do you think the document needs more text (or different text)?

Best Regards,
Alexey

---

From: Sean Leonard <[email-masked]>
Date: Sun, 22 May 2016 09:11:50 -0700

> On May 21, 2016, at 1:51 PM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Jim,
> 

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

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 22 May 2016 20:33:48 -0700

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Sean Leonard
> Sent: Sunday, May 22, 2016 9:12 AM
> To: [email-masked]
> Cc: Alexey Melnikov <[email-masked]>
> Subject: Re: [Spasm] comments on draft-ietf-pkix-eai-addresses-01
> 
> 
> >> republished if we are planning to use it as a starting point.  (If
> >> this is done the name would also need to be adjusted.)
> >
> 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.)

I am not sure what you are saying is going to be covered by the removal of the text and what is not covered by the removal of the text.  I am worried that you are starting to move from the world of email addresses to NAI forms that are used by systems such as RADIUS, but we are labeling this as being an email address form.

I am not sure that I understand the reason that you are distinguishing between deliverable and non-deliverable addresses in this field.  Do you have an application in mind where non-deliverable addresses are needed?

Jim

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

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 22 May 2016 20:33:48 -0700

> From: Spasm [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: Saturday, May 21, 2016 1:52 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
protocol and
> not as used in similar slots in From/To/Cc/Bcc header fields. Suggestions
how to
> make this clear are welcome.
> 

My preference would be to delete the text; I don't think that it adds
anything to the text.  I do however thing that you might want to remove the
brackets from the token name in the text as that is part of the definition
of email addresses in some places.

I am worried about the following case and I think that text needs to be
added for it.  One can encode the address as [email-masked] or
"joe"@example.com .  Both of these addresses are legal, but if you do a byte
comparison between them they will not compare.  

> 
> > 3.  A section on name constraints is needed in this document similar
> > to the text in section 4.2.1.10 in rfc 5280
> 
addresses
> just apply to Internationalized Email addresses?

I don't think you can just punt this because of the difference in the
encoded name.  While I think that the rules are going to be the same, the
actual structure defined in general name is going to be different.

Jim