Minor edits.

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