From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
I propose the following:
- There will be no base-level interoperability statement for the content of
the identifier: it's up to the application using S/MIME
- S/MIME messages that are to be sent through SMTP MUST have the identifier
be an RFC822 email address, and any cert that goes with that message also
MUST use an RFC822 email address
Paul, the content of the cert is the crux of the issue. I agree with the
many recent comments that email addresses should not be required or even
recommended in the cert at all, irrespective of any S/MIME User Agent
requirements.
Reasons include 1) the more information that goes into a cert, the shorter
the expected lifetime, 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), 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.
One topic that came up on the PKIX list many months ago was the use of
RFC822-style strings as identities. It is quite reasonable that some
people might find RFC822 names to be more comfortable than DNs, and it
might even be reasonable for CAs to issue certs to RFC822-style identities,
whatever it means to certify something like that.
But an RFC822 identity is a completely separate thing than an SMTP delivery
address - there are forwarding services now that let you keep the same
identity regardless of how often you change ISPs. Doing any sort of
checking of an SMTP delivery address against an RFC822 identity, if it exists,
will often be futile (more than one account, kiosks/friend's account/IETF
terminal room, address-munging gateways/listservs, etc).
Requiring or recommending the existence of an RFC822 identity in certs
solely for the purpose of enabling a check against a totally volatile
delivery address is not warranted.
Dave Kemp