Adds RTCCertificate, a reference counted object indirectly owning an SSLCertificate

webrtc/base/rtccertificate.cc

+/*
+ *  Copyright 2015 The WebRTC Project Authors. All rights reserved.
+ *
+ *  Use of this source code is governed by a BSD-style license
+ *  that can be found in the LICENSE file in the root of the source
+ *  tree. An additional intellectual property rights grant can be found
+ *  in the file PATENTS.  All contributing project authors may
+ *  be found in the AUTHORS file in the root of the source tree.
+ */
+
+#include "webrtc/base/rtccertificate.h"
+
+#include "webrtc/base/checks.h"
+
+namespace rtc {
+
+scoped_refptr<RTCCertificate> RTCCertificate::Create(
+    scoped_ptr<SSLIdentity> identity) {
+  return new RefCountedObject<RTCCertificate>(identity.release());
+}
+
+RTCCertificate::RTCCertificate(SSLIdentity* identity)
+    : identity_(identity) {
+  DCHECK(identity_);
+}
+
+
+uint64 RTCCertificate::expires_ns() const {

[torbjorng (webrtc), 2015/08/19 15:23:19]

Is "ns" here for nanoseconds? I believe a saved expires field ought to be a time
stamp, not a field of remaining time.

[hbos, 2015/08/19 16:04:32]

Yes ns for nanoseconds, but meant as a timestamp. I looked at timeutils.h and
saw Time(), TimeMicros() and TimeNanos(); these are the "current time in
milli/micro/nanoseconds". Maybe there is a date format that could be used
instead, but I'm assuming these are time since 1970.

Time() returns uint32 so I'm guessing that has wrap around problems if you care
about the date. The other two Time...() are uint64 and should be fine. And I'm
hoping a timestamp like this is easily convertable to a blink/JavaScript type of
date.

I'll make the name clearer though to avoid this confusion.

(tommi might be more familiar with date and time in webrtc/blink?)

+  // TODO(hbos): Update once SSLIdentity/SSLCertificate supports expires field.
+  return 0;
+}
+
+const SSLCertificate& RTCCertificate::ssl_certificate() const {

[torbjorng (webrtc), 2015/08/19 15:23:19]

I suspect (but haven't checked) that we'd need access to the keypair too at this
abstraction level (although that is of course not part of the cert, but it might
anyway for ownership reasons be easiest to do it here).

[hbos, 2015/08/19 16:04:32]

Agreed.

The keypair would be an implementation-specific thing, so whatever needs to know
about the keypair should get the SSLIdentity*, not some abstract "key pair"
class, correct? (Otherwise I could add getters for that and still hide the raw
SSLIdentity*).

+  return identity_->certificate();
+}
+
+}  // namespace rtc