Phillip Hallam-Baker wrote:
There is a missing element in the S/MIME infrastructure, a mechanism that
tells email senders the policy of the receiver.
[..]
I think we really need an S/MIME v4
(sigh)
No, what we need are better implementations.
This is what I expect RFC 4262 is for but:
RFC 4262 simply stuffs S/MIME caps into a cert extension. Which has its own
drawbacks though but should be discussed another time.
1) I don't think there is a capability defined for 'I prefer encrypted
email'
No need for that, or it's at least another topic.
2) Working out the capability for 'I support AES-256' requires unreasonable
effort.
Seamonkey and Thunderbird MUAs already send the OID for AES-256 in the S/MIME
caps. But they always use 3DES when sending S/MIME messages.
There are still S/MIME libraries out there that only support 3DES, even
when the library itself has AES.
And that's exactly the point:
If I want to convince developers to put effort into their implementation to
actually look at S/MIME caps and choose a better cipher it would be nice to
point at an RFC as a good argument. But the current text does not give any
argument at all to support anything else than 3DES.
=> the wording is bad
Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime