Anders Rundgren wrote, On 2008-11-22 02:12: > The following is related to the S/MIME discussions.
Anders, here are your choices: You may either have a) encryption using authenticated keys or b) encryption using unauthenticated keys. Certificates are used for authenticated encryption. If you don't want authenticated encryption, you don't use certificates. It's that simple. The idea of producing phony certificates, so called "self signed" certificates, or certs from "pseudo CAs" is an attempt to force unauthenticated keys into a system whose ENTIRE and SOLE purpose is to authenticate keys, and avoid the use of unauthenticated keys. If you want to design an application protocol that uses purely unauthenticated keys (and it appears that you do), then design it to not use certificates at all, but to simply use unauthenticated keys. Yes, there are application protocols out there that do that. They're vulnerable to Man in the middle attacks, but that's the price you pay for choosing to use unauthenticated keys. SSL supports the use of unauthenticated "bare" keys, without any certs. If that's what you want, go for it. But first consider the capabilities of authenticated keys carefully. There's absolutely NOTHING that says that in every application protocol, key authentication must be tied to DNS names. The decision to bind keys to DNS names is a decision made by the designers of the https application protocol, and it fits their model, where contact is initiated based on a DNS name. But for other applications, where contact is NOT initiated based on DNS name, binding of keys to DNS names in meaningless. In other applications, which identify end points with identities in other spaces besides DNS names, authentication of keys requires binding them to what ever identities are used by that application. That's why authenticated email encryption protocols don't bind to DNS names, they bind to mailbox names (email addresses). There's a certain world-wide instant messaging service that offers file transfer capabilities. It has the ability to offer authenticated and encrypted IM and authenticated and encrypted file transfer. It uses S/MIME for the IM and SSL for the file transfer. Every one of its clients offers both. It doesn't require that certs have DNS names in them, because users identify each other through names that are not DNS names and are not mailbox addresses. The certificates that the users use to authenticate each other for the S/MIME based IM service are the same certificates used for the SSL file transfer. The reasoning is that when you've determined the certificate of the party to whom you're IMing, and you want to do file transfer, you know that you want to transfer your files to the same party to whom you've been IMing. So, the very same cert used to identify the party for IM is the cert used to identify that party's SSL server. When the SSL client connects to the peer's SSL server for file transfer, it checks to see that the cert is the same cert used in the IM. It does not check for a DNS name or an email address. It checks that the cert is the very same cert. This is SSL peer-to-peer. In this system, there are servers that act as relays between the IM endpoints, and also between the SSL endpoints (if necessary desired). Those servers don't decrypt anything (they can't). They just pass the traffic through from one end to the other. All encryption is end to end. If one peer is able to receive incoming connections (many are not) then one client can connect directly to the other over the internet, bypassing the IM servers for file transfer, but if the receiving party cannot receive incoming connections, it connects to the IM servers, and the file transfer takes place through the IM server. It's still end to end encryption. The IM servers don't decrypt anything because a) they don't have the keys, and b) it would be way too slow anyway. The clients all require certs from real CAs, Self-signed certs are not an option, but there are no predefined requirements on what cert names must contain. The UI clearly presents the peer's cert name to the user and the user must decide if that is a name with whom he wants to IM (or file transfer) or not. This system has been around for years. The clients all use NSS for all the SMIME IM messages and for all the SSL file transfers. Works with any cert issued by any of the CAs in Mozilla's list. I use it every day. Chances are good that you do too. It's the worlds largest IM network. If you have your own cert, such as (say) an email cert, and would like to try secure IM over AOL's instant messenger network, write to me off list. Please don't waste any more time talking about "pseudo CAs". That's pointless. If your application wants unauthenticated keys, then use them and don't bother with certs. My long standing objection to self signed certs is not an objection to unauthenticated encryption (although I have no use for unauthenticated encryption), but rather is an objection to trying to force the system whose sole purpose is to prevent/avoid unauthenticated keys from being used a a way to distribute unauthenticated keys. Did you know there's even an RFC proposing the use of opportunistic encryption over http (not https)? It can use either authenticated or unauthenticated keys. No publicly offered clients or servers in the world (known to me) implement it, and it has some real problems with proxies because proxies must encrypt and decrypt at every stage (hello MITM) but hey, that's no objection to people who want unauthenticated encryption. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
