Kyle Hamilton wrote:
On Sat, Nov 29, 2008 at 3:57 PM, Frank Hecker
<[EMAIL PROTECTED]> wrote:
Anders Rundgren wrote:
From what I have seen on this list there has been a lot of talk about
inclusion of various CA root certificates in the Mozilla distributions.
IMO, most of these CAs are insignificant except for SSL certs.
I'm not sure your intended meaning is. There is no significant use of
CA-issued certificates on the public Internet other than for enabling
SSL/TLS.
So why is there so much bitching about S/MIME? Oh yeah, it's cuz it's
supported by another Mozilla app.
Well, it has crypto built in, so presumably could be used for email.
Plugins could be used as well, although the one I tried was almost as
bad, it is practically unworkable if you have more than one key in your
keyring, because it assumes only one key.
(I discovered some other oddities about S/MIME recently: revocation
seems to be incongruent with key distribution. I can distribute a new
cert only in an S/MIME signed email, but I can't distro any updates to
my key situation. When I lose a key, all the old encrypted email is no
longer readable ... which presumably happens when revocation happens as
well. I wonder if it denies the signatures as well? Does this mean
digital signing just disappeared because of a key compromise?)
The primary reason CAs apply to have certificates included into NSS, and the
primary reason we have a policy about this, is because CAs want their
customers' SSL certificates recognized in Firefox.
Then Firefox should fork its version of NSS and manage its own
certificate trust list. Since there are other clients of NSS, though,
NSS has taken it upon itself to manage its own trust list, "on behalf
of" those organizations that use it, whether those organizations want
to use it or not.
Well, ... "should" is a popular word :)
Why? Because the vast majority of organizations (in the rare situation
that
they use client-side PKI), actually issue their own client-certificates.
Yes, because almost all use of client certificates is in enterprise
networks, not on the public Internet.
Gee. Maybe it's because the public internet doesn't rely on
business-flavored security. Maybe the public internet actually needs
some cryptographic mechanism that doesn't have the same
presuppositions (and thus the same failures).
Something like that; one favourite is the business-world concept of
authentication being a necessary feature, whereas in the private world,
anti-authentication is often considered a necessary feature.
For all that Frank and Nelson seem to be worried about the user
experience, they sure seem not to lobby for improvement all that much.
Oh, for this, I have to pipe in. Mozilla is like other mostly open
source operations; improvements are dependent on the availability of
developers, first and foremost. In the security field, most of the
developers are funded by the various organisations that have an interest
in this.
I don't know if there is even anyone working on Tbird security; one
thing about this was that Mozilla recognised this about 1-2 years back
and forked off Mozilla Messaging to deal with the overwhelming Firefox
presence. Although we wouldn't see much fruits from that yet (I don't
know if they have done enough to mark a major release yet) I suppose a
valid question would be how much of their resource/mission is pushed
towards user security and/or corporate security, and how much of this is
going to feed back into their sustainability goals.
I'll note again that I very much like Microsoft's means of adding
things to the default trust list (as of Vista): MS has a certificate
that's marked for "trust list signing", and every trust list they send
out with every update to it is signed by that key. That means that
you just have to de-trust that certificate, and you suddenly don't
trust the list they sent.
This might be considered a hole in the PKI armour, at the top, in a
theoretical sense. However, elegance and completion should not be taken
too far.
If MS can run a CA like that, why can't Mozilla? I'd like to see
Mozilla be able to rely on the technological capabilities already
extant in NSS (by revoking a certificate) rather than relying on a
client update to simply remove the offending bundle of bits.
My answer: because there is no validated threat. Yet. There is no
clear and present danger.
And, if we were to sit down and assume a threat in that area, blocking
that hole isn't likely to earn us very much, we would probably find that
we were in substantially more trouble elsewhere. Which leads us to some
uncomfortable directions. Architecturally, that's a rabbit hole, and
I'd like to see some firmer requirements before wasting time on it.
(That last, by the way, may actually stymie law enforcement, by
violating the forensic boundary.)
That assumes a requirement, something that I'd be loath to do, because
it places correction before prevention, and because once Mr Plod is
involved, we've generally lost anyway ;)
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
