Serge Knystautas wrote:
> Noel J. Bergman wrote:
> > We agree on the necessity of verifying the sender address as a predicate
to
> > stopping spam.
> Agreed, and maybe even that server signing is a good idea.
Yes.
> > Another issue is that the very thing you want, which we can get from
S/MIME,
> > is something that other people don't want. I have maintained for years
that
> > anonymity on the net is what empowers the behaviors we find
objectionable.
> > Others believe that anonymity == privacy.
> I'm not sure how S/MIME provides that. Can you expand on that?
If I sign a message, I am applying an operation with my private key. In
order to reverse it, you need my public key, which will have a chain telling
you who the Certificate Authority is that issued it. If you trust them to
authenticate me before issuing the key pair, then since my private key is
reversable only by my public key, you can know that the message was indeed
signed by me, an entity with an authenticated identity.
General principles of public key encryption:
Signed message:
Send: Sender's private key applied to either message or message digest,
Recv: Sender's public key applied, verifying sender.
Private message:
Send: Receiver's public key applied to entire message,
Recv: Only the receiver has the private key necessary to read.
Making something private after signing hides the true identity of the signer
to anyone except the recipient.
I don't think we're disagreeing about any of this, simply discussing how to
apply it.
> However, I think the approach of server signing does a lot to provide
> anonymity.
Relatively so. The question then becomes how much you trust the server to
authenticate who actually sent the message. If you have a server-signed
message from [EMAIL PROTECTED], your server is essentially accepting the
liability of saying that, indeed, this message came from the CEO and no
other.
> you want a team or a server to be the sender, yet still be able to assure
> everyone is was sent from Microsoft or AOL's customer service and not
> some password stealer.
There is nothing that prevents that from happening with the PKI. That is a
perfectly valid use, in my view.
> > Well, I don't do it because generally people don't care, and it doesn't
work
> > with an archiver
> >
(http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]
he.org&msgNo=7146&raw=true).
> > And we've already talked about why most people lazily accept the status
quo.
> Right, I had forgotten about that... archiving is another reason S/MIME
> sucks.
I'm not sure if that is necessary, or just typical. The S/MIME spec isn't
always easy reading, and I haven't had time to go into it in too much depth.
One thing that I'm not finding in the RFCs, but have read about in general
PKI articles, is the use of a signed digest rather than encrypting the
entire message.
> > In any event, if you want to propose a variation of S/MIME where we
attach a
> > signed digest made from some selection of the RFC 2822 headers, subject
and
> > body content (other than the digest part), and promote it, that's OK
with
> > me.
> Yes. I would like to propose one too... my half-formed thoughts were to
> have public/private key for an organization, using some headers (not the
> message content since that can change), create a hash, and store that as
> a message header.
That is reasonable. As I said, I seem to recall reading about a similar
technique in general articles on the subject, but I'm not seeing it in the
S/MIME RFCs.
S/MIME takes the opposite approach: you sign the content, not the headers,
since the headers can also change. The "compromise" is to sign (by
encapsulation) the key headers along with the content, and the envelope has
just the routing headers, e.g., the Received chain. And S/MIME uses body
parts instead of headers.
I don't see that there is any value to protecting the RFC 822 headers
without also protecting the content. So what if I take valid headers and
replace the content with spam? That is the same problem with querying a
server to know if the sender address was valid. The address may be good,
but not the content.
Perhaps a header could indicate that "X signed 0..N, Y added N+1..Z, and
signed 0..Z", it would allow verifying the original content and the mailing
lists's footer?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
