Pure Python HTTPS Server
Sat Feb 28 10:35:23 CET 2004
trevp at trevp.net (Trevor Perrin) writes:
> > 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.
Where do you get the fingerprint? By email from the person you want
to connect to? How do you know that the email is really coming from them?
> > 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.
Yes, but each of the N people needs to authenticate N-1 of those
fingerprints somehow, so that's O(N**2) authentication operations.
> > 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..
I don't know about going berserk writing ASN1 parsers and that whole
bit, but there really should be some way to do basic cert checking.
More information about the Python-list