Rename net::ct::LogEntry to SignedEntryData and clarify the comment.

net/cert/signed_certificate_timestamp.h

Index: net/cert/signed_certificate_timestamp.h
diff --git a/net/cert/signed_certificate_timestamp.h b/net/cert/signed_certificate_timestamp.h
index 96eded2c54bd95abf7738f275c0fa9904129e513..abccf782fb89b7f0960c9bea31e9e31ae8432f60 100644
--- a/net/cert/signed_certificate_timestamp.h
+++ b/net/cert/signed_certificate_timestamp.h
@@ -24,7 +24,12 @@ namespace net {
 // Structures related to Certificate Transparency (RFC6962).
 namespace ct {
 
-// LogEntry struct in RFC 6962, Section 3.1
+// Similar to LogEntry struct in RFC 6962, Section 3.1, with the following
+// differences:
+// 1. Only contains end-entities, no chains.
+// 2. Instead of a Precertificate, it contains a PreCert(from Section 3.2).
+//    (Precertificate = Certificate with poison extension
+//     PreCert = issuer_key_hash + TBSCertificate without poison extension)

[Ryan Sleevi, 2017/04/18 14:53:29]

Right, this is actually the signed_entry of an SCT from
https://tools.ietf.org/html/rfc6962#section-3.2

Maybe this should be renamed SignedEntryData?

Eran, what do you think?

It'd be much larger to rename, so I'm not necessarily requesting that in this
CL, but perhaps that context is worth updating the comment to reflect that.

// Contains the data necessary to reconstruct the signed_entry
// of a SignedCertificateTimestamp, from RFC 6962, Section 3.2.
//
// All the data necessary to validate a SignedCertificateTimestamp
// is present within the SignedCertificateTimestamp, except for
// the signature_type, entry_type, and the actual entry. The only
// supported signature_type at present is certificate_timestamp.
// The entry_type is implicit from the context in which it is
// received (those in the X.509 extension are precert_entry, all
// others are x509_entry). The signed_entry itself is
// reconstructed from the certificate (or precertificate) being
// verified.
// The SignedEntryData contains this reconstructed data, and can
// be used to either generate or verify SCTs.


(Is the very wordy answer)

WDYT?

[Eran Messeri, 2017/04/19 10:42:07]

Nit: The precertificate isn't being verified - it could be a certificate
corresponding to a precertificate that's being verified. That bit in the comment
seems to me a bit confusing.
Nit: Verify the signature in the SCT? 
I agree - SignedEntryData sounds like a much better name. The assessment that
this is not really a 'LogEntry' struct as defined in 6962 Section 3.1. is
accurate, this structure is indeed only useful for reconstructing the data which
is signed by the signature in the SignedCertificateTimestamp.

[mattm, 2017/04/21 21:12:15]

Done.

 struct NET_EXPORT LogEntry {
   // LogEntryType enum in RFC 6962, Section 3.1
   enum Type {
@@ -41,6 +46,7 @@ struct NET_EXPORT LogEntry {
   // Set if type == LOG_ENTRY_TYPE_X509
   std::string leaf_certificate;
 
+  // PreCert struct in RFC 6962, Section 3.2.
   // Set if type == LOG_ENTRY_TYPE_PRECERT
   SHA256HashValue issuer_key_hash;
   std::string tbs_certificate;