As someone who is looking to run a log server, I'll answer with my personal
opinions.
On Tue, Jul 01, 2014 at 03:45:12PM -0700, Rick Andrews wrote:
> The current spec includes a call to Retrieve Accepted Root Certificates.
> Should we infer from that that the list might change over time? We expect
> new roots would be added, but would roots ever get removed? For example,
> browser vendors are in the process of removing 1024-bit roots from their
> trust stores, and in the next few years we expect that SHA-1 roots might
> be removed too. Would log server operators also phase out such roots?
Since roots are only there to prevent mass-spammage, the only circumstance
in which I would foresee a root certificate being removed from the log's
trusted set would be if it went so totally rogue it was issuing a huge
volume of certificates and submitting it to the log.
Quite frankly, if you get control of a root or intermediate CA certificate's
signing key, and the most valuable thing you can think to do with it is spam
a CT log, you need to get out more.
> Once there are more than three log servers, we expect to decide up front
> which log servers we will contact for SCTs. We do not expect to
> dynamically query each log server to confirm that it still trusts our
> root, just before attempting to log a certificate. Is that a valid
> assumption?
Completely valid.
> It would be preferable for the log server operator to publish a list of
> roots and commit to supporting those roots until the CA informs the
> operator that the root is no longer in active use, and all certificates
> chained to that root have expired.
Darn tootin'.
> We have been providing cross-certificates to customers to deploy so that
> their certificate could chain up to a 1024-bit root (for use in older
> browsers without our 2048-bit roots). If the cross-certificate is
> ignored, the end-entity cert chains up to one of our 2048-bit roots. We
> expect to continue using cross-certificates until we determine that their
> use is no longer required. We'd like to be sure that the use of
> cross-certificates will not cause any problems for log servers. For
> example, take the case where we log a certificate we're about to issue (or
> have issued) and we include the cross-certificate in the chain sent to the
> log server. Then the customer (for whatever reason) decides to also send
> their certificate to the log server, but without the cross-certificate.
> Will the log server see this as the same certificate, and return to the
> customer the same SCTs? Or will the certificate get logged a second time?
> If the latter, will that cause any problems?
The Signed Certificate Timestamps identify the end-entity certificate being
signed, and a timestamp of when it was accepted for inclusion into the log.
My implementation, at the very least, re-issues the same SCT if it sees the
same certificate again, regardless of the method by which is it chained to
one of the trusted root certs.
On a related point, I'm intending (until circumstances prove it to be a
foolhardy notion) to be *very* liberal in what roots I accept -- I'll
probably pre-populate with the trust stores of the browsers, etc, but I'll
have a form or something you can paste your root CA cert into and I'll add
it, unless you're obviously trying it on.
- Matt
--
When I was a kid I used to pray every night for a new bicycle. Then I
realised that the Lord doesn't work that way so I stole one and asked Him to
forgive me.
-- Emo Philips
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
