Review Board Summary - RFQX Security Architecture Package

Current Decision

DecisionReady for customer clarification workshopRecommended

Traceability GateWARN - Customer Clarification NeededCurrent

P1 Decisions6Open

Customer ReadinessReady for customer clarification workshopWorkshop

Why

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Reason	Evidence
Architecture, capability, interface and security maps are consolidated.	Architecture Cockpit
Baseline is not approval-ready while customer decisions remain open.	6 P1 / 1 P2 decisions

What Is Strong

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Strength	Evidence
ECA ECU identity and AMT context	source document
Security capability model	source document
Traceability preserves uncertainty	source document

What Is Still Open

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Open Area	Impact
Unconfirmed item boundary	Asset, interface and TARA allocation can shift
Unconfirmed diagnostic role model	Privileged services may be under- or over-controlled
Unconfirmed update/key ownership	Signing, rollback, PKI and HSM decisions remain open
Unconfirmed SecOC/SDT scope	Vehicle-data authenticity/freshness cannot close

Decisions Needed

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Decision	Priority	Question	Area	Owner
CQ-BOUNDARY-03	P1	Confirm the customer decision needed to baseline this requirement item: Term Definition Shall This word, or the term "Required", means that the definition is an absolute requirement of the specification. Threat Analysis and Risk Assessment A structured approach to identify possible threats and evaluate risks with respect to the potential damages and the effort needed for successful attack. Cybersecurity concept A cybersecurity concept is a work product that documents cybersecurity relevant aspects of the product. The cybersecurity concept shall describe the scope of the risk analysis, risks that were identified during the risk analysis, cybe rsecurity goals, cybersecurity requirements, mitigation strategies, validation, and verification strategies, etc. Table 1: Definition of terms. This affects product/system boundary scope, supplier positioning, and traceability status.	System boundary / item definition	Joint
CQ-BOUNDARY-05	P1	Confirm the customer decision needed to baseline this requirement item: Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment.. This affects product/system boundary scope, supplier positioning, and traceability status.	System boundary / item definition	Joint
CQ-BOUNDARY-127	P1	Confirm the customer decision needed to baseline this requirement item: Table 1 – Definition of Terms Term Definition Shall This word, or the terms "Required" or "Must", means that the definition is an absolute requirement of the specification. Shall not This phrase, or the phrase "Must not", means that the definition is an absolute prohibition of the specification. Should This word, or the adjective “Recommended”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications shall be understood and carefully weighed before choosing a different course. Should not This phrase, or the phrase “Not recommended”, means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. May This word, or the adjective “Optional”, means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option shall be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option shall be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides).. This affects product/system boundary scope, supplier positioning, and traceability status.	System boundary / item definition	Joint
CQ-BOUNDARY-158	P1	Confirm the customer decision needed to baseline this requirement item: Byte Description Range Resolu tion This byte shall be set to value 2 and is used to identify the response structure variant #9 Occurrence counter OCC, as described in section 5.7.2 [unsigned integer] 0..127 0 M #10 DTC priority 1 – Highest priority 2 - Second highest priority 3 – Lowest priority 255 – Unknown 1..3, 255 0xFF M #11..#16 Time/Date of the first DTC activation See Table 98 but without byte #7 and #8 M #17..#22 Time/Date of the latest DTC activation M #23..#26 ECU Operational hours at the first DTC activation [4-byte int, big endian] as described in section 5.7.5.2.. This affects product/system boundary scope, supplier positioning, and traceability status.	System boundary / item definition	Joint
CQ-BOUNDARY-199	P1	Confirm the customer decision needed to baseline this requirement item: The server shall have support for the ASN.1 contents as defined: DataSecurityContainer ::= SEQUENCE { version OCTET STRING (SIZE(2)), id OCTET STRING (SIZE(16)), verificationEntries SEQUENCE (SIZE(0..MAX)) OF VerificationEntry, encryptionEntries SEQUENCE (SIZE(0..MAX)) OF EncryptionEntry, itemEntries SEQUENCE (SIZE(0..MAX)) OF ItemEntry } VerificationEntry ::= CHOICE { hashCmp [0] EXPLICIT HashCmp }. This affects product/system boundary scope, supplier positioning, and traceability status.	System boundary / item definition	Joint
CQ-BOUNDARY-201	P1	Confirm the binding diagnostic behavior and service authorization expected for this item: The purpose of this document is to clarify vehicle manufacture specific extensions and exceptions to the Authentication 0x29 service specified in ISO 14229-1:2020. CVS150 Cryptographic Specification CVS32 SecuredDataTransmis sion 0x84 CVS151 RBAC CVS33 Entity Management Protocol (EMP) CVS31 Authenticate 0x29 CVS124 Traton Specification on Unified diagnostic services (UDS) CVS30 X.509 Specification CVS34 EMP – Basic Entities Figure 1 – Overview of relation between specifications The following documents are normative and indispensable for the application of this document: • Traton Specification on Unified diagnostic Services (UDS) requirements (CVS124) • ISO 14229-1:2020, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements Whenever a requirement in this specification or the Traton Specification on Unified diagnostic Services (UDS) requirements (CVS124) is non-compliant with one or more requirements in ISO 14229-1:2020 the requirements in this specification and (CVS124) take precedence. Any deviations from this specification shall be documented and must be reviewed by the vehicle manufacturer. It is the vehicle manufacturer that decides if a deviation can be accepted or not. Multiple security concepts are available in the Authentication (ISO 14229-1:2020) service, however, only APCE (ISO 14229-1:2020) is supported by the concept described in this document, see Figure 2.. This affects UDS service allocation, security-access roles, safe-state checks, and verification scope.	System boundary / item definition	Joint
CQ-BACKEND-02	P2	Confirm whether this software-update/bootloader item is binding for the ECA ECU baseline or informative guidance: It should be possible to reuse the generic bootloader for future currently unknown purposes/applications without a need to create a new part number for the platform.. This affects bootloader/update design scope, diagnostic programming behavior, verification evidence, and supplier effort estimation.	Backend and IT Systems / Security Operations	Joint

