Journal RGS et open source

Posté par  . Licence CC By‑SA.
Étiquettes :
25
21
sept.
2018

Bonjour,

travaillant dans une collectivité locale, je suis en charge des signature électronique RGS (Référentiel Général de Sécurité) depuis quelques années.
Et plus le temps passe, plus j'ai cette sensation que ce système s'éloigne du "libre". Pour tout dire, ma hiérarchie avait choisi de remigrer des postes vers windows à cause du RGS !

Je m'étonne de ne trouver quasi aucune information à ce sujet dans les communautés du libre…
Pourtant, le sujet me semble important. Ce système est le seul qui permet de signer "légalement" des document administratif de façon numérique. Il ne fonctionne pas sous linux, mal sous mac, et s'appuie essentiellement sur des applications privative :
- java de oracle (openJDK n'est pas compatible) ;
- internet explorer ;
- des "middleware" sorti d'on ne sait pas où.

Bien des personnes comparent ce système au carte d'identité nationale. Afin de sensibiliser les utilisateurs, quand j'en parle, de façon simplifié je dit "les signatures électronique en France sont assuré par Oracle et Microsoft, deux entreprise de droit Américain, ce sont les lois Françaises qui l'impose".

J'aurais souhaité avoir l'avis d'autre libriste à ce sujet.

A noter que la réglementation européenne conduit vers eIDAS en remplacement de RGS. Mais ça ne semble pas très différent.

  • # Titre faux ou je comprends rien?

    Posté par  . Évalué à 8.

    Soit j'ai pas tout compris, soit vu le contenu du journal, le titre ne devrait-il pas être "RGS et open source"?

    • [^] # Re: Titre faux ou je comprends rien?

      Posté par  . Évalué à 1.

      Si, ce devrait être "et", mais je ne sais pas modifier le titre :(
      Merci de ta remarque

      • [^] # Re: Titre faux ou je comprends rien?

        Posté par  . Évalué à 4.

        C'est corrigé.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4. Dernière modification le 21 septembre 2018 à 10:08.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Titre faux ou je comprends rien?

        Posté par  . Évalué à 5.

        Au hasard :

        • un décideur s'est fait plaisir (peut être influencé par un commercial) et a mis en place une solution certifiée/évaluée/qualifiée alors qu'il n'y en avait pas besoin
        • il n'existe pas de solution libre conforme et certifiée comme telle répondant au niveau d'exigence retenu/imposé vis à vis du RGS (il y a des exigences différentes quand on vise le une ou trois étoiles)
      • [^] # Re: Titre faux ou je comprends rien?

        Posté par  . Évalué à 4.

        Le RGS se classe en 3 niveaux, souvent désignés par des étoiles.
        le 1 étoile est un certificat x509 presque classique.
        les 2 et 3 étoiles sont des tokens de signature matériel.

        Avec les tokens de signature commence un vaste bazar d'incompatibilité. Ils sont vendus avec leur driver (et/ou middleware, peut importe le nom) qui ne sont pas compatible entre eux (ni compatible linux). Leur carte SIM ne sont pas reconnues avec d'autre token, etc.

        Donc ce n'est pas dans les documents du RGS, mais c'est dans les fait vue que justement le RGS n'impose justement pas d'interopérabilité.

        Une fois le problème de token mis de coté, nous en arrivons à l'utilisation.
        Le RGS peut servir à l'authentifier, et à signer.
        La signature d'un document s'avère des plus surprenante. Je n'ai rien trouvé qui soit libre, du moins libre au sens ou je l'entend.
        Il existe certes un produit : "i-parapheur" qui est libre, édité par Adullact : I-parapheur.
        Mais il a besoin comme tous les autres de java, et uniquement la version Oracle de java. Si j'ai bien compris c'est parce que ces logiciels exploitent tous les fonction de crypto non-libre de java !

        Et après se pose la question de la vérification d'une signature.
        Les PDF peuvent être signé au format PAdES, sympa comme idée. Reste plus qu'a trouvé un lecteur PDF capable d'en lire la(es) signature(s).
        Idem pour les autres formats.

        • [^] # Re: Titre faux ou je comprends rien?

          Posté par  . Évalué à 5.

          Avec les tokens de signature commence un vaste bazar d'incompatibilité. Ils sont vendus avec leur driver (et/ou middleware, peut importe le nom) qui ne sont pas compatible entre eux (ni compatible linux).

          Qu'est-ce que tu appelle "token de signature matériel". Parce qu'il en existe qui fonctionne avec Linux, aussi bien des smartcard classique que des HSM Gemalto. Et il y a la norme pkcs11 pour ça (je ne sais pas si ça s'applique à ton cas).

          Je n'ai rien trouvé qui soit libre, du moins libre au sens ou je l'entend.

          mupdf permet de signer et valider qu'un PDF est signé par exemple

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Titre faux ou je comprends rien?

            Posté par  . Évalué à 3.

            mupdf permet de signer et valider qu'un PDF est signé par exemple

            Il y a des millions de logiciels qui permettent de signer des PDF. Le tout est d'en trouver un qui fasse ça suffisamment proprement pour que ce soit compatible du RGS.

            Je cite (RGS v2, annexe A1 v3, page 5, L28-30) :"La mise en œuvre d’un procédé de signature électronique respectant les exigences définies pour le niveau *** permet de bénéficier de la présomption de fiabilité du procédé de signature telle que prévue dans l’article 1316-4 du code civil."

            Traduction : il faut taper dans du *** pour avoir une valeur probante équivalente à une signature manuscrite originale. C'est WTF, mais c'est comme ça.

            Le RGS pour la signature c'est 1) un logiciel qui ne fait pas n'importe quoi, 2) avec des clefs qui ne viennent pas de n'importe où, 3) en utilisant plus ou moins une fonction crypto de confiance, 4) avec un certain niveau de certitude.

            Entre le * et le ***, les critères varient et le niveau d'assurance, mais avec mupdf, on peut signer, mais de ce que j'en vois, ça ne pourrait même pas être sur le radar du RGS.

            (… Mais encore faut-il être sur qu'on a besoin d'un tampon RGS)

            • [^] # Re: Titre faux ou je comprends rien?

              Posté par  (site web personnel) . Évalué à 4.

              Les difficultés du RGS sont aussi beaucoup au niveau de l'organisationnel, mais c'est nécessaire pour avoir des garanties sur le fait qu'un admin ne puisse pas générer des clefs de signature supplémentaires pour imiter la signature d'une personne.

              • [^] # Re: Titre faux ou je comprends rien?

                Posté par  . Évalué à 5.

                J'ai créé ce journal pour aborder l'aspect open-source des implémentations.
                Je peux bien évidement parler de tout plein de chose autour du RGS, j'en bouffe depuis + de 3 ans. ;)

                Je vais donner une petite anecdote de ce qui ce passe ici (et pas qu'ici) :
                Pour vérifier certaine signature d'ordre de payement effectuer à la DGFiP (les impôt donc), cette dernière demande parfois des "captures d'écran" du logiciel de gestion financière qui affiche "signé par …".
                Alors pardonnez moi du peu. je crains que les garanties n'engages que ceux qui y croient !

                Et du coup, croyez moi ou pas, mais je suis convaincu que le RGS présente d'énorme problème de sécurité.
                Et que tôt ou tard des experts judiciaires et magistrats vont s'arracher quelques cheveux pour démontrer qu'un document a été ou pas falsifié.

                • [^] # Re: Titre faux ou je comprends rien?

                  Posté par  . Évalué à 0.

                  J'ai créé ce journal pour aborder l'aspect open-source des implémentations.

                  Et du coup, qu'est ce que tu veux que l'on te dise, exactement ?
                  La compatibilité avec le RGS passe par une certification variable sur une base d'exigences. A priori, il n'y a pas de solutions libres avec le tampon kivabien.

                  C'est regrettable, mais c'est ainsi, that's law.

                  Alors pardonnez moi du peu. je crains que les garanties n'engages que ceux qui y croient !

                  Ben en l'espèce, ça ne semble pas être un problème de RGS, mais plus un problème de sécu opérationnelle.

                  • [^] # Re: Titre faux ou je comprends rien?

                    Posté par  . Évalué à 3. Dernière modification le 21 septembre 2018 à 17:28.

                    Et du coup, qu'est ce que tu veux que l'on te dise, exactement ?
                    La compatibilité avec le RGS passe par une certification variable sur une base d'exigences. A priori, il n'y a pas de solutions libres avec le tampon kivabien.

                    En fait, je m'étonnais justement du faible nombre de trace vis à vis de RGS dans le monde du libre.
                    Le RGS c'est à la base de la sécurité, et le libre est souvent en avance sur la sécurité (notamment le chiffrement, du fait de la difficulté d'avoir un code qui est exempt d'exploit). Et en fait, ben tout RGS est basé sur oracle, et ça semble ne gêner que moi.

                    Ben en l'espèce, ça ne semble pas être un problème de RGS, mais plus un problème de sécu opérationnelle.

                    Le fonctionnement de RGS encourage des comportements dangereux, alors qu'il devrait les décourager. Du coup in fine, quand il y aura contestation judiciaire (parce qu'il s'agit bien de cela, le RGS est là pour apporter une preuve) ça sera compliqué.
                    Mais ça sort du domaine du libre :)

                    • [^] # Re: Titre faux ou je comprends rien?

                      Posté par  . Évalué à 3.

                      En fait, je m'étonnais justement du faible nombre de trace vis à vis de RGS dans le monde du libre.

                      Le problème du "libre" sur ces sujets, c'est que personne ne porte le sujet de la compliance à quelque norme que ce soit.
                      Dans le cas du RGS, il faut en plus s'assurer que la solution complète tienne la route. Dans l'exemple du lecteur de PDF : token+drivers, soft PDF, PKI, etc. Donc l'intégrateur doit s'y coller.

                      le libre est souvent en avance sur la sécurité (notamment le chiffrement, du fait de la difficulté d'avoir un code qui est exempt d'exploit).

                      Je ne vois pas sur quoi tu peux te fonder pour balancer une affirmation de ce genre. Sur la crypto, wat ? Sur les codes exempts d'exploits, je rappelle que ce n'est pas parce qu'un code est ouvert qu'on le regarde. Ex. OpenSSL et ses multiples déboires, XEN et ses XSA monstrueux, etc.

                      Le fonctionnement de RGS encourage des comportements dangereux,

                      C'est le cas de n'importe quel truc un peu contraignant. On peut aussi ne rien faire et laisser n'importe qui signer n'importe quoi avec mupdf dans la joie et la bonne humeur.

                      Du coup in fine, quand il y aura contestation judiciaire (parce qu'il s'agit bien de cela, le RGS est là pour apporter une preuve) ça sera compliqué.

                      Oui, c'est de la preuve, cf mon post du dessus.
                      Avec un bricolage à base de mupdf, même si techniquement ça fonctionne, tu t'auto-démolis juridiquement.

            • [^] # Re: Titre faux ou je comprends rien?

              Posté par  . Évalué à 2.

              1) un logiciel qui ne fait pas n'importe quoi

              Je ne vois pas trop ce que tu veux dire. La plupart doivent correspondre à ce critère.

              2) avec des clefs qui ne viennent pas de n'importe où

              Ben, tu prends celle du HSM

              3) en utilisant plus ou moins une fonction crypto de confiance

              Ça aussi, la plupart des softs doivent le faire.

              4) avec un certain niveau de certitude

              Certitude de quoi ?

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Titre faux ou je comprends rien?

                Posté par  . Évalué à 2.

                Je ne vois pas trop ce que tu veux dire. La plupart doivent correspondre à ce critère.

                Le font il bien ? Il s'agit d'avoir une bonne assurance de ça. Par exemple, est il possible quand tu fais une opération de signature, tu ne signes que ce que tu penses signer et pas autre chose, genre t'as pas une vulnérabilité béante qui fait qu'il est possible quand tu signes un PDF d'ordre de virement en 1 vers A il te fait signer un virement de 10 vers B.

                Ben, tu prends celle du HSM

                Comment tu t'assures de la qualité des clefs qui sont dans le HSM ? Et de la PKI qui va autour ? Il ne s'agirait pas d'utiliser des clefs faibles parce que l'on a utilisé une entropie toute naze.

                Ça aussi, la plupart des softs doivent le faire.

                Certitude de quoi ?

                Il faudrait que tu regardes un peu le RGS, je pense. Toute la logique y est expliquée et notamment les niveaux d'assurance. Je peux te dire que pour avoir une signature équivalente niveau preuve à une signature manuscrite (le ***), on tape dans du dur.

                • [^] # Re: Titre faux ou je comprends rien?

                  Posté par  . Évalué à 3.

                  Je pense qu'il y a une incompréhension. Je parlais de la partie technique, vu que le journal parlait à la base des logiciels libres dans le carde du RGS, je parlais du point de vue technique. Tout le reste, c'est de la procédure à mettre en place en interne. C'est compliqué mais c'est possible avec du libre.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Titre faux ou je comprends rien?

                    Posté par  . Évalué à 1. Dernière modification le 25 septembre 2018 à 11:58.

                    vu que le journal parlait à la base des logiciels libres dans le carde du RGS, je parlais du point de vue technique. Tout le reste, c'est de la procédure à mettre en place en interne. C'est compliqué mais c'est possible avec du libre.

                    Pour l'instant, malgré mes efforts, je n'arrive pas à le faire convenablement avec du libre.
                    Coté signature, nous utilisons i-parapheur qui est libre, excepté oracle (pour java).

                    Coté lecteur PDF (pour PAdES) par contre, c'est un échec, même avec mupdf.
                    De plus c'est pour avoir un outils afin que les utilisateurs finaux puissent vérifier les signatures, graphique tout ça tout ça).

                    Coté CAdES, pas mieux. Un document signé avec l'outil d'un éditeur n'est pas vérifiable avec l'outil d'un autre éditeur…

          • [^] # Re: Titre faux ou je comprends rien?

            Posté par  . Évalué à 1.

            Un "token de signature matériel", un SmartCard, un key card reader sont vraisemblablement la même chose.
            Et je ne les choisi pas, puisqu'ils sont fournis avec la SIM déjà dedans. Et d'après le fournisseur, faut pas toucher.
            Néanmoins les tout dernier que nous avons eut sont de marque Gemalto et réponde à cette description :
            Bus 001 Device 036: ID 08e6:3438 Gemplus GemPC Key SmartCard Reader.

            Je ne connaissais pas mupdf, mais pour l'instant je n'ai pas réussi à lui faire afficher une signature "RGS".

            • [^] # Re: Titre faux ou je comprends rien?

              Posté par  . Évalué à 3.

              Un "token de signature matériel", un SmartCard, un key card reader sont vraisemblablement la même chose.

              Oui, disons que classiquement, plus de confiance est donnée dans un HSM sur PCIe que sur une smartcard qui traine dans un portefeuille. Mais techniquement, c'est la même chose.

              Bus 001 Device 036: ID 08e6:3438 Gemplus GemPC Key SmartCard Reader.

              Et tu as regardé la doc de Gemalto pour Linux http://support.gemalto.com/fileadmin/user_upload/IAM/FAQ/How_to_install_the_PC-Link_reader_on_Linux.pdf ? Avec ça tu devrais pouvoir pouvoir utiliser OpenSC ou signer via PKCS11 avec openssl.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Titre faux ou je comprends rien?

                Posté par  . Évalué à 0.

                Merci pour le lien, je regarderai.

                Ce devrait permettre l'authentification.

                Pour la signature, c'est une autre histoire

          • [^] # Re: Titre faux ou je comprends rien?

            Posté par  . Évalué à 2. Dernière modification le 24 septembre 2018 à 08:39.

            Je serai intéressé de savoir comment on peut signer (et vérifier une signature) avec muPDF, car la doc ne dit rien à ce sujet. Je n'ai pas du regarder au bon endroit (https://mupdf.com/docs/).

        • [^] # Re: Titre faux ou je comprends rien?

          Posté par  . Évalué à 1.

          J'ai testé et je pense utiliser la solution signserver.

          J'ai écrit quelques lignes sur son installation : https://github.com/blink38/signserver

          L'avantage est qu'il est libre et dispose d'une API java. L'inconvénient que l'on pourra lui trouver est que le certificat du signeur doit être installé sur le serveur. Mais ça simplifie quand même la signature du point de vue client.

          J'avais lors de mes recherches vu que la ville de Madrid ou Barcelone (je ne sais plus trop) avait développé un client pour navigateur pour pouvoir signer du côté du client.

          Enfin, j'avais également vu quelques infos sur un projet européen d'une solution de signature de document (dans https://fr.slideshare.net/DavidNaramski1/open-source-tools-for-e-signature-yajug-v3)
          retrouvé : http://dss.nowina.lu/signature

          • [^] # Re: Titre faux ou je comprends rien?

            Posté par  (site web personnel) . Évalué à 2.

            Si tu veux dire par "le certificat du signeur doit être installé sur le serveur" que la clef privée du signeur se trouve également sur le serveur, la signature du client n'a plus aucune validité.

            Pour que la signature du client ait un intérêt, il ne faut pas que la clef privée quitte sa carte à puce (ce qui est normalement impossible, de toute façon).

            • [^] # Re: Titre faux ou je comprends rien?

              Posté par  (site web personnel) . Évalué à 2.

              Pour que la signature du client ait un intérêt, il ne faut pas que la clef privée quitte sa carte à puce (ce qui est normalement impossible, de toute façon).

              Normalement impossible. Mais en pratique parfois anormalement possible : https://hal.inria.fr/hal-00691958v3

              « Résumé : Nous montrons comment exploiter l’interface de plusieurs appareils cryptographiques pour extraire leurs clés cryptographiques. »

              Adhérer à l'April, ça vous tente ?

              • [^] # Re: Titre faux ou je comprends rien?

                Posté par  (site web personnel) . Évalué à 2. Dernière modification le 21 septembre 2018 à 20:12.

                Oui, bien sûr, il y a malheureusement des failles, mais on doit partir du principe que les clefs privées ne peuvent pas être extraites quand on conçoit le système (en particulier, on ne peut pas supposer que les clefs privées de signature1 d'un utilisateur sont sur un serveur).

                1: en revanche, les clefs de chiffrement devraient être séquestrées.

            • [^] # Re: Titre faux ou je comprends rien?

              Posté par  . Évalué à 1.

              Si tu veux dire par "le certificat du signeur doit être installé sur le serveur" que la clef privée du signeur se trouve également sur le serveur, la signature du client n'a plus aucune validité.

              ça se discute. Dans mon cas, le signeur récupère ses clés via PKCS#12. Il n'y a pas de carte à puce.

              Quant à avoir la clé privée sur le serveur, s'il est mis en place un mécanisme robuste pour empêcher l'accès à la clé privée à une personne non autorisée, et si le système est certifié, je ne vois pas le problème. Pour ma part, le serveur de signature est utilisé uniquement depuis une application via une API, et n'est accessible, au niveau réseau, que par le serveur hébergeant l'appli (réseau dédié).
              Donc pour accéder au serveur de signature, il faudrait avoir eu un accès au serveur applicatif. Je considère que c'est équivalent niveau sécurité, voire meilleure, que les solutions de signature via un client java pour navigateur qui fait la signature sur le poste du signeur.

              • [^] # Re: Titre faux ou je comprends rien?

                Posté par  . Évalué à 1.

                ça se discute. Dans mon cas, le signeur récupère ses clés via PKCS#12. Il n'y a pas de carte à puce.

                C'est pas du RGS ** ni RGS *** du coup.
                Moi je suis concerné par du RGS **

                Quant au RGS *, certes il n'est pas matériel, mais je crois que les clés doivent rester en possession des utilisateurs et ne pas être accessible à 'autre y compris admin sys.
                Je sais que c'est très théorique, on sait que les RGS ** et *** sont très souvent dans le tiroir des secrétaires… (ce qui est encouragé implicitement au vue du bazar que c'est, je connais un élu qui avait 5 clés différentes, mais c'est encore un autre aspect discutable du RGS).

                Quant à avoir la clé privée sur le serveur, s'il est mis en place un mécanisme robuste pour empêcher l'accès à la clé privée à une personne non autorisée, et si le système est certifié, je ne vois pas le problème.

                Certifié ?
                Sans doute pas certifié RGS, n'est ce pas ?

                Pour ma part, le serveur de signature est utilisé uniquement depuis une application via une API, et n'est accessible, au niveau réseau, que par le serveur hébergeant l'appli (réseau dédié).
                Donc pour accéder au serveur de signature, il faudrait avoir eu un accès au serveur applicatif. Je considère que c'est équivalent niveau sécurité, voire meilleure, que les solutions de signature via un client java pour navigateur qui fait la signature sur le poste du signeur.

                C'est peut-être aussi fiable, peut-être plus.
                Mais est-ce RGS ?

              • [^] # Re: Titre faux ou je comprends rien?

                Posté par  (site web personnel) . Évalué à 2.

                C'est possible que soit aussi sécurisé qu'une solution pourrie (bon, ok, je suis un peu méchant).
                Mais tu ne pourras jamais faire accepter le principe à quelqu'un qui veut une solution RGS*/**.
                On peut accepter un concept permettant qu'un utilisateur imprudent puisse se faire voler sa clef. Par contre, un concept où tous les utilisateurs (prudents ou non) peuvent se faire voler leur identité par un admin aura normalement du mal à convaincre.

  • # RGS et exploitation

    Posté par  (site web personnel) . Évalué à 3.

    Plus généralement, j'ai l'impression que le problème du RGS c'est qu'il est écrit par des gens qui n'ont aucune idée de ce qu'est l'exploitation.

    J'ai pour ma part été confronté plusieurs fois a des complexifications induites par le RGS comme par exemple lorsqu'il faut héberger plusieurs centaines de sous domaines et que les wildcard sont interdits ou quand il faut chiffrer du NFS …

    Pour moi c'est une approche totalement contre-productive de la sécurité qui devrait au contraire promouvoir des processus simple à comprendre et a auditer…

  • # J'ai trouvé une solution

    Posté par  . Évalué à 4.

    Hello,

    J'ai eu le problème similaire au boulot (PME de ~10 salarié dans l'assainissement). Je m'occupe (entre autres) de l'informatique et une partie des telecom, et avec l'arrivée prochaine de marchés nous imposant un certificat RGS**, j'ai du gérer le dossier : expliquer au gérant et à la comptable en termes qu'ils comprennent, trouver un fournisseur de signature, briefer le gérant avant qu'il aille signer, le débriefer ensuite, et tester le système.

    Après avoir parcouru quelques FAQ de fournisseurs potentiels et envoyé quelques questions techniques par mail, j'ai fini par choisir ChamberSign et ça s'est déroulé mieux que sur le plan. Les commerciaux avant-vente sont compétents et répondent rapidement par mail (je déteste le téléphone, t'es obligé de noter, de parler et de réfléchir simultanément et en temps réel si tu veux une trace exhaustive 24H après).

    Une fois la signature effectuée et le support physique fourni, ils envoient un mail qui permet de récupérer les pilotes. Le mail donne les infos pour y revenir sans limite dans le temps et de re-télécharger les pilotes si nécessaire (les pilotes ne sont par contre pas "open bar" sur le site Web).
    Il y a un pilote pour Linux, même s'il est proprio. J'ai testé et ça fonctionne sous Debian (avec Firefox, de mémoire). Je garde au chaud un Windows configuré et testé au cas où tel ou tel site rechigne à une signature sous Linux.

    Après, je n'ai pas cherché plus que ça si on pouvait essayer d'inventer un pilote libre en espionnant le pilote proprio, le port USB, les infos échangées via le réseau, etc. Je ne suis pas payé à faire ça et ça ne m'intéresse pas d'y passer mon temps. (Et je suppose que si quelqu'un le fait sans dialoguer et coopérer avec le fabricant du bidule ET le fournisseur du certificat, ça risque d'entraîner davantage de fermeture, voire un abandon de la version Linux).

    Je ne me suis même pas demandé s'il y avait d'autres systèmes compatibles, vu qu'on n'a pas besoin de plus d'un.

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.