lundi 24 mars 2014

SEPAmail et le W3C

En ce début de semaine se tient une conférence du W3C à Paris autour du futur du paiement sur le Web.

Le W3C, c'est le consortium de quelques 380 entreprises, fondées en 1994 par Tim Berners-Lee, avec le leit-motiv « un seul web partout et pour tous ».
Toujours piloté de Tim Berners-Lee (inventeur de HTML et HTTP) présenté souvent comme le papa du Web, le W3C est chargé de promouvoir les protocoles qui permettent une application mondiale partagée sur le réseau internet, notamment : HTML, XHTML, XML, RDF, SPARQL, CSS, PNG, SVG, SOAP... Bref, plein de protocoles utilisés par SEPAmail.
 
La problématique, et l'agenda complet de cet évènement se trouve ici.


Plusieurs acteurs de la communauté SEPAmail ont présenté des "prises de position" sur le sujet.

L'une de ces prises de positions expose le besoin de ré-équilibrage de la relation entre le chaland (pour faire vite et imprécis, l'acheteur) et le marchand dans le paiement en général et celui à distance sur le web en particulier.

Dans les pistes avancées pour ré-équilibrer par la standardisation, il y a, entre autres, SEPAmail, mais aussi des technologies dont nous avons parlées dans nos billets.

Je vous livre la version française au format pdf.

Jeffrey Jaffe, l'actuel directeur du W3C (CEO), est à Paris, et devrait rencontrer aujourd'hui certains acteurs de SEPAmail. Pour quelques uns des artisans du protocole SEPAmail, c'est un peu le graal...





mercredi 19 mars 2014

SEPAmail : communiqué de presse sur le lancement du service SEPAmail

Lundi 17 mars, les adhérents SEPAmail ont communiqué sur le succès de l’expérimentation SEPAmail en 2013 et sur le lancement du service pour leur client en 2014.
Ce communiqué a été repris cette semaine dans de nombreux articles:



jeudi 13 mars 2014

Codes de retour du protocole SEPAmail au niveau de la couche Missive

Le protocole SEPAmail liste sur cette page (standard en version 1206) des codes en trois chiffres pour qualifier/préciser la nature de l'acquittement d'une missive.

Nous allons, dans ce billet, successivement :
  • reprendre la définition générale de ces codes
  • regarder l'usage de chacun des codes
  • répondre à quelques questions fréquemment posées

Définition des codes d'acquittement

Les codes d'acquittement forment une nomenclature à chiffres [0-9]{3} sur trois positions :
  • la classe (position 1)
  • le sujet (position 2)
  • le détail (position 3)
Cette nomenclature est similaire aux codes de statut du retour des protocoles HTTP, SMTP etc...

La classe peut être :
  • classe 1 = non utilisé pour le moment, information
  • classe 2 = succès
  • classe 3 = non utilisé pour le moment
  • classe 4 = erreur transitoire
  • classe 5 = erreur permanente

Inventaire des codes proposés par le standard

La liste des codes d'acquittement proposés peut se schématiser en carte mentale :
Liste des codes retour proposés par la version 1206

Nous allons voir que de nombreux codes ne servent pas.

Ils ont (malheureusement) pour seul effet de perdre ceux qui veulent comprendre le protocole.

Ils sont résiduels aux expérimentations passées (et des besoins ponctuels de développeurs) et n'ont pas vocation à rester dans le standard, maintenant que l'industrialisation est en cours et les expérimentations finies.


Sujet 1 : les addresses


Ce sujet permet d'acquitter une missive nominale sur les champs de l'entête de missive A.5.1 (balise Snd) et A.5.4 (balise Rcv) exclusivement.


5.1.1     Unknown sender

L'expéditeur de la missive, comme défini par la balise A.5.1 (Snd, balises BIC et|ou IBAN) n'est pas connu par le récepteur. Ce code est répondu en complément d'un acquittement de type NAK. Le récepteur se pose la question du BIC de l’émetteur (référentiel commun) ou de la forme de l'IBAN émis, qui est le plus généralement un QXBAN.


5.1.2     Unknown receiver

Le destinataire de la missive, comme défini par la balise A.5.4 (Rcv, balises BIC, IBAN, BBAN, PAN, RIS2D) n'est pas connu par le récepteur. Cela peut concerner le BIC (référentiel commun) ou un identifiant bancaire du récepteur qui n'est pas connu par le récepteur.


