From 38f1f5179244f5edd9155f39d7eb6e467a855607 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Mon, 24 Feb 2025 17:04:03 +0100 Subject: [PATCH 1/4] fixes #156 --- draft-ietf-rats-corim.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index e094c15f..0f5a3f7e 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -1337,7 +1337,7 @@ The existence of these keys is asserted in Evidence, Reference Values, or Endors 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. +Attest Key triples instruct a Verifier to perform key validation checks, such as revocation, certification path construction & verification, or proof of possession. The Verifier SHOULD verify keys contained in Attest Key triples. Additional details about how a key was provisioned or is protected may be asserted using Endorsements such as `endorsed-triples`. @@ -2631,7 +2631,7 @@ groups to use this information as they see fit". Evidence appraisal is at the core of any RATS protocol flow, mediating all interactions between Attesters and their Relying Parties. The Verifier is effectively part of the Attesters' and Relying Parties' trusted computing base (TCB). -Any mistake in the appraisal process could have security implications. +Any mistake in the appraisal procedure conducted by the Verifier could have security implications. For instance, it could lead to the subversion of an access control function, which creates a chance for privilege escalation. Therefore, the Verifier’s code and configuration, especially those of the CoRIM processor, are primary security assets that must be built and maintained as securely as possible. @@ -2648,16 +2648,17 @@ This includes the following aspects: - Conducting regular, automated audits and reviews of the system, such as ensuring that users' privileges are correctly configured and that any new code has been audited and approved by independent parties; - Failing securely in the event of errors to avoid compromising the security of the system. -The appraisal process should be auditable and reproducible. -The integrity of the code and data during execution should be made an explicit objective, for example ensuring that the appraisal functions are computed in an attestable trusted execution environment (TEE). +It is critical that appraisal procedures are auditable and reproducible. +The integrity of code and data during execution is an explicit objective, for example, ensuring that the appraisal functions are executed in an attestable trusted execution environment (TEE). The integrity of public and private key material and the secrecy of private key material must be ensured at all times. This includes key material carried in attestation key triples and key material used to verify the authority of triples (such as public keys that identify trusted supply chain actors). For more detailed information on protecting Trust Anchors, refer to {{Section 12.4 of -rats-arch}}. +As it is possible to use the public part of an asymmetric key pair for Evidence generation to be used to identify an Attesting Environment, this method of potentially identifying unique instances of Attesting Environments (and profiling their respective owners) can come with privacy considerations that have to be carefully weighed. The Verifier should use cryptographically protected, mutually authenticated secure channels to all its trusted input sources (Endorsers, RVPs, Verifier Owners). These links must reach as deep as possible - possibly terminating within the appraisal session context - to avoid man-in-the-middle attacks. -Also consider minimizing the use of intermediaries: each intermediary becomes another party that needs to be trusted and therefore factored in the Attesters and Relying Parties' TCBs. +Minimizing the use of intermediaries is also vital: each intermediary becomes another party that needs to be trusted and therefore factored in the Attesters and Relying Parties' TCBs. Refer to {{Section 12.2 of -rats-arch}} for information on Conceptual Messages protection. [^issue] https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/11 From 33d9d8e3aad5469cdc37723e790c58bc399128f2 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Tue, 25 Feb 2025 10:57:42 +0100 Subject: [PATCH 2/4] Update draft-ietf-rats-corim.md Co-authored-by: Thomas Fossati --- draft-ietf-rats-corim.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index 0f5a3f7e..349ae9cc 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -1337,7 +1337,7 @@ The existence of these keys is asserted in Evidence, Reference Values, or Endors 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, certification path construction & verification, or proof of possession. +Attest Key triples instruct a Verifier to perform key validation checks, such as revocation, certification path construction and validation, or proof of possession. The Verifier SHOULD verify keys contained in Attest Key triples. Additional details about how a key was provisioned or is protected may be asserted using Endorsements such as `endorsed-triples`. From 4faf6bf37a53600ec2c34b18fe2acfa7978d8493 Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Tue, 25 Feb 2025 10:58:08 +0100 Subject: [PATCH 3/4] Update draft-ietf-rats-corim.md yes Co-authored-by: Thomas Fossati --- draft-ietf-rats-corim.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index 349ae9cc..ce6e2561 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -2654,7 +2654,7 @@ The integrity of code and data during execution is an explicit objective, for ex The integrity of public and private key material and the secrecy of private key material must be ensured at all times. This includes key material carried in attestation key triples and key material used to verify the authority of triples (such as public keys that identify trusted supply chain actors). For more detailed information on protecting Trust Anchors, refer to {{Section 12.4 of -rats-arch}}. -As it is possible to use the public part of an asymmetric key pair for Evidence generation to be used to identify an Attesting Environment, this method of potentially identifying unique instances of Attesting Environments (and profiling their respective owners) can come with privacy considerations that have to be carefully weighed. +Utilizing the public part of an asymmetric key pair used for Evidence generation to identify an Attesting Environment raises privacy considerations that must be carefully considered. The Verifier should use cryptographically protected, mutually authenticated secure channels to all its trusted input sources (Endorsers, RVPs, Verifier Owners). These links must reach as deep as possible - possibly terminating within the appraisal session context - to avoid man-in-the-middle attacks. From 0a4b340eef48543fd4bc9a65227fb5a276a8f71d Mon Sep 17 00:00:00 2001 From: Henk Birkholz Date: Tue, 25 Feb 2025 10:58:45 +0100 Subject: [PATCH 4/4] Update draft-ietf-rats-corim.md okay Co-authored-by: Ned Smith --- draft-ietf-rats-corim.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-rats-corim.md b/draft-ietf-rats-corim.md index ce6e2561..bc6d2992 100644 --- a/draft-ietf-rats-corim.md +++ b/draft-ietf-rats-corim.md @@ -2658,7 +2658,7 @@ Utilizing the public part of an asymmetric key pair used for Evidence generation The Verifier should use cryptographically protected, mutually authenticated secure channels to all its trusted input sources (Endorsers, RVPs, Verifier Owners). These links must reach as deep as possible - possibly terminating within the appraisal session context - to avoid man-in-the-middle attacks. -Minimizing the use of intermediaries is also vital: each intermediary becomes another party that needs to be trusted and therefore factored in the Attesters and Relying Parties' TCBs. +Minimizing the use of intermediaries is also vital: each intermediary becomes another party that might need to be trusted and therefore factored in the Attesters and Relying Parties' TCBs. Refer to {{Section 12.2 of -rats-arch}} for information on Conceptual Messages protection. [^issue] https://github.com/ietf-rats-wg/draft-ietf-rats-corim/issues/11