From 5bc171d95c6f3f7076818712749f37f385af5c0a Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Mon, 21 Oct 2024 22:46:05 +0200 Subject: [PATCH] Minor edits. --- draft-ietf-lamps-csr-attestation.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/draft-ietf-lamps-csr-attestation.md b/draft-ietf-lamps-csr-attestation.md index 548ee17..dbbc641 100644 --- a/draft-ietf-lamps-csr-attestation.md +++ b/draft-ietf-lamps-csr-attestation.md @@ -93,7 +93,7 @@ informative: org: "Trusted Computing Group" title: "TCG OID Registry" target: https://trustedcomputinggroup.org/resource/tcg-oid-registry/ - date: Oktober, 2024 + date: October, 2024 TCGDICE1.1: author: org: "Trusted Computing Group" @@ -192,8 +192,8 @@ Result, which is then processed by the RA/CA prior to the certificate issuance. In addition to the background check model, the RATS architecture also -specifies the passport model and combinations. See Section 5.2 of -{{RFC9334}} for a description of the passport model. The passport model +specifies the passport model and combinations. See {{Section 5.2 of +RFC9334}} for a description of the passport model. The passport model requires the Attester to transmit Evidence to the Verifier directly in order to obtain the Attestation Result, which is then forwarded to the Relying Party. This specification utilizes the background check model since CSRs are @@ -239,14 +239,14 @@ parentheses. ~~~ {: #fig-arch title="Example data flow demonstrating the architecture with Background Check Model."} -As discussed in RFC 9334, different security and privacy aspects need to be +As discussed in RFC 9334 {{RFC9334}}, different security and privacy aspects need to be considered. For example, Evidence may need to be protected against replay and -Section 10 of RFC 9334 lists approach for offering freshness. There are also +{{Section 10 of RFC9334}} lists approach for offering freshness. There are also concerns about the exposure of persistent identifiers by utilizing attestation -technology, which are discussed in Section 11 of RFC 9334. Finally, the keying +technology, which are discussed in {{Section 11 of RFC9334}}. Finally, the keying material used by the Attester needs to be protected against unauthorized access, and against signing arbitrary content that originated from outside the device. -This aspect is described in Section 12 of RFC 9334. Most of these aspects are, +This aspect is described in {{Section 12 of RFC9334}}. Most of these aspects are, however, outside the scope of this specification but relevant for use with a given attestation technology. The focus of this specification is on the transport of Evidence from the Attester to the Relying Party via existing @@ -742,7 +742,7 @@ require the use of Evidence in a CSR is out-of-scope for this document. Evidence generated by an Attester generally needs to be fresh to provide value to the Verifier since the configuration on the device may change -over time. Section 10 of {{RFC9334}} discusses different approaches for +over time. {{Section 10 of RFC9334}} discusses different approaches for providing freshness, including a nonce-based approach, the use of timestamps and an epoch-based technique. The use of nonces requires that nonce to be provided by the Relying Party in some protocol step prior to Evidence and CSR generation, @@ -788,7 +788,7 @@ Implementers should also be cautious around `type` OID or `hint` values that cau ## Additional security considerations -In addition to the security considerations listed here, implementers should be familiar with the security considerations of the specifications on this this depends: PKCS#10 {{RFC2986}}, CRMF {{RFC4211}}, as well as general security concepts relating to evidence and remote attestation; many of these concepts are discussed in the Remote ATtestation prodedureS (RATS) Architecture {{RFC9334}} sections 6 Roles and Entities, 7 Trust Model, 9 Freshness, 11 Privacy Considerations, and 12 Security Considerations. Implementers should also be aware of any security considerations relating to the specific evidence format being carried within the CSR. +In addition to the security considerations listed here, implementers should be familiar with the security considerations of the specifications on this this depends: PKCS#10 {{RFC2986}}, CRMF {{RFC4211}}, as well as general security concepts relating to evidence and remote attestation; many of these concepts are discussed in {{Section 6 of RFC9334}}, {{Section 7 of RFC9334}}, {{Section 9 of RFC9334}}, {{Section 11 of RFC9334}}, and {{Section 12 of RFC9334}}. Implementers should also be aware of any security considerations relating to the specific evidence format being carried within the CSR. --- back @@ -1118,7 +1118,7 @@ Note that this example demonstrates most of the features of this specification: This example does not demonstrate an EvidenceBundle that contains multiple EvidenceStatements sharing a certificate chain. ~~~ -{::include sampledata/tcgAttestTpmCertify.pem} +{::include-fold sampledata/tcgAttestTpmCertify.pem} ~~~ ## PSA Attestation Token in CSR @@ -1184,7 +1184,7 @@ the result of CBOR encoding the CMW collection shown below # ASN.1 Module ~~~ -{::include CSR-ATTESTATION-2023.asn} +{::include-fold CSR-ATTESTATION-2023.asn} ~~~ ## TCG DICE Example in ASN.1 @@ -1193,7 +1193,7 @@ This section gives an example of extending the ASN.1 module above to carry an ex The example used is the Trusted Computing Group DICE Attestation Conceptual Message Wrapper, as defined in {{TCGDICE1.1}}. ~~~ -{::include CSR-ATTESTATION-WITH-DICE-CMW.asn} +{::include-fold CSR-ATTESTATION-WITH-DICE-CMW.asn} ~~~ ## TCG DICE TcbInfo Example in CSR @@ -1202,7 +1202,7 @@ This section gives an example of extending the ASN.1 module above to carry an ex The example used is the Trusted Computing Group DiceTcbInfo, as defined in {{TCGDICE1.1}}. ~~~ -{::include CSR-ATTESTATION-WITH-DiceTcbInfo.txt} +{::include-fold CSR-ATTESTATION-WITH-DiceTcbInfo.txt} ~~~ # Acknowledgments