5.1.3     Receiver known but out of SEPAmail scheme or ecosystem.

Le destinataire de la missive, comme défini par la balise A.5.4 (Rcv, balises BIC, IBAN, BBAN, PAN, RIS2D) est connu par le récepteur mais ne reçoit pas de missives SEPAmail sur cet ecosystème.
Ce code sert pour préciser à l'expéditeur que ce destinataire existe mais qu'il ne reçoit pas les missives SEPAmail. Il est donc inutile d'utiliser SEPAmail avec ce destinataire pour le moment, et ce, quelque soit l'application de SEPAmail et l'expéditeur.
Ce code ne sert donc pas pour refuser l'attache d'un expéditeur précis ou pour une application de SEPAmail précise.


2.1.9     Receiver known, missive forwarded

C'est le code le plus utilisé, car c'est le seul code de succès de la liste utilisable avec un acquitement positif (ACK).


Sujet 2 : la boite aux lettres


Ce sujet est ambigu car il adresse la couche échange d'enveloppe SEPAmail et non la structure de la missive.


Il est historique à l'expérimentation : lors du passage du mode canonique au mode flash (web services), les implémenteurs de l'expérimentation ont eu besoin de ces codes retours natifs au protocole d'échange SMTP, d'où ces codes concernant les adresses mails de l'enveloppe SMTP/S-MIME et la longeur des messages autorisés, au sens message SMTP et non message SEPAmail.


Mon conseil est de ne pas utiliser ce sujet dans l'acquittement d'une missive et de bien réfléchir à l'implémentation naturelle de l'échange d'enveloppe SEPAmail, quelque soit le type de contenu transporté.


Sujet 3 : les systèmes



Ce sujet traite des erreurs "dites" système, c'est à dire relevant de l'infrastructure connectée.


N.3.1     File system full

Ce code (431 ou 531) ne devrait pas être utilisé en acquittement de missive entre deux adhérents SEPAmail. Il n'adresse pas le contenu de la missive mais l'échange d'enveloppes. Il y a donc d'autres couches protocolaires pour décrire ce statut.


N.3.2     Inaccessible server

Ce code (432 ou 532) ne devrait pas être utilisé en acquittement de missive entre deux adhérents SEPAmail. Il n'adresse pas le contenu de la missive mais l'échange d'enveloppes. Il y a donc d'autres couches protocolaires pour décrire ce statut.


4.3.3     Sending date+time incorrect, and outside of the margin. (Missive has not been handled).

Ce code retour (433 ou 533) permet de traiter une incohérence d'horodatage de la missive, champs A.5.2 (balise SndDtTm) ne permettant pas d'acquitter la missive.
Si la missive peut être acquittée positivement, selon les règles de réception définies dans la directive d'implémentation , alors le bon code retour est 219 avec une précision dans le champs A.6.7 (balise RtgWarn/Code à la valeur BAD_TIME) et non un code 433 ou 533. Il n'y a donc pas de code retour possible 233, comme indiqué par la mention "Missive has not been handled".


5.3.3     Sending date+time incorrect, and outside of the margin. (Missive has not been handled).

Je ne vois pas de sens à ce code retour. Si quelqu'un voit un tel cas, Je suis preneur en commentaire d'un cas d'usage.


Sujet 4   Le débiteur



Ce sujet est une erreur de compréhension du modèle en couche proposé par SEPAmail ainsi qu'une erreur de compréhension de la notion d'application.
Il est dédié à l'application de SEPAmail RUBIS.


Je suis certain qu'il ne devrait pas être utilisé.


Le code 541 devrait plutôt être un code 512 ou 513.
Le code 249 serait un code 219.
La notion de compte de test n'a pas de sens SEPAmail et elle relève d'une confusion avec l'articulation monétique pendant l'expérimentation.


Sujet 5 La sécurité et la cryptographie



Ce sujet est important pour SEPAmail; il concerne la sécurité en général et la cryptographie en particulier, telle qu'elle est utilisée dans l'enveloppe SEPAmail ou dans la missive SEPAmail.
La cryptographie utilisée pour les connexions sécurisée des protocole HTTP, SMTP ou autres, n'est donc pas concernée par ces codes d'acquittement

