Merge pull request #65 from mcr/mcr-editorial-suggestions

MCR editorial suggestions

Author: henkbirkholz

draft-ietf-rats-reference-interaction-models.md

@@ -217,10 +217,10 @@ Similarly, deviations from the generic model described in this document can be i
 In order to ensure appropriate conveyance of Evidence, the following requirements MUST be fulfilled:
 
 Integrity:
-: Information provided by an Attester MUST NOT have been altered since it was created. This may be achieved via symmetric cryptography, e.g., using COSE Mac0 as in PSA TF-M profile ({{Section 5.2 of -psa-token}}), or asymmetric, like ECDSA.
+: Information provided by an Attester MUST NOT have been altered since it was created. This may be achieved via symmetric cryptography, e.g., using COSE Mac0 as in PSA TF-M profile ({{Section 5.2 of -psa-token}}), or asymmetric, such as a COSE Sign algorithm like ECDSA.
 
 Authentication:
-: The information provided by the Attester MUST be authentic. To do this, the Attester should authenticate itself to the Verifier. This can be done through implicit authentication using a digital signature over the Attestation Evidence, which does not require additional protocol steps, or by using a secure channel (see {{-uccs}}) including authentication.
+: The information provided by the Attester MUST be authentic. To do this, the Attester should authenticate itself to the Verifier. This can be done through implicit authentication using a digital signature over the Attestation Evidence, which does not require additional protocol steps, or by using a secure channel (see {{-uccs}}) that includes authentication.
 
 # Normative Prerequisites
 
@@ -390,7 +390,7 @@ The Challenge/Response remote attestation procedure is typically initiated by th
 Alternative initiation flows, e.g., via an intermediary or through pre-configured requests (e.g., Call-Home procedures or trusted trigger events from Relying Parties), are out of scope for this document.
 A request includes a Handle, an optional list of Attestation Key IDs, and an optional Claim Selection.
 
-In the Challenge/Response model, the Handle is composed of qualifying data in the form of a practically infeasible-to-guess nonce, such as a cryptographically strong random number.
+In the Challenge/Response model, the Handle is composed of qualifying data in the form of a practically infeasible-to-guess nonce {{?RFC4949}}, such as a cryptographically strong random number.
 This nonce is typically generated by the Verifier to guarantee Evidence freshness and prevent replay attacks; however, depending on deployment context, it may also be generated by another trusted role, such as a Relying Party.
 
 The list of Attestation Key IDs selects the attestation keys with which the Attester is requested to sign the attestation Evidence.