Nelson,
Thank you for your elaborate answer.
Naturally there is no problem to solve if everybody is connected to one of a
handful of IM providers. The purpose of my proposal was rather investigating
the possibility that each organization or ISP run their own secure messaging
server in about the same way they run mail-servers today, and without any
particular bias towards consumers, citizens, or employees. To achieve that you
need a scalable trust infrastructure otherwise you run into the situation we
have with secure email which has reduced it to a community-scale security
scheme.
Since there already are hundreds of thousands SSL certificates out there, each
one could serve as a poor mans CA for the domain they are *authoritative* in.
How these CAs enroll users would follow existing practices which are completely
up to the policy of the domain owner. AOL would presumably use
email-roundtrips, while your employer would likely based enrolment on Active
Directory.
That is, I'm definitely talking about authenticated keys, since a "pseudo CA"
is is indeed minting end-user certificates from its associated SSL certificate.
Yes, BasicConstraints and KeyUsage are ignored :-)
That DNS do not represent the only naming-system there is is for sure but as a
foundation for a globally interoperable messaging system, it is hard to come up
with anything better.
Regarding message formats, I haven't gone to that level yet. If there are
existing RFCs that would work out-of-box that would be fantastic! I have
though a feeling that some "tweaks" in the interpretation would be necessary
since the described scheme is incompatible with existing PKI validation schemes.
Anders
----- Original Message -----
From: "Nelson B Bolyard" <[EMAIL PROTECTED]>
To: "mozilla's crypto code discussion list" <dev-tech-crypto@lists.mozilla.org>
Sent: Saturday, November 22, 2008 12:11
Subject: Re: Creating a Global User-level CA/Trust Infrastructure for
SecureMessaging
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
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
