version novembre 2012 - documentation...

PDF générés en utilisant l’atelier en source ouvert « mwlib ». Voir http://code.pediapress.com/ pour plus d’informations.PDF generated at: Fri, 23 Nov 2012 18:12:43 PMT

SEPAmail Norme 1206version novembre 2012

ContenusArticles

Contributeurs 1206 1Présentation générale 2

La messagerie 3Présentation et principes 3Les mécanismes d'échange 6Standards:Spécification de l'échange des enveloppes SEPAmail 10Les mécanismes d'identification 15Standards:ICQX 19Standards 1206:RIS2D 20Standards:Algorithme de génération du QXBAN 21La vision métier 22

La sécurité 25Principes de sécurité 25Standards:SMIRK CRY1203, la cryptographie 26

La norme 29La norme 29Standards:IG General rules 31Standards:IG color coding 32Standards:SMIRK MIS1202, la missive dans les échanges interbancaires 32Standards:IG missive 43Missive de service 47Horodatage des missives 48Statistiques 49Standards 1206:IG missive returnCodes 51Standards:IG message 52Standards:SMIRK MES1102, le message dans le réseau interbancaire 55Standards:SMIRK APP1103, l'application SEPAmail 58Standards:SMIRK REF1104, les référentiels 61Standards:SMIRK REF1201, le référentiel ICQX@SCHEME 64

L'application RUBIS 72RUBIS 72

Les principes généraux (RUBIS) 72Les avantages pour le client (RUBIS) 73Cas d'usage (RUBIS) 74La gestion des inscriptions des débiteurs (RUBIS 1206) 79La gestion des flux (RUBIS) 82Les normes utilisées par RUBIS 87Le lettrage des virements (RUBIS) 88Standards 1206:Les règles métier (RUBIS) 89Le récapitulatif des messages (RUBIS 1206) 91Standards 1206:IG payment.activation 92Standards 1206:IG Rubis ActivationRequest 92Standards 1206:IG Rubis ActivationReport 99Standards 1206:IG Rubis ActivationEnroll 107

L'application GEMME 109GEMME 109Les principes généraux (GEMME) 109Les avantages pour le client (GEMME) 110Cas d'usages (GEMME) 110La problématique des flux autour du prélèvement 112La gestion des flux (GEMME) 113Les normes utilisées (GEMME) 114Le récapitulatif des messages (GEMME) 114Standards:Les règles métier (GEMME) 115Standards:IG direct.debit 119Standards:IG Gemme MandateInitiationRequest 119Standards:IG Gemme MandateAcceptanceReport 125Standards:IG Gemme Prenotification 131Standards:IG Gemme RequestForCopy 134

L'application DIAMOND 137DIAMOND 137Les principes généraux (DIAMOND) 137Standards:Les règles métier (DIAMOND) 138Le récapitulatif des messages (DIAMOND) 145Standards:IG identification.verification 145Standards:IG Diamond VerificationReport 145Standards:IG Diamond VerificationRequest 149

L'écosystème secure 153Standards:IG secure 153Standards:IG Secure EnrollAdvise 153Standards 1206:IG Secure EnrollRequest 156Standards 1206:IG Secure EnrollReport 159

RéférencesSources et contributeurs de l’article 161Source des images, licences et contributeurs 163

Licence des articlesLicence 164

Norme 1206

Proposé par le Comité Normes

u Animatrice: Lise MAHAUT, CREDIT MUTUEL-CIC

u Committer: Olivier JOUSSELIN, SOLAGO

u Membres:

• Chloé BOIVIN, NATIXIS PAIEMENTS,

• Thierry PONS, Rui VAZ, Bertrand SANDOZ, BNP-PARIBAS

• Théa SIEMONS, Isabelle GODELIER, Groupe CREDIT AGRICOLE

• Frédérique FORTIN, Hervé NEUMAN, SOCIETE GENERALE

• Lionel CHEMLA, Cyril VIGNET, BPCE

• Hervé ROBACHE, STET

Approuvé' pprouvé par k Com fté de C oo rd don

u Animateur: Cyril VIGNET, BPCE k

u Comité de Projet:

• Christine GUILLAUMET, BNP-PARIBAS

• Sophie PARIZE, Erwan GUIGONIS, BPCE

• Marc RAINTEAU, CREDIT MUTUEL-CIC

• Arnaud-Louis CHEVALUER, SOCIETE GENERALE

• Luc LAFFON, Groupe CRED1T AGRICOLE

u Animatrice du Comité Normes : Lise MAHAUT, CREDIT MUTUEL-CIC

u Animatrice du GT Juridique : Valérie NDJEINTI, BPCE

u Animatrice du GT Expérimentation : Christine GUILLAUMET, BNP-PARIBAS

u Animateurs du GT sécurité LaurenjRECHAL, BNPPARIBAS, Régis ROCROY, SOCIETE GENERALE

u Animateur du GULS : Nicolas MUHADRI, STREAMMIND

u Animateur GT Banque de France: Manfred OLM, DECIBI

u Coordination STET: Arnaud MARTIN, STET

Cette norme est mise à disposition selon les termes de la licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

Présentation générale 2

Présentation généraleSEPAmail est un service de messagerie sécurisée pour l'ensemble des entités économiques européennes.SEPAmail utilise des flux XML sécurisés utilisant le BIC et l’IBAN comme identifiant de référence.En valorisant Internet et les normes du W3C, le réseau SEPAmail permet, à coût réduit, la réalisation d’échangescomplexes entre les clients des banques à un niveau mondial.Ce nouveau réseau interbancaire se veut une contribution de l’industrie bancaire à l’agenda de Lisbonne et Europe2020 en facilitant les échanges dématérialisés entre les entités économiques.

HistoriqueSEPAmail est un projet d’innovation démarré en 2008 dans le but de proposer une messagerie interbancaire sécuriséeprincipalement pour une utilisation pour des documents non comptables autour des paiements (factures, mandats,devis, avis,...)Ce concept a été décliné techniquement et une série de messages structurés pour les flux autour des prélèvements aété définie. Sur la base de ce concept un partenariat a été signé avec SFR pour la mise en œuvre d’un pilote sur fluxréel.

Pré-requisPour comprendre cette documentation, un certain nombre de notions doivent être connues, voire maîtrisées. Voiciune liste de ce qui est supposé connu :• le fonctionnement du courrier électronique : sa structure (RFC 822 et suivants, ainsi que ceux relatifs à S/MIME),

son mode d'acheminement (de MTA à MTA), les erreurs protocolaires pouvant survenir ...• le fonctionnement de DNS• de bonnes notions de cryptographie, en provenance par exemple du portail de la cryptologie [1] de WikipediaSi vous consultez la documentation sur le Wiki de SEPAmail, nous vous recommandons en outre de comprendreauparavant ce qu'est un wiki, comment il fonctionne et comment interagir avec lui.

Références[1] http:/ / fr. wikipedia. org/ wiki/ Portail:Cryptologie

http://fr.wikipedia.org/wiki/Portail:Cryptologiehttp://fr.wikipedia.org/wiki/Portail:Cryptologie

3

La messagerie

Présentation et principes{{Norme 1206}} {{TOC:messagerie}} Le système SEPAmail se compose :• d’un réseau interbancaire sécurisé assurant le transport de messages structurés conformément aux normes

partagées par les utilisateurs de SEPAmail. Le réseau SEPAmail se déploie par l’interconnexion entre serveursconformes à la norme installés dans chaque établissement adhérent.

• de services métiers à valeur ajoutée, supportés par le système SEPAmail au travers de l’utilisation d’une famille demessages structurés liés à chaque service métier mis en ligne sur ce réseau.

SEPAmail décrit également les connecteurs permettant aux entreprises d'envoyer, de recevoir et de gérer desmessages –- ou plus exactement, en termes SEPAmail, des missives – à travers diverses formes d'interfaces :courriel, Web service, et même échange de fichiers.

Les espaces de confiancePour assurer une parfaite sécurisation des échanges et des données, SEPAmail repose sur trois espaces de confiancecomplètement distincts et indépendants :

• L’espace expéditeur – banque de l’expéditeur, dont la sécurité repose sur les systèmes en place : banque à distanceet authentification associée, remise de fichiers ...

