Add OCSPVerifyResult for tracking stapled OCSP responses cross-platform.

net/cert/ocsp_verify_result.h

+// Copyright 2016 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_OCSP_VERIFY_RESULT_H
+#define NET_CERT_OCSP_VERIFY_RESULT_H
+
+#include <string>
+
+#include "base/optional.h"
+#include "net/base/net_export.h"
+#include "net/cert/ocsp_revocation_status.h"
+
+namespace net {
+
+// The result of OCSP verification. This always contains a ResponseStatus, which
+// describes whether or not an OCSP response was provided, and response level
+// errors. It optionally contains an OCSPRevocationStatus when |response_status
+// = PROVIDED|. For example, a stapled OCSP response matching the certificate,
+// and indicating a non-revoked status, will have |response_status = PROVIDED|
+// and |revocation_status = GOOD|. This is populated as part of the certificate
+// verification process, and should not be modified at other layers.
+struct NET_EXPORT OCSPVerifyResult {
+  OCSPVerifyResult();
+  OCSPVerifyResult(const OCSPVerifyResult&);
+  ~OCSPVerifyResult();
+
+  void Reset();

[Ryan Sleevi, 2016/07/18 20:08:08]

See remarks about Reset()

[dadrian, 2016/07/18 22:23:32]

Removed.

+
+  enum ResponseStatus {
+    // No OCSPResponse was stapled.
+    MISSING,
+
+    // An up-to-date OCSP response was stapled and matched the certificate.
+    PROVIDED,
+
+    // The stapled OCSP response did not have a SUCCESSFUL status.
+    BAD_RESPONSE,
+
+    // The OCSPResponseData field producedAt was outside the certificate
+    // validity period.
+    BAD_PRODUCED_AT,
+
+    // At least one OCSPSingleResponse was stapled, but none matched the
+    // certificate.
+    NO_MATCHING_RESPONSE,
+
+    // A matching OCSPSingleResponse was stapled, but was either expired or not
+    // yet valid.
+    INVALID_DATE,
+
+    // The OCSPResponse structure could not be parsed.
+    PARSE_RESPONSE,
+
+    // The OCSPResponseData structure could not be parsed.
+    PARSE_RESPONSE_DATA,
+
+  };
+
+  ResponseStatus response_status;

[Ryan Sleevi, 2016/07/18 20:08:08]

From an API perspective, I'd argue that the C++11 syntax of

ResponseStatus response_status = MISSING;

In this header represents an acceptable API contract (that is, it's not
"leaking" implementation details into the header, and serves as reasonable
documentation about the default initialization state)

This would allow you to =default in the .cc completely.

The rubric I use is largely borrowed from Lakos' "Large Scale C++ design" -
which is, what's the expected rate of change in this header, and would
everything that depends on it reasonably need to be recompiled if it changed.
The goal is to minimize changes to headers as much as possible, and keep as much
implementation status in the .cc - If it's an implementation detail, dependents
shouldn't have to be recompiled.

I would argue that this (the default = MISSING) represents a reasonable API
contract, it's not something we'd change, and we *would* want things to be
recompiled if we changed the default value, so... go ahead and C++11 it :)

[dadrian, 2016/07/18 22:23:32]

Done.

+
+  // The strictest CertStatus matching the certificate (REVOKED > UNKNOWN >
+  // GOOD). Only present if |response_status| = PROVIDED.
+  base::Optional<OCSPRevocationStatus> revocation_status;

[svaldez, 2016/07/16 08:51:53]

I think there's some disagreement over whether we should be using base::Optional
in net. Might want to check with sleevi?

[Ryan Sleevi, 2016/07/18 20:08:08]

Aye, I'm a hater of it, because I've generally seen it abused more than helpful.
But it's part of base and it's part of C++, so I am willing to accept I'm in the
minority here.

I'm not sure this really buys us anything by being optional, either from storage
or API clarity.

[dadrian, 2016/07/18 22:23:32]

Works pretty well with no optional and just a value.

Done.

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