Sync more DMServer proto comments to the client.

components/policy/proto/device_management_backend.proto

Index: components/policy/proto/device_management_backend.proto
diff --git a/components/policy/proto/device_management_backend.proto b/components/policy/proto/device_management_backend.proto
index b70bacdd5eb54f46c2757253d85a1c39f18c99b0..1a8206ed23414bc6e8149bd9cb6918f6dfb00d9f 100644
--- a/components/policy/proto/device_management_backend.proto
+++ b/components/policy/proto/device_management_backend.proto
@@ -483,20 +483,19 @@ message PolicyFetchResponse {
   // drop such PolicyFetchResponse.
   optional bytes new_public_key_verification_data = 8;
 
-  // If new_public_key is specified, this field contains a signature
-  // of a PolicyPublicKeyAndDomain protobuf, 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.
+  // If new_public_key is specified, this field contains the signature of a
+  // PublicKeyVerificationData protobuf, 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 picks 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 returns an error
+  // instead of policy data. In case a hash was not specified, DMServer leaves
+  // the verification signature field empty (legacy behavior).
+  // This signature is provided to better protect first key delivery (since the
+  // browser does not possess the previous signing key, DMServer cannot compute
+  // new_public_key_signature).
+  // See http://go/chrome-nac-server-design for more information.
   optional bytes new_public_key_verification_data_signature = 9;
 }
 
@@ -1309,8 +1308,12 @@ message DeviceManagementRequest {
 
 // Response from server to device.
 //
-// The server uses the following numbers as HTTP status codes
-// to report top-level errors.
+// For release clients, DMServer returns errors using HTTP Status Code, so that
+// clients only need to check one place for all error codes.  It is also easier
+// to perform log analysis and customer support since HTTP Status Code is easily
+// visible in the logs.
+//
+// The following list defines the error code returned by this API:
 //
 // 200 OK: valid response is returned to client.
 // 400 Bad Request: invalid argument.