Within the context of EDIINT AS2
http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-06.txt and the Gas
Industry Standard for Internet EDI, the sender and receiver ID's are allowed
to be DUNS numbers. Use of DUNS numbers makes comparison straight forward
(no concerns over case), it's just a ASCII integer. Obviously DUNS numbers
don't work well in inter-personal identification, but seems to work fine in
B2B scenarios.
Dick Brooks
www.8760.com
-----Original Message-----
From: owner-ietf-smime(_at_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)imc(_dot_)org]On
Behalf Of Greg Colla
Sent: Thursday, November 04, 1999 3:46 PM
To: ietf-pkix(_at_)imc(_dot_)org; ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comparing rfc822 addresses to certificates
Bob's e-mail has triggered a couple of other issues with RFC822 addresses
and certificates that have been doing the rounds here.
Does it need to be an RFC822 address?
Probably not. Here's an example. A closed user group that are using a
proprietary mail system wish to use S/MIME. In this case, each user's
proprietary mail address would be sufficient in both the certificate's
subjectAltName field and message's From address fields for the sender/signer
comparison.
Does there need to be a comparison?
Definitely yes. We need to ensure that the recipient is warned that the
signer is not the sender, even though the message can be verified.
Are there exceptions?
Also yes.
1. Quite often when companies change name or merge, each user will be given
another e-mail address. to make the make PKI system more useable, we don't
want to enforce key and cert rolling for the whole organisation - they
probably have enough problems without us adding to it ;-)
One solution is that the users associate secondary addresses to
certificates. This must be a secure association, the user will know if it
has been tampered with. If a message is received where the sender's address
is equivalent to the address in the cert, or an address associated with the
cert, then no warning is given.
2. Domain signing. In some installations, a domain gateway is used to sign
on behalf of the sender as it exits the domain. In this case, the address in
the domain's signing cert won't match the originator's address. (Refer to
the DOMSEC draft for further info). The receiving client needs to compensate
for this. There are various work-arounds for this, including (A) the
generation of certificates on-the-fly, each with the same public key, but
different e-mail addresses, (B) association of users' addresses with the
domain's certificate on the recipient's client and (C) the DOMSEC methods.
3. Countersigning and co-signing. This is a big enough issue by itself and
can be left for a later date.
So the conclusion is that there should be a sender/signer comparison,
although the comparison may not be direct.
Greg
-----Original Message-----
From: Bob Jueneman [mailto:BJUENEMAN(_at_)novell(_dot_)com]
Sent: Friday, November 05, 1999 5:35 AM
To: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz;
ietf-pkix(_at_)imc(_dot_)org
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Comparing rfc822 addresses to certificates
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