Projet 2a
Consultation 2017/22: Projets d'ordonnances pour la mise en œuvre de la nouvelle loi fédérale sur la surveillance de la correspondance par poste et télécommunication · 194 pages
Fedlex · Projet · Page 46Fedlex · Projet
Technical requirements for the handover interfaces for the execution of telecommunications surveillance
The content of the XML requests are specified in the sections 7.3 and 7.4 for the historical data and the sections 8.3 and 8.4 for the Information Requests.
4.2.4.2.1 Message flow for successful email order processing for retained data
The message flow of the XML over HTTP interception orders for retained data exchange between the PTSS and CSP in case of successful processing is according to ETSI TS 102 657 V1.17.1 clause 5.2.1 (flows noted HI-A).
4.2.4.2.2 Message flow for errors or failed XML over HTTP order processing for retained
data
The message flow of the XML over HTTP interception orders for retained data exchange between the PTSS and CSP in case of errors and failed processing is according to ETSI TS 102 657 V1.17.1 clause 5.1.5 and the specific requirements described in the section 7.5.
4.2.4.2.3 Message flow for cancellation XML over HTTP order processing for retained data
The message flow of the XML over HTTP interception orders for retained data exchange between the PTSS and CSP in case of cancellation processing is according to ETSI TS 102 657 V1.17.1 clause 5.2.2 and the specific requirements described in the section 7.5.
4.3 Secure Email Exchange
4.3.1 General
The administrative interface using secure email may be used to support several
administrative processes as mentioned in the tables above in 4.1. In addition, the secure email can also be used to transport results of retroactive interception and information requests results.
4.3.2 Secure email with OpenPGP and keys management
The secure email interface uses OpenPGP as specified in the RFC 4880 with the specific requirements and options indicated below:
1. Keys must have at least a 2048-bit size and a validity of at least 3 years.
2. PGP signed and encrypted (email body or email attachments) must be encoded in ASCII armor. (with the suffix .asc)
3. Data (email body and/or attachments) must be first OpenPGP signed and then OpenPGP encrypted. This process can occur in one step or two steps. The whole email must not be signed nor encrypted.
4. Each organisation (CSP and PTSS) is responsible for the generation and the
management of its own OpenPGP certificates and related private and public keys. Each organisation shall exchange its public key only and perform the check of the key's fingerprint via another channel than email. For instance by phone.
5. Before the keys expire the PTSS and CSP are responsible for generating new keys and to inform the other party at least 30 calendar days in advance. If a key has been revoked a new key must immedialtely be generated and sent to the other party.