RFC: root cert tool

[Juan Lang]

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