Recommendation

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Recommendation	Rationale
Run a focused customer clarification workshop before baseline approval.	Gate remains warning until boundary, interface, diagnostic, update, PKI and SecOC/SDT decisions are recorded.

Review board summary markdown

Review Board Summary

Current Decision

Decision	Status
Ready for customer clarification workshop.	Recommended

Why

Reason	Evidence
System function, architecture domains and security scope are consolidated.	Architecture Cockpit, system overview and generated diagrams
Approval is not ready because customer decisions remain open.	6 P1 and 1 P2 clarification items

What Is Strong

Strength	Evidence
ECA ECU identity and AMT context	source document
Security capability model	source document
Traceability gate preserves uncertainty	source document

What Is Still Open

Open Area	Impact
Unconfirmed item boundary	Asset, interface and TARA allocation can shift
Unconfirmed diagnostic role model	Privileged services may be under- or over-controlled
Unconfirmed update/key ownership	Signing, rollback, PKI and HSM decisions remain open
Unconfirmed SecOC/SDT scope	Vehicle-data authenticity/freshness cannot close

Decisions Needed

Decision	Priority	Area	Owner
CQ-BOUNDARY-03	P1	System boundary / item definition	Joint
CQ-BOUNDARY-05	P1	System boundary / item definition	Joint
CQ-BOUNDARY-127	P1	System boundary / item definition	Joint
CQ-BOUNDARY-158	P1	System boundary / item definition	Joint
CQ-BOUNDARY-199	P1	System boundary / item definition	Joint
CQ-BOUNDARY-201	P1	System boundary / item definition	Joint
CQ-BACKEND-02	P2	Backend and IT Systems / Security Operations	Joint

Recommendation

Recommendation	Rationale
Run a focused customer clarification workshop before baseline approval.	Traceability gate is WARN - Customer Clarification Needed; OCR=false; downstream PDF analysis=false; 1790 requirements remain Markdown-derived.