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.
Let me put the issue this way: Internet identities have RFC822
local-part(_at_)domain syntax. The semantics of these identities are
understood by end-users. These identifiers are applicable to any
Internet protocol, not just mail.
I don't buy that RFC822-syntax identities are more likely to change than
In order for S/MIME agents to interoperate, receiving UA's need to be
able to present an identity of the signer to the user in a manner that
is simple and comprehensible. This is not going to work if UA's have to
deal with presenting two entirely different syntaxes for identities,
especially if one of them is as complex as the DN syntax. What is more
likely is that UA's are going to have to add a subsystem to map
DN-syntax identites to RFC822 identities and UAs are going to be far
less likely to get the security issues of this mapping right than the
far fewer and better equipped CAs.