• Le réseau interbancaire SEPAmail dont la sécurité repose sur :

http://documentation.sepamail.eu/index.php?title=Fichier%3ASEPAmail_espaceIndependantSecurite.png

Présentation et principes 4

• Un nom de domaine unique géré par le « scheme-manager » et associant l’adresse BIC.sepamail.eu à la bonneadresse physique de routage de la banque possédant le BIC

• Une déclaration au scheme-manager de la clé publique qui sera utilisée par S/MIME, déclaration faite enmême temps que la fourniture de l’adresse IP de la banque

• L’espace banque du destinataire – destinataire, dont la sécurité repose également sur les systèmes en place :banque à distance et authentification associée, remise de fichiers, ...

• Il y a un certificat S/MIME de signature et un certificat S/MIME de chiffrement par BIC et par applicationSEPAmail.

La structuration du systèmeL'élément de base pour les échanges d'informations, dans SEPAmail, est la missive. Quel que soit le canal d'échange,et quels que soient l'expéditeur et le destinataire, toutes les informations circulant dans le système sontsystématiquement structurées en missives. Il existe quatre types de missives, qui seront décrites en détail par la suite:• la missive nominale, qui sert d'acheminement à un message• la missive d'acquittement, élément essentiellement protocolaire qui permet notamment à l'expéditeur d'être sûr de

la réception des informations transmises• la missive de service, permettant d'échanger des commandes et des réponses entre des éléments actifs du système.

Elle ne peut pas être utilisée en interbancaire.• la missive d'interfaçage (SMAPI), permettant à l'éditeur d'une solution SEPAmail de donner accès à des fonctions

internes de sa plate-forme. Elle ne peut être utilisée qu'en intrabancaire.La missive est sécurisée par des mécanismes de signature et de chiffrement. Elle peut être vue comme uneenveloppe, dont le contenu peut être quelconque, mais n'est accessible qu'au destinataire. Dans la plupart des cas, etnotamment dans le cas des missives nominales, le contenu d'une missive est un message SEPAmail. Le messagecontient des informations relatives au service mis en jeu, la nature de ces informations variant bien entendu selon lemessage. L'ensemble des éléments de SEPAmail, missives et messages, sont des structures XML. Tous les élémentssont décrits par des schémas XML précis, s'appuyant, dans la mesure du possible, sur la norme et le dictionnaire dedonnées ISO 20022. Enfin, les missives sont échangées, entre les acteurs du système SEPAmail, par le biais d'unmécanisme d'échange. Trois mécanismes, qui sont détaillés par ailleurs, sont actuellement définis et implémentésdans le système :• le courrier électronique• un web-service• un système d'échange de fichiers.Le schéma ci-dessous récapitule les éléments de structure du système SEPAmail:

Présentation et principes 5

Rappel S/MIME• Le standard S/MIME étend le format de courrier MIME pour permettre, au travers de plusieurs mécanismes

cryptographiques, de chiffrer et signer les différents composants d'un message. Il s'applique donc directement surle contenu du message et non sur le canal de transport de ce contenu.

• La clé de session est insérée dans l'en-tête de chaque partie S/MIME, après avoir été chiffrée à l'aide de la clépublique de chacun des destinataires. Ainsi ces derniers pourront par la suite déchiffrer, à l'aide de leurs clésprivées, la clé de session et accéder au contenu de la partie S/MIME.

• Par ailleurs, la signature d'une partie S/MIME est générée à l'aide de la clé privée de l'expéditeur. La vérificationde cette signature à l'aide de la clé publique de l'expéditeur permet de garantir au destinataire l'identité de celui-ciet de contrôler l'intégrité de la partie S/MIME.

Source : http:/ / www. commentcamarche. net/ contents/ crypto/ s-mime. php3#q=smime& cur=1& url=%2F

http://documentation.sepamail.eu/index.php?title=Fichier%3AGASEM_cyv_2011_fr_diapo_041.pnghttp://www.commentcamarche.net/contents/crypto/s-mime.php3#q=smime&cur=1&url=%2F

Les mécanismes d'échange 6

Les mécanismes d'échange{{Norme 1206}} {{TOC:messagerie}}

Précisions sur les échangesDans son acceptation initiale, SEPAmail gère uniquement une interface interbancaire, c'est à dire celle des fluxéchangés entre les banques.Dans la pratique, il se peut qu'une banque utilise soit le protocole SEPAmail, soit la structure SEPAmail (missive),soit les 2 dans ses échanges avec ses propres clients (interface client). Plus généralement, une banque peut aussiutiliser en interne (interface intrabancaire) les normes SEPAmail.Trois mécanismes d'échanges ont été définis : courriel, web service, fichier.Parmi ces mécanismes d'échange disponibles, seul le canal courriel est obligatoire, et doit être supporté par tous lesadhérents à SEPAmail en interbancaire. Le mécanisme d'échange interbancaire fondé sur les Web services estfacultatif (même si c'est celui mis en œuvre dans l'expérimentation).Par ailleurs, SEPAmail est un système asynchrone par architecture. De ce fait, l'acheminement des messages ne peutêtre soumis à aucun engagement absolu quant au temps de transit. Les délais liés aux priorités des missives sont doncà mettre en perspective du canal utilisé – par exemple, une missive en priorité HIGHEST envoyée par courriel risquefort de ne pas être acquittée dans les délais prévus par ce niveau de priorité.Un troisième mécanisme (fichier) a été défini pendant la phase d'expérimentation, initialement pour des besoinsintrabancaires, et ne concerne JAMAIS l'interface interbancaire. Il peut être utilisé pour l'interface client oul'interface intrabancaire.La description donnée ici des mécanismes d'échange est essentiellement fonctionnelle, et légèrement technique. Desspécifications techniques complètes, traitant notamment des problématiques d'adressage, sont disponibles ici.

Le courrier électronique

PrincipeLe mécanisme d'échange fondé sur le courrier électronique a été le premier implémenté, et le système SEPAmail entire d'ailleurs son nom. Le principe en est simple : tous les éléments sont acheminés comme des messages mail.Le contenu du mail doit donc être conforme au RFC 3851 [1][2], le corps du mail étant obligatoirement une missiveSEPAmail, apparaissant comme un attachement au format S/MIME (RFC 5321 [3][4]).L'expéditeur et le destinataire du mail sont obligatoirement de la forme :

@.sepamail.eu

correspond à un ensemble de messages acheminés.Cinq écosystèmes sont actuellement supportés :• direct.debit, qui est utilisé par l'application GEMME• payment.activation, qui permet la création de virements de proximité, et est utilisé par l'application RUBIS• identification.verification, pour la vérification d'identifiants bancaires, en rapport avec l'application DIAMOND• secure, qui permet l'échange d'éléments de sécurité (certificats ou messages) entre tous les intervenants du

système SEPAmail• test, destiné comme son nom l'indique à des tests de configuration et/ou de communication est le BIC de l'expéditeur (ou du destinataire). Dans le cas d'un échange interbancaire, les deux adresses doivent présenter ce BIC. Dans le cas d'un échange entre client et banque, l'adresse de l'expéditeur peut comporter un

http://www.ietf.org/rfc/rfc3851.txthttp://www.ietf.org/rfc/rfc5321.txt


IBAN au lieu du BIC.Les messages doivent être d'abord signés en utilisant la clé privée de signature de l'expéditeur, puis chiffrés enutilisant la clé publique de chiffrement du destinataire.Les adresses IP des serveurs de mail doivent être déposées au préalable auprès du Scheme SEPAmail, ainsi que lescertificats utilisés pour le chiffrement et la signature des messages.

Utilisation du canal courrielEn-dehors de l'utilisation d'adresses IP fixes et pré-déclarées pour router les messages, les messages acheminés parce canal suivent les règles habituelles du courriel. Il est donc de la responsabilité de l'expéditeur de s'assurer de labonne émission des messages qu'il envoie : les notifications d'erreur ou de non-remise sont acheminées par le canalstandard entre MTA, et l'expéditeur doit prendre en charge la réexpédition éventuelle dans ce cas.

Le Web service

