Add parsing code for TBSCertificate's "validity" field.

net/cert/internal/parse_certificate.h

Index: net/cert/internal/parse_certificate.h
diff --git a/net/cert/internal/parse_certificate.h b/net/cert/internal/parse_certificate.h
index cf8b431b69e6bf6d3c93f54a24ce06bd8b35c0cf..9372f936efeeb0797dd6fd7e2ac296eab6fc51bb 100644
--- a/net/cert/internal/parse_certificate.h
+++ b/net/cert/internal/parse_certificate.h
@@ -54,6 +54,19 @@ NET_EXPORT bool ParseTbsCertificate(const der::Input& tbs_tlv,
                                     ParsedTbsCertificate* out)
     WARN_UNUSED_RESULT;
 
+// Parses a DER-encoded "Validity" as specified by RFC 5280. Returns true on
+// success and sets the results in |not_before| and |not_after|:
+//
+//       Validity ::= SEQUENCE {
+//            notBefore      Time,
+//            notAfter       Time }
+//
+// Note that upon success it is NOT guaranteed that |*not_before <= *not_after|.
+NET_EXPORT bool ParseValidity(const der::Input& validity_tlv,
+                              der::GeneralizedTime* not_before,
+                              der::GeneralizedTime* not_after)
+    WARN_UNUSED_RESULT;
+
 // Represents a "Version" from RFC 5280:
 //         Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }
 enum class CertificateVersion {
@@ -142,6 +155,8 @@ struct NET_EXPORT ParsedTbsCertificate {
   //
   // This contains the full (unverified) Tag-Length-Value for a SEQUENCE. No
   // guarantees are made regarding the value of this SEQUENCE.
+  //
+  // This can be further parsed using ParseValidity().
   der::Input validity_tlv;

[davidben, 2015/08/14 18:23:10]

Since it's just two fields, I wonder if you should just put not_before and
not_after fields directly into ParsedCertificate. (I dunno what's the criteria
for deciding what does or doesn't get parsed in each pass and probably missed
some design discussions.)

[eroman, 2015/08/14 18:37:04]

I discuss the design overview in this message:
https://codereview.chromium.org/1279963003/#msg2

My rough guideline was that any non-SEQUENCE of Certificate/TBSCertificate would
be parsed fully, and the SEQUENCEs would be deferred to a subsequent parsing
call.

The thinking behind this was primarily to simplify an incremental
implementation, but also with a secondary consideration for performance
(consumers can pick out the pieces they want without having to fully parse
stuff).

In this case it may be better to just parse Validity up-front; I can go ahead
and do that. The only real downside (for me the coder) is it involves needing to
update all the pseudo-TBSCertificate test data :)

 
   // Corresponds with "subject" from RFC 5280: