On 23/01/13 03:54 AM, Jeffrey Walton wrote:
"Opera will autorepair damage to the certificate repository, a missing
Certificate Authority is considered damage. Opera ships with a list of
frequently used certificates, and if any of these are missing they
will be added the next time the repository is read from disk. Other
certificates will be added from the online repository as needed."
- http://my.opera.com/community/forums/topic.dml?id=1580452
Feature or not... depends on who is asking.
The (old) PKI concept is that they user has to enter into an agreement
with their PKI provider. This was often analogised as establishing
trust. Unfortunately this didn't work in the secure browser world, as
the concept was too hard for users. It sorta worked in a paper
institutionalised setting where one could handwave away some things, but
broke completely when it came to ordinary userland.
So, the vendors stepped in and made the arrangements directly with the
PKI providers, packaged them up together and shipped the 'trust package'
out to users with little or no say [0]. Historically, the browser
experience is that this is the only way to make the PKI concept work.
But this also flipped the so-called trust equation from "I as user trust
my PKI provider to do the right thing" to something more like "you must
trust this provider." It only takes a moment's reflection to realise
that this is not the meaning of trust at all -- the marketing folks have
re-designed the word 'trust' to mean its exact opposite.
So, in maintaining the 'trust' equation, many people inside realise that
if the user starts fiddling around with some vestigial settings left
over from the original PKI concept, it breaks the model and gives the
user a 'bad experience' (tm). Hence there is a tendency in some vendors
to overly-control the 'trust package'. E.g., Microsoft is occasionally
criticised for replacing deleted keys automatically. This is generally
a good thing, ordinary users (the 99% market) can't cope with the
concept otherwise.
The problem however for those more technical folks is that we look at
the words and expect them to relate to our ordinary English meaning. No
such. You will trust your vendor, you have no choice.
Oh, and relate the technical vendor-trusts-CA equation to the 2011 new
normal of attacks. Obviously, post-2011, the CA needs a way to revoke
the root. Update cycle times are too slow... so the vendors have been
working since around 2010 to do dynamic control of their root lists.
They need it because they are the trusting party, and trust doesn't work
unless the vendor can change its settings.
Conclusion: It's definitely a feature, but not yours.
iang
[0] I recently alluded to a contract between the vendors and the CAs,
and that is another view on the same question. Unfortunately the
contracts are obfuscated and not necessarily written down. For example,
there is no one single document between Mozilla and its CAs, and the
precise contract would be something to be found in court, starting from
their policy, and adding any other representations made. Other vendors
may have it more clearly laid out, but have not typically posted it. It
is into this gulf that the CABForum document Baseline Requirements
stepped so nicely. It is (IMHO) likely the most clear contract in
existence right now, although CABForum members will not necessarily agree.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