PrincipeCette méthode d'échange a été initialement prévue pour permettre à un émetteur de gérer ses messages de façon plussynchrone et plus directe que le courrier électronique.Dans l'état actuel du système, il est déployé pour les échanges entre banques (connecteur interbancaire) et pour leséchanges entre les entreprises et leurs banques (connecteur entreprise).Le principe du Web service est similaire à celui du courrier électronique : le message envoyé comporte un en-têtebasique, et un corps, respectant le format S/MIME, contenant une missive SEPAmail, signée puis chiffrée.Dans l'en-tête comme dans la missive, l'identifiant de l'expéditeur peut être une adresse mail quelconque, gérée par lecréancier, mais doit correspondre précisément au certificat utilisé pour chiffrer la missive. À défaut, la transmissionsera rejetée. Le destinataire, lui, est de la même forme que pour le canal mail : @BIC.sepamail.eu oùle BIC est celui de la banque du créancier.La connexion avec le Web service se fait au travers du protocole HTTP, donc sans chiffrement de la liaison. Lesdonnées binaires sont encodées au travers du protocole MTOM. Comme pour tous les autres mécanismes d'échangepouvant être ouverts vers l'extérieur, les messages doivent être, d'une part signés en utilisant la clé privée designature de l'expéditeur, d'autre part chiffrés en utilisant la clé publique de chiffrement du destinataire. Tous lestypes de missives peuvent figurer dans un message WebService.Ceci ouvre donc de nombreuses possibilités à l'entreprise utilisant ce canal :• envoyer des nouveaux éléments (mandats, notifications ...) à SEPAmail, en utilisant des missives nominales• se connecter pour gérer les messages reçus (acquittements, modifications de coordonnées bancaires ...), par le

biais de missives de service• dans des versions futures, modifier ses informations ou sa relation avec le système SEPAmailDans tous les cas, le Web service n'est prévu que pour fonctionner en mode "pull" : un client doit se connecter auWeb service à son initiative pour communiquer.


Utilisation du Web serviceDans un cadre intrabancaire (communication créancier-banque du créancier notamment), l'utilisation de la missivede service sur le Web Service peut se substituer entièrement à la connexion SMTP. Le serveur SEPAmail joue alorsle rôle de serveur de messagerie pour ses clients, ce qui n'est pas son rôle fondamental.Dans ce cadre, il est donc de la pleine et entière responsabilité de l'entreprise ou du créancier :• de se connecter à intervalles suffisamment fréquents pour recevoir les nouveaux messages.• de gérer correctement une éventuelle absence de réponse de la part du serveur (time-out)• d'exploiter ces messages, étant entendu que SEPAmail n'assure qu'un rôle de stockage et non d'exploitation, sauf

pour les données concernant strictement le système SEPAmail (état des mandats dans la base de données interne,par exemple)

• de gérer les messages présents sur le serveur, notamment en supprimant ceux qui ne sont plus utiles. Ceci a pourbut, d'une part de faciliter la gestion des messages restants en réduisant leur nombre, d'autre part de limiter laplace occupée sur les serveurs SEPAmail, dont la vocation n'est pas à proprement parler de servir des messages.

Précisons que l'archivage est assuré par SEPAmail de façon interne. Le fait de supprimer un message par le biais duWeb service le rend donc inaccessible par ce même canal, mais ne le détruit pas entièrement des données deSEPAmail.

L'échange de fichiers

PrincipeCe troisième canal d'échange est conçu pour être utilisé uniquement sur une interface interne à la banque, notammentparce que les données sont transférées sans être chiffrées. Il est donc avant tout destiné à s'interfacer avec dessystèmes d'informations bancaires partageant tout ou partie de l'infrastructure avec celle de SEPAmail. Dans cecanal, les éléments à acheminer sont stockés dans des fichiers, aussi bien en entrée qu'en sortie. Ceci permet doncd'organiser des traitements en batch des données. Les fichiers seront au format XML, conformément au schémafourni par SEPAmail.L'en-tête du fichier contient trois éléments, tous obligatoires :• la date et heure de constitution du fichier.• l'identification du tiers avec lequel l'échange se déroule. Dans tous les cas, c'est un BIC. Pour un fichier entrant,

c'est le BIC de l'émetteur et, pour un fichier sortant, c'est celui du destinataire.• le nombre de missives contenues dans le fichier.Si le nombre de missives effectivement présentes après l'en-tête du fichier est différent de celui indiqué dansl'en-tête, une erreur protocolaire sera déclenchée, aucune des missives ne sera traitée, et elles feront toutes l'objetd'un acquittement négatif.Un fichier non conforme à la norme ou au schéma peut être purement et simplement ignoré : aucun acquittementprotocolaire, au niveau fichier, n'existe dans ce canal. Comme pour les autres canaux, l'expéditeur qui ne reçoit pasles missives d'acquittement correspondant à ses missives nominales doit prendre en charge leur réémission.


Utilisation du canal fichiersL'organisation du canal fichiers et ses détails précis sont laissés à l'initiative de l'éditeur de solutions SEPAmail,notamment en ce qui concerne :• les noms des fichiers• les emplacements où ils se trouvent• la fréquence de leur intégration et/ou de leur production• l'obligation ou non de produire un fichier si aucun élément ne doit être transmis.

Exemple de fonctionnementA titre d'exemple, nous décrivons ici un mode de fonctionnement de ce canal adopté lors de l'une desexpérimentations, avec l'une des implémentations de SEPAmail :Chaque tiers souhaitant utiliser un connecteur fichiers dispose d'un répertoire spécifique pour ses échanges defichiers. Ce répertoire comportera deux sous-répertoires, l'un pour les fichiers entrants et l'autre pour les fichierssortants, afin de séparer clairement les deux flux.Le nom des fichiers sera de la forme _...xml• est la date de création sous la forme aaaammjj• est l'heure de création sous la forme HHMM• est le BIC de l'émetteur ou du destinataire, selon les cas• est l'application associée aux messages contenus dans ce fichier, par exemple gemme, rubis, test ...

Elle peut également prendre la valeur ALL si le fichier contient des messages destinés à (ou provenant de)plusieurs applications.

• peut prendre deux valeurs :• in si le fichier est entrant dans SEPAmail, donc produit par un tiers• out s'il est produit par SEPAmail, donc à destination d'un tiers.

Un fichier peut contenir un nombre quelconque de missives, y compris 0. Il sera donc composé d'un en-tête, puisd'un nombre quelconque de missives, de type Missive.Il est recommandé que la date de création figurant dans l'en-tête du fichier corresponde au nom du fichier lui-même,mais ceci n'est pas obligatoire.Le système SEPAmail vérifiera le contenu du sous-répertoire des fichiers entrants toutes les heures, à 5 minutesaprès l'heure juste. Il produira ensuite un fichier dans le répertoire des fichiers sortants, contenant toutes les missivesdisponibles pour ce destinataire à ce moment. Ce fichier sera disponible chaque heure, au plus tard 35 minutes aprèsl'heure juste. Un fichier devra être généré à chaque heure, aussi bien par le système SEPAmail que par le tiers, et ce,même s'il n'y a aucune missive à transmettre.Chaque partie a la responsabilité de supprimer ou d'archiver les fichiers après traitement.SEPAmail archivera les fichiers entrants, et le tiers gèrera les fichiers sortants. En tout état de cause, un fichier datantde plus de quatorze jours pourra être purement et simplement supprimé par SEPAmail, afin d'éviter l'engorgement dusystème.


Références[1] http:/ / www. ietf. org/ rfc/ rfc3851. txt[2] http:/ / www. ietf. org/ rfc/ rfc3851. txt[3] http:/ / www. ietf. org/ rfc/ rfc5321. txt[4] http:/ / www. ietf. org/ rfc/ rfc5321. txt

Standards:Spécification de l'échange desenveloppes SEPAmail

document de la série: spécifications fonctionnelles et/ou techniques

les mécanismes d'échange des enveloppes SEPAmail

version 1.0 du 24 juillet 2012

