Add DER parsing of AlgorithmId for signatures.

net/cert/internal/signature_algorithm.h

Index: net/cert/internal/signature_algorithm.h
diff --git a/net/cert/internal/signature_algorithm.h b/net/cert/internal/signature_algorithm.h
new file mode 100644
index 0000000000000000000000000000000000000000..6ea832ce9060d470bf59be1c2f649d1396fdbbe7
--- /dev/null
+++ b/net/cert/internal/signature_algorithm.h
@@ -0,0 +1,49 @@
+// 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 NET_CERT_INTERNAL_SIGNATURE_ALGORITHM_H_
+#define NET_CERT_INTERNAL_SIGNATURE_ALGORITHM_H_
+
+#include "base/compiler_specific.h"
+#include "net/base/net_export.h"
+
+namespace net {
+
+namespace der {
+class Input;
+}
+
+enum class SignatureAlgorithmId {
+  RsaPkcs1_5,
+  Ecdsa,
+};
+
+enum class DigestAlgorithmId {
+  Sha1,
+  Sha256,
+  Sha384,
+  Sha512,
+};
+
+// SignatureAlgorithm describes a signature algorithm and its parameters. This
+// corresponds to "AlgorithmIdentifier" from RFC 5280.
+struct NET_EXPORT SignatureAlgorithm {

[Ryan Sleevi, 2015/06/29 16:36:29]

DESIGN: It seems weird to have a structure with enum members that can be created
in an undefined/ambiguous state.

Should this be moved to a proper class-type with explicit constructors &
copying? What if someone just slings a ('null') SignatureAlgorithm around, which
looks like it'd be seen as RSA-PKCS#1 v1.5 with SHA-1

[eroman, 2015/06/29 17:05:06]

I will switch this to a full blown class.

+  // Assigns the SignatureAlgorithm by parsing a DER-encoded
+  // "AlgorithmIdentifier" (RFC 5280).
+  //
+  // Returns true on success.
+  bool AssignFromDer(const der::Input& signature_algorithm) WARN_UNUSED_RESULT;
+
+  // Returns true if |*this| is equivalent to |other|.
+  bool Equals(const SignatureAlgorithm& other) const WARN_UNUSED_RESULT;
+
+  SignatureAlgorithmId algorithm;
+  DigestAlgorithmId digest;
+
+  // TODO(eroman): Add support for RSASSA-PSS.

[Ryan Sleevi, 2015/06/29 16:36:29]

Is the idea being that you'll support RSASSA-PSS via explicit sub members? What
about the work for EdDSA (Curve25519), which may have similar sub-parameters
beyond hash? (I can never quite follow it)

I'm just curious how you see handling SignatureAlgorithms with params in a
general case, with PSS being a concrete example.

[eroman, 2015/06/29 17:05:06]

Let me go ahead and add RSASSA-PSS support to this changelist, and then we can
discuss the design in more concrete terms.

My thinking for RSASSA-PSS was to just inline the salt length parameter into
SignatureAlgorithm, and then add an enum for RsaSsaPss. I figured for the
current set of verification algorithms this approach would be sufficient.

When we out-grow this and need to add more parameters for future algorithms, we
could switch to using something like WebCryptoAlgorithm which allows for a
separate heap-allocated parameters object.

An alternate design would be to keep the DER-encoded AlgorithmIdentifier as the
canonical representation. This solves needing to duplicate the representation
for each algorithm. The downside is this can lead to code that re-parses the DER
in several places (when validating the algorithm vs doing the verification vs
comparing algorithms), which I think makes for a weaker layering.

+};
+
+}  // namespace net
+
+#endif  // NET_CERT_INTERNAL_SIGNATURE_ALGORITHM_H_