Refactor how net/data/verify_certificate_chain_unittest/*

net/data/verify_certificate_chain_unittest/README

Index: net/data/verify_certificate_chain_unittest/README
diff --git a/net/data/verify_certificate_chain_unittest/README b/net/data/verify_certificate_chain_unittest/README
index 87a46987990f19acbb63f9f1afe99e9294f9fa45..073abd7fa9949f835f236bc262302cf7f0371451 100644
--- a/net/data/verify_certificate_chain_unittest/README
+++ b/net/data/verify_certificate_chain_unittest/README
@@ -1,79 +1,78 @@
 This directory contains test data for verifying certificate chains.
 
-It contains the following types of files:
+Tests are grouped into directories that contain the keys, python to generate
+chains, and test expectations. "DIR" is used as a generic placeholder below to
+identify such a directory.
 
 ===============================
-generate-*.py
+DIR/generate-chains.py
 ===============================
 
-Generates the file for an individual test case. If the python file was
-named generate-XXX.py, then the corresponding output will be named
-XXX.pem.
+Python script that generates one or more ".pem" file containing a sequence of
+CERTIFICATE blocks. In most cases it will generate a single chain called
+"chain.pem".
 
 ===============================
-generate-all.sh
+DIR/keys/*.key
 ===============================
 
-Runs all of the generate-*.py scripts and does some cleanup.
+The keys used (as well as generated) by the .py file generate-chains.py. The
+private keys shouldn't be needed to run the tests, however are useful when
+re-generating the test data to have stable results (at least for signature
+types which are deterministic, like RSASSA PKCS#1 which is used by most of the
+certificates data).
 
 ===============================
-keys/XXX/*.key
+DIR/*.pem
 ===============================
 
-The keys used/generated by test XXX. The private keys shouldn't be needed to run
-the tests, however are useful when re-generating the test data to have stable
-results (at least for signature types which are deterministic, like RSASSA
-PKCS#1 which is used by most of the certificates data).
+A sequence of CERTIFICATE blocks that was created by the generate-chains.py
+script. (Although in a few cases there are manually created .pem files that
+lack a generator script).
 
 ===============================
-*.pem
+DIR/*.test
 ===============================
 
-Each .pem file describes the inputs for certificate chain verification, and the
-expected result. These are the PEM blocks that each file contains and their
-interpretation:
-
-CERTIFICATE:
-
-These PEM blocks describe the ordered chain of certificates starting from the
-target certificate and progressing towards the trust anchor (but not including
-the trust anchor).
-
- - There must be one or more such PEM blocks
- - Its contents are a DER-encoded X.509 certificate
- - The first block is the target certificate
- - The (i+1)th CERTIFICATE is (allegedly) the one which issued the ith
-   CERTIFICATE.
+A sequence of key-value pairs that identify the inputs to certificate
+verification, as well as the expected outputs. The format is essentially a
+newline separated sequence of key/value pairs:
 
-TRUST_ANCHOR_{XXX}:
+key: value\n
 
-This PEM block describes the trust anchor to use when verifying the chain.
-There are two possible names for this PEM block, which affect how it is
-interpreted: TRUST_ANCHOR_CONSTRAINED or TRUST_ANCHOR_UNCONSTRAINED.
+All keys must be specified by tests, although they can be in any order.
+The possible keys are:
 
- - There must be exactly one TRUST_ANCHOR_{XXX} block.
- - Its contents are a DER-encoded X.509 certificate
- - The subject and SPKI from the certificate define the trust anchor
- - If the block was named TRUST_ANCHOR_CONSTRAINED, then any constraints on the
-   certificate are also considered normative when verifying paths. Otherwise
-   any standard extensions provided by the root certificate are not used during
-   path validation.
+  "chain" - The value is a file path (relative to the test file) to a .pem
+      containing the CERTIFICATE chain.
 
-TIMESTAMP:
+  "last_cert_trust" - The value identifies the trustedness of the last
+      certificate in the chain (i.e. whether it is a trust anchor or not). This
+      maps to the CertificateTrustType enum. Possible values are:
+          "TRUSTED_ANCHOR"
+          "TRUSTED_ANCHOR_WITH_CONSTRAINTS"
+          "UNSPECIFIED"
+          "DISTRUSTED"
 
-This PEM block describes the time to use when verifying the chain.
+  "utc_time" - A string encoding for the generalized time at which verification
+      should be done. Example "150302120000Z"
 
- - There must be exactly one such PEM block
- - Its contents are a DER-encoded UTCTime.
+  "key_purpose" - The expected EKU to use when verifying. Maps to
+      KeyPurpose enum. Possible values are:
+      "ANY_EKU"
+      "SERVER_AUTH"
+      "CLIENT_AUTH"
 
-VERIFY_RESULT:
+  "errors" - This has special parsing rules: it is interpreted as the
+      final key in the file. All lines after "errors:\n" are read as being the
+      error string (this allows embedding newlines in it).
 
-This PEM block describes the expected result from verifying the path.
+Additionally, it is possible to add python-style comments by starting a line
+with "#".
 
- - There must be exactly one such PEM block
- - Its contents are a string with value of either "SUCCESS" or "FAIL"
-
-ERRORS:
+===============================
+generate-all.sh
+===============================
 
-This PEM block is a pretty-printed textual dump of all the errors, as given by
-CertErrors::ToDebugString().
+Runs all of the generate-chains.py scripts and cleans up the temp files
+afterwards.