Phillip M Hallam-Baker wrote:
1) We define a new OID with semantics 'Authenticated header'.
This is solving a different problem, that of an intermediary modifying
the headers. The problem the email-in-certs issue is trying to solve is
that of a signer misrepresenting their identity to the recipient.
The problem here is that many clients do not expose the email
address itself to the user. A user may legitimately have more than
one email. Thus there is disagreement as to whether email
address is necessarily a good signifier to use to establish
identity.
I tend to think it is a good signifier to use for identity since on
the Internet it may be considered the primary name... On the
other hand it appears overly restrictive to insist on its inclusion
in the cert.
Note that even if one is using HTTP as a transport for S/MIME
the email address is likely to be needed. The point of using
S/MIME in this way would be to support transaction layer
security, the principle advantage of which (over SSL) is that
it allows support for asynchronous communication models.
I would expect that a system using S/MIME in this way would
involve interleaved SMTP and HTTP responses.
Note also that if we really are interested in HTTP support we
have to consider it explicitly. There is a vast installed base
of HTTP infrastructure which cannot be ignored but which
does not support MIME. If we really want to support HTTP
we should consider specifying an opption to sign an HTTP
message using a detached PKCS#7 signature block carried
in a header.
Perhaps we can resolve the issue by saying that clients MUST
recognize the email address extension in the certificate if it
is present and not require anything more.
Phill