Au sein du réseau des adhérents SEPAmail, il est nécessaire de pouvoir simplement échanger des enveloppesSEPAmail. Ces enveloppes se concrétisent sous la forme de composants S/MIME, au sein d'un message SMTP. Cedocument 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 decette missive) est prise en charge en émission et en réception par un automate qui, selon le protocole decommunication 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 ressourcehttps://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éthodereceiveEnvelopeSmtp)

• assure l'échange de cette enveloppe dans le cas de HTTP de deux manières possibles :• en l'insérant dans le corps d'une requête POST envoyée sur la ressource

http://bic.sepamail.eu/ecosystem/receive-envelope-smtp et attendant une réponse 200 ou 204• en l'envoyant via un service web SOAP (url http://bic.sepamail.eu/ecosystem/soap à l'aide d'une méthode

receiveEnvelopeSmtp)Remarque : la méthode mise en place (décembre 2011) se nomme sendMissive et non receiveEnvelopeSmtp.

http://www.ietf.org/rfc/rfc3851.txthttp://www.ietf.org/rfc/rfc3851.txthttp://www.ietf.org/rfc/rfc5321.txthttp://www.ietf.org/rfc/rfc5321.txt

Standards:Spécification de l'échange des enveloppes SEPAmail 11

Spécifications techniques

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

Iln'est pas prévu de réseau de secours dans la phase expérimentale (aucun paiement ne transite par SEPAmail, c'estjuste 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'adressageChacun des systèmes d'information définit une adresse DNS dans le registre du domaine sepamail.eu, géré par leScheme, 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,

http://documentation.sepamail.eu/index.php?title=Fichier:ReseauInternetSepamail.png


• 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 uneré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 principalmais l'adhérent SEPAmail peut aussi implémenter une liste de MX externes pour répartir la charge entre plusieursserveurs externes au domaine sepamail.eu.Remarque : il faut qu'un service dédié du Scheme local (QXOO) s'occupe de l'aspect DNS.

L'authentificationIl y a plusieurs authentifications. La compréhension du concept est généralement mal partagée par les parties devantle 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 SSLversion supérieure ou égale à la version 3.3).

l'échange avec SMTPLe 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 HTTPSLe 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 styled'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 HTTPLe transport peut aussi se réaliser entre deux serveurs implémentant HTTP sans couche TLS. La missive est alorsforcé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 styled'architecture comme REST.

Échange de l'enveloppe SEPAmail avec une mécanique simpleLe 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 204La ressource est spécifique à ecosystem (équivalent de l'échange SMTP sur une adresse de [email protected]). Elle précise la méthode de réception de l'enveloppe smtp en la nommant explicitementreceive-envelope-smtp.Charge à l'automate de distribuer l'enveloppe dans la boite de courriel [email protected] pour le traitementSEPAmail.

Échange de l'enveloppe SEPAmail avec une couche SOAPLe principe est d'utiliser le protocole SOAP (version supérieure ou égale à 1.2[2]) qui n'est pas un protocole de lafamille 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 desmé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 receiveEnvelopeSmtp• avec comme arguments :

• les paramètres d'authentification• la missive à envoyer

Charge à l'automate de distribuer l'enveloppe dans la boite de courriel [email protected] pour le traitementSEPAmail.


Notes d'architectureLes notes qui suivent n'ont pas de valeur normative. Elles sont fournies à titre de précisions sur les choix techniqueset é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 desfiles 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 surplusieurs architectures les fonctions différentes (notamment l'antispam, l'antivirus) et gérer de façon différenciée letrafic 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 protocolede 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 chargedevrait 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

http://tools.ietf.org/html/rfc5246http://tools.ietf.org/html/rfc6176http://www.w3.org/2002/07/soap-translation/soap12-part0.html

Les mécanismes d'identification 15

Les mécanismes d'identification{{TOC:messagerie}}

Le BIC et l’IBANLa problématique de l’adressage dans une messagerie repose sur le partage des identifiants. SEPAmail a apporté unedouble réponse, non dans une approche technique, mais dans une vision métier :• La messagerie étant plutôt pour une sécurisation au travers de banques, le BIC est l’identifiant du ‘‘fournisseur

d’accès SEPAmail’’• L’identifiant du client de la banque peut être choisi parmi plusieurs (numéro de compte, numéro de carte,

identifiant dédié banque en ligne) mais la proximité du SEPA et la promesse de services autour des paiementsrendent le choix de l’IBAN, paneuropéen, une évidence.

Même si le sigle IBAN@BIC est utilisé, il ne correspond qu’à une vue métier et non à une vue technique. Du pointde vue métier :• Le BIC, identifiant des banques, n’est pas sensible et donc circule en clair• l’IBAN, identifiant des clients, est par nature une donnée sensible et doit être protégée. Il ne peut donc circuler

que sous un format confidentiel

le BIC : des contraintes pour les clientsDe plus, la première expérimentation avec SFR a mis en évidence :• le créancier peut facilement retrouver l'IBAN à partir du numéro de compte client (BBAN en anglais), par un

algorithme connu• le créancier ne dispose pas de moyen fiable de trouver un BIC.Prenant en compte la réalité du terrain, anticipant aussi la pression réglementaire et projetant la norme SEPAmaildans une utilisation client-banque, SEPAmail a proposé de ne pas obliger le client à fournir de BIC mais uniquementun IBAN, charge à la banque SEPAmail de fournir l'enrichissement.

Une identification non figéeDés le début de SEPAmail, les standards et la mise en œuvre se sont attachés à ne pas solidifier l’usage du BIC et del’IBAN pour être en mesure d’utiliser d’autres types d’identification pouvant répondre à des besoins complémentairesà ceux du SEPA. En effet dans le SEPA, l'utilisation de l’IBAN ne couvre que les paiements par virement ouprélèvement.De manière plus générale, toute identification de type identifiant@bic peut devenir intéressante pour SEPAmail.Cette caractéristique, couplée à la notion précédente d'enrichissement, permet de proposer toute une gammed'identifiant dans SEPAmail.


Identification par PAN : Primary Account Number, ou tout simplementnuméro de carte bancairele numéro de carte est un identifiant au moins aussi, voire plus, connu que l'IBAN. Il a aussi l'avantage d'être souventprésent avec le client, le porteur de carte, plus que le Relevé d'identité bancaire !le PAN peut être facilement utilisé pour :• identifier le BIN (bank identification number) à partir du PAN. Dans la plupart des cas, prendre les 6 premiers

caractères suffit• associer le BIC au BIN : ceci se fait à partir du fichier des établissements géré par Cartes Bancaires ou par

d'autres organismes pour d'autres places européennes• formater les envois SEPAmail avec

• le BIC et le PAN, ce dernier remplaçant l'IBAN pour identifier le client destinataire• le BIC et l'IBAN pour le client émetteur de l'envoi

• associer, au niveau de la banque destinataire de l'envoi, le PAN avec soit l'IBAN soit le compte référence duclient. Par définition, tout émetteur de carte sait associer un numéro de carte avec un numéro de compte, neserait-ce que pour débiter son client !

L'utilisation du PAN pourrait servir à une extension des avis de paiement aux paiements monétiques : JADE pour lamonétique !

QXBAN : une identification SEPAmailMême si l'IBAN devient couramment utilisé, il pose un souci de sécurité car c'est un élément sensible du client. Ilpeut être utilisé par certains fraudeurs, soit comme mode d'identification auprès d'un centre d'appel peu regardant surles procédures d'authentification, soit pour générer des prélèvements y compris sans mandats préalables.Dans le cadre de l'expérimentation RUBIS et de l'expérimentation SAPPHIRE, il est apparu les contraintes suivantes:• il n'est pas acceptable de donner directement l'IBAN au créancier

