SSL/TLS without certificates

Question

I\'m working on a pet project that will (eventually, when it\'s done) allow for secure file transfers (there\'s more to it than just that, but the rest isn\'t particularly r

Answer 1

To expand on Eugene's answer (I would have put this as a comment, but it's a bit long)...

Having done this sort of things with the FOAF+SSL project (later renamed WebID), sticking with X.509 certificates makes the implementation easier, simply because most SSL/TLS stacks are designed with them in mind (and their API reflect this).

Last time I checked FOAF+SSL, the traditional PKI checks were still in place for the client to check the server certificate. Another option, similar to SSH, would be to accept the public key/certificate the first time you encounter it and warn the user when it changes. That's more or less the way SSH works anyway (in particular, I guess that few people actually check the key's fingerprint out of bands the first time they see it).

Considering just the client-certificate usage (although some of this could apply to server certs in a similar way):

• Most server libraries seem to be able to process X.509 certificates, but let you change the way they are verified (e.g. X509TrustManager in Java).
• Whilst you won't be able to trust anything the client-cert says until you have verified it otherwise, being able to embed some extra information (such as a Subject DN or Subject Alternative Name to see who the user claim to be) can help (a) the users organise their certs and (b) give a hint for the verifier to know what to look for. A bare public key can be hard to manage.
• A number of existing client tools (especially browsers) use X.509 certificates when doing SSL/TLS client authentication. Not much needs to be done to configure a client to use a self-signed X.509 cert (as opposed to a cert from a PKI). (There are very few tools that support OpenPGP for TLS, I'm not sure any are able to use it as a form of client certificate.)
• Since you won't be able to trust the cert without external checks, it doesn't matter whether it's self-signed or not (i.e. whether the issuer and the subject are the same), at least assuming the user wouldn't send you a cert with which it wouldn't agree (so it wouldn't have to be sealed by its own key). A consequence of that is that you can build a service to issue certs quite easily. In-browser key-generation, for example, is convenient for users who don't want to use openssl or keytool commands. Here is an example service that will issue a certificate with the SAN the user wants (there might be more recent versions if you check with the FOAF+SSL/WebID project). Whichever private key or issuer name such a service uses barely matters, but since browsers are designed around traditional PKIs, it doesn't make it easy to use really self-signed certificates.

There are also issues when it comes to asking for a specific client-certificate. The TLS 1.1 specification explicitly allows empty certification authorities (see RFC 4346), whereas the TLS 1.0 were silent on the subject. In practice, even with TLS 1.0, most client tools seem to be happy with an empty list (they'll just offer more choice). If you want your certificates for your system to be easily identifiable, you could use the same issuer DN for all these certs, even if they're not signed with the same private key in practice (again, since you would ignore the signature).

Answer 2

Use self-signed certificates - this is the same as "raw" keys but easier to manage (see this question regarding how to accept or not accept a self-signed certificate in openssl).