[cryptography] Why anon-DH is less damaging than current browser PKI (a rant in five paragraphs)

Jeffrey Altman jaltman at secure-endpoints.com
Mon Jan 7 14:05:06 EST 2013


On 1/7/2013 12:32 PM, Guido Witmond wrote:
> Lost track who said this:
>>>> "Fixing PKI" isn't the problem, PKI itself is the problem. It
>>>> doesn't work, and as long as browser vendors keep distracting
>>>> themselves by fiddling with even more PKI, they'll never get
>>>> around to addressing the actual problem.
>>>>
> 
> 
> Imho, the problem with PKI is not the technology. I believe the
> mathematics of Public Key cryptography to be sound.
> 
> What I consider the source of the problem with the current deployment of
> PKI is that I'm _FORCED_ to _TRUST_ the global CAs and all their derived
> certificates. If I don't place trust in these global CAs, I can't
> communicate securely with a website, nor can I send or receive encrypted
> emails. Whether or not that trust is justified.
> 
> Trust cannot be forced. It must be earned. And there is no way for me as
> end-user to express my trust levels for the global CAs. I can't reject
> Verisign and decide to use only GoDaddy to prove the 'correctness' of a
> server certificate. Not without breaking the web: I get scary error
> messages when I want to visit a site.

Its not just that we are forced to trust the global CAs.  As long as
there is more than one of them we have to decide which CA do which trust
for which site.  When a connection to https://banking.example.com is
established the only piece of information that the client knows for sure
is the FQDN of the host.  One of the things that we require is the
ability for the client to determine which trust infrastructure to use
based solely upon that name.  If the client can answer this question
securely, then there is a firm foundation upon which to build the rest.

While I like the idea of Certificate Transparency (CT), I fear that any
implementation will be insufficient.  As the
http://www.certificate-transparency.org/ site indicates, it isn't going
to be possible to get every CA on board to generate the log data nor is
it going to be possible to get every HTTPS server to bundle the audit
proof.  There is also no mention of how CT can be implemented for
application protocols that rely upon X.509 certificates without using TLS.

I would like to hear ideas from those on the list of how we can provide
a secure method of identifying the appropriate trust infrastructure
based upon the FQDN of the target.   Where the trust infrastructure
might be a single self-signed certificate, a CA my organization runs
itself, or a third party CA that is hired to issue certificates on my
behalf.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: OpenPGP digital signature
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130107/2c9daf04/attachment.asc>


More information about the cryptography mailing list