get-roots/get-anchors TTL/cache duration

[Florian M.]

Hi list,

I am currently writing a script to submit certificate chains to the
logs, much like Graham Edgecombe's
(https://github.com/grahamedgecombe/ct-submit).

His script does the job but I wanted a tool with a few
additional checks, such as:
* whether the chain that is submitted is consistent;
* if the chain has a chance to be accepted by checking the get-roots API;
* if the SCT that is returned is valid and signed by the log.

The following quote from Ryan Sleevi, written in the context of the
"Google Aviator incident under investigation" on CT-Policy suggests that
the get-roots/get-anchors response might vary overtime and that some
trust anchors might be removed.

On Sat, Oct 22, 2016 at 12:13 AM, Ryan Sleevi wrote:

I suspect you're more specifically thinking of "What happens when a
single certificate is presented, and the option is either blow MMD or
blow 99% uptime", which is a possible situation, but one would have
hoped that the Log Operator took appropriate steps to avoid that
situation, since a variety of options exist - up to and including no
longer including CAs as accepted by the Log until the Log Operator is
able to scale.

The possible variation of this list is consistent with the mere
existence of this API endpoint. If this list was immutable, it would
make sense to add it to the log metadata that one can find in
log_list.json at the certificate-transparency.org website.

On the other hand, I haven't found any guidance or information regarding
the time to live of this endpoint answers. I definitely might have
missed it, though.
Caching the answer would help prevent my script and others' to harass
the log servers with get-roots/get-anchors calls, each time a new chain
is to be submitted.

Is there a de facto standard for the caching duration? Should I request
the list of acceptable roots each time I submit a new chain, or a batch
of new chains? Should we update the RFC6962-bis get-anchors endpoint
specification to add an output TTL attribute?

Thanks,

Cheers,
Florian Maury

[Paul Hadfield]

Hi Florian,

I would imagine that existing HTTP/1.1 caching directives would suffice for this, rather

than attempting to define new ways of expressing cachability in RFC6962-bis.

Have you looked to see whether any of the CT logs currently running output

HTTP cache-related headers in their get-roots responses?

If they don't I would assume that it's fine to call get-roots as often as you like.

regards,

Paul

 

Thanks,

Cheers,
Florian Maury

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob Stradling]

On 07/11/16 12:22, Florian M. wrote:
<snip>

> Hi list,
>
> I am currently writing a script to submit certificate chains to the
> logs, much like Graham Edgecombe's
> (https://github.com/grahamedgecombe/ct-submit).
>
> His script does the job but I wanted a tool with a few
> additional checks, such as:
> * whether the chain that is submitted is consistent;
> * if the chain has a chance to be accepted by checking the get-roots API;
> * if the SCT that is returned is valid and signed by the log.

On a related note, I hacked this together the other day...

https://crt.sh/gen-add-chain

Give it just a leaf cert; it'll then use the crt.sh DB to discover a
suitable trust chain and spit out JSON that you can then submit to a
log's /ct/v1/add-chain API.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Florian M.]

On Monday, November 7, 2016 at 1:26:54 PM UTC+1, Paul Hadfield wrote:

I would imagine that existing HTTP/1.1 caching directives would suffice for this, rather

than attempting to define new ways of expressing cachability in RFC6962-bis.

Have you looked to see whether any of the CT logs currently running output

HTTP cache-related headers in their get-roots responses?

If they don't I would assume that it's fine to call get-roots as often as you like. 

 

Paul,

Thank you for your answer.

You made a very good point. I'll do just that.

I just queried the logs. The results were:

Google Aviator, Pilot, Rocketeer : 5 minutes, public

Symantec CT, Symantec Vega: 1 day

Digicert: public, 0 seconds, no-cache

Venafi, Wosign, StartSSL and CNNIC did not return any cache-related headers.

Thanks.

Cheers,

Florian