diff --git a/Gemfile b/Gemfile index 0a66e38e..ec2dad40 100644 --- a/Gemfile +++ b/Gemfile @@ -1,5 +1,5 @@ source 'https://rubygems.org' gem 'json_pure' -gem 'cddl', '>=0.12.5' +gem 'cddl', '>=0.12.6' gem 'cbor-diag', '>=0.8.7' diff --git a/Makefile b/Makefile index 4ffbfad1..35a2c2c6 100644 --- a/Makefile +++ b/Makefile @@ -14,7 +14,7 @@ include cddl/corim-frags.mk define cddl_targets -$(drafts_xml):: cddl/$(1)-autogen.cddl +$(drafts_xml): cddl/$(1)-autogen.cddl cddl/$(1)-autogen.cddl: $(addprefix cddl/,$(2)) $(MAKE) -C cddl check-$(1) @@ -24,6 +24,7 @@ endef # cddl_targets $(eval $(call cddl_targets,corim,$(CORIM_FRAGS))) $(eval $(call cddl_targets,comid,$(COMID_FRAGS))) +$(eval $(call cddl_targets,intrep,$(INTREP_FRAGS))) cddl/concise-swid-tag.cddl: ; $(MAKE) -C cddl $(notdir $@) diff --git a/cddl/attest-key-triple-record.cddl b/cddl/attest-key-triple-record.cddl index 1154da28..74643d17 100644 --- a/cddl/attest-key-triple-record.cddl +++ b/cddl/attest-key-triple-record.cddl @@ -1,4 +1,8 @@ attest-key-triple-record = [ - environment-map - [ + $crypto-key-type-choice ] + environment: environment-map + key-list: [ + $crypto-key-type-choice ] + ? conditions: non-empty< { + ? &(mkey: 0) => $measured-element-type-choice, + ? &(authorized-by: 1) => [ + $crypto-key-type-choice ] + }> ] diff --git a/cddl/corim-frags.mk b/cddl/corim-frags.mk index d8a9dd94..70e85aa1 100644 --- a/cddl/corim-frags.mk +++ b/cddl/corim-frags.mk @@ -77,7 +77,8 @@ CORIM_FRAGS += $(COMID_FRAGS) CORIM_EXAMPLES := $(wildcard examples/corim-*.diag) -INTREP_FRAGS := intrep-acs.cddl +INTREP_FRAGS := intrep-start.cddl +INTREP_FRAGS += intrep-acs.cddl INTREP_FRAGS += intrep-ae.cddl INTREP_FRAGS += intrep-ar.cddl INTREP_FRAGS += intrep-ars.cddl @@ -86,6 +87,7 @@ INTREP_FRAGS += intrep-ev.cddl INTREP_FRAGS += intrep-policy.cddl INTREP_FRAGS += intrep-rv.cddl INTREP_FRAGS += intrep-claims-map.cddl +INTREP_FRAGS += intrep-key.cddl # deps INTREP_FRAGS += non-empty.cddl INTREP_FRAGS += environment-map.cddl @@ -102,5 +104,11 @@ INTREP_FRAGS += ip-addr-type-choice.cddl INTREP_FRAGS += ueid.cddl INTREP_FRAGS += uuid.cddl INTREP_FRAGS += integrity-registers.cddl +INTREP_FRAGS += crypto-key-type-choice.cddl +INTREP_FRAGS += profile-type-choice.cddl +INTREP_FRAGS += cose-key.cddl +INTREP_FRAGS += cose-label-and-value.cddl +INTREP_FRAGS += class-id-type-choice.cddl +INTREP_FRAGS += oid.cddl INTREP_EXAMPLES := $(wildcard examples/intrep-*.diag) diff --git a/cddl/examples/comid-5.diag b/cddl/examples/comid-5.diag index 0aae5876..416fd256 100644 --- a/cddl/examples/comid-5.diag +++ b/cddl/examples/comid-5.diag @@ -3,6 +3,27 @@ / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f' }, / comid.triples / 4 : { + / reference-triples / 0 : [ + [ + / environment-map / { + / class / 0 : { + / class-id / 0 : + / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e39' ) + } + }, + [ + / measurement-map / { + / mkey / 0 : "thing 2", + / mval / 1 : { + / cryptokeys / 13 : [ + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_X"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_Y") + ] + } + } + ] + ] + ], / identity-triples / 2 : [ [ / environment-map / { @@ -16,10 +37,10 @@ / layer / 3 : 1 } }, - [ + / key-list / [ / tagged-pkix-base64-key-type / 554("base64_key_X"), - / tagged-pkix-base64-cert-type / 555("base64_cert"), - / tagged-pkix-base64-cert-path-type / 556("base64_cert_path"), + / tagged-pkix-base64-cert-type / 555("base64_cert_Y"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_Z"), / tagged-thumbprint-type / 557([ / alg / 1, / sha256 / / value / h'44aa336af4cb14a879432e53dd6571c7fa9bccafb75f488259262d6ea3a4d91b' @@ -38,6 +59,130 @@ / value / h'66aa336af4cb14a879432e53dd6571c7fa9bccafb75f488259262d6ea3a4d91b' ]) ] + ], + [ + / environment-map / { + / class / 0 : { + / class-id / 0 : + / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e38' ) + } + }, + / key-list / [ + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_X"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_Y") + ], + / conditions / { + / mkey / 0 : "thing 1" + } + ], + [ + / environment-map / { + / class / 0 : { + / class-id / 0 : + / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e39' ) + } + }, + / key-list / [ + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_X"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_Y") + ], + / conditions / { + / mkey / 0 : "thing 2", + / authorized-by / 1: [ + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_A"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_B") + ] + } + ], + [ + / environment-map / { + / class / 0 : { + / class-id / 0 : + / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e40' ) + } + }, + / key-list / [ + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_X"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_Y") + ], + / conditions / { + / authorized-by / 1: [ + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_A"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_B") + ] + } + ] + ], + / attest-key-triples / 3 : [ + [ + / environment-map / { + / class / 0 : { + / class-id / 0 : + / tagged-uuid-type / 37( + h'67b28b6c34cc40a19117ab5b05911e37' + ), + / vendor / 1 : "ACME Inc.", + / model / 2 : "ACME RoadRunner", + / layer / 3 : 1 + } + }, + / key-list / [ + / tagged-pkix-base64-key-type / 554("base64_key_X"), + / tagged-pkix-base64-cert-type / 555("base64_cert_Y"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_Z") + ] + ], + [ + / environment-map / { + / class / 0 : { + / class-id / 0 : + / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e30' ) + } + }, + / key-list / [ + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_X"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_Y") + ], + / conditions / { + / mkey / 0 : "thing 1" + } + ], + [ + / environment-map / { + / class / 0 : { + / class-id / 0 : + / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e31' ) + } + }, + / key-list / [ + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_X"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_Y") + ], + / conditions / { + / mkey / 0 : "thing 2", + / authorized-by / 1: [ + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_A"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_B") + ] + } + ], + [ + / environment-map / { + / class / 0 : { + / class-id / 0 : + / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e32' ) + } + }, + / key-list / [ + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_X"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_Y") + ], + / conditions / { + / authorized-by / 1: [ + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_A"), + / tagged-pkix-base64-cert-path-type / 556("base64_cert_path_B") + ] + } ] ] } diff --git a/cddl/examples/intrep-1.diag b/cddl/examples/intrep-1.diag new file mode 100644 index 00000000..71da18f5 --- /dev/null +++ b/cddl/examples/intrep-1.diag @@ -0,0 +1,4 @@ +/ ECT / { + "cmtype" : 2 +} + diff --git a/cddl/examples/intrep-2.diag b/cddl/examples/intrep-2.diag new file mode 100644 index 00000000..56dc4f40 --- /dev/null +++ b/cddl/examples/intrep-2.diag @@ -0,0 +1,9 @@ +/ ECT / { + "environment" : { + / class / 0 : { + / class-id / 0 : + / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e37' ) + } + }, + "cmtype" : 1 +} diff --git a/cddl/examples/intrep-3.diag b/cddl/examples/intrep-3.diag new file mode 100644 index 00000000..ede28f45 --- /dev/null +++ b/cddl/examples/intrep-3.diag @@ -0,0 +1,32 @@ +/ ECT / { + "environment" : { + / class / 0 : { + / class-id / 0 : + / tagged-uuid-type / 37( h'67b28b6c34cc40a19117ab5b05911e37' ) + } + }, + "element-list" : [ + / element-map / { + "element-claims" : { + / ver / 0 : { + / version / 0 : "1.0.0" + }, + / digests / 2 : [ [ + / hash-alg-id / 1, / sha256 / + / hash-value / h'44aa336af4cb14a879432e53dd6571c7fa9bccafb75f488259262d6ea3a4d91b' + ] ], + / intrep-key / 65534 : [ + / typed-crypto-key / { + "key": 556("base64_cert_path_X"), + "key-type": 1 + }, + / typed-crypto-key / { + "key": 554("base64_key_Y"), + "key-type": 2 + } + ] + } + } + ], + "cmtype" : 2 +} diff --git a/cddl/identity-triple-record.cddl b/cddl/identity-triple-record.cddl index c7e751d3..adb2b2c2 100644 --- a/cddl/identity-triple-record.cddl +++ b/cddl/identity-triple-record.cddl @@ -1,4 +1,8 @@ identity-triple-record = [ - environment-map - [ + $crypto-key-type-choice ] -] + environment: environment-map + key-list: [ + $crypto-key-type-choice ] + ? conditions: non-empty<{ + ? &(mkey: 0) => $measured-element-type-choice, + ? &(authorized-by: 1) => [ + $crypto-key-type-choice ] + }> +] \ No newline at end of file diff --git a/cddl/intrep-key.cddl b/cddl/intrep-key.cddl new file mode 100644 index 00000000..21f4c81c --- /dev/null +++ b/cddl/intrep-key.cddl @@ -0,0 +1,14 @@ +$$measurement-values-map-extension //= ( + &(intrep-keys: 65534) => [ + typed-crypto-key ] +) + +typed-crypto-key = { + key: $crypto-key-type-choice + ? key-type: uint .bits key-type +} + +key-type = &( + attest-key: 0 + identity-key: 1 +) + diff --git a/cddl/intrep-start.cddl b/cddl/intrep-start.cddl new file mode 100644 index 00000000..41486a03 --- /dev/null +++ b/cddl/intrep-start.cddl @@ -0,0 +1 @@ +start = ECT diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index 9b17ea3d..e8bb9815 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -114,6 +114,13 @@ informative: I-D.ietf-rats-eat: eat I-D.ietf-rats-concise-ta-stores: ta-store I-D.ietf-rats-ar4si: ar4si + DICE.cert: + title: DICE Certificate Profiles + author: + org: Trusted Computing Group + seriesinfo: Version 1.0, Revision 0.01 + date: July 2020 + target: https://trustedcomputinggroup.org/wp-content/uploads/DICE-Certificate-Profiles-r01_pub.pdf entity: SELF: "RFCthis" @@ -683,7 +690,7 @@ The following describes each member of the `triples-map`: stateful environment records. Described in {{sec-comid-triple-cond-endors}}. -##### Environments +##### Environments {#sec-environments} An `environment-map` may be used to represent a whole Attester, an Attesting Environment, or a Target Environment. The exact semantic depends on the @@ -1216,50 +1223,67 @@ The first `series` entry that successfully matches the `selection` criteria term #### Device Identity Triple {#sec-comid-triple-identity} -A Device Identity triple record relates one or more cryptographic keys to a device identity. -The cryptographic keys are bound to or associated with a Target Environment that is within the device. -The device identifier may be part of the Target Environment's `environment-map` or may be part of some other device identity credential, such as a certificate. -The cryptographic keys are expected to be used to authenticate the device. +Device Identity triples (see `identity-triples` in {{sec-comid-triples}}) endorse that the keys were securely provisioned to the named Target Environment. +A single Target Environment (as identified by `environment` and `mkey`) may contain one or more cryptographic keys. +The existence of these keys is asserted in Evidence, Reference Values, or Endorsements. + +The device identity keys may have been used to authenticate the Attester device or may be held in reserve for later use. Device Identity triples instruct a Verifier to perform key validation checks, such as revocation, certificate path construction & verification, or proof of possession. The Verifier SHOULD verify keys contained in Device Identity triples. -A Device Identity triple endorses that the keys were securely provisioned to the named Target Environment. Additional details about how a key was provisioned or is protected may be asserted using Endorsements such as `endorsed-triples`. Depending on key formatting, as defined by `$crypto-key-type-choice`, the Verifier may take different steps to locate and verify the key. -If a key has usage restrictions that limit its use to device identity challenges, Verifiers SHOULD check for key use that violates usage restrictions. +If a key has usage restrictions that limit its use to device identity challenges, Verifiers SHOULD enforce key use restrictions. -Verification of a key, including its use restrictions, MAY produce Claims that are added to the ACS. -Alternatively, Verifiers MAY report key verification results as part of an error reporting function. +Each successful verification of a key in `key-list` SHALL produce Endorsement Claims that are added to the Attester's Claim set. +Claims are asserted with the joint authority of the Endorser (CoRIM signer) and the Verifier. +Additionally, Verifiers MAY report key verification results as part of an error reporting function. ~~~ cddl {::include cddl/identity-triple-record.cddl} ~~~ +* `environment`: An `environment-map` condition used to identify the target Evidence or Reference Value. + See {{sec-environments}}. + +* `key-list`: A list of `$crypto-key-type-choice` keys that identifies which keys are to be verified. + See {{sec-crypto-keys}}. + +* `mkey`: An optional `$measured-element-type-choice` condition used to identify the element within the target Evidence or Reference Value. + See {{sec-comid-mkey}}. + +* `authorized-by`: An optional list of `$crypto-key-type-choice` keys that identifies the authorities that asserted the `key-list` in the target Evidence or Reference Values. + #### Attest Key Triple {#sec-comid-triple-attest-key} -An Attest Key triple record relates one or more cryptographic keys to an Attesting Environment. -The cryptographic keys are wielded by an Attesting Environment that collects measurements from a Target Environment. -The cryptographic keys sign Evidence. +Attest Key triples (see `attest-key-triples` in {{sec-comid-triples}}) endorse that the keys were securely provisioned to the named Attesting Environment. +An Attesting Environment (as identified by `environment` and `mkey`) may contain one or more cryptographic keys. +The existence of these keys is asserted in Evidence, Reference Values, or Endorsements. + +The attestation keys may have been used to sign Evidence or may be held in reserve for later use. Attest Key triples instruct a Verifier to perform key validation checks, such as revocation, certificate path construction & verification, or proof of possession. The Verifier SHOULD verify keys contained in Attest Key triples. -Attest Key triples endorse that the keys were securely provisioned to the named (identified via an `environment-map`) Attesting Environment. Additional details about how a key was provisioned or is protected may be asserted using Endorsements such as `endorsed-triples`. Depending on key formatting, as defined by `$crypto-key-type-choice`, the Verifier may take different steps to locate and verify the key. -If a key has usage restrictions that limits its use to Evidence signing, Verifiers SHOULD check for key use that violates usage restrictions. +If a key has usage restrictions that limits its use to Evidence signing (e.g., see Section 5.1.5.3 in {{DICE.cert}}). +Verifiers SHOULD enforce key use restrictions. -Verification of a key, including its use restrictions, MAY produce Claims that are added to the ACS. -Alternatively, Verifiers MAY report key verification results as part of an error reporting function. +Each successful verification of a key in `key-list` SHALL produce Endorsement Claims that are added to the Attester's Claim set. +Claims are asserted with the joint authority of the Endorser (CoRIM signer) and the Verifier. +Additionally, Verifiers MAY report key verification results as part of an error reporting function. ~~~ cddl {::include cddl/attest-key-triple-record.cddl} ~~~ +See {{sec-comid-triple-identity}} for additional details. + #### Domain Dependency Triple {#sec-comid-triple-domain-dependency} A Domain Dependency triple defines trust dependencies between measurement @@ -1909,7 +1933,7 @@ The selected tags are mapped to an internal representation, making them suitable #### Endorsement Triples Transformations {#sec-end-trans} -Endorsed Values Triple Transformation : +##### Endorsed Values Triple Transformation {#sec-end-trans-evt} {:ett-enum: counter="ett" style="format Step %d."} @@ -1939,7 +1963,7 @@ Endorsed Values Triple Transformation : * If the Endorsement conceptual message has a profile, the profile is copied to the `ev`.`addition`.`profile` field. -Conditional Endorsement Triple Transformation : +##### Conditional Endorsement Triple Transformation {#sec-end-trans-cet} {:cett-enum: counter="cett" style="format Step %d."} @@ -1972,7 +1996,7 @@ Conditional Endorsement Triple Transformation : * If the Endorsement conceptual message has a profile, the profile is copied to the `ev`.`addition`.`profile` field. -Conditional Endorsement Series Triple Transformation : +##### Conditional Endorsement Triple Transformation {#sec-end-trans-cest} {:cestt-enum: counter="cestt" style="format Step %d."} @@ -2008,6 +2032,39 @@ Conditional Endorsement Series Triple Transformation : * If the Endorsement conceptual message has a profile, the profile is copied to the `evs`.`series`.`addition`.`profile` field. +##### Key Verification Triples Transformation {#sec-end-trans-kvt} + +The following transformation steps are applied for both the `identity-triples` and `attest-key-triples` with noted exceptions: + +{:kvt-enum: counter="ckvt" style="format Step %d."} + +{: kvt-enum} +* An `ev` entry ({{sec-ir-end-val}}) is allocated. + +* The `cmtype` of the `ev` entry's `addition` ECT is set to `endorsements`. + +* Populate the `ev` `condition` ECT using either the `identity-triple-record` or `attest-key-triple-record` ({{sec-comid-triple-identity}}) as follows: + +{:kvt2-enum: counter="kvt2" style="format %i."} + +{: kvt2-enum} +* **copy**(`environment-map`, `ev`.`condition`.`environment`.`environment-map`). + +* Foreach _key_ in `keylist`.`$crypto-key-type-choice`, **copy**(_key_, `ev`.`condition`.`element-list`.`element-map`.`element-claims`.`measurement-values-map`.`intrep-keys`.`key`). + +* If `key-list` originated from `attest-key-triples`, **set**(`ev`.`condition`.`element-list`.`element-map`.`element-claims`.`measurement-values-map`.`intrep-keys`.`key-type` = `attest-key`). + +* Else if `key-list` originated from `identity-triples`, **set**(`ev`.`condition`.`element-list`.`element-map`.`element-claims`.`measurement-values-map`.`intrep-keys`.`key-type` = `identity-key`). + +* If populated, **copy**(`mkey`, `ev`.`condition`.`element-list`.`element-map`.`element-id`). + +* If populated, **copy**(`authorized-by`, `ev`.`condition`.`authority`). + +{: kvt-enum} +* The signer of the Identity or Attest Key Endorsement conceptual message is copied to the `ev`.`addition`.`authority` field. + +* If the Endorsement conceptual message has a profile, the profile is copied to the `ev`.`addition`.`profile` field. + #### Evidence Tranformation Evidence is transformed from an external representation to an internal representation based on the `ae` relation ({{sec-ir-evidence}}). @@ -2164,7 +2221,7 @@ Endorsements are added to the ACS if the Endorsement condition is satisifed by t #### Processing Endorsements {#sec-process-end} Endorsements are matched with ACS entries by iterating through the `ev` list. -For each `ev` entry, the `condition` ECT is compared with an ACS ECT, where the ACS ECT `cmtype` contains either `evidence` or `endorsements`. +For each `ev` entry, the `condition` ECT is compared with an ACS ECT, where the ACS ECT `cmtype` contains either `evidence`, `reference-values`, or `endorsements`. If the ECTs match ({{sec-match-condition-ect}}), the `ev` `addition` ECT is added to the ACS. #### Processing Conditional Endorsements {#sec-process-cond-end} @@ -2176,12 +2233,39 @@ Conditional endorsements have the same processing steps as shown in ({{sec-proce Conditional Endorsement Series Triples are transformed into an internal representation based on `evs`. Conditional series endorsements are matched with ACS entries first by iterating through the `evs` list, -where for each `evs` entry, the `condition` ECT is compared with an ACS ECT, where the ACS ECT `cmtype` contains either `evidence` or `endorsements`. +where for each `evs` entry, the `condition` ECT is compared with an ACS ECT, where the ACS ECT `cmtype` contains either `evidence`, `reference-values`, or `endorsements`. If the ECTs match ({{sec-match-condition-ect}}), the `evs` `series` array is iterated, where for each `series` entry, if the `selection` ECT matches an ACS ECT, the `addition` ECT is added to the ACS. Series processing terminates when the first series entry matches. +#### Processing Key Verification Endorsements {#sec-process-keys} + +For each `ev` entry, the `condition` ECT is compared with an ACS ECT, where the ACS ECT `cmtype` contains either `evidence`, `reference-values`, or `endorsements`. +If the ECTs match ({{sec-match-condition-ect}}), for each _key_ in `ev`.`condition`.`element-claims`.`measurement-values-map`.`intrep-keys`: + +* Verify the certificate signatures for the certification path. + +* Verify certificate revocation status for the certification path. + +* Verify key usage restrictions appropriate for the type of key. + +* If key verification succeeds, **append**(_key_, `ev`.`addition`.`element-list`.`element-map`.`element-claims`.`measurement-values-map`.`intrep-keys`). + +If key verification succeeds for any _key_: + +* **copy**(`ev`.`condition`.`environment`, `ev`.`addition`.`environment`). + +* **copy**(`ev`.`condition`.`element-list`.`element-map`.`element-id`, `ev`.`addition`.`element-list`.`element-map`.`element-id`). + +* Set `ev`.`addition`.`cmtype` to `endorsements`. + +* Add the Verifier authority `$crypto-key-type-choice` to the `ev`.`addition`.`authority` field. + +* Add the `addition` ECT to the ACS. + +Otherwise, do not add the `addition` ECT to the ACS. + ### Examples for optional phases 5, 6, and 7 {#sec-phases567} Phases 5, 6, and 7 are optional depending on implementation design. @@ -2191,17 +2275,16 @@ Additionally, the creation of Attestation Results is out-of-scope for this docum Phase 5: Verifier Augmentation -Claims related to Verifier-applied consistency checks are asserted under the authority of the Verifier. -For example, the `attest-key-triple-record` may contain a cryptographic key to which the Verifier applies certificate path construction and validation. -Validation may reveal an expired certificate. -The Verifier implementation might generate a certificate path validation exception that is handled externally, or it could generate a Claim that the certificate path is invalid. +Verifiers may add value to accepted Claims, such as ensuring freshness, consistency, and integrity. +The results of the added value may be asserted as Claims with Verifier authority. +For example, if a Verifier is able to ensure collected Evidence is fresh, it might create a freshness Claim that is included with the Evidence Claims in the ACS. Phase 6: Policy Augmentation Appraisal policy inputs could result in Claims that augment the ACS. For example, an Appraisal Policy for Evidence may specify that if all of a collection of subcomponents satisfy a particular quality metric, the top-level component also satisfies the quality metric. The Verifier might generate an Endorsement ECT for the top-level component that asserts a quality metric. -Details about the policy applied may also augment the ACS. +Details about the applied policy may augment the ACS. An internal representation of policy details, based on the policy ECT, as described in {{sec-ir-policy}}, contains the environments affected by the policy with policy identifiers as Claims. Phase 7: Attestation Results Production and Transformation