From 867ab2c5d8a470584f7a493ad3d44975f2c3952c Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Mon, 1 Jul 2024 11:25:22 +0200 Subject: [PATCH 1/4] New Hint Text Proposal Aiming to address the mailing list discussion Question: Is there a good ASN.1 structure to use for FQDNs? --- draft-ietf-lamps-csr-attestation.md | 48 ++++++++++++++--------------- 1 file changed, 23 insertions(+), 25 deletions(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index 69ecc4d..d5a9070 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -527,34 +527,32 @@ EvidenceStatement ::= SEQUENCE { In {{code-EvidenceStatement}}, type is an OID that indicates the format of the value of stmt. -The Attester MAY populate the hint with the name of a Verifier software package -which will be capable of parsing the data contained in `EvidenceStatement.stmt`; -this is to help the Relying Party select the correct Verifier without requiring -the Relying Party to perform any parsing of the data in `EvidenceStatement.stmt`. -The type OID, which identifies the format of the data found in the Evidence statement, -typically suffices for a Relying Party to select the correct -Verifier (software) to invoke. However, in some cases the Relying Party -may have more than one Verifier capable of parsing a given type OID -- for -example if the OID indicates a wrapper format such as DICE -ConceptualMessageWrapper that can contain further proprietary data. -A design goal of this specification is to enable Relying Parties to -select an appropriate Verifier (software) without the need to perform any -parsing of the `EvidenceStatement.stmt` data. -To help with this, the Attester MAY populate the hint with a name of a -software package that will be capable of parsing this data. -The hint SHOULD contain a value that is unique -to this Verifier, for example, a fully qualified domain name (FQDN), a uniform -resource name (URN) {{RFC8141}}, or a registered value corresponding to this -Evidence format. -In a typical usage scenario, the RP is pre-configured with a list of trusted -Verifiers and the corresponding hint values can be used to look up appropriate Verifier. -Tricking an RP into interacting with an unknown and untrusted Verifier has to be avoided -as the retrieved Attestation Result must be reliable. +Based on the responsibilities of the different roles in the RATS architecture, +Relying Parties need to relay Evidence to Verifiers for evaluation and obtain +an Attestation Result in return. Ideally, the Relying Party should select a Verifier +based on the received Evidence without requiring the Relying Party to inspect the +Evidence itself. This "routing" decision is simple when there is only a single +Verifier configured for use by a Relying Party but gets more complex when there +are different Verifiers available and each of them capable of parsing only certain +Evidence formats. + +To simplify the task for the Relying Party an optional field, the hint, is available +in the EvidenceStatement structure, as shown in {{code-EvidenceStatement}}. An +Attester MAY include the hint to the EvidenceStatement and it MAY be processed +by the Relying Party. The Relying Party MAY decide not to trust the information +embedded in the hint or policy MAY override any information provided by the Attester +via this hint. + +When the Attester populates the hint, it MUST contain a fully qualified domain +name (FQDN). In a typical usage scenario, the Relying Party is pre-configured with +a list of trusted Verifiers and the corresponding hint values can be used to look +up appropriate Verifier. Tricking an Relying Party into interacting with an unknown +and untrusted Verifier must be avoided. Usage of the hint field can be seen in the TPM2_attest example in {{appdx-tpm2}} where the type OID indicates the OID -id-TcgAttestCertify and the corresponding hint indicates the Verifier software -"tpmverifier.example.com" should be invoked for parsing it. +id-TcgAttestCertify and the corresponding hint identifies the Verifier as +"tpmverifier.example.com". ~~~ EvidenceBundles ::= SEQUENCE SIZE (1..MAX) OF EvidenceBundle From 4277c4ea6063848257b16465941e4ac74283d5e5 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Mon, 1 Jul 2024 11:28:28 +0200 Subject: [PATCH 2/4] fix nits --- draft-ietf-lamps-csr-attestation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index d5a9070..d336e54 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -1282,7 +1282,7 @@ Pető, Mike Agrenius Kushner, Tomas Gustavsson, Dieter Bong, Christopher Meyer, Michael StJohns, Carl Wallace, Michael Richardson, Tomofumi Okubo, Olivier Couillard, John Gray, Eric Amador, Johnson Darren, Herman Slatman, Tiru Reddy, Corey Bonnell, Argenius Kushner, James Hagborg, A.J. Stein, John Kemp, -Ned Smith, +Ned Smith, We would like to specifically thank Mike StJohns for his work on an earlier version of this draft. From e69d8e6a2250c65b5912fa43af4b22c5baf779cd Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Mon, 1 Jul 2024 10:11:03 -0500 Subject: [PATCH 3/4] Mike's edits on the updated Hint text --- draft-ietf-lamps-csr-attestation.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index d336e54..0428e50 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -536,6 +536,13 @@ Verifier configured for use by a Relying Party but gets more complex when there are different Verifiers available and each of them capable of parsing only certain Evidence formats. +In some cases, the EvidenceStatement.type OID will be sufficient information +for the Relying Party to correctly route it to an appropriate Verifier, +however since the type OID only identifies the general data format, it is possible +that multiple Verifiers are registered against the same type OID in which case the +Relying Party will either require additional parsing of the evidence statement, or +the Attester will be required to provide additional information. + To simplify the task for the Relying Party an optional field, the hint, is available in the EvidenceStatement structure, as shown in {{code-EvidenceStatement}}. An Attester MAY include the hint to the EvidenceStatement and it MAY be processed @@ -544,7 +551,13 @@ embedded in the hint or policy MAY override any information provided by the Atte via this hint. When the Attester populates the hint, it MUST contain a fully qualified domain -name (FQDN). In a typical usage scenario, the Relying Party is pre-configured with +name (FQDN) which uniquely identifies a Verifier. +The problem of mapping hint FQDNs to Verifiers, and the problem of FQDN collision +is out of scope for this specification; it is assumed that Attester and Verifier +makers can manage this appropriately on their own FQDN trees, however if this +becomes problematic then a public registry may be needed. + +In a typical usage scenario, the Relying Party is pre-configured with a list of trusted Verifiers and the corresponding hint values can be used to look up appropriate Verifier. Tricking an Relying Party into interacting with an unknown and untrusted Verifier must be avoided. From 61e6e8cb97e7c20514c4ba5c3e703734cd392851 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Mon, 1 Jul 2024 10:54:03 -0500 Subject: [PATCH 4/4] make fix-lint --- draft-ietf-lamps-csr-attestation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index 0428e50..1b94475 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -539,7 +539,7 @@ Evidence formats. In some cases, the EvidenceStatement.type OID will be sufficient information for the Relying Party to correctly route it to an appropriate Verifier, however since the type OID only identifies the general data format, it is possible -that multiple Verifiers are registered against the same type OID in which case the +that multiple Verifiers are registered against the same type OID in which case the Relying Party will either require additional parsing of the evidence statement, or the Attester will be required to provide additional information.