[cryptography] Is this a feature?

ianG iang at iang.org
Wed Jan 23 02:11:50 EST 2013


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.



More information about the cryptography mailing list