• il est difficile de promouvoir l'IBAN pour les clients dont le souci principal reste la communication de l'IBANet donc qui continuent avec le chèque (car le prélèvement nécessite de communiquer l'IBAN)

• il apparaît une augmentation de la sensibilité des bases de données créanciers dès lors que l'on y ajoute desnuméros IBAN

• il n'est pas pratique d'échanger un IBAN entre 2 personnes.SEPAmail a donc créé le QXBAN :• un format d'IBAN (ou presque) pour rester compatible avec les développements et normes SEPAmail• une utilisation interdite en compensation, donc pas de prélèvements possibles• une utilisation peu ergonomique (grand nombre de caractères) pour éviter une utilisation dans des procédures

d'authentification• une utilisation réservée au réseau SEPAmailLe format du QXBAN suit presque la norme des IBAN avec quelques spécificités :• le country code est QX ce qui est le seul NON RESPECT de la norme des IBAN. Le code pays QX n'existant pas,

il ne peut y avoir de compensation avec un tel code.• le code banque DOIT être le BIC de la banque, ou tout du moins celui de routage SEPAmail des flux• le numéro de compte DOIT être un tirage aléatoire sous la responsabilité de la banque du client• le numéro de compte DOIT utiliser la longueur maximale pour augmenter le niveau d'aléa du QXBAN.Il est bien entendu que la banque qui a émis un QXBAN s'engage à traiter sa réception, et donc à prévoir lacorrespondance interne entre le QXBAN et l'IBAN du client.


On trouve ici l'algorithme de génération du QXBAN

Relevé d'identité SEPAmail : RIS2DIl est apparu une synergie intéressante des travaux sur le QXBAN et des travaux du projet 2D-DOC. Ceci a conduit àdéfinir la notion de RIS2D ou relevé d'identité SEPAmail reprenant :• la logique de relevé de compte bancaire mais adapté à l'identification d'un "compte SEPAmail"• la matérialisation sous forme de code-à-barre 2D tant pour une simplification de la lecture qu'au vu du nombre de

données à gérer.Le RIS2D reprend les informations de NOM, PRENOM, QXBAN et une signature de ces données au format2D-DOC.Il n'est pas prévu de représentation du Relevé d'Identité SEPAmail hors de celle en format RIS2D.Le format intègre, outre le code-à-barre :• les étoiles apportant un rappel du logo SEPAMAIL• un début de mention du prénom et du nom en clair pour pouvoir s'y retrouver.

Protection des identifiants pour le paiement par virementLe schéma suivant montre comment il est possible d'éviter de communiquer son IBAN pour le paiement parvirement et donc de protéger cette donnée sensible.

1. A l'inscription de son client au service, la banque du client génère le QXBAN, maintient la base de données{QXBAN->IBAN} et le remet à son client sous forme de RIS2D (puce 1)

2. le client a ainsi donc tout le loisir de mettre à disposition du créancier ce fichier image facilement lisible et dont lecréancier peut extraire le QXBAN, le nom et le prénom (puce 2)

3. le créancier peut démarrer la séquence de demande de règlement en utilisant exclusivement le QXBAN de sonclient (flux bleu)

http://documentation.sepamail.eu/index.php?title=Fichier:Messagerie-identification-rubis.png


4. la banque recevant la demande peut identifier son client grâce à sa base de données {QXBAN->IBAN} (puce 4)et proposer le service de validation à son client. Notons au passage que le compte qui sera débité peut être uncompte quelconque de ce client si la banque offre ce service.

5. le flux de retour (flux rouge) se fait en utilisant le QXBAN du client débiteur6. le virement utilise l'IBAN du donneur d'ordre. Cependant cet IBAN reste dans l'enceinte de la banque du

créancier car celle-ci n'a pas le droit de remettre l'IBAN du donneur d'ordre à un bénéficiaire.

Protection des identifiants pour le paiement par prélèvementLe prélèvement pose une problématique certaine du fait de l'obligation de donner son IBAN au créancier. Uneutilisation des identifiants (RIS2D-QXBAN) et des flux SEPAmail pourrait permettre de s'affranchir de cettecontrainte. En effet la norme SEPA DIRECT DEBIT impose une référence unique de mandat (RUM) que l'on peutmettre à profit.1. comme précédemment, la banque du débiteur a généré et mis à disposition un RIS2D (puce 1)2. le client débiteur donne son RIS2D ou son QXBAN au créancier tout en demandant un paiement par

prélèvement. Notons au passage que cela pourrait pousser plus de clients à ce mode de paiement.3. le créancier génère une demande de mandat avec le service GEMME@SEPAMAIL en utilisant le QXBAN et la

RUM, référence unique du mandat (flux bleu)4. la banque du débiteur identifie son client grâce à la base de données {QXBAN->IBAN}, fait choisir le compte de

prélèvement désiré par son client et renvoie (flux rouge) le mandat de prélèvement accepté par son client et avecle véritable IBAN du client. En parallèle, la banque du débiteur mémorise les RUM acceptées par son client et engère la validité.

5. la banque du créancier constitue une base de données {créancier/RUM -> IBAN} et indique à son client créancierque le mandat est accepté

6. il suffira au créancier de fournir la RUM comme identifiant de paiement dans ses fichiers d'initiation deprélèvement (flux noir)

7. la banque du créancier complète la RUM avec l'IBAN trouvé dans la base de données {créancier/RUM -> IBAN}et émet en compensation.

Ainsi les identifiants sensibles (IBAN) restent dans les enceintes bancaires pour une meilleure protection des clientset une plus grande simplicité de gestion par le créancier.De plus le mécanisme précédent ne crée pas de lien fort entre la banque du créancier et le créancier. Celui-ci peutchanger de banque assez simplement :1. le créancier envoie des avenants de mandats en utilisant le couple QXBAN/RUM en passant par sa nouvelle

banque2. la banque du débiteur peut répondre immédiatement sans validation nécessaire par le débiteur puisque nous

sommes dans le cas d'un amendement3. la nouvelle banque du créancier constitue la base de données {créancier/RUM -> IBAN} et pourra ainsi

compléter les flux de prélèvements

ICQXl'ICQX est un identifiant des personnes morales participant à SEPAmail. La normalisation de l'ICQX est dérivée decelle de l'ICS.

Standards:ICQX 19

Standards:ICQXL'ICQX est l'identifiant unique d'un créancier personne morale dans le réseau SEPAmail. Cet identifiant est géré parle SCHEME. Il est unique pour une entité économique et pérenne.Il n'est pas nécessaire qu'un créancier dispose d'un identifiant ICS pour obtenir un ICQX.

PrincipesLes ICQX sont destinés à gérer le référentiel des créanciers des différents services de SEPAmail, [email protected] base des ICQX est gérée par le Scheme Manager SEPAmail, qui attribue donc les ICQX à sa seule discrétion.• L’ICQX repose sur la norme définie dans SEPA pour l’ICS• Le code pays est celui du RIS : QX• Les 2 premiers caractères du Business code de l’ICS sont utilisés pour le code pays du créancier• Pour les créanciers de test ces 2 premiers caractères seront positionnés à QX• Le troisième caractère du Business code est au libre choix du créancier. Il est mis à Z par défaut

StructureL’ICQX est un champ de 35 caractères alphanumériques comprenant :• Positions 1 et 2 : les caractères « QX »• Positions 3 et 4 : deux chiffres : clé de contrôle (ISO7064)• Positions 5 et 6 : deux lettres majuscules

• Soit le code pays du QXOO local : « FR » pour la France• Soit QX dans le cas des ICQX de test

• Position 7 : un caractère alphanumérique• « Z » par défaut quand l’ICQX est attribué par le QXOO (ou local OO)• Caractère à la discrétion du créancier : il peut donc changer ce caractère suivant le message

• Positions 8 à 35 (aussi appelé « identificateur ») : la constitution de ces 28 caractères est à la discrétion du QXOO(ou local OO)

Références• SMIRK le référentiel ICQX@SCHEME

http://documentation.sepamail.eu/index.php?title=Standards:SMIRK_REF1201

Standards 1206:RIS2D 20

Standards 1206:RIS2D

un exemple de RIS2D

Un RIS2D (Relevé d'Identité SEPAmail 2D) est une image de typecode barre 2D au format datamatrix[1] contenant des données propresà l'utilisateur de SEPAmail:

• nom,• prénom,• BIC,• identifiant QXBAN,• date d'expirationVoici un exemple de RIS2D

le contenu

Le contenu du RIS2D est conforme à la norme 2D-DOC, à quelquesdétails près qui ont fait l'objet d'une demande d'extension de cettenorme [2].

Les champs suivants de 2D-DOC sont obligatoires pour le RIS2D (en italique, les éléments actuellement absents de2D-DOC) :• bloc d'en-tête, avec un code d'identification de document à 05• 08 - date d'expiration• 30 - qualité, nom et prénom dans l'ordre qualité/nom/prénom, en séparant les champs par des /• 31 - code IBAN, qui contiendra le QXBAN• 32 - code BIC/SWIFT• bloc signature

ExempleVoici un exemple de contenu de RIS2D :• en-tête

• autorité émettrice : FR99• pas de date d'émission• date de signature : 26/09/2012 (4652 jours, soit 122C hex, depuis le 01/01/2000)• type de document : 05, RIS2D

• données• date d'expiration : 26/09/2013 (5017 jours, soit 1399 hex)• propriétaire : M. Gilles Montparnasse• QXBAN : QX97CEPAFRPP751AZX25TR1234567890AA• BIC : BIC11XXXXX

La chaîne 2D-DOC correspondante sera la suivante (en ignorant le padding, l'encodage et la signature) :DC01FR991204FFFF122C0508139930M/MONTPARNASSE/GILLES31QX97CEPAFRPP751AZX25TR1234567890AA32BIC11XXXXXNotez que le saut de ligne dans la chaîne ci-dessus n'est présent que pour indiquer la séparation entre l'en-tête et lesdonnées, il devrait être absent en réalité.

http://documentation.sepamail.eu/index.php?title=Fichier%3AExempleRIS2D.png

Standards 1206:RIS2D 21

Références[1] norme ISO http:/ / www. iso. org/ iso/ iso_catalogue/ catalogue_tc/ catalogue_detail. htm?csnumber=44230[2] http:/ / documentation. sepamail. eu/ images/ c/ c9/ DemandeEvolution2dDoc. pdf

Standards:Algorithme de génération du QXBANRéférence : spécifications CYV 2010. Le QXBAN est un code de 34 caractères composé de :• un code QX (2 caractères)• une clé de contrôle (2 caractères), selon le calcul de clé de contrôle de l'IBAN (guide EBS 204 du cfonb [1])• un BIC sur 11 caractères, complété avec des lettres X s'il ne fait que 8 caractères (avec le modèle

[A-Z]{6}[A-Z0-9]{5})• un identifiant interne au BIC sur 19 caractères (avec le modèle [A-Z0-9]{19}), tiré aléatoirement

On propose la séquence fonctionnelle suivante pour le tirage :• tirage aléatoire (loi uniforme) de trois nombres• génération des QXBANs équivalents, avec calcul de la clé de contrôle• vérification si les QXBAN ainsi générés existent déjà• si non pour au moins un, alors on prend ce QXBAN• si oui pour les trois, alors on génère une exception sur la génération du QXBAN et une alerte de densité à

l'administrateur du référentiel• si oui pour deux d'entre eux, on génère une simple alerte de densité à l'administrateur du référentiel sans exception

sur la générationL'avantage de cette séquence est que :• le coût en temps est fixe quelque soit le tirage• l'alerte de densité est bien prévue dès le départ pour l'administrateur du référentiel

Références[1] Guide EBS 204 (format word) (http:/ / www. cfonb. org/ afb/ cfonb. nsf/ b9516c67bcee30e8c1256d240054307a/

c2514ac346c158cac125689500369ac4/ $FILE/ EBS204. doc) (archive au format pdf)

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44230http://documentation.sepamail.eu/images/c/c9/DemandeEvolution2dDoc.pdfhttp://documentation.sepamail.eu/index.php?title=Fichier:PeigneQXBAN.pnghttp://www.cfonb.org/afb/cfonb.nsf/b9516c67bcee30e8c1256d240054307a/c2514ac346c158cac125689500369ac4/$FILE/EBS204.dochttp://www.cfonb.org/afb/cfonb.nsf/b9516c67bcee30e8c1256d240054307a/c2514ac346c158cac125689500369ac4/$FILE/EBS204.dochttp://documentation.sepamail.eu/index.php?title=M%C3%A9dia:EBS204.pdf

La vision métier 22

La vision métier{{TOC:messagerie}}

L'émetteur et le destinataireDu point de vue technique, il y a bien un émetteur de l'envoi et un destinataire. Du point de vue métier, l'envoi estsurtout important pour sa réponse. De ce fait, l'émetteur de l'envoi devient le destinataire de la réponse.Dans les premiers services envisagés, il sera donc toujours préféré l'utilisation des identifiants métiers : créancier,débiteur, donneur d'ordre, bénéficiaire.Néanmois pour une présentation générale, nous utiliserons les mots émetteur initial et destinataire initial en lieu etplace des mots émetteur et destinataire ayant un double sens.

Les échanges métiers se structurent donc suivant le schéma précédent :• une initialisation d'un envoi réalisée par l'émetteur initial• la transmission de l'envoi vers la banque du destinataire. Dans la structure SEPAmail, cette transmission est

nommée REQUEST (payment-request, mandate-request,...)• la mise à disposition par la banque du destinataire, suivant le ou les canaux proposés par cette banque• la validation par le destinataire initial. Au même titre que pour l'initialisation, les règles d'authentification peuvent

être adaptées au service sous-jacent.• Une fois la validation effectuée et contrôlée, la réponse est nommée REPORT (mandate-report,

payment-report,...)

http://documentation.sepamail.eu/index.php?title=Fichier:Messagerie-m%C3%A9tier-emetteur.png


Principes d’acquittementPour assurer le bon fonctionnement de la messagerie à un niveau métier, chaque envoi interbancaire (missivenominale) doit faire l'objet par la banque du destinataire d'une missive d'acquittement. Celle-ci peut comporter deséléments sur le niveau de service mais doit éviter les données métiers. Ces dernières sont censées faire l'objet d'unemissive nominale transportant un message de type REPORT.La missive d’acquittement n'est pas acquittée.

Il n'y a aucune obligation que la missive d'acquittement passe par le même canal d'échange que la missivenominale. En particulier, il est tout à fait possible d'utiliser uniquement le canal SMTP pour toutes les missivesd'acquittement.

Principes de desserte (reachability)SEPAmail étant une initiative privée, il n'est pas envisageable que tous les acteurs adhérents démarrent le mêmejour, et ceci à chaque nouvelle application ou nouvelle évolution.De ce constat, il est important que la banque de l'émetteur gère la desserte à 2 niveaux :• niveau global par information qu'un réseau bancaire destinataire a ouvert le service (information qui sera

organisée au niveau de la structure de gouvernance)• niveau transaction en mettant à disposition une réponse intermédiaire (puce 2) indiquant si la banque est

desservie.

http://documentation.sepamail.eu/index.php?title=Fichier:Messagerie-m%C3%A9tier-acquitement.png


La banque de l'émetteur peut profiter de cette gestion de la desserte pour offrir un service complémentaire. Dans lecadre de l'expérimentation GEMME, le service consiste à :• recevoir l'ensemble des flux de mandats,• répondre suivant que le mandat est transmis ou non (banque non desservie)• stocker les mandats non desservis• automatiser l'envoi ultérieur de ces stocks chaque fois qu'une nouvelle banque rejoindra le réseau SEPAmailIl est évident qu'un tel service n'est pas très utile dans le cas de RUBIS dont les demandes de règlement ont unepériode d'utilisation réduite.

http://documentation.sepamail.eu/index.php?title=Fichier:Messagerie-m%C3%A9tier-desserte.png

25

La sécurité

Principes de sécurité{{TOC:sécurité}}Il y a plusieurs principes de sécurité au sein de SEPAmail.• Indépendance des espaces de sécurité

• client - banque / banque – banque / banque – client• chaque articulation entre espaces de sécurité passe par un membre adhérent à l’espace (banque)

• Authentification• les missives SEPAmail sont obligatoirement signées en S/MIME (utilisation de chiffrement avec une clé

secrète de l’expéditeur de la missive), ce qui assure l'authentification de l'expéditeur de la missive et l'intégritéde cette dernière

• les messages SEPAmail peuvent être signés par l'émetteur du message et cette signature est transportéejusqu'au destinataire, ce qui assure l'authentification de l'émetteur du message

• Signature numérique• la signature numérique (appelée aussi signature électronique) est possible pour le message en harmonisant les

règles communes à respecter au sein du réseau des adhérents SEPAmail. Ce sujet est traité par le protocoleSAPPhire.

• Confidentialité• la confidentialité est obtenue par chiffrement des missives avec la clé publique S/MIME du destinataire.

• Traçabilité• Tous les éléments doivent être suivis, et doivent pouvoir être produits à titre de preuve• ils doivent rester associés à leur expéditeur et à leur destinataire, dûment authentifiés

• Échange de l'information• webservice avec utilisation SSL (HTTPS+SOAP ou HTTPS+REST)• SMTP

Signature des messagesLa possibilité de signature des messages est prévue par l'incorporation d'un schéma XML de signature et permetainsi de communiquer sur une faisabilité de principe.La mise en œuvre d'une technique de signature des messages va dépendre du type de message et surtout de commentl'application utilisant le message est contractuellement réalisée :• Mandat GEMME (hors expérimentation) :

• une signature du message retour pour contrôle indépendant par le créancier peut être un plus, si tant est que lecréancier ait les moyens de contrôle de la signature

• cependant, un transfert de responsabilité de la banque du créancier à la banque du débiteur peut aussi êtreutilisé : dans ce cadre, qui serait contractuel entre banques, la seule réception de la missive signée par labanque du créancier pourrait suffire. La banque du débiteur s'engageant en cas de différent avec le créancier.

• il y aura peut-être les 2 types de flux à terme suivant les besoins des clients.• Règlement RUBIS :

Principes de sécurité 26

• Pas de nécessité d’avoir une notion de signature au niveau du message de retour : c’est le virement qui estirrévocable et cela suffit pour la plupart des cas d'usage.

• A terme, on peut aussi imaginer que seule une missive signée de la banque suffit car contractuellement celle-cis’engage devant les autres banques à honorer les informations de cette missive. Par exemple, le renvoi d'unemissive dans laquelle le message porte une information de garantie du virement engage la banque du débiteur,charge à elle d'avoir bien fait les contrôles avec son débiteur.

Le besoin le plus nécessaire sur la signature des messages sera pour ceux du service JASPE. Ce point étant en coursd'étude, nous pouvons résumer que la signature des messages n'est pas une fonction à l'ordre du jour.

Indépendance des espaces de sécuritéSEPAmail propose de véhiculer l'information le long d'espaces de sécurité indépendants comme décrit dans leschéma ci-dessous:Il y a :• l'espace de sécurité entre chacun des adhérents et son client, selon les canaux existants (DAB/GAB, banque à

distance, guichet, centre d'appel, application mobile)• l’espace de sécurité entre les deux adhérents SEPAmail, mis en œuvre tel que défini dans la norme SEPAmail.

Standards:SMIRK CRY1203, la cryptographiedocument de la série: demande de commentaires

la cryptographie

code SMIRK CRY1203version 1.0 du 26 juillet 2012

Cette demande de commentaires (SMIRK pour SepaMail Internal Request for Komment) spécifie les règlescommunes d'utilisation de la cryptographie. Ce SMIRK est un standard de la communauté SEPAmail, spécifié etmaintenu par le scheme SEPAmail.

IntroductionSEPamail utilise des procédés techniques de cryptographie asymétrique pour assurer:• l'authentification forte des adhérents du réseau SEPAmail,• la confidentialité et l'intégrité de l'information échangée.Ce document précise les normes utilisées et le cadre de cette utilisation dans le réseau des adhérents SEPAmail. Unepartie annexe décrit l'extension qui peut être fait de la norme dans un cadre hors-réseau, notamment entre unadhérent et son client.

Standards:SMIRK CRY1203, la cryptographie 27

AvertissementSEPAmail encadre juridiquement le cadre et la portée:• des transferts sécurisés d'information, qui constituent le dispositif technique SEPAmail,• des mandats électroniques de chaque membre du réseau pour son propre compte ou celui de ses clients,• des garanties pour chaque membre du réseau.Ce cadre juridique ne fait pas partie de ce document. Notamment, la non-répudiation est contractuelle et juridiquedans le cadre de SEPAmail. Elle ne fait donc pas partie des prérogatives du dispositif technique.

Principes

Utilisation de S/mime sur IP avec deux parcours possibles

• SEPAmail utilise la norme S/Mime [1]

• avec deux échanges possibles entre les adhérentsSEPAmail :• le parcours canonique utilisant un échange via le

protocole SMTP [2]

• un parcours flash utilisant un échange via un webservice [3]

• ainsi que les usages X509 [4] de confidentialité etd'authentification (intégrité de fait)

• avec une signature incluse dans le contenu chiffré

Le certificat SEPAmail

SEPAmail utilise deux certificats S/MIME pourchacune des adresses de courriels utilisées (une par BICet par écosystème, voir la demande de commentaireautour de la missive [5]). L'un des certificats est utilisé exclusivement pour le chiffrement, l'autre exclusivement pourla signature.

Ce certificat doit présenter les caractéristiques suivantes :• un usage du bi-clé pour

• la confidentialité (chiffrement ou key encipherment)• l'authentification (digital signature)

• signé par une autorité de certification reconnue• un nom canonique (canonicalname ou CN) à l'adresse de courriel [ecosystem]@[bic].sepamail.eu

http://documentation.sepamail.eu/index.php?title=Fichier%3ACoucheParcourSepamail.png

Standards:SMIRK CRY1203, la cryptographie 28

Cas du parcours canoniqueDans le cas du parcours canonique (privilégié), la confidentialité et la signature sont obligatoires.

Cas du parcours flashDans le cas du parcours flash, une négociation de l'échange pair à pair entre les adhérents au réseau SEPAmail estobligatoire afin de savoir quelles sont les exigences du client et du serveur en matière :• de protocole d'échange (HTTP, HTTPS)• de politique d'authentification des équipements réseaux (réciproque, unilatérale)• de protocole de web-services (SOAP, REST, autres)• de politique de réponse et de qualité de service (temps de réponse, résultat désynchronisé ou synchronisé dans la

réponse)

Références[1] http:/ / fr. wikipedia. org/ wiki/ S/ MIME[2] http:/ / fr. wikipedia. org/ wiki/ Smtp[3] http:/ / fr. wikipedia. org/ wiki/ Web_service[4] http:/ / fr. wikipedia. org/ wiki/ X. 509[5] http:/ / documentation. sepamail. eu/ wiki/ Private_scheme:SMIRK_MIS1202

http://fr.wikipedia.org/wiki/S/MIMEhttp://fr.wikipedia.org/wiki/Smtphttp://fr.wikipedia.org/wiki/Web_servicehttp://fr.wikipedia.org/wiki/X.509http://documentation.sepamail.eu/wiki/Private_scheme:SMIRK_MIS1202

29

La norme

La norme{{TOC:norme}}

Principes généraux de la norme

Préambule : numérotationChaque version de la norme est identifiée par un numéro à 4 chiffres, sous la forme AAMM. Ainsi, la version 1206date du mois de juin 2012, par exemple. Le comité de coordination règle la fréquence et le contenu des versionssuccessives.La version 1206 de la norme a changé beaucoup de choses par rapport à la précédente version, 1202. En résumé, onpeut même considérer qu'elle a tout changé.En revanche, les versions futures de la norme n'auront pas forcément le même impact. Elles pourraient se contenterd'évolutions limitées sur certains messages ou certains écosystèmes, voire les laisser complètement intacts -- en secontentant par exemple d'ajouter une ou plusieurs applications nouvelles.Il n'y a donc pas forcément identité entre les numéros de version de tous les messages et celui de la norme elle-même: si ces messages n'ont pas changé depuis la version précédente de la norme, ils conserveront le même numéro deversion. On peut dire que le numéro de version de la norme est le maximum des numéros des messages et de lamissive la constituant.

La norme 30

PérimètreOn trouve ci-dessous sous forme graphique la représentation du périmètre des spécifications de la norme SEPAmail :

Au sein d'un adhérent SEPAmail bancaire, il y a quatre classes de composants fonctionnels principaux :• SMART qui reçoit et émet des missives dans le réseau des adhérents SEPAmail (espace coopératif inter-bancaire)• les composants métiers autour du paiement:

• RUBIS, autour de la demande de règlements qui traite les messages RUBIS (lié à l’écosystèmepayment.activation)

• GEMME, autour de la signature de mandats qui traite les messages GEMME (lié à l’écosystème direct.debit)• un composant métier de sécurité:

• SAPPHIRE, autour de l'authentification et de l'échange de composants d'authentification, qui traite lesmessages SAPPHIRE (lié à l'écosystème secure)

