Copy challenge*Key methods to enterprise.platformKeys.

chrome/common/extensions/api/enterprise_platform_keys.idl

Index: chrome/common/extensions/api/enterprise_platform_keys.idl
diff --git a/chrome/common/extensions/api/enterprise_platform_keys.idl b/chrome/common/extensions/api/enterprise_platform_keys.idl
index 5133bf572e72a5c68b7ef9f2bf6f5a38900046c2..a22fef215b5f7f81aec314fd60bf717c6b63664d 100644
--- a/chrome/common/extensions/api/enterprise_platform_keys.idl
+++ b/chrome/common/extensions/api/enterprise_platform_keys.idl
@@ -45,6 +45,11 @@ namespace enterprise.platformKeys {
   // operation is finished.
   callback DoneCallback = void();
 
+  // Invoked by <code>challengeMachineKey</code> or
+  // <code>challengeUserKey</code> with the challenge response.
+  // |response|: The challenge response, encoded using Base64.
+  callback ChallengeCallback = void(DOMString response);
+
   interface Functions {
     // Returns the available Tokens. In a regular user's session the list will
     // always contain the user's token with <code>id</code> <code>"user"</code>.
@@ -84,5 +89,64 @@ namespace enterprise.platformKeys {
     static void removeCertificate(DOMString tokenId,
                                   ArrayBuffer certificate,
                                   optional DoneCallback callback);
+
+    // Challenges a hardware-backed Enterprise Machine Key and emits the
+    // response as part of a remote attestation protocol. Only useful on Chrome
+    // OS and in conjunction with the Verified Access Web API which both issues
+    // challenges and verifies responses. A successful verification by the
+    // Verified Access Web API is a strong signal of all of the following:
+    // * The current device is a legitimate Chrome OS device.
+    // * The current device is managed by the domain specified during
+    //   verification.
+    // * The current signed-in user is managed by the domain specified during
+    //   verification.
+    // * The current device state complies with enterprise device policy. For
+    //   example, a policy may specify that the device must not be in developer
+    //   mode.
+    // * Any device identity emitted by the verification is tightly bound to the
+    //   hardware of the current device.
+    // This function is highly restricted and will fail if the current device
+    // is not managed, the current user is not managed, or if this operation
+    // has not explicitly been enabled for the caller by enterprise device
+    // policy. The Enterprise Machine Key does not reside in the
+    // <code>"system"</code> token and is not accessible by any other API.
+    // |challenge|: A challenge as emitted by the Verified Access Web API,
+    //              encoded using Base64.

[emaxx, 2016/02/19 17:20:58]

Isn't it better to use ArrayBuffer's instead of the base64-encoded strings?

As far as I can see, the existing methods in the chrome.enterprise.platformKeys
API (or, for example, in the somehow relevant chrome.certificateProvider API)
use ArrayBuffer in order to pass and receive the binary data.

[Devlin, 2016/02/19 18:05:02]

I don't know that one is inherently better than the other (probably depends on
the data), but I would say that we should be consistent.  So yeah, I'd prefer
ArrayBuffer here.

[Darren Krahn, 2016/02/23 23:39:46]

Done.

+    // |callback|: Called back with the challenge response.
+    static void challengeMachineKey(DOMString challenge,
+                                    ChallengeCallback callback);
+
+    // Challenges a hardware-backed Enterprise User Key and emits the response
+    // as part of a remote attestation protocol. Only useful on Chrome OS and in
+    // conjunction with the Verified Access Web API which both issues challenges
+    // and verifies responses. A successful verification by the Verified Access
+    // Web API is a strong signal of all of the following:
+    // * The current device is a legitimate Chrome OS device.
+    // * The current device is managed by the domain specified during
+    //   verification.
+    // * The current signed-in user is managed by the domain specified during
+    //   verification.
+    // * The current device state complies with enterprise user policy. For
+    //   example, a policy may specify that the device must not be in developer
+    //   mode.
+    // * The public key emitted by the verification is tightly bound to the
+    //   hardware of the current device and to the current signed-in user.
+    // This function is highly restricted and will fail if the current device is
+    // not managed, the current user is not managed, or if this operation has
+    // not explicitly been enabled for the caller by enterprise user policy.
+    // The Enterprise User Key does not reside in the <code>"user"</code> token
+    // and is not accessible by any other API.
+    // |challenge|: A challenge as emitted by the Verified Access Web API,
+    //              encoded using Base64.
+    // |registerKey|: If set, the current Enterprise User Key is registered with
+    //                the <code>"user"</code> token and relinquishes the
+    //                Enterprise User Key role. The key can then be associated
+    //                with a certificate and used like any other signing key.
+    //                This key is 2048-bit RSA. Subsequent calls to this
+    //                function will then generate a new Enterprise User Key.
+    // |callback|: Called back with the challenge response.
+    static void challengeUserKey(DOMString challenge,
+                                 boolean registerKey,
+                                 ChallengeCallback callback);
   };
 };