Cast device revocation checking.

components/cast_certificate/proto/revocation.proto

+// Copyright (c) 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+//
+// Data structures related to Cast device certificate revocation infrastructure.
+
+// This proto must be kept in sync with google3.
+
+syntax = "proto2";
+
+option optimize_for = LITE_RUNTIME;
+
+package cast_certificate;
+
+message CrlBundle {
+  // List of supported versions of the same revocation list.
+  repeated Crl crls = 1;
+}
+
+message Crl {
+  // Octet string of serialized TbsCrl protobuf.
+  optional bytes tbs_crl = 1;
+
+  // Binary ASN.1 DER encoding of the signer's certificate.
+  optional bytes signer_cert = 2;

[eroman, 2016/07/12 21:22:01]

DESIGN: is this system going to allow for delegating the CRL authority?

Given that there is only one trusted CRL root, and the Crl includes just 1
signer cert (no intermediates), the certificate hiearchy is going to be limited
to only things directly signed by the root.

If that is the system used, then there isn't much advantage to having this
signer_cert over just having the CRL root sign these directly.

Is the intent here that Google would be the only entity capable of signing CRLs?

[sheretov, 2016/07/12 21:59:04]

The two-level hierarchy is for operational reasons.  Google is the only entity
that's going to signing these.

[ryanchung, 2016/07/14 16:15:26]

The CRL will be signed by an ICA issued by the CRL root. This way, it is
possible to rotate out the signer. The CRL ICAs will only be accessible by
Google.

[eroman, 2016/07/15 22:52:48]

Thanks sheretov/ryanchung for the explanations!
(And apologies if I glossed over details in our earlier conversations requiring
any repetitions here).

So if a CRL ICA was ever compromised, our recourse would be to change the CRL
root used by Chrome right? (assuming the TTL on those ICAs is long).

[ryanchung, 2016/07/18 23:39:07]

I would prefer the ICAs to be short-lived (~ 1 week?). Otherwise it would make
more sense to just sign directly with the root. sheretov@, what do you think?

+
+  // Signature calculated over the contents of the tbs_crl field.

[eroman, 2016/07/12 21:22:01]

Add an explanation that the signature algorithm is implied by the version.

Alternately, why not just include a SignatureAlgorithm (DER-encoded) instead?
This would easily extend to future signature algorithms, as well as support for
RSA PSS which has other parameters.
From a coding perspective it is pretty simple, we have a function to parse
SignatureAlgorithms.
And from the server side it is also easy -- if you want to use RSA PKCS#1 with
SHA256 you can just hardcode the signature algorithm to this constant:

https://cs.chromium.org/chromium/src/net/cert/internal/signature_algorithm_un...

[sheretov, 2016/07/12 21:59:04]

We've gone down that road (AlgorithmIDs sprinkled throughout the structures) and
ended up with a single version number (TbsCrl.version) implying all algorithms. 
This approach significantly simplifies processing logic with one check at the
top, instead of multiple throughout.  Any algorithm upgrade will be a big deal
once there are verifiers deployed on multiple client platforms.  The plan for
that situation is to bless a new algorithm suite as a new TbsCrl.version, and
publish multiple versions of the CRL concurrently in a CrlBundle, so that client
verifiers with support for new algorithms can have a staggered rollout.  Once
the rollout reaches critical mass, and we are comfortable with breaking
non-updated CRL verifiers, we stop including the old version of the CRL in the
published bundle.

[eroman, 2016/07/15 22:52:48]

Fair enough, thanks for the explanation.

+  optional bytes signature = 3;
+}
+
+message TbsCrl {
+  // Version 0 algorithms:
+  //  revoked_public_key_hashes: SHA-256
+  //  SerialNumberRange.issuer_public_key_hash: SHA-256
+  //  Crl.signature: RSA-PKCS1 V1.5 with SHA-256
+  optional uint64 version = 1 [default = 0];
+  optional uint64 issuance_time_millis = 2;
+  optional uint64 validity_period_millis = 3;
+  repeated bytes revoked_public_key_hashes = 4;
+  repeated SerialNumberRange revoked_serial_number_ranges = 5;
+}
+
+message SerialNumberRange {
+  optional bytes issuer_public_key_hash = 1;
+  optional uint64 first_serial_number = 2;
+  optional uint64 last_serial_number = 3;

[eroman, 2016/07/12 21:22:01]

Document whether this is inclusive or exclusive (i.e. [first_serial_number,
last_serial_number] vs [first_serial_number, last_serial_number)).

I believe it is the former (inclusive).

[ryanchung, 2016/07/14 16:15:26]

Done.

+}