• SMILE qui reçoit et émet des missives dans le réseau des clients de la banque (espace compétitif intra-bancaire)Les documents de la norme sont :• les schémas XML [1] et leurs directives d'implémentation• les demandes de commentaires (SMIRK en bleu)• les règles métiers (business rules en vert)

• RUBIS• GEMME

• des spécifications techniques et fonctionnelles• API SMART (file et web-service)• protocoles échanges• validation XML• guide entreprises et éditeurs

http://documentation.sepamail.eu/index.php?title=Fichier:Perimetre_specification.pnghttp://xsd.sepamail.eu/current/

La norme 31

Références[1] http:/ / xsd. sepamail. eu/ current/

Standards:IG General rulesdocument de la série: directive d'implémentation

Implementation Guidelines : general rules

These rules apply to all messages in Sepamail.

Acceptable charactersAs per SEPA rules, the only acceptable characters are as follows :• lower case letters a -z• upper case letters A - Z• digits 0 - 9• special chars / : - ? ( ) . , ' +• spaceThis is valid for all messages, and it is an absolute rule in all ISO parts.

The "Name" fieldWhenever the "Name" (Nm) field is used, it must be filled as follows :• if the designated party is a corporation, its registered name must be used• if the designated party is a person, this field should hold "firstName lastName", with a single space between both.

