I don't think the question is whether RFC822 syntax identities are useful
for S/MIME; I think the issue is whether this identity must match the From
header address. A message on the list yesterday did a very good job of
distinguishing between an SMTP delivery address and an identifier and the
many reasons why I may have multiple addresses. If the RFC822 syntax
identity is what a user or domain wants to use to represent to recipients
that user, no problem. But to require that this identifier match the actual
header address will break mail. Just to try to summarize some of the
reasons why there could be different From addresses:
- multiple email accounts
- changing email accounts
- use of mail forwarding services
- gateways
- LAN-based mail not using RFC822 syntax internally
- use of someone else's account or a temporary account (e.g., at IETF)
Many RFC822 syntax addresses are not very descriptive of who the user is; I
would like the option of representing myself with the kind of flexibility I
get with a DN. All I ask is that the identity I choose be presented to the
recipient so they will know who signed the message.
Elliott Ginsburg
At 01:57 PM 12/22/97 -0800, John Gardiner Myers wrote:
Elliott N Ginsburg wrote:
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.
Internet mail is the primary application for S/MIME. That is, if
Internet mail applications using S/MIME fail to interoperate, then the
S/MIME standard has clearly failed. This is not true for any other
application.
If the choices made in S/MIME make it useful for other applications,
then that is a bonus. There is every reason to think that RFC822 syntax
identities are usable for common Internet HTTP.
If some other application does not need to fully interoperate with
Internet mail, would like to use the bulk of S/MIME, but finds S/MIME's
requirements insufficient or inappropriate, then the thing for that
application to do is to *PROFILE* S/MIME, specifying whatever identity,
cipher, etc. requirements it needs instead of or in addition to the base
S/MIME standard.
Interoperability and generality are diametrically opposed.
Interoperability is Job #1. Generality is secondary.