Add parsers for the Encryption and Encryption-Key HTTP headers.

components/gcm_driver/crypto/encryption_header_parsers.h

Index: components/gcm_driver/crypto/encryption_header_parsers.h
diff --git a/components/gcm_driver/crypto/encryption_header_parsers.h b/components/gcm_driver/crypto/encryption_header_parsers.h
new file mode 100644
index 0000000000000000000000000000000000000000..0ca82a0e68e9d914f7713f5a9cff9bdfa2b796ea
--- /dev/null
+++ b/components/gcm_driver/crypto/encryption_header_parsers.h
@@ -0,0 +1,43 @@
+// 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.
+
+#ifndef COMPONENTS_GCM_DRIVER_CRYPTO_ENCRYPTION_HEADER_PARSERS_H_
+#define COMPONENTS_GCM_DRIVER_CRYPTO_ENCRYPTION_HEADER_PARSERS_H_
+
+#include <stdint.h>
+#include <string>
+#include <vector>
+
+namespace gcm {
+
+// Structure representing a parsed and decoded value from the Encryption header.
+// https://tools.ietf.org/html/draft-thomson-http-encryption-01#section-3
+struct EncryptionHeaderValue {
+  std::string keyid;
+  std::string salt;
+  int64_t rs = 4096;
+};
+
+// Structure representing a parsed and decoded value from the Encryption-Key
+// header.
+// https://tools.ietf.org/html/draft-thomson-http-encryption-01#section-4
+struct EncryptionKeyHeaderValue {
+  std::string keyid;
+  std::string key;
+  std::string dh;
+};
+
+// Parses |input| following the syntax of the Encryption HTTP header. Returns
+// whether the |input| could be parsed into |result| successfully.
+bool ParseEncryptionHeader(const std::string& input,
+                           std::vector<EncryptionHeaderValue>* result);
+
+// Parses |input| following the syntax of the Encryption-Key HTTP header.
+// Returns whether the |input| could be parsed into |result| successfully.
+bool ParseEncryptionKeyHeader(const std::string& input,

[johnme, 2015/07/21 14:34:43]

I'm not sure this is the optimal API. Unless I'm misreading the spec, it seems
that an Encryption-Key entry must always be paired with an Encryption entry that
has the same keyid (the reverse is not true, since there may be no
Encryption-Key entry).

So it seems this parser would be easier to use if it took care of matching the
entries based on their keyids, e.g.:

// Pass an empty string for encryption_key_header if it was omitted.
ParseEncryptionHeaders(
    const std::string& encryption_header,
    const std::string& encryption_key_header,
    std::vector<EncryptionHeadersValue>* result);

struct EncryptionHeadersValue {
  // keyid, key and dh may be empty.
  std::string keyid;
  std::string salt;
  int64_t rs = 4096;
  std::string key;
  std::string dh;
}

[Peter Beverloo, 2015/07/21 17:51:30]

My thinking here is that they are two separate headers, with separate value
requirements. Furthermore, since the "keyid" name may be omitted when the UA has
other means of matching key information with a request, for example the used
subscription Id (which we use), and header values could theoretically be
repeated, it will not always be clear what to match with what.

Additionally, while we will be the DH parameter of the Encryption-Key header,
other consumers may only need Encryption. draft-thomson-http-encryption-01 has
been set up to be generic, which means it's likely that we'll get a second
consumer in Chrome, in which case componentizing this (or moving it elsewhere)
is beneficial.

+                              std::vector<EncryptionKeyHeaderValue>* result);
+
+}  // namespace gcm
+
+#endif  // COMPONENTS_GCM_DRIVER_CRYPTO_ENCRYPTION_HEADER_PARSERS_H_