Implement VerifySignedData() for ECDSA, RSA PKCS#1 and RSA PSS.

net/cert/internal/verify_signed_data.h

+// 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_VERIFY_SIGNED_DATA_H_
+#define NET_CERT_INTERNAL_VERIFY_SIGNED_DATA_H_
+
+#include "base/compiler_specific.h"
+#include "net/base/net_export.h"
+
+namespace net {
+
+namespace der {
+class Input;
+}  // namespace der
+
+class SignatureAlgorithm;
+
+// Verifies that |signature_value| is a valid signature of |signed_data| using
+// the algorithm |signature_algorithm| and the public key |public_key|.
+//
+//   |signature_algorithm| - The parsed AlgorithmIdentifier
+//   |signed_data| - The blob of data to verify
+//   |signature_value| - The bytes for the signature's value, to be interpreted
+//        according to the signature algorithm.
+//        IMPORTANT: In RFC 5280, signatureValue is a BIT STRING. The expected
+//        input to this function is the byte contents of that bit string, and
+//        not the BIT STRING's DER itself.

[davidben, 2015/07/21 16:26:27]

"byte contents of that bit string" vs "BIT STRING's DER itself" is a little
ambiguous. I could either interpret it as:

- signature_value is the byte string with the 00 phase octet removed, not the
contents of the DER-encoded BIT STRING, phase octet included

- signature_value is the byte string contents of the BIT STRING, including the
phase octet, not the entire DER element.

Going by the code, it seems you mean the former.


I would write this as:

// IMPORTANT: In RFC 5280, signatureValue is a BIT STRING, however all supported
signature algorithms use byte strings encoded as a BIT STRING with a consistent
encoding. |signature_value| is a byte string, so the caller must decode the BIT
STRING by removing the first DER contents octet and checking the value is zero.

The specs are apparently incredibly badly-written on this point. RFC 3279,
section 2.2 just says "This signature value is then ASN.1 encoded as a BIT
STRING" and then goes on to describe three signature formats of type []byte, not
[]bit. RFC 4055, section 3.2 is much more explicit about the encoding.)


The other option is what signature_value is actually the BIT STRING
representation and VerifySignedData internally strips off and checks/strips the
leading phase octet internally. (We can reject anything that's not 00. X.509
using BIT STRING was just plain a mistake.)

[eroman, 2015/07/21 19:24:28]

OK so thinking about this more, I think it makes the most sense to just change
the input to a BIT STRING.

Initially I was torn on whether this API should take a BIT STRING, or require
the caller to extract the contents. I settled on the latter mainly out of
laziness, because much of my test data was already in that format.

But based on how it will be called, it is going to be more helpul to just take a
BIT STRING and do all the magic of extraction and making sure there non-multiple
of 8 bits etc in VerifySignedData.

Unless you object, I will start converting the test data to the new format and
update once that is complete (and then this comment can be simplified).

[davidben, 2015/07/21 19:41:14]

SGTM. This is a pretty X.509-specific interface, so making it take the X.509
type, even though the X.509 type is completely idiotic, is probably sane. :-)

+//   |public_key| - A DER-encoded SubjectPublicKeyInfo.
+//
+// Returns true if verification was successful.
+NET_EXPORT bool VerifySignedData(const SignatureAlgorithm& signature_algorithm,
+                                 const der::Input& signed_data,
+                                 const der::Input& signature_value,
+                                 const der::Input& public_key)
+    WARN_UNUSED_RESULT;
+
+}  // namespace net
+
+#endif  // NET_CERT_INTERNAL_VERIFY_SIGNED_DATA_H_