Certificate Transparency - Google "argon2017" Log Server Inclusion Request |
||||||||||||||
Issue descriptionContact Information: - email: google-ct-logs@googlegroups.com - phone number: +442070313000 (Google UK) - Log Operator: Al Cutter, Pierre Phaneuf, Paul Hadfield, Martin Smith, Rob Percival, Kat Joyce, David Drysdale, Alan Parra Log Server URL: https://ct.googleapis.com/logs/argon2017 Log ID: +tTJfMSe4vishcXqXOoJ0CINu/TknGtQZi/4aPhrjCg= Certificate Expiry Range: Jan 01 2017 00:00:00Z inclusive to Jan 01 2018 00:00:00Z exclusive Server public key: attached in PEM file google-argon2017-public-key.pem. Description: Google's newest public CT Log, operating since 2017-August-10. This Log is implemented and operated by Google. This Log accepts all certificates that are anchored in a root trusted by one of the major browser vendors including Apple, Microsoft and Mozilla. This Log accepts certificates expiring within the date range as listed above. We will freeze the Log once its inclusion expiry window has passed and close it for new submissions as of Jan 01 2018 00:00:00Z. We will then request that trust be withdrawn from this log by Chromium as all the certificates it contains will have expired and will therefore be no longer valid. The combination of the certificate expiry ranges of the new Google Argon Logs will allow any certificate that chains to a trusted root and has a lifetime of 39 months or less to be logged to one of the new Argon Logs, if it is issued within the next year. Further Argon Logs will be turned up in the future in order to maintain the window for accepted certificates. This Log is public and provides open access. There are no fees for submitting certificates or any other usage including queries and mirroring. No prior contracts or agreements are required before the Log may be used. Submissions are rate limited by IP address. Queries are rate limited by IP address. Rate limited requests will be denied with an HTTP error status code. We intend to provide serving capacity to support any reasonable usage level but additional automatic mechanisms exist that will operate to protect our infrastructure in emergency situations. The purpose of our new Logs is an attempt to move towards a more managed and predictable lifecycle for CT Logs and thereby reduce operational overhead for both submitters and log operators. We have no current plan or schedule to discontinue serving these Logs, but may revisit this as operational policies within the ecosystem evolve. MMD: 24 hours Accepted roots: Attached file: google-argon2017-roots-20170818.pem Implementation Note: This Log is one of the first that are based on our new Golang implementation of Certificate Transparency. The open source version of this code can be found at: https://github.com/google/trillian and https://github.com/google/certificate-transparency-go and it is made available under an Apache 2.0 license.
,
Aug 22 2017
Note: The current policy requires that "The Log's public key, attached as a binary file containing the DER encoding of the SubjectPublicKeyInfo ASN.1 structure". These were attached as PEM files :) With that exception, I believe this meets all the criteria for inclusion. Assigning to Rob for monitoring.
,
Aug 22 2017
I've posted a proposal to change the policy to require PEM files instead (https://groups.google.com/a/chromium.org/d/topic/ct-policy/M9Vchxs9gvY/discussion), since that's predominantly been how public keys have been provided by operators in the past (it seems we've overlooked that previously). PEM keys are generally easier to use anyway. I'm going to officially start compliance monitoring now but we'll change the public keys to DER files in a few days if people object to my policy change. Is that ok?
,
Aug 23 2017
The Argon2017 log public key in DER format. Martin
,
Aug 23 2017
Thank you for your request, we have started monitoring your log server. Should no issues be detected, the initial compliance monitoring phase will be complete on 21st November 2017 and we will update this bug shortly after that date to confirm.
,
Sep 4 2017
,
Oct 2 2017
I've been getting a 500 internal error on a request like this for hours now: https://ct.googleapis.com/logs/argon2017/ct/v1/get-entries?start=444171&end=444873 I think that if you try the same request enough times it becomes successful, like it gets a timeout trying to load all the data, but next time already has some in RAM and can get some more.
,
Oct 3 2017
I'm not currently aware of any problems. If there are then they'll be visible to our availability monitoring so we'll check up on that. Are you making a large number of requests? It's possible they're being rate limited. Martin
,
Oct 3 2017
I'm trying to get all entries. I ask it to give me 1024 entries in the request, then but most of the time that fails. If it works, I get 500 entries. If that request is successful I will ask for the next 1024 entries, with a limit of 10 such request before a delay. The download of such 10 request when successful takes about 100 seconds, so that's about 1 request per 10 seconds. At the time I reported this yesterday there were delays of around half an hour before trying it again, and the first request after that failed again. Parallel from the same host there are get-sth requests. They never have a problem, the time is a bit random but it's about 2 request per minute.
,
Oct 3 2017
I'm observing similar problems. Here was the result of a recent attempt to fetch https://ct.googleapis.com/logs/argon2017/ct/v1/get-entries?start=0&end=1000 Internal Server Error backend GetLeavesByIndex request failed: RPC::DEADLINE_EXCEEDED: context deadline exceeded
,
Oct 3 2017
A couple observations: 1. get-entries takes longer to complete the more entries I request. 2. I consistently get the RPC::DEADLINE_EXCEEDED error when I request a large number of entries (> 500), unless I recently requested the same range. This suggests to me that Trillian is hitting a timeout when trying to retrieve all of those entries. Instead of returning an error, Trillian would ideally return the entries that it was able to retrieve.
,
Oct 4 2017
Thanks for the additional info. We're investigating several possible causes why this could be happening. Martin
,
Nov 14 2017
The following root certificates should be accepted by this log within the next few days. This brings us up-to-date with the latest roots trusted by Apple, Microsoft and Mozilla. https://bugs.chromium.org/p/chromium/issues/attachment?aid=312118
,
Nov 14 2017
In addition to the above certificates, the attached certificates will also be accepted.
,
Nov 21 2017
The NextAction date has arrived: 2017-11-21
,
Nov 23 2017
We have reduced the maximum number of entries returned by /ct/v1/get-entries to 100. This is to mitigate a performance issue that has been causing a small number of these requests to fail (less than 1%). We are investigating the underlying cause and intend to publish a postmortem on https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy once that is complete.
,
Dec 1 2017
We've posted a post mortem on the latency issue here: https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/c1rU2kpHkJk Many thanks to awga for the observations.
,
Feb 27 2018
Devon, please advise once this log can be added to Chrome.
,
Apr 2 2018
This log's expiry range was set for 2017 and lapsed before it would have been included in a release of Chrome, so it wasn't added alongside the 2018+ shards. Spring cleaning as WontFix. |
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by robpercival@chromium.org
, Aug 18 2017Labels: allpublic