S/MIME,Another issue is that the very thing you want, which we can get fromthatis something that other people don't want. I have maintained for yearsobjectionable.anonymity on the net is what empowers the behaviors we findOthers 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.
Yes, yes, I know how PK stuff works. Was just asking how anonymity support is already provided by S/MIME. I don't think that's what you meant though.
Making something private after signing hides the true identity of the signer to anyone except the recipient.
That's less anonymity, not more. You're confusing transport security with anonymity. Anonymity is the desire to send someone a message without them knowing who sent it.
I don't think we're disagreeing about any of this, simply discussing how to apply it.
Sure, understood.
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.
No, I don't think that's the question. :) In fact trying to ask that question is how most email implementations fail, IMHO. You have to let the Perl hackers of the world decide HOW they know [EMAIL PROTECTED] is the CEO of lokitech.com. Put the burden, responsibility, and thus flexibility on the domain.
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.
What?? We already agreed nobody uses PKI because the lack of it is meaningless. This exactly negates PKI's ability to do this. Ok, I'm equating PKI with S/MIME, but I think that's a fair assumption.
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.
Yeah, as long as you don't have to attach disclaims, unsubscribe instructions, or ads on messages, this works.
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.
I'm trying to solve identity theft, not email security. I'm shooting for exactly 0% of a message to be protected.
If someone hacked the email server outside of some company's mailbox that was using this technique, and rewrote the body of every message, then they've got problems beyond what I'm trying to solve.
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?
Bill pointed out that you need to sign the entire content instead of just the email address because then you don't have enough encrypted/hashed data, and your key gets cracked quickly. This is why S/MIME uses body parts instead of just headers.
However, I think that has usage restrictions and isn't really an option. So the flip side is to use as many standard headers as possible, and then maybe add a bunch of "seed" headers. So your message hashing would calculate off of the following:
To: Cc: From: Message-ID: X-Mailer:
Then you add your seed headers: X-Auth-Garbage: ca09s87ec0a9w8ecakjwhecao9w8e7ca09w8e7c0a98we7c09a8 2k34jhlk13j4hrlkj3hf09a87d09v8a7234kljh34c97a098
Those fields plus your private key create a digest that adds this header: X-Auth-Digest: 1234567890123456
Maybe make it a 32 alphanumeric instead of 16... dunno. Maybe make it case-sensitive too since header data should remain case sensitive, and include some punctuation for fun.
Anyway, that's all I have now. Not very pleased with it yet. Again, not trying to protect the message (header or footer), not trying to help you authenticate, trying to allow a server/domain to sign messages, trying to make it very easy to validate. The last step is how to distribute the public key information, and I figure DNS is a natural for this.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
