Added extra security consideration text.

draft-ietf-lamps-csr-attestation.md

@@ -76,6 +76,8 @@ informative:
   I-D.ietf-rats-msg-wrap:
   I-D.bft-rats-kat:
   RFC7030:
+  I-D.ietf-rats-daa:
+  I-D.ietf-lamps-attestation-freshness:
   I-D.tschofenig-rats-psa-token:
   TPM20:
     author:
@@ -774,6 +776,18 @@ The current registry values can be retrieved from the IANA online website.
 
 # Security Considerations
 
+In the RATS architecture, when Evidence or an Attestation Result is presented to a Relying Party (RP), the RP may learn detailed information about the Attester unless that information has been redacted or encrypted. Consequently, a certain amount of trust must be placed in the RP, which raises potential privacy concerns because an RP could be used to track devices. This observation is noted in Section 11 of {{RFC9334}}.
+
+Typically, the RPs considered in the RATS architecture are application services that use remote attestation, rather than RAs or CAs. Devices inherently place significant trust in RA/CA infrastructure elements, and therefore any additional information revealed through remote attestation to such entities is generally less concerning than disclosure to application services. The problem of copying Evidence by CAs into an X.509 certificate is discussed in {{sec-con-publishing-x509}}.
+
+These privacy risks can be mitigated using several approaches, including:
+
+- Shared Attestation Keys: A manufacturer of devices may provision all devices with the same attestation key(s), or share a common attestation key across devices of the same product family. This approach anonymizes individual devices by making them indistinguishable from others using the same key(s). However, it also means losing the ability to revoke a single attestation key if a specific device is compromised. Care must be taken to avoid embedding uniquely identifying information in the Evidence, as that would reduce the privacy benefits of using remote attestation.
+
+- Per-Device Attestation Keys: Devices may be designed to dynamically generate distinct attestation keys (and request the corresponding certificates) for each use case, device, or session. This is analogous to the Privacy CA model, in which a device is initially provisioned with an attestation key and certificate; then, in conjunction with a privacy-preserving CA, it can obtain unique keys and certificates as needed. This strategy reduces the potential for tracking while maintaining strong security assurances. This is the model described in this document.
+
+- Anonymous Attestation Mechanisms: Direct anonymous attestation (DAA) or similar cryptographic methods can be employed to generate blinded attestation signatures. In these schemes, the verifier can validate the attestation using a root key but does not gain a global correlation handle. Thus, repeated use of the same attestation key cannot be exploited to track devices. {{I-D.ietf-rats-daa}} extends the RATS architecture with such a DAA scheme, significantly enhancing privacy.
+
 ## Background Check Model Security Considerations
 
 A PKCS#10 or CRMF Certification Request message typically consists of a
@@ -875,20 +889,19 @@ an Attester. Policies used at the Verifier and the Relying Party are
 implementation dependent and out of scope for this document. Whether to
 require the use of Evidence in a CSR is out-of-scope for this document.
 
-## Freshness
+## Freshness for the Background Check Model
 
 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
 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
+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,
 and the use of timestamps requires synchronized clocks which cannot be
 guaranteed in all operating environments. Epochs also require an out-of-band
 communication channel.
-This document only specifies how to carry existing Evidence formats inside a CSR,
-and so issues of synchronizing freshness data is left to be handled, for example,
-via certificate management protocols.
+This document leaves the exchange of nonces and other freshness data to
+certificate management protocols, see {{I-D.ietf-lamps-attestation-freshness}}.
 Developers, operators, and designers of protocols, which embed
 Evidence-carrying-CSRs, MUST consider what notion of freshness is
 appropriate and available in-context; thus the issue of freshness is
@@ -907,7 +920,9 @@ time T to have been generated inside the hardware boundary and to be
 non-exportable, then it can be assumed that those properties of that key
 will continue to hold into the future.
 
-## Publishing Evidence in an X.509 extension {#sec-con-publishing-x509}
+Note: Freshness is also a concern for remote attestation in the passport model; however, the protocol between the Attester and the Verifier lies outside the scope of this specification.
+
+## Publishing Evidence in an X.509 Extension {#sec-con-publishing-x509}
 
 This document specifies an Extension for carrying Evidence in a CRMF Certificate Signing Request (CSR), but it is intentionally NOT RECOMMENDED for a CA to copy the ext-evidence extension into the published certificate.
 The reason for this is that certificates are considered public information and the Evidence might contain detailed information about hardware and patch levels of the device on which the private key resides.
@@ -924,7 +939,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 {{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.
+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 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 and Attestation Result formats being carried within the CSR.
 
 --- back