Date and time fieldsAll date, time or date and time fields are in ISO 8601 format[1]. The time zone indicator MUST be used, in any of theformats supported by the standard.[1] http:/ / fr. wikipedia. org/ wiki/ ISO_8601

http://xsd.sepamail.eu/current/http://fr.wikipedia.org/wiki/ISO_8601

Standards:IG color coding 32

Standards:IG color codingCatégorie:Specification Committee

document de la série: directive d'implémentation

Color coding scheme for implementation guidelines

Element Available (or mandatory) in SEPAmail, must be used according to SEPAmail rules. Some of these elements also exist in SEPA rulebooksand must also be used according to these rules.

Element Available in SEPA rulebooks, unused in SEPAmail

Element Not available under any of these rules

Standards:SMIRK MIS1202, la missive dans leséchanges interbancaires{{Norme 1206}}

document de la série: demande de commentaires

la missive dans le réseau interbancaire

code SMIRK MIS1202 version 1.1 du 26 juin 2012

Introduction et généralitésLa missive est la seule entité permettant l'échange d'informations dans le système SEPAmail, où elle joue un rôled'enveloppe pour les données confidentielles. Pour pouvoir acheminer efficacement les différentes informations dusystème, quatre types de missives ont été définis :• la missive nominale, acheminant un message• la missive d'acquittement, à but essentiellement protocolaireainsi 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 duréseau SEPAmail

