Add new certificateProvider extension API.

chrome/common/extensions/api/certificate_provider.idl

Index: chrome/common/extensions/api/certificate_provider.idl
diff --git a/chrome/common/extensions/api/certificate_provider.idl b/chrome/common/extensions/api/certificate_provider.idl
new file mode 100644
index 0000000000000000000000000000000000000000..9b202754eb30f77b92b30c6c031b7124d60b7492
--- /dev/null
+++ b/chrome/common/extensions/api/certificate_provider.idl
@@ -0,0 +1,72 @@
+// Copyright 2015 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.
+
+// Use this API to make certificates, for example from a Smart Card, available
+// to the platform which can then use these certificates for TLS client
+// authentication.
+namespace certificateProvider {
+  enum Hash {
+    MD5_SHA1,
+    SHA1,
+    SHA256,
+    SHA384,
+    SHA512
+  };
+
+  dictionary CertificateInfo {
+    // Must be the DER encoding of a X.509 client certificate.
+    ArrayBuffer certificate;

[davidben, 2015/07/10 14:03:32]

Is there a story for the smartcard sending a certificate chain / do we need one?
(Or is that to be built using certificates in NSS? I've always found the client
certificate chain configuration story bizarre.)

[pneubeck (no reviews), 2015/08/17 12:13:03]

We can add this if it ever becomes an important requirement.

+
+    // Must be set to all hashes supported for this certificate. This extension
+    // will only be asked for signatures of digests calculated with one of these
+    // hash algorithms.
+    Hash[] supportedHashes;
+  };
+
+  dictionary SignRequest {

[davidben, 2015/07/10 14:03:32]

Shouldn't this include the certificate we're trying to sign with or some other
handle to the private key? Otherwise you don't know which is in use.

[pneubeck (no reviews), 2015/07/10 15:17:25]

ops. of course. I'll probably add
 // The certificate of the key that must be used for signing the digest.
 ArrayBuffer certificate

(ArrayBuffer publicKey
 would be another option)

+    // The digest that must be signed.
+    ArrayBuffer digest;
+
+    // Refers to the hash algorithm that was used to create |digest|.
+    Hash hash;
+  };
+
+  // Either |error| or |signature| and not both must be set.
+  dictionary SignatureDetails {
+    // If the signature of the digest could not be calculated, this field must
+    // be set.
+    DOMString? error;
+
+    // If no error occurred, this field must be set to the signature of the
+    // digest using the private the of the requested client certificate.
+    // For an RSA key, the signature must be a PKCS#1 signature. The extension
+    // is responsible for prepending the DigestInfo prefix and adding PKCS#1
+    // padding.

[davidben, 2015/07/10 14:03:32]

Nit: Dunno if it's worth explicitly mentioning here or at the top that MD5_SHA1
is weird and doesn't have DigestInfo padding? Pre-TLS-1.2 had a somewhat custom
construct.

[pneubeck (no reviews), 2015/07/10 15:17:25]

Yes, we should probably explain such in more detail.

[pneubeck (no reviews), 2015/08/17 12:13:02]

I'll remove MD5_SHA1 for now. Doesn't seem to be required by the VPN providers
that we know of.

[davidben, 2015/08/18 21:17:52]

[Commented in other CL, but MD5_SHA1 is the only hash that can be signed before
TLS 1.2, so it almost certainly needs to be there. VPN providers might have
confused it with something else.]

+    ArrayBuffer? signature;
+  };
+
+  callback DoneCallback = void ();
+
+  interface Functions {
+    // Notifies Chrome that this extension is capable of responding to signing
+    // requests for the certificates listed in |certificates|. The list must
+    // only contain certificates for which the extension can sign data
+    // using the associated private key.
+    static void publishClientCertificates(CertificateInfo[] certificates,
+                                          DoneCallback callback);

[davidben, 2015/07/10 14:03:32]

Any reason why it's publicClientCertificates and not an async
getClientCeritifcates API? It seems the latter would be more natural and save us
maintaining a list in-memory on behalf of the xtn.

[pneubeck (no reviews), 2015/08/17 12:13:02]

(thoroughly discussed in the implementation in another CL, just a few points for
other readers)

At least with the currently synchronous FetchClientCertPrivateKey I don't see
how we can avoid caching the certificate list in Chrome.
However, we agreed that notifying the extension, allows the extension to delay
loading certificates if it wants to.

My main criticism of the notification is that we leak information about when the
user is using client authentication.

[davidben, 2015/08/18 21:17:52]

It seems it's a getClientCertificates API now but, for posterity,
FetchClientCertPrivateKey doesn't constrain this at all. That's done once we've
selected a single cert. Querying the certificate list needn't be synchronous.
I don't think this is much of a concern. You don't actually get much information
about it. Also, realistically, people aren't likely to have client certs from
multiple deployments at once so the only certificates available are the ones
from this provider anyway.

Plus, for privacy, client certs are already horrible. They send the certificate
in the clear. :-)

+
+    // Responses to a previous |onSignDigestRequested| event. |requestId| must
+    // match the id of such an event. For each id, this function must be called
+    // exactly once.
+    static void replyToSignRequest(long requestId, SignatureDetails reply);
+  };
+
+  interface Events {
+    // This event fires every time the browser needs to sign a message using a
+    // certificate provided by this extension using |publishClientCertificates|.
+    // The extension must sign the data in |request| using the appropriate
+    // algorithm and private key and return it using |replyToSignRequest|.
+    static void onSignDigestRequested(long requestId, SignRequest request);
+  };
+};