Justin Karneges wrote:
On Wednesday 20 August 2008 10:53:36 Dave Cridland wrote:On Wed Aug 20 18:43:32 2008, Peter Saint-Andre wrote:And that's not even to get into the Layer 8 issues of what the IETF security mafia might find acceptable -- RFC 3921 requires support for RFC 3923 and we need to substitute something reasonable for that ugly ugly S/MIME stuff that no one has ever implemented and no one ever will.Hmmm... Now probably not a good time to mention that we probably *will* need to have a per-stanza signing (and possible encrypting) spec in some cases, too. Luckily, these are all specialist cases, like signing pubsub items, MUC messages, etc. And, erm, security labelling. Because this is signature stuff, X.509 is basically our single weapon of choice here - we could do S/MIME, therefore, but even the people doing this stuff now aren't using S/MIME.I think the S/MIME approach really isn't as bad as it is made out to be. The ugliness with RFC 3923 is the fact that you have to convert message content to/from that weird email-ish CPIM format. The crypto part is sane, and we'd be hard-pressed to do better.
Sadly, I agree with you. It's the CPIM madness that is so ugly.
S/MIME uses the Cryptographic Message Syntax format (RFC 3852, PKCS#7) underneath, which can be used to sign/encrypt arbitrary binary blobs.
And I see that everyone on this security-conscious list signs their email with S/MIME...
Here's a pretty good rant of why S/MIME is better than xml-dsig: http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt
Isn't that like saying Hitler was better than Stalin? ;-) /psa
smime.p7s
Description: S/MIME Cryptographic Signature
