Hi Paul, I appreciate the feedback.
Ta. I've had a quick look. A couple of minor comments:
You might want to include "BEGIN TRUSTED CERTIFICATE" as an option when parsing PEM-format files. All the root CAs I've seen don't use this, but apparently its a possibility.
Okay, I'll keep it in mind. If no one's using it I won't be in a big hurry. Thanks.
Also, OpenSSL (but unfortunately not GnuTLS) can scan a directory, loading all files like <serial>.0 (e.g. "a87d9192.0"). Adding support for something like that might be useful, but certainly not urgent.
Yeah, like above, I'll let usage dictate how quickly I get on that ;)
Hmmm, I think we could do better than downloading from an static (well-known) URL.
So do I, but mono does it, so I was lazy too ;)
Exactly. This is one of the big problems with PKI: obtaining the CA root certificates. In general, it's impossible to do this reliably using just the Internet: some out-of-bound traffic (Phone, FedEx?) is needed to establish the trust.
Yes, that's true, but if trust truly is the issue, we have to ask what exactly is being protected. Right now, in Wine, it's precisely nothing. Even once all the cert checking code is implemented, the apps that use these APIs are few. Running firefox in Wine, for example, uses its own certificate stores - downloaded from the Internet as part of the installer - and not any certs installed locally.
In my personal opinion, certificates don't say as much as we'd like them to. If we'd never used certs with SSL, perhaps eavesdropping attacks would be more prevalent, but that doesn't seem likely either - one can use key negotiation protocols that don't assume you trust the other end. Man-in-the-middle attacks might be more likely - but they apply to downloading Firefox in the first place, so the fact that we ignore them means that they're either not that much of a threat, or that people don't care about them. Attackers - and I'm thinking of the web here - seem to be much more likely to engage in social engineering attacks, perhaps because users can't tell the difference between SSL-protected sites and ordinary ones, nor can they articulate the difference between the two, even if they can discern it. (I can dig up some paper references on this if you like.)
One of the nice features of git (if I've understood correctly) is it's cryptographic internal consistency checks: if one trusts the first SHA-1 hash then all subsequent git-objects can be verified: you know the tree is always as Alexandre intended.
That's true, and it's partly the reason I sent a patch adding the certs to the registry as my first attempt. The problem is that certs are opaque (asn.1 encoded,) so Alexandre can't easily judge whether the certs are correct. So for perhaps just this reason, or perhaps also that he doesn't feel they should be in the registry at all (see his other emails), that patch wasn't committed. That led me to this approach.
What do you think of my most recent suggestion, that the Root store should not read from the registry, but should read from certs installed locally, where the path to them is set in the registry?
Thanks, --Juan