Subject: Re: rfc822name Name Constraints question

From: "Housley, Russ" <[email-masked]>
Date: Mon, 02 Sep 2002 11:26:19 -0400

Anne:

The email address name constraint contains the right-hand part.  So, any 
email address that exactly matches the right-hand part in the name 
constraint is valid.

>RFC3280 describes how name constraints for "Internet mail
>addresses" may be specified, but is unclear on a few points:
>
>1. If the NameConstraint is "[email-masked]", does that include
>    "[email-masked]"?

Yes.  The email address "[email-masked]" does satisfy the "[email-masked]" 
constraint.

>2. Can "@xyz.com" be used to match all mail addresses at
>    "xyz.com" but not addresses at "abc.xyz.com?

Yes.  The constraint "@xyz.com" would only be satisfied by mailboxes (or 
.forward entries) on the host xyz.com.

>3. The paragraph says the constraint "xyz.com" is satisfied by
>    "any mail address at the host "xyz.com", and ".xyz.com" is
>    satisfied by an address within the domain xyz.com, but not
>    xyz.com itself.  How then do I specify all addresses in the
>    domain xyz.com AND xyz.com itself?

The constraint "xyz.com" permits "[email-masked]" and "[email-masked]"

Russ

---

From: Steve Hanna <[email-masked]>
Date: Wed, 04 Sep 2002 15:39:34 -0400

"Housley, Russ" wrote:
> The email address name constraint contains the right-hand part.
> So, any email address that exactly matches the right-hand part
> in the name constraint is valid.
> 

I was surprised to see this answer. Here's the relevant text
from RFC 3280 (section 4.2.1.11):

   A name constraint for Internet mail 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 "xyz.com".  To indicate all
   Internet mail addresses on a particular host, the constraint is
   specified as the host name.  For example, the constraint "xyz.com" is
   satisfied by any mail address at the host "xyz.com".  To specify any
   address within a domain, the constraint is specified with a leading
   period (as with URIs).  For example, ".xyz.com" indicates all the
   Internet mail addresses in the domain "xyz.com", but not Internet
   mail addresses on the host "xyz.com".

I see no indication here that a constraint of "[email-masked]"
would be satisfied by the address "[email-masked]". It seems
that the RFC describes three cases:

1) If the constraint is a complete mail address, then it is
   only satisfied by that mail address.

2) If the constraint is a host name, then it is satisfied by any
   mail address at that host.

3) If the constraint is a host name with a leading period, it is
   satisfied by any address within that domain.

If my analysis is correct, a constraint of "[email-masked]" is only
satisfied by "[email-masked]" (or anything that matches using
case-insensitive matching, since email addresses are case-insensitive).
There's no way to specify a constraint that would match exactly the set
of all email addresses that end in "[email-masked]".

The text of the RFC doesn't seem to support your assertion:
"The email address name constraint contains the right-hand part.
So, any email address that exactly matches the right-hand part in
the name constraint is valid."

> .forward entries) on the host xyz.com.

Looking at the RFC, the interpretation of the mail address constraint
"@xyz.com" is not defined. It is neither a complete mail address, a
host name, nor a host name with a leading period. However, the constraint
"xyz.com" would accomplish Anne's goal here (matching all mail addresses
at the xyz.com but not addresses at abc.xyz.com).

> The constraint "xyz.com" permits "[email-masked]" and "[email-masked]"

Not according to the RFC as I read it. The constraint "xyz.com"
only permits "[email-masked]" and "[email-masked]", not "[email-masked]".
If you want to specify a constraint that matches all of and only all of
the mail addresses on host xyz.com and all of the mail addresses in
the domain xyz.com, then you'd need to specify two constraint, one
being "xyz.com" and the other being ".xyz.com".

Please explain to me how your interpretation of the RFC is supported
by the text. I don't want to make a federal case out of this, but I
also don't want people to be confused by an erroneous interpretation
of the RFC. And if I'm wrong (or the RFC is wrong), I'd like to know
about it.

Thanks,

Steve Hanna

P.S. Anne did not ask me about her question before sending it, in case
you were wondering. I was on vacation last week.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 4 Sep 2002 21:53:07 -0400

Steve and Russ:

X.509 requires that the name constraints be enforced on hierarchical
names only. I do not remember the RFC-822 chapter and verse, but I
thought items to the right of "@" are hierarchical and can be enforced.
I thought items to the left of "@" is a single address string.

In short, RFC 3280 should enforce hierarchical aspects of RFC 822 names.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Steve Hanna
Sent: Wednesday, September 04, 2002 3:40 PM
To: Housley, Russ
Cc: [email-masked]; [email-masked]
Subject: Re: rfc822name Name Constraints question

"Housley, Russ" wrote:
> The email address name constraint contains the right-hand part. So, 
> any email address that exactly matches the right-hand part in the name

> constraint is valid.
> 
> >RFC3280 describes how name constraints for "Internet mail addresses" 
> >may be specified, but is unclear on a few points:
> >
> Yes.  The email address "[email-masked]" does satisfy the 
> "[email-masked]" constraint.

I was surprised to see this answer. Here's the relevant text from RFC
3280 (section 4.2.1.11):

I see no indication here that a constraint of "[email-masked]" would be
satisfied by the address "[email-masked]". It seems that the RFC
describes three cases:

The text of the RFC doesn't seem to support your assertion: "The email
address name constraint contains the right-hand part. So, any email
address that exactly matches the right-hand part in the name constraint
is valid."

> Yes.  The constraint "@xyz.com" would only be satisfied by mailboxes 
> (or .forward entries) on the host xyz.com.

Looking at the RFC, the interpretation of the mail address constraint
"@xyz.com" is not defined. It is neither a complete mail address, a host
name, nor a host name with a leading period. However, the constraint
"xyz.com" would accomplish Anne's goal here (matching all mail addresses
at the xyz.com but not addresses at abc.xyz.com).

> The constraint "xyz.com" permits "[email-masked]" and "[email-masked]"

Not according to the RFC as I read it. The constraint "xyz.com" only
permits "[email-masked]" and "[email-masked]", not "[email-masked]". If
you want to specify a constraint that matches all of and only all of the
mail addresses on host xyz.com and all of the mail addresses in the
domain xyz.com, then you'd need to specify two constraint, one being
"xyz.com" and the other being ".xyz.com".

Please explain to me how your interpretation of the RFC is supported by
the text. I don't want to make a federal case out of this, but I also
don't want people to be confused by an erroneous interpretation of the
RFC. And if I'm wrong (or the RFC is wrong), I'd like to know about it.

Thanks,

Steve Hanna

---

From: Steve Hanna <[email-masked]>
Date: Fri, 06 Sep 2002 16:13:47 -0400

Santosh Chokhani wrote:
> thought items to the right of "@" are hierarchical and can be
> enforced. I thought items to the left of "@" is a single address
> string.

That's right. An rfc822Name is an RFC 822 addr-spec. To the
left of "@" is the local-part, which is a string with no
standard structure. To the right of "@" is the domain, which
has a hierarchical structure. These days, the domain is
generally a DNS domain name.

The domain has a hierarchical structure, so it makes sense for
RFC 3280 to allow you to specify only the uppermost portions
of the domain in a name constraint. The local-part has no
standard structure (although local domains could establish
their own structure). So it's good that RFC 3280 (at least, as
I read it) doesn't provide any way to specify a portion
of the local-part in a name constraint.

> In short, RFC 3280 should enforce hierarchical aspects of

Agreed.

-Steve