SMIRK MIS1202, la missive dans les échanges interbancaires
Introduction et généralités
La missive est la seule entité permettant l'échange d'informations dans le système SEPAmail, où elle joue un rôle d'enveloppe pour les données confidentielles. Pour pouvoir acheminer efficacement les différentes informations du système, quatre types de missives ont été définis :
- la missive nominale, acheminant un message
- la missive d'acquittement, à but essentiellement protocolaire
ainsi que :
- la missive de service, permettant un dialogue de nature « commande - réponse » entre deux systèmes, réservée à l'espace compétitif hors réseau des adhérents SEPAmail, donc non utilisé dans les échanges entre les adhérents du réseau SEPAmail
- la missive SMAPI (SEPAmail API), accessible exclusivement en intrabancaire, et permettant à un éditeur SEPAmail de fournir un accès direct à certains éléments de sa plateforme.
La missive SMAPI est en bordure de la norme SEPAmail : son existence fait partie de la norme, mais le contenu exact des messages SMAPI est laissé à la discrétion des éditeurs.
SEPAmail se sert de la missive pour :
- l'adressage de l'information (qui est le destinataire, qui est l'émetteur)
- le routage de l'information (comment j'achemine l'information)
- la réception de l'information (l'information est-elle arrivée)
- l'intégrité de l'information (est-ce la bonne information)
- l'authentification des parties (l'émetteur et le destinataire sont-ils ceux qu'ils prétendent être)
- l'horodatage de l'information (quand l'information est-elle émise et reçue)
Les principes
La missive est un flux XML respectant le schéma sepamail_missive[1], qui fait partie des spécifications du système. Cet élément sert à transporter toutes sortes de messages ou autres contenus. Elle joue le rôle d'enveloppe et peut être acheminée par divers moyens.
La missive peut être de deux types :
- une missive nominale, enveloppe pour toute forme de contenu (mais en particulier pour un message Sepamail),
- une missive d'acquittement, qui permet d'accuser réception d'une missive nominale.
Remarque : La missive de service est une notion à ne pas utiliser dans l'espace interbancaire. Elle ne fait donc pas partie de ce SMIRK. Un lexique des termes utilisés se trouve sur la documentation de la communauté SEPAmail[2].
Le routage
Le routage se sert d'un adressage de type « courriel » sur le domaine sepamail.eu[3] de la forme :
<ecosystem>@<bic>.sepamail.eu
ou
<ecosystem>@<xx.scheme>.sepamail.eu
où :
- <ecosystem> est une famille SEPAmail valide du référentiel ecosystem@scheme
- <bic> est un BIC valide du référentiel bic@scheme
- <xx.scheme> représente un nœud du réseau appartenant au scheme et administré par lui (xx est facultatif, c'est un code représentant le gestionnaire au sein du scheme, par exemple fr.scheme pour le QXOO français.[4])
Le routage est réalisé par les adhérents SEPAmail et au sein du scheme à l'aide d'automates qui implémentent les règles de routage suivantes :
Règles de routage à la réception
- Un adhérent n'accepte des missives que pour les BICs qu'il représente. Un adhérent ne fait donc pas de relais pour un autre adhérent.
- Un adhérent n'accepte des missives qu'en provenance d'un BIC lié à un adhérent SEPAmail. Le réseau SEPAmail est donc un réseau réservé à ses seuls adhérents et fermé au reste du monde.
Règles de routage à l'émission
- Un adhérent n'envoie des flux au sein du réseau SEPAmail qu'à un adhérent SEPAmail pour un BIC déclaré et valide du référentiel bic@scheme.
L'acquittement d'une missive
L'acquittement vise à informer l'émetteur de la réception, bonne ou mauvaise, de la missive émise et d'un horodatage de cette réception.
C'est l'émetteur qui pilote l'envoi d'information et non le destinataire. L'acquittement est obligatoire et systématique, il ne dépend pas de l'historique de la séquence.
La classe de l'acquittement ne dépend que des contrôles implémentés par le destinataire. On trouve les codes retour dans une directive d'implémentation spécifique.
L'acquittement se fait selon les règles suivantes :
- seules les missives nominales sont acquittées
- toute missive nominale reçue (quelque soit son ordre) doit être acquittée.
- l'acquittement doit être mis en œuvre selon la priorité et en respectant les délais maximaux de la priorité.
Le séquencement
La séquence naturelle d'un échange de missives est :
- un adhérent A émet une missive nominale destinée à un adhérent B depuis un système source de la missive
- l'adhérent B reçoit la missive nominale provenant de l'adhérent A dans un système cible de la missive
- l'adhérent B émet une ou plusieurs missives d'acquittement destinée à l'adhérent A en réponse à la missive nominale
- l'adhérent A reçoit la ou les missives d’acquittement
Nous donnons ci-dessous les règles à implémenter sur le séquencement :
- le destinataire de toute missive nominale reçue doit mettre en œuvre l'acquittement de cette missive nominale par au moins une missive d'acquittement
- aucune missive de type autre que « nominale » ou « acquittement » n'est émise
- aucune missive de type autre que « nominale » n'est acquittée
- aucune missive de type « acquittement » n'est émise sans avoir reçu au préalable une missive de type « nominale »
Renvoi d'une missive
Un système de renvoi d'une missive peut être implémenté.
Il fonctionne ainsi :
- il n'est mis en œuvre qu'avec les missives nominales,
- la missive est renvoyée avec un ordre incrémenté de 1 ; l'émetteur s'interdit de changer le contenu de la missive renvoyée, à l'exception du numéro d'ordre
- la signature S/MIME de l'émetteur est donc différente.
Dans le cas où une missive nominale n'est pas acquittée après un certain temps, les règles suivantes sont implémentées :
- l'émetteur de toute missive nominale dont l'acquittement n'est pas constaté dans un temps supérieur aux minima définis pour la priorité de la missive peut renvoyer la missive avec un numéro d'ordre incrémenté ; il s'interdit de le faire avant ; il n'est pas obligé de le faire
- le renvoi d'une missive ne peut pas intervenir plus d'un certain temps, précisé dans le tableau ci-après, après l'émission de la missive précédente
- l'émetteur de toute missive nominale dont l'acquittement n'est pas constaté dans le laps de temps maximal autorisé pour la priorité de la missive et qui a renvoyé au moins une fois la missive peut alors mettre en œuvre le procédé d'escalade prévu ; il s'interdit de le faire avant ; il n'est pas obligé de le faire.
Le système d'incrément de l'ordre des missives nominales n'est pas destiné à permettre d'envoyer plusieurs fois une même missive pour obtenir des acquittements différents. Ce système n'est utilisé que pour obtenir un acquittement si celui-ci n'est pas arrivé.
On a donc les règles suivantes :
- un système de réception et de contrôle des acquittements doit être mis en place,
- le renvoi d'une missive n'est pas possible si elle est déjà acquittée sauf si la classe d'acquittement est 4 (erreur transitoire).
| Priorité | Délai maximal acquittement | Délai minimal avant renvoi | Délai maximal avant renvoi | Nombre maximal de renvois | |
|---|---|---|---|---|---|
| 1 | la plus haute | 20 sec | 30 sec | 1 min | 3 |
| 2 | haute | 3 min | 5 min | 10 min | 5 |
| 3 | normale | 4 h | 4 h | 8 h | 4 |
| 4 | basse | 12 h | 12 h | 24 h | 3 |
| 5 | la plus basse | 48 h | 48 h | 96 h | 3 |
Les délais de renvoi sont remis à zéro à chaque renvoi de la missive. Ainsi, si une missive de priorité "haute" est envoyée à l'instant T pour la première fois (ordre 1), celle d'ordre 2 pourra être envoyée entre T+5mn et T+10mn. Si elle est envoyée à T+7mn, la missive d'ordre 3 (toujours en l'absence d'acquittement évidemment) pourra être envoyée entre T+12mn et T+17mn, et ainsi de suite.
Le délai maximal d'acquittement, le délai minimal avant renvoi et le nombre maximal de renvois indiqué ici sont des valeurs par défaut. Si deux adhérents concluent un accord bilatéral, ils peuvent librement convenir de délais différents et/ou d'un plus grand nombre de renvois.
| Priorité | Délai minimal avant escalade | |
|---|---|---|
| 1 | la plus haute | 10 min |
| 2 | haute | 30 min |
| 3 | normale | 16 h |
| 4 | basse | 36 h |
| 5 | la plus basse | 120 h |
Rappel : ce délai est calculé à partir de l'émission de la première missive (ordre 1), il n'est pas remis à zéro à chaque rémission, contrairement aux délais de renvoi ci-dessus.
Le procédé d'escalade
Dans le cas où une missive ne serait pas acquittée, même après un renvoi, l'adhérent peut procéder à l'escalade prévue par le scheme dès qu'un délai minimal est passé après le dernier renvoi (voir tableau ci-dessus).
Cette escalade est spécifiée par le Scheme dans un SMIRK spécifique.
Le contenu
Selon les règles métier de SEPAmail, une missive contient obligatoirement :
- un identifiant unique,
- un type,
- un ordre de présentation,
- un en-tête,
et selon le type de missive :
- un acquittement pour une missive de type acquittement,
- un message SEPAmail pour une missive de type nominal,
et facultativement :
- une signature du message, à ne pas confondre avec le cachet électronique apposé à la missive au sein de l'enveloppe S/MIME. Cette signature sert essentiellement à pouvoir adjoindre une signature électronique du signataire, client de la banque et émetteur du message.
Il faut noter que, du strict point de vue de la conformité au schéma XML, les blocs message et acquittement sont facultatifs (cf. schéma ci-contre).
L'en-tête de la missive respecte trois principes :
- le principe de symétrie entre le destinataire et l'émetteur du message, car l'un et l'autre peuvent avoir les deux fonctions
- le principe de priorité, qui permet à chaque entité de gérer l'affluence en priorisant les flux
- le principe d'intégrité des informations générées par les automates qui est assuré par des sommes de contrôle sur le contenu dont on veut vérifier l'intégrité
L'enveloppe
La missive est encapsulée dans une enveloppe SMTP-S/MIME. Cette enveloppe contient :
- des entêtes:
- FROM, adresse de courriel comme spécifié dans ce document, valide avec un nom de domaine déclaré au niveau des DNS
- TO, adresse de courriel comme spécifié dans ce document, valide avec un nom de domaine déclaré au niveau des DNS
- X-priority, priorité selon la spécification de ce document
- SUBJECT vide par défaut, sans information signifiante sur le contenu du message
- un corps reprenant deux parties
- la missive, chiffrée avec la clé privée du certificat S/MIME liée à l'adresse FROM
- une signature S/MIME, obligatoire
Remarque : la missive doit être chiffrée dans tous les cas, même dans le cas d'un parcours flash (webservice sur couche HTTPS), afin de permettre une non adhérence des couches applicatives de production de l'enveloppe SMTP et de son transport.
La sécurité : authentification, confidentialité et horodatage
La sécurité est assurée à plusieurs niveaux :
- l'authentification des deux parties
- la confidentialité de l'information transmise
- l'horodatage des opérations d'émission et de réception des missives
SEPAmail utilise des procédés de cryptographie asymétrique.
Les adhérents disposent de façon certaine et sécurisée des clés publiques de chaque adhérent.
L'authentification de l'émetteur (adhérent SEPAmail) est alors assurée par une signature du condensat du contenu intégral de la missive avec la clé privée de l'émetteur. Le destinataire pourra alors vérifier que le condensat de la missive qu'il a généré est le même que celui de la signature qu'il a déchiffré.
La confidentialité est assurée par le chiffrement de la missive par l'émetteur avec la clé publique du destinataire. Ainsi, seul le destinataire pourra déchiffrer le flux avec sa clé privée.
La missive est horodatée en émission et en réception par une marque de temps de type date/heure. Les principes détaillés d'horodatage applicables à SEPAmail, inspirés des bonnes pratiques de la FNTC [5], sont décrits dans cette page.
Si un horodatage de type « contremarque de temps signée » est nécessaire, alors cet horodatage est réalisé sur l'enveloppe SMTP (et non seulement la missive) par un service tiers certifié, juste avant l'émission ou juste après la réception.
Le protocole d'échange des missives
L'échange des missives se fait nativement sur le réseau IP via la couche de transport TCP.
Sur ces couches, SEPAmail implémente deux parcours avec deux protocoles de communication différents :
- SMTP
- HTTPS+SOAP
Remarque : Cet échange fait l'objet de recommandations d'implémentation et sort du cadre normatif de ce document.
Remarque : Une étude est en cours pour permettre un parcours flash sur la base de HTTP+REST
La qualité de service
La qualité du service est soumise à un cadre faisant l'objet d'un document séparé [6].
Fonctionnement
Voici les schémas fonctionnels de la réception et de l'émission d'une missive, à réaliser par les automates des adhérents bancaires.
Les actions sur les données à effectuer sont en bleu, les tests en vert.
Les opérations se succèdent selon une série temporelle représentée de haut en bas.
Réception d'une missive nominale
Réception enveloppe SMTP au format S/MIME
Le récepteur de missive réceptionne des enveloppes au format S/MIME, quelque soit le canal d'entrée de cette enveloppe (SOAP ou SMTP).
Vérification de l'intégrité S/MIME
Il faut vérifier que l'enveloppe reçue est bien au format S/MIME.
Il doit y avoir également :
- le champ FROM renseigné
- le champ TO renseigné
- une partie chiffrée ou non
- une signature au format S/MIME
Remarque : le sujet SMTP peut être absent ou vide.
Extraction de l'en-tête MIME et des deux parties
On extrait l'adresse FROM, l'adresse TO et les deux parties jointes à l'enveloppe, normalement le contenu XML de la missive et une signature de ce contenu.
Vérification des BIC
Il faut extraire les sous-domaines des adresses FROM et TO.
Ces deux sous-domaines doivent être ceux d'un BIC appartenant à bic@scheme.
Celui correspondant au destinataire (TO) doit également être l'un des BICs rattachés à l'adhérent destinataire dans le référentiel member@scheme.
Vérification de l'écosystème
L'écosystème fourni par l'adresse de courriel doit être un ensemble de messages géré par le réseau SEPAmail, appartenant à ecosystem@scheme.
Déchiffrement
La première partie de l'enveloppe MIME est chiffrée (Content-Type: multipart/encrypted), et doit donc être déchiffrée avec la clé privée du destinataire (BIC extrait de l'adresse TO (protocole défini par l'attribut protocol de l'en-tête Content-Type). La chaîne ainsi déchiffrée est considérée comme la missive à vérifier.
Calcul du condensat de la missive
Un condensat du contenu de la missive est calculé selon la méthode déclarée dans les propriétés S/MIME (attribut micalg de l'en-tête Content-Type).
Vérification de la signature S/MIME de l'adhérent émetteur
La signature de l'adhérent SEPAmail émetteur est vérifiée en comparant le condensat calculé précédemment avec le résultat du déchiffrement de la signature.
Vérification de la conformité du XML
La missive est un document XML dont on vérifie qu'il est bien formé (la syntaxe est correcte)[7].
Vérification de la validité du XML
La missive est un document XML dont on vérifie :
- qu'il contient une référence à l'espace de nom SEPAmail,
- qu'il est valide (il valide le schéma XML qu'il référence).
Extraction en-tête
On extrait l'en-tête de la missive afin de permettre les vérifications suivantes.
Horodatage
La missive est horodatée en réception, ce qui consiste à enrichir le contenu XML en renseignant le champ « RcvDtTm » de l'en-tête de la missive avec la date et heure du système.
Vérification champ Rcv
Le champ Rcv contient au moins :
- un identifiant d'un utilisateur SEPAmail (généralement un identifiant bancaire IBAN, PAN, QXBAN ...),
- un identifiant de l'adhérent SEPAmail (BIC ou code entité SCHEME)
Cet identifiant doit correspondre à un utilisateur valide pour le service SEPAmail.
Il doit donc représenter un utilisateur actif dans l'un des référentiels d'identifiants gérés par l'adhérent destinataire de la missive : QXBAN@BIC, IBAN@BIC, PAN@BIC.
Acquittement
L'acquittement fait l'objet d'une émission de missive avec des règles qui ont été définies plus haut.
Routage interne de la missive
La missive est routée vers l'application bancaire ou le dispositif technique lié à l'écosystème SEPAmail concerné.
Réception d'une missive d'acquittement
L'adhérent SEPAmail n'est pas tenu dans l'absolu d'effectuer un traitement en réception de l'acquittement, sauf
- pour obtenir les statistiques demandées par le Scheme
- pour se conformer aux obligations de la Charte de l'adhérent
S'il souhaite traiter ces missives, il devra implémenter la même procédure que celle utilisée pour la réception d’une missive nominale, à la différence qu’une missive d’acquittement n’est pas elle-même acquittée.
Remarque : dans le cas d'erreurs au sein de la missive d'acquittement lors des vérifications (XML non conforme ou valide, en-têtes non valides), on ne peut donc pas signaler ces erreurs. Le mécanisme de renvoi de la missive nominale ou le procédé d'escalade doivent alors être utilisés, pour ne pas faire boucler le système.
Vérification antécédent missive d'acquittement
A ce stade, on peut vérifier si la missive d'acquittement possède déjà un antécédent :
- en réception : existe-t-il d'autres acquittements sur la même missive nominale ?
- en émission : existe-t-il une missive nominale ?
Routage interne de la missive vers le SI
La missive est routée vers l'application bancaire ou le dispositif technique lié à l'écosystème SEPAmail si lalogique du SI bancaire le nécessite.
Émission d'une missive nominale
Récupération ordre émission/information
Une missive nominale est émise sur ordre d'émission d'une application bancaire.
La missive peut être récupérée telle quelle, auquel cas elle est vérifiée avant signature/chiffrement et envoi.
La missive peut être construite par l'automate.
Dans les deux cas, les vérifications suivantes sont réalisées.
Vérification des BIC
Il faut extraire les BIC des informations transmises ou les déduire d'un référentiel IBAN@BIC. Les deux BIC doivent appartenir à member@scheme ou être SCHEME.
Celui correspondant à l'expéditeur (FROM) doit également être un BIC possédé par l'adhérent.
Vérification de l'ecosystème
L'écosystème peut-être déduit du message contenu dans la missive ou transmis par l'application bancaire (souhaitable). Ce doit être un écosystème géré par le réseau SEPAmail, appartenant à ecosystem@scheme.
Vérification MsvSnd
Le champ MsvSnd contient un identifiant (IBAN, QXBAN, PAN, ICQX/BIC, BIC)
Cet identifiant doit correspondre à un utilisateur valide pour le service SEPAmail.
Il doit donc être actif dans l'un des référentiels d'identifiants gérés par l'adhérent émetteur de la missive : QXBAN@BIC, IBAN@BIC, PAN@BIC.
Vérification de la conformité du XML du message
Le message à envelopper dans la missive est un document XML dont on vérifie la conformité.
Vérification de la validité du XML du message
Le message est un document XML dont on vérifie :
- qu'il contient une référence à un schéma XML de la famille de l'application demandée,
- qu'il est valide.
Construction de la missive
On construit la missive à partir du message et des informations précédemment vérifiées ou, dans le cas d'une transmission initiale de missive, par un enrichissement de cette missive.
Horodatage
La missive est horodatée en émission, ce qui consiste à enrichir le contenu XML en renseignant le champ « SndDtTm » de l'en-tête de la missive avec la date et heure du système.
Vérification de la conformité du XML de la missive
La missive construite à l'étape précédente est un document XML dont on vérifie la conformité.
Vérification de la validité du XML de la missive
La missive est un document XML dont on vérifie :
- qu'il contient une référence au schéma XML sepamail_missive[8]
- qu'il est valide.
calcul du condensat de la missive
Un condensat de la missive est calculé selon une méthode valide qui est déclarée dans les propriétés S/MIME (attribut micalg de l'en-tête Content-Type).
signature S/MIME de l'adhérent émetteur
La signature du condensat créé précédemment est réalisée à partir à l'aide de la clé privée de l'adhérent SEPAmail émetteur, dédiée à l'envoi de missives.
Chiffrement
Le chiffrement de la missive est réalisé à l'aide de la clé publique de chiffrement du destinataire.
Constitution de l'enveloppe MIME
Une enveloppe MIME est constituée. Elle contient :
- le champ FROM,
- le champ TO,
- une première partie contenant la missive éventuellement chiffrée,
- une seconde partie contenant la signature S/MIME de la missive.
Remarque: les pièces jointes éventuelles du message sont jointes au message et donc incluses dans le XML comme du binaire. Le mécanisme MIME des pièces jointes n'est donc pas utilisé pour celles-ci, mais seulement pour la missive ET la signature.
Envoi selon priorité
La priorité de la missive est reprise pour le transport
Émission d'une missive d'acquittement
Le cas d'une missive d'acquittement est similaire. Seul le message est remplacé par la structure d'acquittement, contenant le code d'acquittement.
Références
- ↑ http://xsd.sepamail.eu/1206/sepamail_missive.xsd
- ↑ Permalien http://documentation.sepamail.eu/wiki/Lexique
- ↑ Le nom de domaine sepamail.eu est géré par le scheme SEPAmail
- ↑ Pour une compréhension de l'organisation du scheme, consulter le SMIRK sur son organisation SMIRK ORG1110
- ↑ Guide des bonnes pratiques en matière de datation d’événements ou d'objets électroniques, http://www.fntc.org/, section guide (utilisateurs enregistrés)
- ↑ SMIRK escalade ESC1108
- ↑ Voir la définition du W3C que l'on retrouve [1]
- ↑ http://xsd.sepamail.eu/1206/sepamail_missive.xsd