[Top] [All Lists]

Re: The address-in-certs issue

1997-12-22 05:56:08
This proposal will potentially force different certs for different uses:
one for email (SMTP) carrying an email address, and one for each other use
which sets a policy. This is certainly not desirable in the community I

There has been much discussion on this list about this issue, and many have
pointed out that there are valid reasons for the 'From' address not
matching the identifier in the cert: using a different account to send,
gateways, services which allow one to have a single mail address, etc. 

It seems clear to me that what is important is to PRESENT to a user
whatever identifiers are in a cert, and not make a decision for the user. I
know of email addresses like 'abc@<domain>', where 'abc' is not very
descriptive; in a case like this, I might also like to see other
identifiers in the cert which give me some additional clues as to who this is.

I suggest:

"S/MIME receiving agents that get signed messages from SMTP MUST alert the
recipient as to the validity of the signature and MUST present the subject
identifiers from the certificate as the signer of the message."

A cert which can be used in email will be just as valid for use in Web
authentication, or to sign and verify some data or software, or for any
other uses. At the same time, the mail recipient will be informed
unambiguously as to the signer of the message.

Elliott Ginsburg

At 10:10 AM 12/17/97 -0800, Paul Hoffman / IMC wrote:
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

Elliott N Ginsburg

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