[cap-talk] A petname toolbar for Firefox

[Ian G]

The other gotcha to bear in mind is that key change
(or cert change) is a thing to deal with in any system.

This gets at the core of "is the key the identity" question;
in that keys are not that long lived in most security
desiderata, so once we admit the notion of a key being
rolled over, we need to get to grips with how this happens
at a user level.

What David suggests - the server is its own authority, and
creates locally signed certs on its own merits - is how any
sensible design would lay things out.  (Yes, that's what
my system does, how about E?)

This isn't going to happen in SSL's PKI, and the PKI
was probably designed not to let it happen (do we
need to show that to this audience?) ... so unless
someone knows a way to get the Apache boys to
re-engineer this part, that design is a theoretical
hope only.

Another factor is SSH experience.  There, they say that
to keep the security model, what the user perceives as
the identity should be preserved at all costs.  That means
if the key changes, then the user sees the change as a
potential threat to be understood and dealt with.  This
of course means that the SSHD will trigger this every
time it re-installs.  Not a big problem for the average
techie, in an average installation.  But, it is a real
nuisance for a) the non-techies in sophisticated shops
who find they have to phone the help desk whenever
this happens, and b) the kernel of the week crowd.

Regardless, and getting back to the point, the mantra
over at the SSH camp seems to be to hold the line and
punt the problem back to the user.  In this I think they
are wise.  They haven't got an easy way to deal with a
system reinstall, so they don't try and fudge the issue,
and thus end up with a half-assed security model with
weaknesses.

Considering all that, I'd say *my* preferred direction
would be to pick the best identity, and then when the
thing changes, punt it up to the user.  That is, I'd defer
any optimisation of the key changeover until I had
actual experience of how bad it is to the users.

 From that pov, I'd still suggest naming using the site
cert, with the domain name as the/one nickname.  I'm
not sure the nickname can be any unique part of the
primary name unless we expect a single key to be
used for multiple domains?

(Hmmm... wildcards, another issue, another day...)

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/