SignedCertificateTimestamp storing & serialization code.

net/cert/ct_verify_result.h

Index: net/cert/ct_verify_result.h
diff --git a/net/cert/ct_verify_result.h b/net/cert/ct_verify_result.h
index ac0a74bd9da5b87f48e55296170fac62e53fd4ea..4ce6cb66fa615ffb719175a296e7ad782249fe80 100644
--- a/net/cert/ct_verify_result.h
+++ b/net/cert/ct_verify_result.h
@@ -25,7 +25,7 @@ struct NET_EXPORT CTVerifyResult {
   // SCTs from known logs where the signature verified correctly.
   SCTList verified_scts;
   // SCTs from known logs where the signature failed to verify.
-  SCTList unverified_scts;
+  SCTList invalid_scts;

[wtc, 2013/11/28 01:28:02]

Nit: Please discuss with Eran to standardize these two member names. It seems
that ideally they should look opposite: "verified vs. unverified" or "valid vs.
invalid".

[alcutter, 2013/11/28 12:08:19]

The problem is that "verified" is the right word for SCTs which have been found
to be valid, but the opposite of that isn't "unverified".

Equally, SCTs for which we don't have the public key may well also in fact be
valid, but we can't verify them so calling the list of SCTs we were able to
check valid_scts feels wrong too.

Since it's effectively tri-state logic, trying to name with opposites is always
going to end up with one list with an incongruous name. So maybe the right
answer is something along the lines of:  verified_scts, invalid_scts,
unverified_scts ?

I'll prepare a follow up patch for that combo so as to not block this on names,
I hope that's ok.

[wtc, 2013/11/28 16:15:07]

Yes, it's ok to deal with names in a follow-up CL.

[alcutter, 2013/11/28 16:42:18]

Ack.

   // SCTs from unknown logs.
   SCTList unknown_logs_scts;
 };