[openssl-dev] [openssl.org #4041] [PATCH] Add Certificate Transparency Support

[Viktor Dukhovni]

On Mon, Sep 14, 2015 at 09:19:32PM +0000, Adam Eijdenberg wrote:

> > What is then the purpose of the new "-serverinfo" option of s_server?
> > If CT works without it, why add it?
> 
> There are 3 ways by which a server can deliver Signed Certificate
> Timestamps (SCTs) to clients:
> 
> 1. SCTs embedded in the certificate itself.

Some certificates will have these, and some won't.  The client-side
API has clients setting CT policy prior to the start of the handshake,
before the client knows the issuer of the server certificate, or
whether the server's certificate is EV or not.

Is that the right design?  Or does it make more sense for the client
to require (or not require) CT dynamically, based on certificate
features, (and likely on whether it is doing tranditional WebPKI
or DANE).

> 2. SCTs embedded in an OCSP-stapled response.

Some servers don't support OCSP stapling, will the introduction of
CT "require" them to start doing that?

> 3. SCTs sent in a TLS extension.

Under what conditions should a server be configured to do that?

> (1) requires work only by the CA issuing the cert.

So entirely transparent to the server...  Do we really need any of
the other models?  Why?

> (2) requires work by the CA in their OCSP responder, and work by the site
> operator to enable OCSP stapling in their server.

What's the advantage of SCT via OCSP rather than in the certificate?

> (3) requires work by the site operator only to configure their server to
> send SCTs.

When is this the right model?

> The "-serverinfo" option to s_server is one way to achieve (3), and in fact
> the tests (in a later commit) for s_client use this flag to verify
> behavior.  I believe "-serverinfo" is purposely generic so it can also be
> used for adding other TLS extension data that does not require dynamic
> processing.

So it is required for (3) only?

> Rich is correct that a server does not need to do anything, that is, until
> clients begin to require CT support (as we expect them to do over time as
> CT proves its value).

The API at the moment seems to support "requiring" CT before any
communication with the server.  That seems to be a flag-day transtion.
Should the policy not be based on particular issuing CAs (that
commit to log everything they issue)?  That would make for a more
incremental transition.

> Chrome, for example, already actually requires SCTs be supplied during
> the handshake for EV certificates that have been issued after January 1
> this year
> https://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-Extended-Validation-Certificates

Which one does not know until the ServerCertificateMessage is
received.  In that light, do CT policy settings made indepent of
any input from the server make sense?

Perhaps the right place for CT policy (which logs to use, whether
CT is required, ...) is in auxiliary data stored with "TRUSTED
CERTIFICATE" objects for root CAs?

-- 
	Viktor.