Added support for signed policy blobs on desktop.

components/policy/proto/device_management_backend.proto

 // Copyright 2013 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.
 
 syntax = "proto2";
 
 option optimize_for = LITE_RUNTIME;
 
 package enterprise_management;
 
@@ skipping 154 matching lines @@
 
   // If this fetch is due to a policy invalidation, this field contains the
   // version provided with the invalidation. The server interprets this value
   // and the value of invalidation_payload to fetch the up-to-date policy.
   optional int64 invalidation_version = 7;
 
   // If this fetch is due to a policy invalidation, this field contains the
   // payload delivered with the invalidation. The server interprets this value
   // and the value of invalidation_version to fetch the up-to-date policy.
   optional bytes invalidation_payload = 8;
+
+  // Hash string for the chrome policy verification public key which is embedded
+  // into Chrome binary. Matching private key will be used by the server
+  // to sign per-domain policy keys during key rotation. If server does not
+  // have the key which matches this hash string, that could indicate malicious
+  // or out-of-date Chrome client.

[Mattias Nissler (ping if slow), 2014/01/27 13:52:13]

This comment should say how the hash is computed.

[Andrew T Wilson (Slow), 2014/01/30 17:10:31]

Why? We don't use it locally, so the actual algorithm used by the server
shouldn't be part of the public contract? This is basically a verbatim copy of
the already-landed server-side proto edit
(https://cs.corp.google.com/?verification_key_hash=#piper///depot/google3/wire...)

[Mattias Nissler (ping if slow), 2014/01/31 21:00:34]

You're right, I was confused. Maybe we should name this verification_key_id
instead and change the comment to say it's opaque instead of saying it's a hash
(which it probably isn't given dkalin's value)?

[Andrew T Wilson (Slow), 2014/02/02 11:31:58]

I'll do this in a followup CL.

+  optional string verification_key_hash = 9;
 }
 
 // This message is included in serialized form in PolicyFetchResponse
 // below.  It may also be signed, with the signature being created for
 // the serialized form.
 message PolicyData {
   // See PolicyFetchRequest.policy_type.
   optional string policy_type = 1;
 
   // [timestamp] is milliseconds since Epoch in UTC timezone. It is
@@ skipping 91 matching lines @@
   optional bytes policy_data_signature = 4;
 
   // If the public key has been rotated on the server, the new public
   // key is sent here. It is already used for |policy_data_signature|
   // above, whereas |new_public_key_signature| is created using the
   // old key (so the client can trust the new key). If this is the
   // first time when the client requests policies (so it doesn't have
   // on old public key), then |new_public_key_signature| is empty.
   optional bytes new_public_key = 5;
   optional bytes new_public_key_signature = 6;
+
+  // If new_public_key is specified, this field contains a signature
+  // of that key, signed using a key only available to DMServer.  
+  // The public key portion of this well-known key is embedded into the
+  // Chrome binary. The hash of that embedded key is passed to DMServer
+  // as verification_key_hash field in PolicyFetchRequest. DMServer will
+  // pick a private key on the server which matches the hash (matches public
+  // key on the client). If DMServer is unable to find matching key, it will
+  // return an error instead of policy data.
+  // In case hash was not specified, DMServer will leave verification signature
+  // field empty (legacy behavior).  
+  // In addition to the checks between new_public_key
+  // and new_public_key_signature described above, Chrome also verifies
+  // new_public_key with the embedded public key and 
+  // new_public_key_verification_signature.

[Mattias Nissler (ping if slow), 2014/01/27 13:52:13]

We should not only verify new_public_key (i.e. the rotation case), but also
against the current public key (i.e. no rotation). I think your code already
does that, so this comment is just inaccurate?

[Andrew T Wilson (Slow), 2014/01/30 17:10:31]

Not sure I understand your question? new_public_key_verification_signature is
only present/stored when a new public key is sent down. The fact that we cache a
key locally and so have to cache the new_public_key_verification_signature to
verify that key on reload doesn't seem pertinent to this proto?

[Mattias Nissler (ping if slow), 2014/01/31 21:00:34]

Technically, you're right. The comment phrasing suggests though that the trust
chain checks only happen if new_public_key is present, when in fact we also
verify the trust chain for signatures on cached and newly-received blobs that
don't contain the new_public_key* fields.

[Andrew T Wilson (Slow), 2014/02/02 11:31:58]

Technically we don't do any verification on newly-received blobs that don't
contain the new_public_key fields - it's only used on key rotation, initial
provisioning of the initial key, and loading from cache. I guess I just don't
understand what comment you want here - I could put "clients that store the
new_public_key in insecure storage will also cache the
new_public_key_verification_signature so they can verify the key has not been
modified when loading" but this seems like the totally wrong place to put this.
It's pretty much inherent that if you have data + a signature, and you're
caching that data and want to verify the data on reload, then you need to cache
the signature too.

I think I might just be misunderstanding what you want, though - what comment
would you propose to make this clearer? I'm happy to push a separate CL through
for that.

+  optional bytes new_public_key_verification_signature = 7;
+
+  // Server-provided identifier of the fetched policy. This is to be used
+  // by the client when requesting Policy Posture assertion through an API
+  // call or SAML flow.
+  optional bytes policy_token = 8;
 }
 
 // Request from device to server for reading policies.
 message DevicePolicyRequest {
   // The policy fetch request.  If this field exists, the request must
   // comes from a non-TT client.  The repeated field allows client to
   // request multiple policies for better performance.
   repeated PolicyFetchRequest request = 3;
 }
 
@@ skipping 325 matching lines @@
 
   // Auto-enrollment detection response.
   optional DeviceAutoEnrollmentResponse auto_enrollment_response = 8;
 
   // EMCert upload response.
   optional DeviceCertUploadResponse cert_upload_response = 9;
 
   // Response to OAuth2 authorization code request.
   optional DeviceServiceApiAccessResponse service_api_access_response = 10;
 }