Outils personnels

Spécification de l'échange des enveloppes SEPAmail

De documentation SEPAmail.

Cette page contient des modifications qui ne sont pas marquées pour la traduction.

SEPAmail – Norme 1206

Cette page fait partie de la version 1206 de la norme.

Sauf indication contraire, elle a été validée par les instances concernées et s'impose à tous les adhérents SEPAmail.
ATTENTION ! La version 1606 de la norme est disponible, vérifiez si cette page est toujours valable.

Au sein du réseau des adhérents SEPAmail, il est nécessaire de pouvoir simplement échanger des enveloppes SEPAmail. Ces enveloppes se concrétisent sous la forme de composants S/MIME, au sein d'un message SMTP. Ce document spécifie techniquement comment cet échange se réalise.

Résumé

L'enveloppe SEPAmail (enveloppe SMTP au format S/MIME contenant une missive SEPAmail et une signature de cette missive) est prise en charge en émission et en réception par un automate qui, selon le protocole de communication retenu :

  • assure l'échange de cette enveloppe dans le cas de SMTP (jeu de commande du protocole d'échange SMTP)
  • assure l'échange de cette enveloppe dans le cas de HTTPS de deux manières possibles :
    • en l'insérant dans le corps d'une requête POST envoyée sur la ressource https://bic.sepamail.eu/ecosystem/receive-envelope-smtp et attendant une réponse 200 ou 204
    • en l'envoyant via un service web SOAP (url https://bic.sepamail.eu/ecosystem/soap à l'aide d'une méthode sendMissive)

Spécifications techniques

L'architecture

L'échange des enveloppes se fait sur le réseau Internet avec la famille de protocole TCP/IP.
ReseauInternetSepamail.png

Il n'est pas prévu de réseau de secours dans la phase expérimentale (aucun paiement ne transite par SEPAmail, c'est juste un réseau d'échange d'information du même niveau que la messagerie électronique).

  • Deux protocoles d'échange sont retenus : HTTP et SMTP.
  • Le routage et l'adressage se font par les protocoles IP et DNS.
  • Le transport est assuré par TCP (UDP pour DNS).

L'adressage

Chacun des systèmes d'information définit une adresse DNS dans le registre du domaine sepamail.eu, géré par le Scheme, avec plusieurs enregistrements A, CNAME et MX.

Supposons que l'adhérent bancaire ait plusieurs BIC pour un même système d'information.

Alors, il décidera du BIC principal (BICp) et tous les autres BICs seront considérés comme secondaires (BICs). Seront définis alors les champs suivants :

Liste des enregistrements à définir dans le registre de SEPAmail.eu
FQDN TTL Type Classe RData F/O
BICp.sepamail.eu 86400 A IN IP1 publique SI O
BICp.sepamail.eu 86400 MX 10 IN BICp.sepamail.eu O
Pour chacun des BIC secondaires
BICs.sepamail.eu 86400 CNAME IN BICp.sepamail.eu F
BICs.sepamail.eu 86400 MX 10 IN BICp.sepamail.eu F

La classe est celle d'internet (IN), le TTL conseillé par défaut est 86400 secondes (24 heures).

Les seuls enregistrements obligatoires sont

  • le RR (resource record) de type A pour le BIC principal,
  • le RR (resource record) de type MX pour le BIC principal.

Remarque : il peut y avoir plusieurs enregistrements A ou MX pour un même FQDN afin de mettre en œuvre une répartition de charge sur plusieurs IP.

Les BICS secondaires sont déclarés comme des alias du BIC principal.

L'enregistrement du service de messagerie est obligatoire. Il pointe usuellement sur le RR de type A du BIC principal mais l'adhérent SEPAmail peut aussi implémenter une liste de MX externes pour répartir la charge entre plusieurs serveurs externes au domaine sepamail.eu.

Remarque : il faut qu'un service dédié du Scheme local (QXOO) s'occupe de l'aspect DNS.

L'authentification

Il y a plusieurs authentifications. La compréhension du concept est généralement mal partagée par les parties devant le mettre en œuvre.

On parle ici de l'authentification du SYSTEME SEPAmail des deux SI pour échanger les enveloppes SEPAmail.

Les principes de l'authentification, quelque soit le protocole d'échange utilisé, sont :

  • il n'y a pas de mots de passe transitant sur le réseau, même chiffrés,
  • l'authentification est fondée sur un échange pair à pair préalable de clé cryptographique entre les parties,
  • il existe une procédure de révocation pair à pair ou centralisée permettant de s'assurer qu'aucune clé révoquée n'est utilisée.
  • Les clés utilisées pour l'échange de missives (échange HTTPS) ne sont pas les mêmes que pour la signature des missives et le chiffrement des missives au sein de l'enveloppe SEPAmail.


On peut utiliser HTTPS, et, dans ce cas, c'est avec TLS en version supérieure ou égale à la version 1.2[1] (ou SSL version supérieure ou égale à la version 3.3).

l'échange avec SMTP

Le transport se fait entre deux serveurs MTA implémentant SMTP.

La missive est alors forcément chiffrée car ce protocole fait transiter les trames en clair.

On a donc les règles suivantes :

  • la missive transportée via SMTP est toujours chiffrée,
  • les MTAs sont paramétrés pour respecter les règles de priorité et de délai de l'acheminement,

l'échange avec HTTPS

Le transport se fait entre deux serveurs qui implémentent HTTP dans sa version au-dessus de TLS (HTTPS).

Le certificat utilisé pour la couche TLS n'est pas l'un de ceux utilisés pour chiffrer et signer les missives SEPAmail.

Il faut alors mettre en place une mécanique applicative du même ordre que celle offerte par les MTAs (envoi, accusé de réception, file d'attente etc...), ce qui peut être fait par un protocole de type RPC comme SOAP ou un style d'architecture comme REST.

On a donc les règles suivantes :

  • l'authentification des serveurs entre eux utilise HTTPS
  • le certificat utilisé pour HTTPS n'est pas un des certificats utilisés par SEPAmail pour chiffrer/signer les missives.

l'échange avec HTTP

Le transport peut aussi se réaliser entre deux serveurs implémentant HTTP sans couche TLS. La missive est alors forcément chiffrée au sein de son enveloppe SMTP/S-MIME, comme pour l'échange avec SMTP.

Il faut alors mettre en place une mécanique applicative du même ordre que celle offerte par les MTAs (envoi, accusé de réception, file d'attente etc...), ce qui peut être fait par un protocole de type RPC comme SOAP ou un style d'architecture comme REST.

Échange de l'enveloppe SEPAmail avec une mécanique simple

Le principe est de :

  • insérer l'enveloppe SEPAmail (enveloppe SMTP S/MIME)
  • dans le corps (BODY et non entête HEADERS) d'une requête HTTP (version > 1.1)
  • méthode POST
  • sur la ressource https://bic.sepamail.eu/ecosystem/receive-envelope-smtp.

La réponse est alors soit :

  • une réponse 204 (pas de contenu)
  • à défaut une réponse 200 (OK) si l'automate ne sait pas implémenter une réponse 204

La ressource est spécifique à ecosystem (équivalent de l'échange SMTP sur une adresse de courriel ecosystem@bic.sepamail.eu). Elle précise la méthode de réception de l'enveloppe smtp en la nommant explicitement receive-envelope-smtp.

Charge à l'automate de distribuer l'enveloppe dans la boite de courriel ecosystem@bic.sepamail.eu pour le traitement SEPAmail.

Échange de l'enveloppe SEPAmail avec une couche SOAP

Le principe est d'utiliser le protocole SOAP (version supérieure ou égale à 1.2[2]) qui n'est pas un protocole de la famille internet pour s'abstraire des parties authentification/échange d'information.

Cette couche est plus utile dans le cadre intrabancaire pour partager avec des systèmes d'information de clients des méthodes sur des objets SEPAmail défini dans le SI de la banque.

Dans le cas d'un échange via SOAP, alors :

  • le service web SOAP est appelé sur l'url
  • https://bic.sepamail.eu/ecosystem/soap
  • à l'aide d'une méthode sendMissive
  • avec comme arguments :
    • les paramètres d'authentification
    • la missive à envoyer

Charge à l'automate de distribuer l'enveloppe dans la boite de courriel ecosystem@bic.sepamail.eu pour le traitement SEPAmail.

Notes d'architecture

Les notes qui suivent n'ont pas de valeur normative. Elles sont fournies à titre de précisions sur les choix techniques et éventuellement d'aide à l'implémentation.

La gestion des files d'attentes

Les MTAs implémentent naturellement un système de files d'attente et d'espaces utilisateurs (les boites de courriels).

Avec le besoin d'antispam et d'antivirus, la plupart des MTAs ont implémenté une architecture en couches avec des files d'attentes et des agents indépendants.

Le traitement des files d'attentes se fait donc indépendamment les unes des autres et ce modèle permet de répartir sur plusieurs architectures les fonctions différentes (notamment l'antispam, l'antivirus) et gérer de façon différenciée le trafic interne au SI et avec l'extérieur.

La gestion de la charge

La gestion de la charge ne se gère pas de la même façon avec un protocole de type web-service et avec un protocole de type SMTP pour une raison principale :

  • le protocole SMTP est construit autour d'une distribution « au mieux » et non immédiate
  • le protocole HTTP est construit pour servir de façon quasi-immédiate l'information et ne permet pas simplement la gestion de file d'attente sur un canal (voir paragraphe précédent)

Dans le réseau interbancaire, le nombre d'adhérents va être faible et le service symétrique. La gestion de la charge devrait pouvoir se réguler assez facilement quelque soit le protocole utilisé.

Références

  1. http://tools.ietf.org/html/rfc5246 et http://tools.ietf.org/html/rfc6176
  2. http://www.w3.org/2002/07/soap-translation/soap12-part0.html
Autres langues :English 12% • ‎Français 100%