BJUENEMAN(_at_)novell(_dot_)com writes:
Contrary to how most public CAs do it, at least so far, the e-mail address is
included in the subjectAltName as per the PKIX RFC, and to our pleasant
surprise all of the e-mail packages we have encountered to date have been
able to handle that format correctly.
Although we could have, we chose not to include an e-mail address of the form
subjectAltName="Robert R. Jueneman" <bjueneman(_at_)novell(_dot_)com> , in
part because
most e-mail packages would just as easily accept "President William Jefferson
Clinton" <bjueneman(_at_)novell(_dot_)com>.
D'you mean they'll accept that as an rfc822Name? Are they supposed to do that?
Peter.
Let me clarify that. I haven't tested that exhaustively across multiple
packages, but I believe that e-mail packages generally ignore the "junk"
prior to the rfc822 mailbox name itself, both on message origin and
message receipt.
Many packages I am familiar with allow you to specify your own From address
one way or the other, even though you may not be able to change the
portion of the address within the angle brackets.
They may or may not reflect that name in the From address that is
presented in the message window or header line, but I believe that most do.
Certainly it appears that you can put anything you wish in front of the
address, and the message will be both sent and received successfully.
That being the case, I doubt that many would complain about a
mismatched rfc822 address in the certificate in that case, but I don't
know that for a fact.
Now, SHOULD they? Honestly, I'm not sure.
Browsing through rfc822, I find the following snippets of definitions:
4.4.1. FROM / RESENT-FROM
This field contains the identity of the person(s) who wished
this message to be sent. The message-creation process should
default this field to be a single, authenticated machine
address, indicating the AGENT (person, system or process)
entering the message. If this is not done, the "Sender" field
MUST be present. If the "From" field IS defaulted this way,
the "Sender" field is optional and is redundant with the
"From" field. In all cases, addresses in the "From" field
must be machine-usable (addr-specs) and may not contain named
lists (groups).
6.1. SYNTAX
address = mailbox ; one addressee
/ group ; named list
group = phrase ":" [#mailbox] ";"
mailbox = addr-spec ; simple address
/ phrase route-addr ; name & addr-spec
route-addr = "<" [route] addr-spec ">"
route = 1#("@" domain) ":" ; path-relative
addr-spec = local-part "@" domain ; global address
local-part = word *("." word) ; uninterpreted
; case-preserved
domain = sub-domain *("." sub-domain)
sub-domain = domain-ref / domain-literal
domain-ref = atom ; symbolic reference
phrase = 1*word ; Sequence of words
word = atom / quoted-string
Parentheses ("(" and ")") are used to indicate comments.
So ignoring the optional route indicator, which I haven't seen used
for at least five years, and excluding groups as required by the
semantics of From, we have as an allowable From address:
address = mailbox
mailbox = addr-spec /
phrase route-addr
route-addr = <addr-spec>
Unfortunately, the semantics of "phrase" or "word" don't seem
to be defined, but the implication seems to be that they are the name of
the originator in the case of a From or Sender field, and the name or
name of the desired recipient(s) in the case of a To or Cc field. This of
course gets even more complicated in the case of a shared mailbox,
as might be the case for a family.
Since the form of the "name" isn't defined, I have to assume that
"phrase" is essentially syntactic sugar, to be interpreted by the
human user.
So I conclude that the following are all legitimate rfc822 From addresses:
kent(_at_)bbn(_dot_)com
Steve Kent(_at_)bbn(_dot_)com
Stephen Kent(_at_)bbn(_dot_)com
Also,
Bob Jueneman <bjueneman(_at_)novell(_dot_)com>
"Robert R. Jueneman" <bjueneman(_at_)novell(_dot_)com>
Robert "R." (Bob) Jueneman (the one who is not the
horse thief) <bjueneman(_at_)novell(_dot_)com>
However, as a message from Tom Gindin points out (and
I'll take his word for it without checking the text of RFC
2459 section 4.2.1.7), PKIX defines an rfc822 attribute
within GeneralName as an addr-spec, NOT an "address".
The S/MIME spec also states that the end-entity certificates
MUST contain an Internet mail address, and that the
address must be an "addr-spec" as defined in Section 6.1.
X.509, however, is ambiguous, and needs to be corrected.
So that seems clear, now. The above constructs would NOT be
legal as an rfc822 type DN or subjectAltName, although I strongly
suspect that many CAs and CA toolkits would accept them and
create certificates containing them.
Unfortunately, this leaves us with the case where the e-mail
package, if it performs correctly, will accept a message with
a From address of
From: "President William Jefferson Clinton "
(note the extra spaces, intended to cause truncation of the
name -- it's really slick Bob in disguise) <bjueneman(_at_)novell(_dot_)com>
and then it will compare just the <bjueneman(_at_)novell(_dot_)com> to the
subjectAltName in my certificate and conclude that all is well,
since the addr-spec in the From matches the content of the attribute
in the certificate.
Worse yet, since some mail programs don't bother to display
the "real" addr-spec, but only the name portion, and most will
truncate even the name if it's too long, the recipient may not see
that anything is amiss at all.
The S/MIME v2 Certificate Handling spec (3.1, last paragraph)
states that "... Receiving agents MUST check that the address (sic)
in the From header of a mail message matches an Internet mail
address in the signer's certificate. ..."
That's somewhat ambiguous, since the "address" portion of a From
address is clearly the more general mailbox name. But clarifying
the S/MIME spec by requiring that the addr-spec portion of the
From address match the addr-spec in the certificate would
merely highlight the problem, not solve it.
So we clearly have a problem where the relying party may be
accidentally or even deliberately mislead, unless he is particularly
careful to compare the full From address (which may only be
available by looking at the mime.822 view of the message) against
the certificate content.
What should we do? I'm not quite sure, but I'm concerned.
Bob