5.7.2     Impossible to decrypt (key1 or key2). In fact, since the decryption of the S-MIME envelope cannot be processed, the embedded missive cannot be read and acknowledged. Thus, the proper behaviour in this case will be avoiding any response to the sender.

Ce code n'a pas de sens au niveau missive et ne permet pas d'acquitter dans les conditions du protocole SEPAmail. Il ne peut donc pas être utilisé.


5.7.3     Unsupported algorithm or security function

Ce code est utilisé quand un algorithme ou une fonction de sécurité non autorisé par le protocole SEPAmail sont utilisés pour l'enveloppe SEPAmail.
Il est naturel, par exemple, si sha1 est utilisé alors que la directive d'implémentation de la cryptographie exige a minima sha256, d'acquitter toute missive enveloppée à l'aide de sha1 avec un tel code.


5.7.4     Integrity error

Ce code est utilisé s'il y a une erreur d'intégrité dans l'utilisation des fonctions de sécurité. Cela peut être une somme de contrôle non intègre, une clé périmée, une signature lue, mais non référencée, une incohérence entre l'adresse mail utilisée par SMIME et l'adresse utilisé dans l'entête SMTP ou l'échange SMTP.


Sujet 8 Contenu



Ce sujet traite de l'analyse du contenu de la seule missive, avec les quelques adhérences résiduelles aux couches message et enveloppe.


5.8.1     XML syntax error, non conforming to schema

Ce code est utilisé quand une missive n'est pas conforme au schéma XML sepamail_missive.xsd.


5.8.2     Missive contents incoherent

Ce code est utilisé quand une missive est conforme au schéma XML mais n'est pas conforme à la directive d'implémentation de la missive dans le cadre de son utilisation.
C'est le code d'erreur utilisé quand une missive de type SMAPI ou de service est utilisé entre deux adhérents SEPAmail.


5.8.3     Invalid missive identifier

Ce code est spécifique à l'identifiant de la missive, notamment si celui-ci est invalide comme doublon ou ne respecte pas la règle de génération de cet identifiant, règle que j'ai commentée dans un précédent billet.


5.8.4     Order number error

Ce code est utilisé quand le champ A.3 (balise MsvOrd) n'est pas conforme à la règle d'usage.


5.8.5     Version not supported

Ce code est utilisé si la version utilisée de la missive SEPAmail n'est pas mise en œuvre.


5.8.6     Corrupted contents or virus detected. In fact, since the detection of a corrupted content may be prior to the extraction of the embedded missive due to infrastructure constraints, this missive may not be acknowledged to the sender.

Ce code fait l'objet d'une ambiguité portée par la protection de type pare-feu applicative des infrastructures qui ne respectent pas, la plupart du temps, le modèle en couche de la famille TCP/IP, afin de mieux protéger le système d'information. Ces systèmes ne répondent pas correctement sur les couches impactées, afin de ne pas donner lieu à des dénis de service.

Voici des cas d'usage qui pourraient utiliser ce code :
  • utilisation d'un caractère UTF8 non autorisé par SEPAmail
  • contenu des champs binaires (CDATA) suspect après passage d'un anti-virus
  • somme de contrôle non cohérente avec le contenu

 

FAQ sur les codes d'acquittement 

 

Peut-on renvoyer un code retour ne contenant qu'une partie de l'information, par exemple un code de classe 5 sans sujet ni détail ?

Rien n'interdit de spécifier seulement la classe, par exemple 2 ou 4 dans préciser le sujet et le détail d'un code d'acquittement.
Le code d'acquittement n'est pas obligatoire.
Seul l'est le statut de l'acquittement, (balise AcqSta)

Pourquoi ne pas supprimer les codes d'acquittement obsolètes ?

Bonne question. Cela devrait être fait après la fin de l'expérimentation.

Lors des expérimentations et avant le passage en conformité des différentes plateformes des adhérents, il a fallu composer avec différentes version logicielles des implémentations et laisser les codes d'acquittement, notamment ceux liés à RUBIS.

Peut-on inventer des nouveaux codes ?

Pour votre usage interne, j'imagine que oui.

Je conseille de les proposer à la communauté si vous souhaitez partager leur interprétation avec d'autres acteurs SEPAmail.

Comment déclarer SEPAmail à la CNIL si un code d'acquittement donne de l'information sur mon client ?


Il est difficile de répondre de façon générique à cette question.

La plupart des codes proposés sont généraux.

