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

[Viktor Dukhovni]

On Mon, Sep 14, 2015 at 11:38:28PM +0000, Adam Eijdenberg wrote:

> > 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).
> >
> 
> The idea of CT is to make mis-issuance easily detectable by requiring all
> certs to be logged in order to be considered valid (and thus deter
> mis-issuance).

That's not going to happen at the same time for all issuers.  With
DANE whether CT applies or not will depend on which TLSA record
matched.  

    * If DANE-EE(3), then CT is out of scope.  
    * If PKIX-TA(0) or PKIX-EE(1) than CT is in scope.
    * If DANE-TA(2) then it may depend whether the trust-anchor in
      question is in fact a public root (though the sensible thing
      is to treat just as with DANE-EE(3)).

> It would not be good if one could deliberately mis-issue a
> cert that would make clients think they need didn't need CT,

Well, that would not be possible if the locally configured public
CA root the certificate chains to indicates whether CT is required
or not.

> so in the fullness of time (when is CT widely adopted, required by browsers)

Browsers are not the only TLS applications, and the Web PKI with
CT is not the only relevant PKI.

> I would expect most clients would just turn this on in the same manner
> they would turn on verifying a cert chains to a trusted root.

This is not sufficient for e.g. DANE verification with a mixture
of DANE-?? and PKIX-?? certificate usages.  Nor is it sufficient
if some roots do CT, but others, say additional internal corporate
roots, do not.

> That said, I agree the higher level API proposed in the later patch isn't
> flexible enough, for example, one couldn't implement the current Chrome
> EV policy with it, and likely should be replaced with a callback similar
> to how verify is currently done.

That's the point I'm trying to make, the API likely still needs
some thought.

> I figured that it's still worth starting on the more basic patches first as
> I expect it'll take a while to get all the pieces through the pipeline, and
> I think will leave us open to try a variety of approaches there later.

I am not a big fan of retro-active design.  We should aim to get
that right, document it, and then write and review code.  Sometimes
implementation uncovers design issues, then we might updatet the
design, but we should start with something plausibly correct.

> > > (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?
> 
> Under both (2) and (3) (but not (1)) the set of SCTs returned for a
> certificate can vary over time.  So, for example, if a CT log ceased to be
> trusted for any reason, servers that send SCTs via methods (2) or (3) can
> log the certificate to new logs and return SCTs from those.  Servers
> configured with (1) alone will need to get and install a new certificate
> from their CA.  
>
> This is reflected in Chrome's current EV policy, which
> guards against this by requiring more SCTs be present depending on
> certificate validity length when they are delivered by being embedded in
> the certificate.

Getting a new certificate when enough of the logs are retired does
not seem too onerous...

> (3) has another desirable property in that no participation is required by
> the CA who issued the certificate.  A server operator can log their own
> certificate, grab the latest version of Apache, nginx or haproxy and
> support CT.  For examples of this see:
> http://www.certificate-transparency.org/resources-for-site-owners

That's all well and good, but I don't forsee a way for clients to
know whether servers should be doing that or not.  After all we
are trying to keep issuing CAs honest, and if the issuing CA is
not participating in CT, than many (or most) of its certificates
will not be logged.

Outside the browser space, I don't forsee a flag day any time soon
with the entire Internet suddenly turning on mandatory CT on the
client side.  A more realistic deployment model is one root CA at
a time, in which case the CA may as well be the one doing the
logging, simplifying the server deployments (just serve the
CA's certificate).

> > > (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?
> 
> The set of SCTs returned can be varied over time by the OCSP operator as
> logs come and go - and less SCTs (= less bandwidth) are required for
> longer-lived certificates (under Chrome's current EV policy).

How much "coming and going" of logs do we expect?

> If your CA doesn't currently offer an option to issue a certificate with
> embedded SCTs, or an OCSP responder with embedded SCTs, then this is a
> great option.  If those other options are available to you, you might still
> choose to serve via the TLS Extension if fidelity around which SCTs from
> which logs are returned is important to you.

I think think this solves the wrong problems, but I now understand
the server deployment models, and API requirements.  Since my
concerns are not OpenSSL-specific, but rather generic to CT, if I
had cycles I'd discuss them on the relevant CT lists.  Since cycles
are scarce, I'll let it drop.

My main concern is the client interface.  I think that CT policy
belongs in the root CA store (a property of suitably augmented root
CA certs).

Any alternative suggestions for how client policy is managed? Note,
I am not even talking about the API yet, rather where the policy
is set operationally.  Applications might still have an interface
to tweak the implicit policy from the root trust-anchor store.

> > 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.
> 
> I think that when you want to require CT or not depends also on the context
> in which openssl is being used.  For example if it's being used as part of
> a browser, there'll be one set of considerations (e.g. an incremental
> rollout like Chrome's current policy or perhaps one as you've described).

Yes.

> However if you were using openssl in an application to make custom API over
> HTTPS calls back to a server that you control, you might want to require CT
> for all calls, as you know that your server supports it.

Yes, though one might simply create and use a root CA store in
which the usual suspects have the right policies "attached" to the
certificates.  In practice the attached policy might be accessed
via auxiliary files, because that might be easier than building
custom "TRUSTED CERTIFICATE" objects.

> I'm not a fan of enabling per CA as it means you can avoid detection of a
> mis-issued certificate by targeting a CA that doesn't indicate it supports
> CT yet.

That's the only means to avoid a flag day.  Clients might over time
elect to only trust CAs that do CT, but initially and for some time
we'll have a mixture of CT-capable and non CT-capable certificates
and servers.

> Again, CT is about providing assurance for site-owners that they can detect
> mis-issuance of certificates, so one other option that we're considering
> (in the context of Chrome) is a mechanism by which a site-owner can opt-in
> to requiring CT ahead of any scheduled requirement (inspired by what Tom
> Ritter proposes in:
> https://ritter.vg/blog-require_certificate_transparency.html)

Fine, though keep in mind that HSTS is a TOFU mechanism, if you
are MiTMed on first contact, you don't benefit.

> > 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?
> 
> Trusted log metadata will need to be stored somewhere.  For the reasons
> above, I don't think it makes sense in general to key this on a root CA
> though.  One thing to consider though is whether the trusted certificate
> objects have any notion of whether they are real root CAs, or certs
> installed by local admins on machines (e.g. by an enterprise that wishes to
> MITM all outbound connections).  For that case ("local" roots) it doesn't
> make a lot of sense to require CT.

Well, as more CAs commit to using CT, deployment grows, until some
day soon CAs MUST use CT or stop being public CAs for the "Web PKI".

However, even then, for quite some time, internal non-public CAs
in organizations may not elect to use CT.  So a global policy
hardcoded into applications will work poorly.  There'll need to be
a way to know which certificates or servers are in scope, and which
are not.

-- 
	Viktor.