[Top] [All Lists]

The address-in-certs issue

1997-12-17 11:08:26
I'd like to start a new thread on this so that we are all on the same page.
I'd like to be sure we all agree on the non-technical reasoning behind what
we're doing in S/MIME v2 and what we want to do in S/MIME v3.

We use a signature to say "I sent this". I believe that this group agrees
on the definition of "sent" and "this" for the context of S/MIME. The
question is who is "I", that is, the identifier of the signer.

In S/MIME v2, we use an RFC822 email address (user(_at_)domain) to be the
identifier of the signer. Email addresses can identify entities such as
people or other mail senders. Further, CAs can do some reasonable checking
before they certify the validity of and email address, such as verifying
that that email address can respond to a challenge about the signature.

Where we have a problem is when a recipent tries to validate "I sent this".
The validation step involves checking the "I" identifier in the signature
against something in the "this". However, the something against which they
would be checking is not authenticated: it's out in the commonly-spoofed
plaintext headers that precede the signed message, not in the authenticated
part of the message.

This is inherently a user interface issue. Because S/MIME messages can be
carried in non-email systems, requiring the "I" identifier to match the
spoofable headers is clearly wrong. Even in email, because the headers that
are checked against are suseptable to both spoofing and munging by
gateways, we cannot force actions based on the comparision of the signature
address and the headers.

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
- S/MIME receiving agents that get messages from SMTP SHOULD check the
email addresses in the signatures and certs of the message against the
From: and Sender: headers of the message, SHOULD have a policy about what
matches and doesn't match, and SHOULD alert the recipient if the address in
the identifier and the header(s) don't match
- Non-email agents SHOULD have a policy about what the content of the
identifier is, SHOULD have a policy about what matches and doesn't match,
and SHOULD have a policy about what to do if the addresses don't match
- A detailed description of the logic of the above has to appear in the
body of the -cert draft, and a warning about it has to appear in the
security section


--Paul Hoffman, Director
--Internet Mail Consortium

<Prev in Thread] Current Thread [Next in Thread>