[145434] in cryptography@c2.net mail archive
Re: A mighty fortress is our PKI
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Wed Jul 28 08:42:00 2010
Date: Wed, 28 Jul 2010 07:30:41 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Paul Tiemann <paul.tiemann.usenet@gmail.com>
Cc: Chris Palmer <chris@noncombatant.org>, cryptography@metzdowd.com
In-Reply-To: <C537D728-FEA7-45BA-9B39-2EC60DAEEEDE@gmail.com>
On Tue, Jul 27, 2010 at 10:10:54PM -0600, Paul Tiemann wrote:
> I like the idea of SSL pinning, but could it be improved if statistics
> were kept long-term (how many times I've visited this site and how
> many times it's had certificate X, but today it has certificate Y from
> a different issuer and certificate X wasn't even near its expiration
> date...)
My preference would be for doing something like SCRAM (and other
SASL/GSS mechanisms) with channel binding (using tls-server-end-point CB
type). It has the effect that the server can confirm that the
certificate seen by the client is the correct one -- whereas the server
cannot do that in the "SSL pinning" approach. It'd have other major
benefits as well.
The problem is: there's no standard way to do this in web browser
applications. Worse, there's not even any prototypes.
I also like the Moonshot approach.
> Another thought: Maybe this has been thought of before, but what about
> emulating the Sender Policy Framework (SPF) for domains and PKI?
> Allow each domain to set a DNS TXT record that lists the allowed CA
> issuers for SSL certificates used on that domain. (Crypto Policy
> Framework=CPF?)
Better yet: use DNSSEC and publish TLS EE certs in the DNS.
Nico
--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