Dans une messagerie, il y a toujours une information transportée et bouclée... donc il y aura de l'information sur l'expéditeur et le destinataire partagée avec les 4 acteurs mis en jeu.

L'intérêt de SEPAmail est que cette relation à 4 est couverte par des contrats clairs entre chaque partie : le contrat adhérent-utilisateur et le contrat d'adhésion SEPAmail.

Il ne faut pas non plus confondre la couche SEPAmail et les applications de SEPAmail, comme RUBIS ou GEMME, qui devraient se déclarer séparément.

Consulter la CNIL ou votre CIL (correspondant informatique et liberté) me paraît un bon préalable pour déclarer.

A quoi sert le champ description de l'acquittement ?


Ce champ sert à mettre une information permettant à l'émetteur de la missive nominale d'analyser plus finement le pourquoi d'un code retour.

Il est libre et doit servir la messagerie sans desservir le client final.

Il est dédié à une analyse humaine et non automate.



Comment peut-on acquitter plusieurs fois une missive nominale ? Si c'est le cas, comment savoir quand le processus d'émission peut-être considéré comme terminé ?

La possibilité d’acquitter une missive en plusieurs fois est évoqué dans la SMIRK MIS1202 et clairement dans la directive d'implémentation de la missive, en donnant un exemple d'acquittement multiple, qui utilise de plus un code 249, code que je proscris un peu plus haut.

Cet acquittement multiple provient d'une demande de pouvoir relier SEPAmail à une chaine de traitement bancaire batch pour RUBIS... là encore, il y a confusion entre les applications de SEPAmail (structurant des dialogues de messages) et la messagerie SEPAmail (mécanisme de routage, d'adressage, d'authentification des partie, de sécurité du transport).

L'acquittement multiple pose aussi une problématique claire de finalisation du processus d'émission et l'implémentation de la fin du processus dépend de l'interprétation des temps de réponse pour acquitter... Est-ce un temps de réponse pour le premier acquittement ou pour le dernier ?

Selon ma compréhension du protocole, l'expérience de l'implémentation, des différents usages de ce protocole, le système d'acquittement devrait être simplifié en proposant clairement que les statuts ACK et NAK soient des statuts finaux (sans possibilité pour le récepteur d'acquitter de nouveau ensuite).

Le système de renvoi sert pour l'émetteur à dire "alors, vous me répondez ?"... Certains récepteurs désirent dire :  "j'ai reçu mais je n'ai pas encore traité, donc pas besoin de renvoyer."

Quelqu'un m'a un jour dit qu'on ne pouvait pas vraiment distinguer si la missive n'était pas arrivée ou si le récepteur n'avait pas encore acquitté.

Ce n'est pas vrai dans l'absolu et vrai dans la pratique de certains systèmes d'information.

