Commit a5ef3a6a authored by Daniel Thompson-Yvetot's avatar Daniel Thompson-Yvetot
Browse files

Update 2 files

- /Meeting Notes/Br_7-16_October_2025.md
- /EN-304-617.md
parent 28cbdd7c
Loading
Loading
Loading
Loading
+48 −0
Original line number Diff line number Diff line
@@ -756,6 +756,28 @@ The essential functions of browsers are to enable browsing of the internet.

# 4.9 Users




##### TESTS

Ref: - Support TLS 1.3+ for all network communications
Objective: To prove that network communications are appropriately encrypted
Preparation: Enumerate all network layers such as https, wss, webrtc etc.
Assessment: For each, capture a communication that displays TLS 1.3 connection negotiation
Verdict: If all network connections are established successfullly => PASS 
Evidence: Full Packet Captures, logs, screenshots, documentation of all methods of communication.



Ref: - Random number generation
Objective: To prove that random numbers have been generated with sufficient entropy
Preparation:
Assessment:
Verdict:
Evidence:
EG: 

# Annex A (informative): Mapping between the present document and CRA requirements

_Table mapping technical security requirements from Section 5 of the present document to essential cybersecurity requirements in Annex I of the CRA. The purpose of this is to help identify missing technical security requirements._
@@ -839,6 +861,32 @@ _Describe how to decide if residual risks are tolerable._

_Describe how to treat any residual risks, for example by documenting them or informing the user._

# Annex J

- potential vulnerability
- discovered vulnerability
- known vulnerability
- publicly known vulnerability
- actively exploited vulnerability
- exploited vulnerability
- exploitable vulnerability
- known exploitable vulnerability
- known newly emerged vulnerability
- notified vulnerability
- AI specific vulnerability
- fixed vulnerability

- https://wpt.fyi/results/cors?label=stable&label=master&aligned
- https://html5test.co/ 
- https://caniuse.com/
- https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md 
- https://chromium.googlesource.com/chromium/src/+/master/docs/security/compromised-renderers.md

# Annex K
Crypto todo

https://certification.enisa.europa.eu/publications/eucc-guidelines-cryptography_en 

# Annex L (informative): Relationship between the present document and the requirements of EU Regulation 2024/2847

DRAFT ANNEX L - DO NOT CONSIDER THE CONTENT
+255 −0
Original line number Diff line number Diff line
# CYBEREUSR(25)BR007

---

## Title: [CYBEREUSR-CRA Browser#7] Meeting Report

---

from Source, Contact: 
Daniel Thompson-Yvetot (CrabNebula)

---

input for Committee: CYBER-EUSR

---

Contribution For:

- [x] Decision  
- [ ] Discussion  
- [ ] Information  

---

Submission date: 16 October 2025

---

