net/data/verify_certificate_chain_unittest/README - Issue 2805213004: Refactor how net/data/verify_certificate_chain_unittest/*

Side by Side Diff: net/data/verify_certificate_chain_unittest/README

Issue 2805213004: Refactor how net/data/verify_certificate_chain_unittest/* (Closed)

Patch Set: rebase Created 3 years, 7 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

« net/cert/internal/test_helpers.cc ('K') | « net/cert/internal/verify_certificate_chain_unittest.cc ('k') | net/data/verify_certificate_chain_unittest/basic-constraints-pathlen-0-self-issued.pem » ('j') | net/data/verify_certificate_chain_unittest/common.py » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
1 This directory contains test data for verifying certificate chains.	1 This directory contains test data for verifying certificate chains.

2	2

3 It contains the following types of files:	3 Tests are grouped into directories that contain the keys, python to generate

	4 chains, and test expectations. "DIR" is used as a generic placeholder below to

	5 identify such a directory.

4	6

5 ===============================	7 ===============================

6 generate-*.py	8 DIR/generate-chain[s].py

7 ===============================	9 ===============================

8	10

9 Generates the file for an individual test case. If the python file was	11 Python script that generates a ".pem" file containing a sequence of CERTIFICATE

10 named generate-XXX.py, then the corresponding output will be named	12 blocks.

11 XXX.pem.	13

	14 ===============================

	15 DIR/keys/*.key

	16 ===============================

	17

	18 The keys used/generated by the test. The private keys shouldn't be needed to run

	19 the tests, however are useful when re-generating the test data to have stable

	20 results (at least for signature types which are deterministic, like RSASSA

	21 PKCS#1 which is used by most of the certificates data).

	22

	23 ===============================

	24 DIR/*.pem

	25 ===============================

	26

	27 A sequence of CERTIFICATE blocks that was created by the generate-chain.py

	28 script (typically).

	29

	30 ===============================

	31 DIR/*.test

	32 ===============================

	33

	34 A sequence of key-value pairs that identify the inputs to certificate

	35 verification, as well as the expected outputs. It's grammar is:

	36

	37 chain: <path to .pem file>

	38 last_cert_trust: "trustAnchor" \| "trustAnchor (enforcesConstraints)" \| "distrust ed" \| "unspecified"

	39 utc_time: <string of the UTC time to do verification at>
	mattm 2017/05/02 06:43:46 key_purpose should be mentioned here key_purpose should be mentioned here eroman 2017/05/02 19:20:23 Done. Show quoted text On 2017/05/02 06:43:46, mattm wrote: > key_purpose should be mentioned here Done.
	40 errors: "" \| "\n" <errors>
	mattm 2017/05/02 06:43:46 expected_errors expected_errors eroman 2017/05/02 19:20:23 Done. Show quoted text On 2017/05/02 06:43:46, mattm wrote: > expected_errors Done.
12	41

13 ===============================	42 ===============================

14 generate-all.sh	43 generate-all.sh

15 ===============================	44 ===============================

16	45

17 Runs all of the generate-*.py scripts and does some cleanup.	46 Runs all of the generate-*.py scripts and does some cleanup.

18

19 ===============================

20 keys/XXX/*.key

21 ===============================

22

23 The keys used/generated by test XXX. The private keys shouldn't be needed to run

24 the tests, however are useful when re-generating the test data to have stable

25 results (at least for signature types which are deterministic, like RSASSA

26 PKCS#1 which is used by most of the certificates data).

27

28 ===============================

29 *.pem

30 ===============================

31

32 Each .pem file describes the inputs for certificate chain verification, and the

33 expected result. These are the PEM blocks that each file contains and their

34 interpretation:

35

36 CERTIFICATE:

37

38 These PEM blocks describe the ordered chain of certificates starting from the

39 target certificate and progressing towards the trust anchor (but not including

40 the trust anchor).

41

42 - There must be one or more such PEM blocks

43 - Its contents are a DER-encoded X.509 certificate

44 - The first block is the target certificate

45 - The (i+1)th CERTIFICATE is (allegedly) the one which issued the ith

46 CERTIFICATE.

47

48 TRUST_ANCHOR_{XXX}:

49

50 This PEM block describes the trust anchor to use when verifying the chain.

51 There are two possible names for this PEM block, which affect how it is

52 interpreted: TRUST_ANCHOR_CONSTRAINED or TRUST_ANCHOR_UNCONSTRAINED.

53

54 - There must be exactly one TRUST_ANCHOR_{XXX} block.

55 - Its contents are a DER-encoded X.509 certificate

56 - The subject and SPKI from the certificate define the trust anchor

57 - If the block was named TRUST_ANCHOR_CONSTRAINED, then any constraints on the

58 certificate are also considered normative when verifying paths. Otherwise

59 any standard extensions provided by the root certificate are not used during

60 path validation.

61

62 TIMESTAMP:

63

64 This PEM block describes the time to use when verifying the chain.

65

66 - There must be exactly one such PEM block

67 - Its contents are a DER-encoded UTCTime.

68

69 VERIFY_RESULT:

70

71 This PEM block describes the expected result from verifying the path.

72

73 - There must be exactly one such PEM block

74 - Its contents are a string with value of either "SUCCESS" or "FAIL"

75

76 ERRORS:

77

78 This PEM block is a pretty-printed textual dump of all the errors, as given by

79 CertErrors::ToDebugString().

OLD	NEW