Dans l'absolu, le protocole d'échange SMTP (et par analogie d'implémentation pour HTTP+SOAP) permet bien de savoir si le système d'information du récepteur a reçu le paquet d'information... un certain nombre de codes retour sont bien prévus et implémenté par toutes les applications MTA, quand elles ne sont pas bridées par un pare-feu applicatif.

Dans la pratique, les système d'information ne sont pas parfaits et leur exploitation peut perdre des messages, et ce la, pour toute sorte de raison.

La proposition d'ajouter un statut d'attente (WAIT) ne résoudra pas le problème de fond. Il faut que l'acquittement soit simple à mettre en œuvre sur la couche missive, ne se confonde pas avec la couche message et applicative de la messagerie SEPAmail.

Il faudrait donc (et cela sera à mon avis forcément le cas dans la version industrielle dès qu'il y aura de gros flux) que les adhérents de SEPAmail, qui mette en œuvre le réseau privé SEPAmail, s'engage à acquitter une seule fois dans les temps de la priorité de la missive.
Les mécanismes de renvoi et d'escalade sont mis en œuvre pour garantir cette qualité de service. Je milite donc rester simple sans présumer des systèmes d'information mettant en œuvre le protocole SEPAmail.

vendredi 7 mars 2014

FAQ n°4 : Autour de quelques règles d'implémentation SEPAmail

Il n'y a pas (encore) d'implémentation de référence du protocole SEPAmail. Il n'y a pas non plus de cas d'usage et d'exemples de flux partagés par la communauté. J'ai ouvert un espace pour cela, mais il n'y a pas encore de soumission importante. Pour ceux qui veulent partager, c'est le projet SMITE, SEPAmail, I Want Test Examples.

L'implémentation SMART des quatre premiers adhérents s'est construite autour d'un produit similaire (SEPAplug®, édité par StreamMind®). L'interprétation des équipes de développement de StreamMind était donc un peu un standard de fait pendant l'expérimentation initiale.

Dès 2010, SEPAmail.eu m'a demandé de faire un contrôle de cohérence entre les documents spécifiant le protocole et les différentes expérimentations autour de RUBIS et de GEMME. Cela m'a permis de confronter les documents produit par le committer de l'époque (Olivier Jousselin) avec les différentes implémentations de composant logiciels.

Un comité Norme s'est constitué en 2011 pour publier le standard SEPAmail en partenariat avec le committer. Trois versions ont vu le jour (la version 1112, 1202 et la version stable 1206, relue et validée par une quarantaine d'acteurs dont les éditeurs de l'expérimentation et tous les contributeurs).

Aujourd'hui, voici la liste des documents de référence du standard :
Pour les adhérents, il y a aussi :
  • un recueil de règles opérationnelles (à demander à sepamail.eu) pour se connecter au réseau SEPAmail
  • un cahier de test de conformité (à demander à sepamail.eu) pour mettre en valider la conformité de sa plate-forme ou de son implémentation
Il y a aussi, pour coopérer sur le standard :

La lecture de ces documents est importante pour connaitre les questions, les remarques des implémenteurs, quand ceux-ci posent des questions à la communauté.

Voici quelques unes des questions les plus souvent posées.

Pourquoi l'identifiant d'un message (balise MsgId) devrait être déduit d'un identifiant de missive (balise MsvId) alors que le message est généré avant la missive ?

La règle issue de la directive d'implémentation des messages est celle-ci : "This identifier should be equal to the missive identifier (MsvId element, see related doc.), followed by an underscore ('_') and by a number, which must be unique in a given missive. In any case, the message identifier MUST be unique for a given sender."

Cette règle, si elle est interprétée de façon naturelle, pose problème. En effet :
  • elle fait confondre la couche message et missive
  • on dénature la notion d'identifiant en essayant d'y coller un concept de classification
  • on limite à des nombres un champ déjà bien réduit par le préfixe en limitant cela à des nombres et non n'importe quel caractère
La plupart de ceux qui ont implémenté le protocole SEPAmail sont restés perplexes devant cette règle puisque le message est, a priori, généré avant la missive.

La plupart s'en sont sortis en générant un identifiant de type Id1_Id2 pour le message et ils ont récupéré l'identifiant Id1 pour construire la missive.
Mais ceci n'est pas satisfaisant dans une logique de protocole en couche.
De plus, un certain nombre de règles implicites, pour le maitre d'ouvrage, se cachent alors derrière cette directive d'implémentation, que l'on peut résumer par les questions qu'il se pose naturellement:
  • l'identifiant du message devant contenir l'identifiant de la missive,  faut-il vérifier cette règle ? Et dans ce cas, pourquoi ne pas inclure une balise MsdId dans le message ?
  • quelle est la nature de la relation entre un message et une missive: 1-1, 1-n, n-m ?
  • est-ce à l'adhérent (le relais et/ou générateur) de gérer ces identifiants ou l'expéditeur de la missive ?
  • en construisant un identifiant signifiant, ne suis-je pas en train de donner involontairement de l'information sur mon système ?

Comment interpréter la directive d'implémentation de l'identifiant d'une missive (balise MsvId) ?

La directive d'implémentation de la missive pose le principe suivant "The format of this identifier is YYYYMMDDhhmmssxxx + "_" + sender_id. The first part is the creation date and time, including milliseconds The second part can be used freely by the sender."

Ceci pose des problèmes à l'implémentation, notamment car cela induit en première lecture une liaison à la date de génération de l'identifiant  avec une limitation sur le nombre d'identifiants que l'on peut créer.

Certains verront donc le besoin d'implémenter une règle de vérification des dates.

Ces problématiques d'implémentation sont venues de longues discussions sur le (soi-disant) besoin d'un identifiant unique de bout en bout pour les missives comme pour les messages. Naturellement, le problème n'est pas simple et je vous renvoie sur la notion d'uuid pour en comprendre la portée et les normes concernées.

Selon moi, ces problèmes ont été réglés en pratique il y a déjà longtemps par les MTA (Mail Transfert Agent) et les clients de messagerie. Un récepteur ne pouvant garantir qu'un émetteur sache identifier de façon unique un message, identifie pour lui-même tout ce qu'il reçoit. Nous devrions donc utiliser les solutions déjà trouvées par d'autres et qui, aujourd'hui, fonctionnent bien.

Un implémenteur peut donc générer son propre identifiant de missive et de message à la réception et ajouter celui-ci dans l'entête de la missive et du message.

Ma proposition, pour respecter la version 1206 du standard (et ne pas initier des complications dans l'implémentation) est de supposer que la "creation date and time" soit celle de SEPAmail (et non autre chose), c'est à dire le 1er avril 2008 vers 13h14 pour tous, comme cela, on en sera quitte pour un poisson d'avril. Je propose donc d'utiliser le préfixe 20080401131415926.

Pourquoi une missive doit absolument contenir un message de type SEPAmail ?

La missive peut contenir dans son corps (balise MsvBdy) zéro ou un message quelconque SEPAmail, comme indiqué dans la directive d'implémentation de la missive SEPAmail.

Il n'est donc pas possible d'inclure plusieurs messages.
Il n'est donc pas possible d'inclure autre chose qu'un message SEPAmail.
La liste des messages SEPAmail est définie dans les schémas.

En 2008, le premier schéma de missive SEPAmail permettait de contenir dans le corps de la missive n'importe quelle donnée (anyType). Ceci avait le charme de permettre de vérifier la validité d'une missive sans celle du contenu de la missive.
Pour l'expérimentation au sein des systèmes d'information bancaires, un responsable de la sécurité a demandé de définir tous les types des données et de ne faire qu'une validation globale de la missive contenant le message.
Les schémas ont donc été changés en conséquence. Les avantages sont ceux mis en avant par le responsable de la sécurité. Comme SEPAmail cherchait à l'époque à privilégier le mode unitaire et ne pas rester dans le mode batch qui est la norme bancaire d'échange d'information, le nombre de messages par missive a été limité à un message au plus.

Les inconvénients de ce choix sont nombreux s'il est respecté à la lettre: confusion de la couche missive et message, impossibilité de chiffrer le message facilement au sein d'une missive en clair, schéma xml très volumineux, balise racine du message xml non équivalente à la balise interne de la missive, etc...

Une proposition d'implémentation intéressante est, à mon avis, d'utiliser un schéma simplifié (par une transformation xsl ?) pour la missive et de bien distinguer les deux couches missive et message, comme on distingue déjà la couche enveloppe.

Pourquoi inclure tous les schémas XML dans le schéma de la missive ?

Un implémenteur m'a demandé pourquoi inclure tous les schémas xsd dans la missive et non seulement ceux dont on a besoin.
Pour bien comprendre de quoi on parle, je vous propose de regarder (attention à la limite mémoire de votre navigateur) ce schéma vectoriel représentant cette inclusion.

Quand un schéma est simple, la validation d'un flux xml est très rapide. Quand il est compliqué, cette validation peut être couteuse en ressource machine ou en mécanisme de cache. Le bon exemple est celui de la validation d'une missive d'acquittement qui ne nécessite aucun schéma de messages à inclure.

La question est donc licite et connue de tous les programmeurs avec l'inclusion des librairies au sein de leur programme.

Avec la solution préconisée du changement de schéma pour la missive (confère la question précédente), on peut implémenter une validation beaucoup plus efficace. C'est donc, selon moi, une réponse élégante à ce vrai problème.

Comment comprendre les espaces de noms SEPAmail ?

Ce sujet revient souvent sur le devant de la scène, notamment car le XML n'est vraiment pas human-readable.

Pour comprendre vite, disons simplement que SEPAmail définit un espace de nom principal décliné en plusieurs schémas (un pour la missive, un pour le message générique, un par type de message, quatre pour les types partagés par les schémas précédents) et fait référence aux espaces de nom de l'iso 20022 (des pain, des camt) et de la signature de xml (dsig).

Pour comprendre dans le détail, regardons la définition de la balise racine du schéma lié à la missive :

<schema
    targetNamespace="http://xsd.sepamail.eu/1206/"
    elementFormDefault="qualified"
    xmlns="http://www.w3.org/2001/XMLSchema"
    xmlns:sem="http://xsd.sepamail.eu/1206/"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">


qui s'interprète comme suit :
  • targetNameSpace définit l'espace de nom du schéma,
  • elementFormDefault précise que tous les sous-éléments sont qualifiés par défaut au sein de l'espace de nom SEPAmail (l'équivalent n'a pas été fait pour les attributs)
  • xmlns="http://www.w3.org/2001/XMLSchema" est la référence à l'espace de nom définissant les schémas XML; cette déclaration pourrait donc être en première ligne
  • xmlns:sem="http://xsd.sepamail.eu/1206/" permet de définir le préfixe sem pour l'espace de nom SEPAmail
  • xmlns:ds="http://www.w3.org/2000/09/xmldsig#" permet de définir le préfixe ds pour l'espace de nom lié à la signature DSIG
On a ensuite :

<import>
    namespace="http://www.w3.org/2000/09/xmldsig#"
    schemalocation="xmldsig-core-schema.xsd">
</import>
<include schemalocation="type_sepa.xsd" />
<include schemalocation="type_sepamail_general.xsd" />
<include schemalocation="type_sepamail_missive.xsd" />
<include schemalocation="sepamail_message.xsd" />


qui s'interprète comme suite :
  • importation de l'espace de nom lié à XMLDSIG, qui permet la canonisation et la signature de flux XML (standard W3C)
  • inclusion du fichier interne à l'espace de nom SEPAmail type_sepa qui comprend les types dérivés de l'iso20022 pour SEPAmail
  • inclusion du fichier interne à l'espace de nom SEPAmail type_sepamail_missive qui comprend les types liés à la couche missive
  • inclusion du fichier interne à l'espace de nom SEPAmail type_sepamail_message qui comprend les types liés à la couche message
  • inclusion du fichier interne à l'espace de nom SEPAmail sepamail_message qui comprend les types de messages SEPAmail
Pour bien comprendre les entêtes des schémas et des flux xml associés, il faut donc maîtriser l'usage des attributs targetNamespace, schemalocation, namespace, elementFormDefault et avoir compris que la référence unique d'un espace de nom est une uri qui n'a pas besoin d'exister, bref une étiquette unique.

Je conseille d'installer localement un atelier xml avec les schémas et d'essayer de valider des flux pour bien comprendre les implications des espaces de noms.

Je conseille aussi d'inclure dans les flux xml la référence aux espaces de nom dans la première balise utilisant l'espace et d'utiliser des préfixes courts mais signifiants.

A la lecture de la question précédente, vous aurez compris que je conseille également une inclusion minimaliste selon les besoins réels de validation des flux.

Pourquoi RUBIS et GEMME ne font pas l'objet d'une SMIRK, comme Jade, Diamond, la missive, le message, la cryptographie etc. ?

La question m'a été posée récemment.
RUBIS et GEMME ne font pas l'objet d'une SMIRK comme JADE ou DIAMOND alors que cela pourrait (et devrait à mon sens) être le cas.


Cela serait un bon exercice de réduire la description de RUBIS et de GEMME à un ensemble de définition et de règles, comme pour JADE.



mercredi 5 mars 2014

SEPAmail : utilisation des protocoles de l'internet SMTP, SMIME, HTTP, REST, SOAP, IP, DNS...

Le protocole SEPAmail peut se définir comme un ensemble de règles permettant de mettre en oeuvre une messagerie entre un expéditeur et un destinataire (appelés les utilisateurs de SEPAmail) via des relais (appelés adhérents du réseau privé SEPAmail).

Ces relais  sont des fournisseurs d'accès au réseau SEPAmail pour le compte de leurs clients.
Le rôle de ces relais est :
  • de relayer les messages de leur client sur le réseau SEPAmail
  • d'authentifier leurs clients quand ils émettent ou reçoivent un message SEPAmail
  • d'accuser réception des messages au nom de leur client destinataire
Pour réaliser ces fonctions en se servant d'un réseau de transport public comme internet, le protocole SEPAmail met en œuvre trois couches d'abstraction :
  • une enveloppe SEPAmail, qui, dans l'état de l'art du moment, est une enveloppe SMTP/S-MIME
  • une missive SEPAmail qui, pour le moment, est un flux xml contenant un entête et un corps
  • un message SEPAmail qui, pour le moment, est un flux xml dérivé d'un gabarit de message générique à entête et corps.
Cette double encapsulation au sein d'une messagerie à relais permet de sécuriser la messagerie et de faire transiter des messages sur le réseau public internet d'un expéditeur à un destinataire avec un bon niveau de confiance, de confidentialité, d'intégrité.

Il existe deux façons de faire transiter les enveloppes SEPAmail:
  • le mode canonique qui est pour le moment un échange SMTP dans l'état de l'art
  • le mode flash, voulu par les premiers adhérents qui est, pour le moment, un échange web-services de serveur à serveur à l'aide du protocole SOAP sur HTTP(S) ou REST sur HTTP(S)
On peut donc schématiser l'utilisation des couches protocolaires par le schéma suivant:
Les couches utilisées par le protocole SEPAmail

Nous retrouvons dans la colonne de gauche les couches du modèle TCP/IP, puis les couches du protocole SEPAmail et enfin les protocoles standards utilisés:
  • S-MIME au sein de SMTP pour la couche enveloppe
  • un échange SMTP pour l'échange SEPAMail en mode canonique (le plus naturel et le moins couteux)
  • un échange SOAP sur HTTP pour l'échange SEPAmail en mode flash tel qu'implémenté pour l'expérimentation (le plus couteux et pas très naturel sauf à implémenter SEPAmail au sein d'une prise SOAP plus générale)
  • un échange REST sur HTTP pour l'échange SEPAmail en mode flash et sobre (rapide, moins couteux que SOAP, naturel car SEPAmail permet d'échanger une ressource enveloppe SEPAmail)
  • TCP comme couche transport quand il est mis en oeuvre sur le réseau à bas coût internet
  • IP et DNS pour la couche réseau

A la lecture de ce schéma, nous voyons que SEPAmail est un protocole en couches utilisant des standards du web. SEPAmail écrit que cette utilisation doit être réalisée dans l'état de l'art, ce qui, signifie, par exemple :
  • pour la couche HTTP, l'utilisation de la version 1.1 pour les possibilités de négociation de contenu et de connexion persistante,
  • pour la couche S-MIME, l'utilisation de sha256 au minimum à la place de sha1 selon les recommandations récentes.

Les règles de l'état de l'art pour les protocoles utilisés par SEPAmail sont, si besoin, précisées dans des règles opérationnelles issus des travaux des adhérents SEPAmail et partagés entre eux.
Ces règles opérationnelles précisent également les restrictions de l'utilisation de certains protocoles en expliquant dans la mesure du possible les raisons afin qu'une règle ne soit pas appliquée indéfiniment si la raison a disparu.

Le standard SEPAmail n'explique donc, ni l'état de l'art des couches utilisées, ni l'utilisation de ces couches.

Prenons un exemple pour bien comprendre ce que cela peut signifier pour celui qui implémente SEPAmail au sein d'un logiciel.

Supposons que l'adhérent de l'expéditeur d'un message envoie une enveloppe SEPAmail en mode canonique avec un algorithme cryptographique non supporté par le système récepteur de l'adhérent du destinataire, alors, il est normal que ce système récepteur réponde un code de type 476 ou 576 (Cryptographic algorithm not supported) sur la couche SMTP, conformément à la RFC 3463.

Si maintenant cette même enveloppe est conforme du point de vue SMIME avec un algorithme supporté par S-MIME et l'agent smtp (MTA) mais que l'enveloppe SEPAmail utilise un algorithme non permis par le protocole SEPAmail, une bonne façon de répondre est de répondre sur la couche SEPAmail, c'est à dire d'envoyer une missive d'acquittement avec un statut NAK et un code retour 573 (Unsupported algorithm or security function ), conformément au fonctionnement proposé par la SMIRK MIS 1202.


Le principe général est ainsi, comme le veut l'usage avec les protocoles internet, de répondre sur la bonne couche des erreurs de la couche et de ne répondre sur la couche SEPAmail que pour ce qui concerne le protocole SEPAmail.

Il est important de noter que le transport d'une enveloppe SEPAmail doit s'imaginer en premier lieu par le mode canonique, c'est à dire via le protocole d'échange SMTP, puisque c'est le mode naturel de la messagerie SEPAmail.
Le mode flash doit être implémenté de façon cohérente au mode canonique, que ce soit via SOAP ou REST, sujet qui fera peut-être l'objet d'un billet.