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

[Adam Eijdenberg]

On Mon, Sep 14, 2015 at 6:53 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> 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.
>

I agree - let's agree on a design before adding client surface that
actually applies CT policy.  That said there is a significant amount of
code that needs to land first which basically follows RFC6962.  Namely:

- data structures for SCTs
- code to read/write SCTs
- code to verify SCTs against a certificate
- data structures for metadata about CT logs
- utilities for creating test data

This initial patch starts on just the first 2 items listed above and
doesn't add new public API surface.  My feeling is there isn't likely to be
much controversy on the work items above, as they pretty faithfully
implement functions to perform tasks described in RFC6962.  We will need to
revisit and update when RFC6962-bis is complete.

I do think there are at least 2 healthy discussions in front of us in terms
of client API design:

1. File format / location / storage for CT log metadata (the strawman in my
patches is the JSON format already published at
http://www.certificate-transparency.org/known-logs, specified in the same
manner as the root CA file)
2. What the client API look like for enabling / requesting / requiring CT
for a given context or connection.

I think these areas of concern match with your thinking:

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.
>

I can see it being useful to have a piece of metadata on a trusted root
that can be set by a local admin that says something like
"this_root_is_local". This should only be set on internal CAs created by
organizations and installed by local admins.  During CT policy evaluation,
if a cert is signed by a root annotated in this manner, do not require CT
even if the client indicates that it normally does expect it (HPKP may
benefit from similar).

Can you give an example of a policy that you'd set on a root trust-anchor
that would work well with CT?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150915/52a85154/attachment.html>