Pure Python HTTPS Server

[Trevor Perrin]

Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote in message news:<7x1xogvr35.fsf at ruckus.brouhaha.com>...
> trevp at trevp.net (Trevor Perrin) writes:
> > There's no path validation or cert creation.  My view is that certs
> > are a disaster, and I'm doing users a *favor* by keeping them at arm's
> > length :-).  Fingerprints are easier to use, so that's what the
> > library encourages.
> 
> But it means you need a separate fingerprint for each person you talk
> to.

You need to *get* the fingerprint of each person you talk to.  But if
you're calling people you need to get their phone number, if you're
emailing them you need to get their email address, etc..  acquiring
fingerprints isn't much different from acquiring those things, and
it's a hundred times easier than doing anything with certificates,
IMHO.


>  If you're going to do that, you may as well just use shared
> symmetric keys and not mess with TLS.

Well, fingerprints are public, not secret data.  So they're much
easier to distribute, and N people only need N fingerprints, whereas
they'd need N-squared shared keys.

(of course you know that; I just can't resist a chance to sing the
virtues of fingerprints...  I'm sort of a fingerprint zealot :-).

(And even if you *are* using symmetric keys, you still might want to
use TLS just for its record layer; that's what the shared-keys
Internet-Draft [1] is about, which tlslite implements).

> 
> > Anyways, I don't plan to add more X.509 support.  If someone else
> > wants to, it is open-source...
> 
> Yeah, that's what I mean about it being a lot of work to do the full
> stack.  It's great that you've provided this starting point though.

Thanks.  I don't agree that the "full stack" of PKIX protocols is
worth implementing or using, but we can agree to disagree on that..
  
Trevor

[1] http://www.ietf.org/internet-drafts/draft-ietf-tls-sharedkeys-02.txt