I don't see why everyone assumes that S/MIME equates with email. It is
likely to be carried over HTTP and there is an electronic commerce/EDI
group looking at it for use there.
At 02:50 PM 12/19/97 -0800, John Gardiner Myers wrote:
David P. Kemp wrote:
Reasons include 1) the more information that goes into a cert, the shorter
the expected lifetime,
Then take out other information. RFC822 identities are what are used in
Internet Mail, and if you're securing Internet Mail objects, those are
the identities you need to certify.
2) additional burdens on CAs/RAs to validate email
addresses (in cases other than the zero-assurance certs which are issued
to email addresses, not people),
If you remove this burden from CAs/RAs, you just move the burden to
UAs. There are far more UAs in the world than CAs, and UAs are far less
well equipped to deal with validation tasks than CAs.
and 3) it's not clear that the user agent
can do anything at all useful with an email address in a cert, given that
users should be allowed to change addresses, mail authenticated messages
from a friend's account, etc.
Technically speaking, if user A sends mail using user B's account, then
RFC822 states that user A's RFC822 identity belongs in the From: header
and user B's identity belongs in the Sender: header. If mail submission
agents become S/MIME aware, this could even work.
Elliott N Ginsburg