| UMAC | Algorithm | 128 bit | MAC | Authentication, Integrity | RFC 4418 [\[11\]](#_ref_11) | |
> NOTE 1: The combination of the mechanism mentioned in Table K.1: ACM-extended cryptographic mechanisms together with the mechanisms in ACM that is appropriate for the cryptographic use-case to form a cryptographic protocol are allowed. For example ChaCha20-Poly1305, HMAC-blake2s or X25519ML-KEM768.
> NOTE 1: The combination of the mechanism mentioned in table {seq tab tab_ACME}: ACM-extended cryptographic mechanisms together with the mechanisms in ACM that is appropriate for the cryptographic use-case to form a cryptographic protocol are allowed. For example ChaCha20-Poly1305, HMAC-blake2s or X25519ML-KEM768.
> NOTE 2: The use-case defined in K.3.2 marked in “Related product function(s) / use case(s), where applicable” is a non-exhaustive list and listed algorithm can be used for other appropriate use-cases as well.
@@ -32,7 +32,7 @@ For the purposes of the present annex:
Figure 1: RDPS model for Annex R — scope focused on the product ↔︎ RDPS boundary
Figure { seq fig \r1 }: RDPS model for Annex R — scope focused on the product ↔︎ RDPS boundary
## R.3 Threat Model
@@ -54,9 +54,11 @@ The threat model considers the following assets:
**DA-RDPS-001 - RDPS interaction content**: The information exchanged across the RDPS boundary, including, as applicable, requests, commands, responses, decisions, configuration data, secrets, update-related data, and Personal Data where such data is exchanged.
For the purposes of DA-RDPS-001, Table R.1 identifies potential categories of RDPS interaction content and indicates the security properties to be considered for each category when determining the applicable Annex R requirement families.
For the purposes of DA-RDPS-001, table {seq tab tab_SP1} identifies potential categories of RDPS interaction content and indicates the security properties to be considered for each category when determining the applicable Annex R requirement families.
Table R.1: Security properties for DA-RDPS-001
<spanid="tab_SP1"></span>
Table { seq tab }: Security properties for DA-RDPS-001
| Content type | Data authenticity | Integrity | Confidentiality |
@@ -67,13 +69,15 @@ Table R.1: Security properties for DA-RDPS-001
| Confidential code or update data | X | X | X |
| Personal data | | X | X |
> NOTE: In Table R.1, “data authenticity” refers to the authenticity or trusted origin of the exchanged interaction content. It does not refer to authentication of the RDPS boundary endpoint.
> NOTE: In table {seq tab tab_SPR} , “data authenticity” refers to the authenticity or trusted origin of the exchanged interaction content. It does not refer to authentication of the RDPS boundary endpoint.
**DA-RDPS-002 – RDPS-dependent product function:** product function for which one or more operations depend on an RDPS, including the associated security-relevant state, decisions, outputs, or configuration.
For the purposes of DA-RDPS-002, Table R.2 identifies the security property relevant to the RDPS-dependent product function.
For the purposes of DA-RDPS-002, table {seq tab tab_SP2} identifies the security property relevant to the RDPS-dependent product function.
<spanid="tab_SP2"></span>
Table R.2: Security property for DA-RDPS-002
Table { seq tab }: Security property for DA-RDPS-002
The table below identifies the CRA Annex I Part I requirements that are directly relevant to the RDPS boundary and maps them to the corresponding Annex R requirements. The purpose of this mapping is to support manufacturer traceability and to identify directly relevant CRA requirements that are not yet fully covered by the current Annex R draft. Requirements not covered by Annex R remain addressed by the core part of the standard, insofar as they apply to the product as a whole.
Table R.5: CRA Annex I Part I ↔ Annex R requirements mapping
<spanid="tab_RCRA"></span>
Table { seq tab }: CRA Annex I Part I ↔ Annex R requirements mapping
| CRA Annex | CRA text (summary) | Annex R mapping | Rationale / gap observation |
