[Sovereign Keys] Certificate Transparency spec and code released [Jeff.Hodges at KingsMountain.com: [therightkey] fyi: Certificate Transparency: Spec and Working Code]

[Seth David Schoen]

Sorry for potentially giving some subscribers here a _third_ copy of this
message.

----- Forwarded message from =JeffH <Jeff.Hodges at KingsMountain.com> -----

Date: Thu, 01 Mar 2012 10:50:56 -0800
From: =JeffH <Jeff.Hodges at KingsMountain.com>
To: therightkey at ietf.org
Subject: [therightkey] fyi: Certificate Transparency: Spec and Working Code

[ note there's a CT-specific mailing list:
<https://groups.google.com/group/certificate-transparency> ]


Subject: Spec and Code
From: Ben Laurie <benl at google.com>
Date: Thu, 1 Mar 2012 17:38:18 +0000
To: certificate-transparency at googlegroups.com

http://www.links.org/?p=1226

"Certificate Transparency: Spec and Working Code<http://www.links.org/?p=1226>

Quite a few people have said to me that Certificate Transparency (CT)
sounds like a good idea, but they’d like to see a proper spec.

Well, there’s been one of those for quite a while, you can find the latest
version in the code
repository<http://code.google.com/p/certificate-transparency/source/browse/doc/sunlight.xml>,
or for your viewing convenience, I just made an HTML
version<http://www.links.org/files/sunlight.html>
.

Today, though, to go with that spec, I’m happy to announce working
code<http://code.google.com/p/certificate-transparency/> for
a subset of the protocol. This covers the trickiest part – a fully
backwards compatible SSL handshake between servers and clients. The rest of
the protocol will necessarily all be new code for interacting with the log
server and other new components, and so should not have these issues.

If you build the code according to the
README<http://code.google.com/p/certificate-transparency/source/browse/src/README>,
then you will find instructions in
test/README<http://code.google.com/p/certificate-transparency/source/browse/src/test/README>
for
the demo.

What this does, in short, is the following:

   - Run a CT log server. Currently this has no persistence across runs,
   but does keep a full log in memory.
   - Issue a self-signed server certificate. A CA issued certificate would
   also be fine, but not so easy to automate for a demo.
   - Use the CT client to register that certificate with the log server and
   to obtain a log proof for it.
   - Use the CT client to convert that proof into a fake “certificate”
   which can be included in the certificate chain in the TLS handshake.
   - Run an Apache 2.2 instance to serve the self-signed certificate and
   the log proof certificate. Note that Apache is unmodified, all that is
   needed is appropriate configuration.
   - Use the CT client to connect to the Apache instance and verify the
   presented log proof.
   - You can also connect to Apache with an existing browser to check that
   you can still access the site despite the presence of the log proof.

There’s plenty more to be done, but this is the part that needs the
earliest scrutiny, since we are bending the rules to get back compatibility
and avoid the need to change server software. Client software has to change
anyway to provide any benefit to users, so that’s less of a worry.

We welcome discussion, suggestions and questions on the mailing
list<https://groups.google.com/group/certificate-transparency>
."

---
end


_______________________________________________
therightkey mailing list
therightkey at ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

----- End forwarded message -----

-- 
Seth Schoen  <schoen at eff.org>
Senior Staff Technologist                       https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
454 Shotwell Street, San Francisco, CA  94110   +1 415 436 9333 x107