Meeting & Allocation, Relevant WI(s), or deliverable(s): [CYBEREUSR-CRA Browser Vertical#6]

---

## 1. Opening of the meeting 13.00 (ETSI Time)

Welcoming and presentation of participants  
List of participants included in the meeting report annex.

> Please note: We will take a 10 minute break at 14.00 CEST

**Approval of the Agenda**

### 1.3 IPR Call & Antitrust and Code of Conduct reminders (in Annex A)

---

## 2. Meeting Session

### 2.1 Informative Section
Informative vs. Normative Sections:

Informative sections (architecture, terminology) will be minimized
Focus should be on normative requirements
Informative sections lead to endless discussions - will be addressed last
Goal: Direct people to normative parts (requirements, capabilities, use cases)
Manufacturers know their products - don't need extensive architectural guidance

### 2.2 Tests
Test Structure Components:

* Reference - Copy of the requirement being tested
* Given - Expected state/setup requirements
* Task - What needs to be performed
* Verification - How to verify the test
* Pass/Fail - Criteria for passing/failing
* Evidence - What constitutes proof (e.g., log files)

### 2.3 Cryptography


## 3. Notes

### 1. Immediate Priorities & Timeline
- **Critical deadline:** End of October for draft submission
- **Monday presentation:** Daniel will present Version 3 at USR meeting seeking approval to share publicly
- **Weekend focus:** Writing tests for requirements and mapping legislation to fulfilled requirements

### 2. Document Structure & Reorganization
The group is aligning with the commonly agreed structure from Amsterdam meeting:
- Moving all 4.x requirements to Chapter/Clause 5
- Chapter/Clause 6 will focus on tests for each requirement
- Goal: Map actual legislation to fulfilled requirements by Monday morning

### 3. Testing Approach - Major Breakthrough

**Valerie's Key Insight:** Understanding how to write tests for process-oriented CRA requirements that cannot be demonstrated on the product itself.

**Testing Framework Structure:**
1. Reference to the requirement
2. Objective/goal of the assessment
3. Preparation steps
4. Assessment activities
5. Verdict (pass/fail)
6. Collection of evidence

**Testing Philosophy:**
- Tests must be concise, human readable, and feasible
- Focus on verifiability rather than checkbox compliance
- Documentation requirements should collect configuration files, screenshots, and process artifacts
- Similar to Module H certification factory floor visits

### 4. Practical Testing Example - TLS 1.3 Support

**Requirement:** Support TLS 1.3

**Test Structure Developed:**
- **Objective:** Prove that network communications are appropriately encrypted
- **Preparation:** 
  - Manufacturer must enumerate all network communication methods
  - Set up network monitoring capability (packet capture)
- **Assessment:** 
  - For each communication method
  - Capture communication displaying TLS 1.3 connection establishment
- **Verdict:** All must pass/display successful TLS 1.3 connection negotiation
- **Evidence:** 
  - Full packet captures
  - Documentation of all communication methods

**Key Principle:** Make it harder to fake documentation than to actually implement the requirement

### 5. Documentation Requirements

**Important Points:**
- Use "the product shall" rather than referring to manufacturer
- Avoid vague checkbox requirements
- Require manufacturers to enumerate specific implementations
- Collect concrete artifacts (config files, screenshots, packet captures)
- MSA (Market Surveillance Authority) can verify claims by inspecting actual implementations

### 6. Horizontal Standards Status

**Current Situation:**
- Expected horizontal standards from other working groups may not be ready
- Browser vertical must address some process issues directly
- PT1 and PT3 are advanced and should be relied upon
- PT2 should not be waited for
- Browser vertical may need to include boilerplate but can swap out later if horizontal standards become available

### 7. Vulnerability Handling & Recertification

**Key Discussions:**
- **Disclosure:** Major vulnerabilities must be reported within 24 hours to IDSA (single reporting platform)
- **Recertification triggers:**
  - Substantial modifications that change risk assessment
  - New security-relevant functions (e.g., replacing authentication method)
  - NOT triggered by bug fixes in existing mitigations
- **Complex vulnerabilities:** (e.g., Rowhammer, Spectre) require longer mitigation timelines
- **State of the art:** Certification continues as long as no major modifications occur
- PT3 working group is addressing these process questions

### 8. Industry Testing References
- Marshall shared automated test suites (e.g., cross-origin tests)
- These can serve as inspiration for writing standard tests
- Goal: Create shared industry standard test suite
- Both manufacturers and MSAs should be able to run tests

### 9. Browser-Specific Considerations
- Browsers have relatively large attack surface
- Direct access to many user resources
- More frequent updates compared to other product categories
- Need to balance security updates with certification requirements

---

## Next Steps
- Weekend: Intensive test writing session
- Monday: USR meeting presentation
- Last week of October: Focus on informative section
- End of October: Final deadline for draft submission

---

## Notes
- Industry members largely absent from this call
- More work expected during comment phase due to limited industry participation
- Group is in "crunch time" mode approaching deadline
- Informative section deferred to last week of October to prioritize normative requirements and tests


## Annex A: ETSI IPR Call, Antitrust reminder and Code of conduct

### A.1 IPR Call

The attention of the members and participants of this TB is drawn to the fact that ETSI members and participants shall use reasonable endeavours under Clause 4.1 of the ETSI IPR Policy, Annex 6 of the Rules of Procedure, to inform ETSI of Essential IPRs in a timely fashion. This section covers the obligation to notify its own IPRs but also other companies’ IPRs. The members and participants take note that they are hereby invited:

- to investigate in their company whether their company does own IPRs which are, or are likely to become Essential in respect of the work of the TB,
- to notify to the ETSI Director-General all potential IPRs that their company may own, by means of the IPR Information Statement and the Licensing Declaration forms through the ETSI IPR online database application at https://ipr.etsi.org/.

Only under exceptional circumstances and if instructed by the ETSI Secretariat, paper declarations may be allowed using the forms provided by the ETSI Secretariat similar to the on-line forms.

Members and participants are encouraged to make general IPR undertakings/declarations that they will make licenses available for all their IPRs under FRAND terms and conditions related to a specific standardization area and then, as soon as feasible, provide (or refine) detailed disclosures.

For further details, please refer to: http://www.etsi.org/about/how-we-work/intellectual-property-rights-iprs.

---

### A.2 Antitrust and Competition Reminder

The attention of the members of this Working Group is drawn to the fact that ETSI activities are subject to all applicable antitrust and competition laws and that compliance with said laws is therefore required of any participant of this meeting including the Chair and Vice Chair.

The leadership shall conduct the present meeting with impartiality.

In case of question, it is recommended that you contact your legal counsel.

---

### A.3 Code of Conduct for ETSI Members

This Code of Conduct is intended as a broad guide to appropriate behaviour while carrying out activities in or for ETSI, particularly in cases where specific rules are not available.

The Code of Conduct is intended to augment the ETSI Directives but does not override them. Generally, the Code of Conduct encourages certain collaborative styles of interaction and discourages behaviour that would harm trust and cooperation between members.

ETSI delegates shall acknowledge that the ETSI organization was set up by the CEPT, composed of European administrations, industry partners and stakeholder groups and that the organization is recognized by EU law as a European Standardisation Organisation, as per Regulation (EU) No 1025/2012.

Delegates should support ETSI operations, including the relationship with European administrations as far as reasonably possible, noting in particular the needs of the EU and EFTA, and the advice provided through their Counsellors.

This Code of Conduct complements other more specific codes, such as the Code of Conduct for Board members.

In general, delegates to ETSI:

- Shall acknowledge that ETSI operates according to the principles of international standardization: consensus, transparency, openness, impartiality, effectiveness, relevance, and coherence.
- Shall acknowledge that, at ETSI, the respect of other delegates, the Secretariat and the professional culture of standardization is foremost.
- Shall acknowledge that consensus-building in the development of ETSI standards should be upheld and respected.

When involved in ETSI activities, delegates to ETSI

- Shall act in meetings and discussions in accordance with ETSI Values (see above).
- Should make sure that discussions and debates take place in a moderate, professional, respectful and friendly manner, without prejudice.
- Unless acting in official roles, are assumed to be presenting ideas according to their best professional judgement.
- Are expected to act in good faith and with due care and diligence, avoid collusive, anticompetitive, or dominant behaviour and to promote a culture of fair and ethical behaviour.
- Are expected to take care to act on a fully informed basis and take decisions with due diligence, in order to engage constructively in ETSI activities.
- Are invited to actively participate in the work of ETSI, providing timely contributions uploaded to the ETSI portal.
- Shall value diversity and act against any discrimination as outlined in the ETSI Values, e.g. regarding gender, race, color, ethnic or social origin, genetic features, language, religion or belief, political or any other opinion, membership of a national minority, property, birth, disability, age or sexual orientation.
- Shall acknowledge that speakers should not be interrupted; delegates may speak once recognized by the convenor/Chair of the call or meeting. Speakers should keep their interventions short and to the point.
- Should take the views of all meeting attendees (including those whose first language is not English) into consideration.
- Shall inform the Chair or the Secretariat of any issue requiring escalation so a solution may be reached in a timely manner. The member(s) concerned will use all means to endeavour to solve the issue through the appropriate mechanisms with the help of other members and will respect and uphold the outcomes of such resolution mechanisms.
- Are expected to endeavour to avoid conflict of interest. If any actual or potential conflicts of interest are identified, they shall immediately be disclosed through the appropriate mechanisms.
- Shall take into account the interests and the objectives of the European Union, e.g. as laid down in EU legislation, EU policy documents or outlined by ETSI’s Counsellors, when developing deliverables in support of EU policies and legislation.

Additionally, ETSI Chairs and Vice-Chairs

- Are expected to act in their official roles according to their best professional and neutral judgement, independent of the interests of their supporting organization.
- Are expected to facilitate discussions across different cultures, inclusively, so that decisions align with ETSI Values, protection of minority rights, gender neutrality etc.
- Shall maintain strict impartiality and act in their roles in the interest of ETSI and its members.
- Shall ensure that the ETSI Guidelines for Antitrust Compliance are followed.
- Shall remind delegates of the highlights of these full CoC guidelines at the start of each meeting (at the same time as Antitrust and IPR reminders).

---

## List of Participants
to be downloaded from etsi portal and added after the meeting

| Title | Lastname | Firstname | ORGA SHORT NAME | ORGA COUNTRY CODE |
|-------|----------|-----------|-----------------|------------------|