• la missive SMAPI (SEPAmail API), accessible exclusivement en intrabancaire, et permettant à un éditeurSEPAmail 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 contenuexact 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)

http://documentation.sepamail.eu/index.php?title=Categorie

Standards:SMIRK MIS1202, la missive dans les échanges interbancaires 33

Les principesLa 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 êtreacheminé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 doncpas partie de ce SMIRK. Un lexique des termes utilisés se trouve sur la documentation de la communautéSEPAmail[2].

Le routageLe routage se sert d'un adressage de type « courriel » sur le domaine sepamail.eu[3] de la forme :

@.sepamail.eu

ou

@.sepamail.eu

où :• est une famille SEPAmail valide du référentiel application@SCHEME• est un BIC valide du référentiel BIC@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 lesrè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 missiveL'acquittement vise à informer l'émetteur de la réception, bonne ou mauvaise, de la missive émise et d'un horodatagede 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 retourdans 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équencementLa 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’acquittementNous 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 missiveUn 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 sontimplé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 dele faire avant ; il n'est pas obligé de le faire

• la réémission d'une missive ne peut pas intervenir plus d'un certain temps, précisé dans le tableau ci-après, aprèsl'é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 unemême missive pour obtenir des acquittements différents. Ce système n'est utilisé que pour obtenir un acquittement sicelui-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).

Temps d'attente avant renvoi selon la priorité de la missive

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" estenvoyé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. Sielle est envoyée à T+7mn, la missive d'ordre 3 (toujours en l'absence d'acquittement évidemment) pourra êtreenvoyé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 desvaleurs par défaut. Si deux adhérents concluent un accord bilatéral, ils peuvent librement convenir de délaisdifférents et/ou d'un plus grand nombre de renvois.

Temps d'attente avant escalade selon la priorité de la missive

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 à chaquerémission, contrairement aux délais de renvoi ci-dessus.


Le procédé d'escaladeDans le cas où une missive ne serait pas acquittée, même après un renvoi, l'adhérent peut procéder à l'escaladepré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 contenuSelon les règles métier de SEPAmail, une missive contient obligatoirement :

Contenu facultatif et obligatoire d'une missive

• 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 la signature de lamissive au sein de l'enveloppeSMTP. Cette signature sertessentiellement à pouvoir adjoindre une signature électronique du signataire, client de la banque et émetteur dumessage.

Il faut noter que, du strict point de vue de la conformité au schéma XML, les blocs message et acquittement sontfacultatifs (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'enveloppeLa 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é auniveau des DNS

• TO, adresse de courriel comme spécifié dans ce document, valide avec un nom de domaine déclaré au niveaudes 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

http://documentation.sepamail.eu/index.php?title=Fichier%3AMissive_contenu.png


• 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 surcouche HTTPS), afin de permettre une non adhérence des couches applicatives de production de l'enveloppe SMTPet de son transport.

La sécurité : authentification, confidentialité et horodatageLa 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 missivesSEPAmail 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 contenuintégral de la missive avec la clé privée de l'émetteur. Le destinataire pourra alors vérifier que le condensat de lamissive 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 principesdétaillés d'horodatage applicables à SEPAmail, inspirés des bonnes pratiques de la FNTC [5], sont décrits dans cettepage.Si un horodatage de type « contremarque de temps signée » est nécessaire, alors cet horodatage est réalisé surl'enveloppe SMTP (et non seulement la missive) par un service tiers certifié, juste avant l'émission ou juste après laréception.

Le protocole d'échange des missives


la place des protocoles d'échange dans l'architecture protocolaire

L'échange des missives se faitnativement sur le réseau IP via lacouche de transport TCP.Sur ces couches, SEPAmailimplémente deux parcours avec deuxprotocoles de communicationdifférents :• SMTP• HTTPS+SOAP{{Remarque }} : Cet échange faitl'objet de recommandationsd'implémentation et sort du cadrenormatif de ce document.{{Remarque}} : Une étude est encours pour permettre un parcours flashsur 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].

FonctionnementVoici les schémas fonctionnels de la réception et de l'émission d'une missive, à réaliser par les automates desadhé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 cetteenveloppe (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.

http://documentation.sepamail.eu/index.php?title=Fichier%3ACoucheParcourSepamail.png


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 lamissive 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 à [email protected] correspondant au destinataire (TO) doit également être l'un des BICs rattachés à l'adhérent destinataire dans leréférentiel adhérent@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 à écosystème@SCHEME.

Déchiffrement

La première partie de l'enveloppe MIME est chiffrée (Content-Type: multipart/encrypted), et doit donc êtredéchiffrée avec la clé privée du destinataire (BIC extrait de l'adresse TO (protocole défini par l'attribut protocol del'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 (attributmicalg 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 leré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 dela 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'acquittementL'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 laS'il souhaite traiter ces missives, il devra implémenter la même procédure que celle utilisée pour la réception d’unemissive 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 conformeou valide, en-têtes non valides), on ne peut donc pas signaler ces erreurs. Le mécanisme de renvoi de la missivenominale 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 lalogiquedu 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 BICdoivent appartenir à adhérent@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 bancair

version novembre 2012 - documentation...

Documents