Subject: [pkix] Looking for some clarification on how to correctly specify rfc822Name constraint for an X.509 certificate

From: "martijn.list" <[email-masked]>
Date: Sun, 17 Aug 2014 15:04:40 +0200

Recently we noticed that an end user S/MIME certificate was not
validated by our encryption gateway. The certificate in question was
issued by an intermediate certificate (which was again issued by a
Quovadis root) that contained an rfc822Name constraint. The rfc822Name
constraint was specified as follows:

@example.com

RFC 5280 specifies the format for rfc822Name constraints as follows:

"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
"example.com".  To indicate all Internet mail 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 Internet mail
addresses in the domain "example.com", but not Internet mail
addresses on the host "example.com"."

(http://tools.ietf.org/html/rfc5280#section-4.2.1.10)

So the way I read this is that a constraint for the domain example.com
should be specified as

example.com

and not as

@example.com

This might explain why our Java based software refuses to validate the
end user certificate since [email-masked] does not match the
@example.com constraint. Adding an @ symbol will also be problematic
when using the .example.com domain constraint since that would then
result in @.example.com.

To confuse things even more, Microsoft seems to mix the two options.
They use @example.com for constraining to the example.com domain but
.example.com for matching sub domains:

"UPN name constraints should always be entered as two separate entries
in the list of name constraints. One entry should include the ampersand
character (such as @nwtraders.com); the second entry should replace the
ampersand with a period (.), so this entry would be .nwtraders.com. This
format allows for the possibility of having a UPN of
subdomain.nwtraders.msft."

>From http://technet.microsoft.com/en-us/library/cc737026%28v=ws.10%29.aspx

Is there any consensus on what the correct format is according to RFC 5280?

Are there other implementations that use @example.com instead of
example.com for rfc822Name constraints?

Kind regards,

Martijn Brinkers

-- 
CipherMail email encryption

Open source email encryption gateway with support for S/MIME, OpenPGP
and PDF messaging.

http://www.ciphermail.com

Twitter: http://twitter.com/CipherMail

---

From: "martijn.list" <[email-masked]>
Date: Fri, 22 Aug 2014 10:08:36 +0200

Since I did not get any response, I guess my question was not clear or I
should ask somewhere else. Any idea where to ask for some clarification
on rfc822Name constraints (see below).

Kind regards,

Martijn Brinkers

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 22 Aug 2014 12:04:06 +0200

In my view, there's no confusion in RFC5280. "@" is not required/accepted
in a rfc822Name element.
The fact that Microsoft choses another format for otherName:UPN does not
change the rfc822Name semantics (while validating against NameConstraints).

2014-08-22 10:08 GMT+02:00 martijn.list <[email-masked]>:

> >>From
> http://technet.microsoft.com/en-us/library/cc737026%28v=ws.10%29.aspx
> >

-- 
Erwann.

---

From: Tom Gindin <[email-masked]>
Date: Tue, 26 Aug 2014 22:31:40 -0400

Erwann:

        That's not my reading of the section.  Three different cases are 
given for rfc822Name constraints, and the single-mailbox one contains an 
embedded at sign.  However, none of them start with an at sign.  It's 
pretty clear that the improper constraint in the example was intended to 
be equivalent to the domain-name-only format with no leading period, and 
should thus have been encoded with the at sign missing.  No compliant RP 
is required to interpret it, of course.

                Tom Gindin

From:   Erwann Abalea <[email-masked]>
To:     "martijn.list" <[email-masked]>
Cc:     "<[email-masked]>" <[email-masked]>
Date:   08/22/2014 06:04 AM
Subject:        Re: [pkix] Looking for some clarification on how to 
correctly specify rfc822Name constraint for an X.509 certificate
Sent by:        "pkix" <[email-masked]>

In my view, there's no confusion in RFC5280. "@" is not required/accepted 
in a rfc822Name element.
The fact that Microsoft choses another format for otherName:UPN does not 
change the rfc822Name semantics (while validating against 
NameConstraints).

Kind regards,

Martijn Brinkers

-- 
Erwann. _______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix