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 SEPAmailmessagerie bancaire sécurisée., il est nécessaire de pouvoir simplement échanger des enveloppes SEPAmail. Ces enveloppes se concrétisent sous la forme de composants S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels, au sein d'un message SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »). Ce document spécifie techniquement comment cet échange se réalise.

Résumé

L'enveloppe SEPAmailmessagerie bancaire sécurisée. (enveloppe SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») au format S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels contenant une missive SEPAmailmessagerie bancaire sécurisée. 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 SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») (jeu de commande du protocole d'échange SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »))
  • 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 SOAPancien acronyme de Simple Object Access Protocol, c'est un protocole de RPC orienté objet bâti sur XML (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 SEPAmailmessagerie bancaire sécurisée., c'est juste un réseau d'échange d'information du même niveau que la messagerie électronique).

  • Deux protocoles d'échange sont retenus : HTTPHyperText Transfer Protocol et SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »).
  • Le routage et l'adressage se font par les protocoles IP et DNSDomain Name System, service permettant d'établir une correspondance entre une adresse IP et un nom de domaine<ref name="dns">http://fr.wikipedia.org/wiki/Domain_Name_System</ref>.
  • Le transport est assuré par TCP (UDP pour DNSDomain Name System, service permettant d'établir une correspondance entre une adresse IP et un nom de domaine<ref name="dns">http://fr.wikipedia.org/wiki/Domain_Name_System</ref>).

L'adressage

Chacun des systèmes d'information définit une adresse DNSDomain Name System, service permettant d'établir une correspondance entre une adresse IP et un nom de domaine<ref name="dns">http://fr.wikipedia.org/wiki/Domain_Name_System</ref> dans le registre du domaine sepamail.eu, géré par le Schemele Scheme, ou Scheme SEPAmail, est l'entité au sein de laquelle les adhérents SEPAmail sont regroupés et qui a pour mission de maintenir la norme SEPAmail et les référentiels., avec plusieurs enregistrements A, CNAME et MX.

Supposons que l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). bancaire ait plusieurs BICBank Identifier Code, norme ISO 9362:1994 pour un même système d'information.

Alors, il décidera du BICBank Identifier Code, norme ISO 9362:1994 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.euSociété gestionnaire de la norme et du scheme SEPAmail
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 BICBank Identifier Code, norme ISO 9362:1994 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 BICBank Identifier Code, norme ISO 9362:1994 principal,
  • le RR (resource record) de type MX pour le BICBank Identifier Code, norme ISO 9362:1994 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 BICBank Identifier Code, norme ISO 9362:1994 principal.

L'enregistrement du service de messagerie est obligatoire. Il pointe usuellement sur le RR de type A du BICBank Identifier Code, norme ISO 9362:1994 principal mais l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). SEPAmailmessagerie bancaire sécurisée. 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 (QXOOBureau local opérationnel du SCHEME (QX Operational Office)) s'occupe de l'aspect DNSDomain Name System, service permettant d'établir une correspondance entre une adresse IP et un nom de domaine<ref name="dns">http://fr.wikipedia.org/wiki/Domain_Name_System</ref>.

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 SEPAmailmessagerie bancaire sécurisée. 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 SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »)

Le transport se fait entre deux serveurs MTAacronyme de Mail Transfer Agent, logiciel pour serveur de transmission de courrier électronique implémentant SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »).

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 SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») 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 HTTPHyperText Transfer Protocol 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 SOAPancien acronyme de Simple Object Access Protocol, c'est un protocole de RPC orienté objet bâti sur XML ou un style d'architecture comme RESTREpresentational State Transfer, architecture distribuée simple, n'utilisant pas d'états<ref>http://fr.wikipedia.org/wiki/REST</ref>.

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 SEPAmailmessagerie bancaire sécurisée. pour chiffrer/signer les missives.

l'échange avec HTTPHyperText Transfer Protocol

Le transport peut aussi se réaliser entre deux serveurs implémentant HTTPHyperText Transfer Protocol sans couche TLS. La missive est alors forcément chiffrée au sein de son enveloppe SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »)/S-MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels, comme pour l'échange avec SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »).

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 SOAPancien acronyme de Simple Object Access Protocol, c'est un protocole de RPC orienté objet bâti sur XML ou un style d'architecture comme RESTREpresentational State Transfer, architecture distribuée simple, n'utilisant pas d'états<ref>http://fr.wikipedia.org/wiki/REST</ref>.

Échange de l'enveloppe SEPAmailmessagerie bancaire sécurisée. avec une mécanique simple

Le principe est de :

  • insérer l'enveloppe SEPAmailmessagerie bancaire sécurisée. (enveloppe SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels)
  • dans le corps (BODY et non entête HEADERS) d'une requête HTTPHyperText Transfer Protocol (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 SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») 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 SEPAmailmessagerie bancaire sécurisée. avec une couche SOAPancien acronyme de Simple Object Access Protocol, c'est un protocole de RPC orienté objet bâti sur XML

Le principe est d'utiliser le protocole SOAPancien acronyme de Simple Object Access Protocol, c'est un protocole de RPC orienté objet bâti sur XML (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 SEPAmailmessagerie bancaire sécurisée. défini dans le SI de la banque.

Dans le cas d'un échange via SOAPancien acronyme de Simple Object Access Protocol, c'est un protocole de RPC orienté objet bâti sur XML, alors :

  • le service web SOAPancien acronyme de Simple Object Access Protocol, c'est un protocole de RPC orienté objet bâti sur XML 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 SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») pour une raison principale :

  • le protocole SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») est construit autour d'une distribution « au mieux » et non immédiate
  • le protocole HTTPHyperText Transfer Protocol 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%