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..b46afe7800b97b40bc2f31fe722d31f8e9b76652
--- /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>
+
+namespace gcm {
+
+// Parses |input| following the syntax of the Encryption HTTP header. Chrome

[Ryan Sleevi, 2015/09/28 19:35:48]

I don't believe //components should be talking about Chrome, especially since
//components are designed to be reusable.

[Peter Beverloo, 2015/10/01 14:56:20]

Done.

+// only supports a single set of properties to be read from the header at this

[Ryan Sleevi, 2015/09/28 19:35:48]

I'm having trouble parsing this, based on header + draft alone.

When you say 'single set of properties', are you describing the multiple layers
of encryption that may be applied? If so, why the arbitrary limitation for a
single layer of encryption? That seems non-conformant - if we don't want to
support that, we should be clear about that (and arguably the spec should
adapt), otherwise, we should support multiple layers, and it may  make more
sense from an API contract to have some form of parser/iterator that takes a
combined header value and then outputs the parameters for each subsequent layer
of encryption.

As the API is designed now, it's not possible to even support multiple layers
without recoding these interfaces, that's why I'm trying to figure out the
reasoning.

[Peter Beverloo, 2015/10/01 14:56:20]

Done.

+// time. The base64url encoded salt will be decoded, the rs will be validated.
+//
+// https://tools.ietf.org/html/draft-thomson-http-encryption-01#section-3
+//
+// Returns whether the |input| was successfully be parsed, and the resulting
+// information was stored in |keyid|, |salt| and |rs|. The output arguments will
+// not be changed unless parsing was successful.
+bool ParseEncryptionHeader(const std::string& input,
+                           std::string* keyid,
+                           std::string* salt,
+                           uint64_t* rs);
+
+// Parses |input| following the syntax of the Encryption-Key HTTP header. Chrome
+// only supports a single set of properties to be read from the header at this

[Ryan Sleevi, 2015/09/28 19:35:48]

Ditto confusion

[Peter Beverloo, 2015/10/01 14:56:20]

Done.

+// time. The base64url encoded key and dh will be decoded.
+//
+// https://tools.ietf.org/html/draft-thomson-http-encryption-01#section-4
+//
+// Returns whether |input| was successfully parsed, and the resulting
+// information was stored in |keyid|, |key| and |dh|. The output arguments will
+// not be changed unless parsing was successful.
+bool ParseEncryptionKeyHeader(const std::string& input,
+                              std::string* keyid,
+                              std::string* key,
+                              std::string* dh);
+
+}  // namespace gcm
+
+#endif  // COMPONENTS_GCM_DRIVER_CRYPTO_ENCRYPTION_HEADER_PARSERS_H_