A | Modèles d'erreur

Que signifie le message d'erreur « Discordance du numéro de série ? Nous vous conseillons fortement de passer par le processus de pré-signature afin de récupérer le véritable numéro de série StepUp » . Ce message d'erreur indique que dans un processus PWD/OTP, le mot de passe a été réinitialisé et re-sélectionné sans effectuer une nouvelle identification avec le processus d'accélération correspondant conformément au Guide de référence.

Je me suis authentifié correctement avec PWD/OTP, Mobile ID ou Mobile ID App – mais la signature n'a pas fonctionné… quelle pourrait en être la raison ?

Les causes sont :

  • Vous avez défini un nouveau mot de passe pour la procédure PWD/OTP. Cela ne peut être effectué que dans des situations exceptionnelles auprès d'une autorité d'enregistrement interne et doit sinon toujours avoir lieu dans le cadre d'une nouvelle identification.
  • Vous vous étiez auparavant authentifié avec PWD/OTP et vous avez maintenant activé votre MobileID avec un numéro de téléphone mobile suisse ou international en utilisant une Mobile ID App. Dans ce cas, une nouvelle identification doit également avoir lieu car le moyen d'authentification appartenant à l'identité a changé.
  • Vous avez changé de carte SIM ou d'opérateur de téléphonie mobile. En conséquence, l'authentification MobileID a changé lors de l'utilisation d'un MobileID. Une nouvelle identification est également nécessaire pour cela.
  • Si aucune de ces causes n'est présente, vous devez ouvrir un ticket.

Souvent, les messages font référence à l'intégrité manquante, c'est-à-dire que le document montre des changements après la signature du document. Par exemple, des éléments du réseau ont été téléchargés et insérés ultérieurement. Cela peut être évité en utilisant systématiquement la dernière version du standard PDF/A PADES pour la signature. Afin de créer des documents PADES corrects, veuillez suivre ce lien ici : https://github.com/SCS-CBU-CED-IAM/AIS/wiki/PAdES-Long-Term-Validation

Il convient de noter que les validateurs de l'UE sont loin d'être harmonisés. Cela signifie que les portails de test peuvent présenter une signature électronique qualifiée comme « invalide », même si elle répond aux exigences de la datation eIDAS. L'UE travaille à l'harmonisation.

"La signature est valide mais la validité de l'identité du signataire n'a pas pu être vérifiée" est la déclaration d'Adobe si aucun format LTV n'a été utilisé. L'arrière-plan est qu'Adobe essaie ensuite de vérifier la validité d'un certificat de 10 minutes. Si aucun format de validation à long terme n'a été utilisé, qui stocke les informations de validité au moment de la signature, celles-ci ne sont plus accessibles après un certain temps. Par conséquent, les signatures avec des certificats à court terme (mais aussi les signatures avec une preuve à long terme) doivent toujours être enregistrées au format LTV. Vous pouvez trouver plus d'indices ici : https://github.com/SCS-CBU-CED-IAM/AIS/wiki/PAdES-Long-Term-Validation

Ce message est déclenché dans deux cas :

a) Dans le cas où vous venez d'être identifié avec l'application Swisscom RA et qu'un changement a déjà eu lieu avec votre méthode d'authentification (carte SIM/changement de contrat, Mobile ID reset, le mot de passe pour la signature a été modifié, changement de PWD/OTP en Mobile ID )

Dans ce cas, tout va bien et vous pouvez continuer à vous inscrire comme d'habitude jusqu'au niveau qualifié.

b) Dans le cas où de nouvelles conditions générales sont disponibles qui doivent être acceptées et qu'un changement a eu lieu avec votre méthode d'authentification depuis la dernière signature réussie (carte SIM/changement de contrat, Mobile ID reset, le mot de passe pour la signature a été modifié, passant de PWD /OTP vers Mobile ID)

Dans ce cas, vous devez être ré-identifié afin de pouvoir faire des signatures qualifiées.

L'appel de vérification qui vérifie si une personne est bien connue du service RA renvoie le code d'erreur suivant :

{

« statutCode » : 404,

"message": "Impossible de vérifier la juridiction de l'utilisateur inconnu avec msisdn XXXXXXXXX",

« exceptionClass » : « EvidenceVerificationException »

}

Cela signifie que la personne est inconnue du service RA. Il se peut que cette personne soit probablement identifiée mais n'ait pas accepté le SMS avec les CGU. Après un court instant (environ 2 semaines), les données de la personne seront supprimées.

Sur cette page Signature Check, vous pouvez vérifier à tout moment si vous pouvez signer électroniquement ou si vous avez besoin d'une nouvelle inscription :

https://check-signature.scapp.swisscom.com/

Si le résultat est positif, il vous sera indiqué avec quel type de signature (QES, FES) et dans quel domaine juridique (UE, Suisse) vous pouvez signer électroniquement.

En cas de résultat négatif, le motif d'un nouvel enregistrement et d'identification pour la signature électronique est affiché.

Traduit avec www.DeepL.com/Translator (version gratuite)

B | Identification en général

En Suisse, Swisscom élargit en permanence les possibilités d'identification dans les Swisscom Shops. Nous rendrons compte de cela sur cette page Web principale. A l'étranger, l'identification ne sera possible que via des partenaires qui le proposent. A moyen terme, Swisscom recherche une connexion aux identités existantes (par ex. vérification d'identité en ligne par une banque ou une eID d'État, comme la Personalausweis allemande ou la SwissID).

Lors de l'identification, le moyen d'authentification (par exemple notamment le numéro de téléphone mobile) est interrogé. Avec cela, une première signature est déjà exécutée (authentification renforcée), typiquement la signature des conditions d'utilisation qui ont été acceptées. Cette signature est transférée au All-in Signing Service. Cela signifie que le All-in Signing System connaît exactement les moyens d'authentification.

Une agence RA est associée à une zone de stockage (appelée « locataire ») dans laquelle seules les personnes identifiées par l'agent maître RA ou d'autres agents RA de son agence sont gérées. L'Agent RA-Master a accès à ce locataire et peut désigner toute personne identifiée de ce locataire en tant qu'agent RA.

Si une personne a été identifiée par une autre méthode du Smart Registration Service (par exemple l'identification vidéo dans l'UE), l'Agent RA-Master ne peut pas désigner cette personne comme agent RA du fait qu'elle est associée à un autre locataire (le locataire SRS). L'agent principal RA doit le réidentifier en utilisant l'application RA.

La seule exception est le tout premier RA-Master Agent : il est de toute façon identifié par une personne de Swisscom, Swisscom Partner ou par exemple une identification vidéo et se retrouve ainsi par défaut dans le «mauvais» locataire. Lorsque l'agence est configurée, l'agent principal RA nommé est recherché et déplacé vers le nouveau locataire correct de l'agence RA. Cependant, d'autres reports ne sont pas possibles.

Ceci est une réponse de test

C | RA-App

Veuillez trouver un tableau avec tous les documents d’identité et passeports acceptés :

Liste de documents supportés par la RA App

Cela se produit indirectement. En pratique, la procédure est la suivante : L'agence RA désigne d'abord un agent maître RA. Cet agent est identifié par Swisscom ou un partenaire de Swisscom et suit une formation. Il reçoit alors une interface utilisateur avec laquelle il peut transformer d'autres personnes identifiées par lui seul en agents RA ou agents maîtres RA. Cependant, ils doivent également suivre une formation e-Learning automatisée demandée.

En principe, Swisscom doit conserver les données très longtemps (11 ans en Suisse ou 35 ans dans l'UE). Mais les personnes peuvent être désactivées par l'agent maître RA ou par Swisscom afin qu'elles ne puissent plus signer.

En moyenne, une identification est réalisée en 2 minutes.

Tenez l'appareil photo vers le haut pour que la totalité du document d'identité soit capturée par la découpe (toujours floue si nécessaire). Rapprochez lentement la caméra du badge et elle recommencera à faire la mise au point.

Les agences RA agissent au nom du bureau d'enregistrement de Swisscom. En plus des devoirs de bonne exécution des activités du registre, la protection des données est également une priorité. Les principes de protection des données de l'art. 28 DSGVO s'appliquent, qui sont reflétées sous une forme précise dans les mesures technico-organisationnelles (TOM) dans le contrat d'agence RA. Ils sont basés sur 2 sections de l'art. 28, qui reflètent l'utilisation de l'application sur l'appareil mobile :

  • La mesure doit « assurer la capacité d'assurer la confidentialité, l'intégrité, la disponibilité et la résilience des systèmes et services dans le cadre du traitement sur le long terme » et
  • Inclure une procédure d'examen, d'évaluation et d'évaluation réguliers de l'efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement.
  • Le responsable du traitement et le sous-traitant prennent des mesures pour garantir que les personnes physiques placées sous leur autorité qui ont accès aux données à caractère personnel ne les traitent que sur instruction du responsable du traitement, à moins qu'elles ne soient tenues de le faire par le droit de l'Union ou le droit national.

Cela signifie qu'en plus de l'utilisation d'employés soigneusement sélectionnés et formés, la protection de l'application sur l'appareil mobile ainsi que la protection de l'accès doivent être garanties. Les appareils sont-ils suffisamment protégés contre les virus ? Sera-t-il interdit de télécharger des programmes d'autres magasins d'applications qui n'offrent pas une protection suffisante ? Les employés gardent-ils leurs codes PIN et leurs mots de passe secrets ? Les appareils ne sont-ils pas rootés ?

La tâche la plus importante de l'agent RA est l'examen strict des documents d'identification qui lui sont soumis et en particulier la vérification stricte des informations de terrain lues par OCR à partir de la carte d'identité / passeport ainsi que l'enregistrement correct du numéro de mobile.

Sur la base des lois sur la protection des données, nous n'offrons aucun contrat d'agence RA avec des agences RA en dehors des juridictions mentionnées. Les agents RA travaillant dans des juridictions autres que l'EEE/UE/CH ne doivent pas identifier les personnes qui sont des résidents de l'EEE/UE/CH.

Aucune instruction spéciale n’est nécessaire, car le processus est exactement le même que pour une identification “en direct” avec le RA App. Le mode démo est décrit dans la formation de base des agents RA.

Vous pouvez accéder au mode démo de la RA App en vous connectant avec les informations suivantes :

  • Numéro de portable : +41123456789
  • Nom de l’entreprise : démo

Corriger. Si une personne n'a pas de pièce d'identité ou de passeport lisible par machine, elle ne peut pas être identifiée avec l'application RA pour la signature électronique et ne peut donc pas utiliser le signing service.

Non. Il est interdit de numériser des copies de documents d'identité ou de passeports avec RA App. La raison en est que les fonctions de sécurité ne peuvent pas être vérifiées sur une copie.

Non, ce n'est pas autorisé. Le RA App a été certifié pour l'identification face à face et ne peut donc être utilisé que dans le cadre d'un contact personnel.

Mobile ID étant une méthode d'authentification personnelle, l'utilisateur doit l'activer lui-même. L'utilisateur doit toujours activer Mobile ID avant l'identification avec RA App ou Smart Registration Service afin que l'utilisateur puisse utiliser Mobile ID comme méthode d'authentification pour la signature. L'utilisateur doit suivre les instructions du menu « MON MOBILE ID » sur www.mobileid.ch . L'utilisateur peut également trouver une FAQ détaillée sur le site Mobile ID

D | Acceptation des conditions d'utilisation et lancement de la méthode d'authentification

Avertissez votre agent RA-Master et demandez-lui de rechercher le numéro de mobile sur le portail. Vous pouvez renvoyer le SMS avec les conditions d'utilisation en cliquant sur le lien avec le symbole PDF :

Assurez-vous que vous n'avez pas enregistré la personne dans le mode démo RA-App (numéro de mobile +41001234567, entreprise « démo »).

Vérifiez la page État du service ( https://trustservices.swisscom.com/service-status/ ) pour voir s'il y a des défauts. Si aucun SMS n'arrive après une nouvelle tentative, veuillez en informer le support.

Si vous êtes déjà enregistré (avec l'application RA ou le Smart Registration Service), vous devez respecter les points suivants :

  • Si vous avez confirmé les conditions d'utilisation avec PWD/OTP lors de l'identification, vous avez défini cette méthode comme méthode de déclaration de volonté. Désormais, si vous activez l'application Mobile ID comme méthode, vous ne pouvez plus signer tant que vous n'avez pas été nouvellement identifié.
  • Si vous utilisez déjà le Mobile ID sur la carte SIM et que vous souhaitez utiliser l'application Mobile ID, vous devez utiliser le code de récupération lors de l'activation ou pour vous authentifier avec le Mobile ID SIM lors de l'activation et ne pas l'activer en tant que "nouveau Mobile ID". Dans le cas contraire, cette application sera également considérée comme un nouveau mode de déclaration de testament et vous devrez vous ré-identifier.
  • La même chose se produit dans l'autre sens si vous souhaitez passer d'une application Mobile ID installée à la carte SIM Mobile ID.

Le message d'erreur typique dans un tel cas est un message d'erreur avec « incompatibilité de série ».

Le Smart Registration Services essaie 5 fois tous les 3 jours d'envoyer à nouveau le SMS. Ce n'est que si toutes les tentatives échouent après 15 jours qu'une réidentification est nécessaire.

Dans la mesure où vous n'avez pas déjà accepté les conditions d'utilisation, il est toujours possible de refuser les conditions d'utilisation. Si vous avez accepté les conditions d'utilisation et que vous avez également utilisé notre service, nous devons enregistrer votre journal d'utilisation et vos données d'enregistrement pendant une période de conservation de 35 ans dans l'UE et de 11 ans en Suisse. Mais vous pourriez facilement arrêter d'émettre des signatures électroniques.

Avec la méthode mot de passe/code SMS, il n'y a malheureusement aucune possibilité de récupération ; un utilisateur doit être ré-identifié dans tous les cas après avoir changé son mot de passe.

E | Déclaration d'intention, signature et authentification

En Suisse, nous passons Mobile ID en mode de secours PWD/OTP par défaut si la carte SIM n'est pas activée pour Mobile ID. Dans la salle eIDAS, travaillez par défaut avec l'application Mobile ID ( https://play.google.com/store/apps/details?id=com.swisscom.mobileid , https://apps.apple.com/de/app/ mobile-id/id1500393675 ), mais nous pouvons également activer PWD/OTP.

L'application Mobile ID est basée sur l'interface Mobile ID, qui propose également une authentification par empreinte digitale ou reconnaissance faciale. Cette application ne nécessite qu'une connexion Internet lors de l'authentification et peut donc être utilisée à l'international. Cependant, une carte SIM internationale (numéro de téléphone portable) est toujours requise pour la configuration de l'application. Voir https://mobileid.ch .

En général, d'autres méthodes d'authentification sont également possibles, mais celles-ci doivent être approuvées par KPMG. Cela nécessite la signature d'un contrat d'assistance à l'intégration, qui réglemente le concept de mise en œuvre et l'exécution de l'audit. Les nouvelles méthodes doivent être autorisées séparément pour ZertES et eIDAS.

Malheureusement non. Vous disposez d'un nouveau moyen d'authentification qui n'était pas initialement enregistré avec l'identification. C'est-à-dire que vous devez être nouvellement identifié à l'aide du MobileID.

Aucune garantie mais cela devrait fonctionner presque partout – on peut avoir un aperçu plus proche de cet aperçu :

https://www.swisscom.ch/fr/residential/forfaits-tarifs/inone-mobile/roaming.html

(Allez à "Tarriff Check", sélectionnez un type de contrat de modèle d'abonnement arbitraire et le pays)

Avec l'application MobileID comme moyen d'authentification, vous êtes indépendant de l'envoi de SMS.

Le service est essentiellement fourni aux résidents de l'UE/EEE et de la Suisse avec des numéros mobiles de ces pays. La réception sur les numéros mobiles d'autres pays peut ne pas fonctionner ou être empêchée par divers pays. Dans le cadre d'un projet, il peut être demandé à Swisscom d'assurer la réception dans ces pays via des fournisseurs SMS spéciaux.

 

Une authentification à 2 facteurs est nécessaire pour la signature qualifiée : « possession » et « connaissance », c'est-à-dire que seule la possession (SMS) ne suffit pas.

Non, OTP est suffisant pour les signatures avancées.

En cas d'authentification par mot de passe/code à usage unique, le mot de passe et le code à usage unique constituent les deux éléments nécessaires à l'émission d'une signature qualifiée. Dès qu'un facteur n'est plus présent, l'authentification à deux facteurs n'est plus donnée et donc la nouvelle procédure d'authentification doit être liée à une nouvelle inscription.

Avec un facteur (code à usage unique), cependant, une signature avancée est toujours possible.

Au début de la signature, il y avait des bureaux d'enregistrement locaux qui pouvaient ensuite lier le nouveau mot de passe à l'enregistrement – ces projets sont maintenant progressivement supprimés et la procédure de réinitialisation du mot de passe sera également supprimée en conséquence au cours du 1er trimestre 2021.

Déjà dans l'écran contextuel après avoir appuyé sur le bouton de réinitialisation du mot de passe, il est indiqué qu'un nouvel enregistrement est lié à la réinitialisation du mot de passe, c'est-à-dire que dès que vous réinitialisez le mot de passe, vous devez confirmer que vous vous réenregistrez.

Étant donné que les deux méthodes nécessitent un secret ainsi que la possession du numéro de téléphone, aucune signature pour l'identité numérique existante ne peut être déclenchée une fois que le numéro de téléphone a été transféré. Cela signifie que la personne doit être nouvellement identifiée.

Étant donné qu'un numéro de ligne fixe ne peut pratiquement pas être attribué à une personne, cela n'est pas possible. Le SMS est destiné à garantir que quelque chose est contacté qui est uniquement et sans exception attribué à la personne qui signe le document.

Les appareils modernes sont équipés d'appels WIFI. Ceux-ci peuvent également être utilisés pour se connecter à une zone WIFI. Sans Internet, cependant, les signatures à distance ne sont pas possibles.

Dans le cas d'un MobileID, vous pouvez utiliser un code de récupération pour transférer le MobileID vers la nouvelle SIM ( https://www.mobileid.ch/fr/login ). Dans le cas de PWD/OTP et du même numéro de téléphone, votre option d'authentification reste également.

MobileID est toujours configuré en combinaison avec une solution de repli PWD/OTP, c'est-à-dire qu'une fenêtre de mot de passe est automatiquement envoyée. Vous pouvez activer votre MobileID sur la plateforme https://mobileid.ch . Si l'application MobileID est utilisée et activée, l'application MobileID est utilisée.

Dans le cas standard, après identification, le client reçoit d'abord les conditions d'utilisation du service de signature de Swisscom. Le client le confirme et déclenche ainsi une première signature des présentes conditions, dans le cadre de laquelle il peut également définir pour la première fois le mot de passe. Ce qu'on appelle "l'authentification renforcée".

Par défaut, Swisscom ne propose actuellement que ces méthodes. Cependant, l'extension sera élaborée à l'avenir, de sorte que les méthodes biométriques puissent également être possibles si l'approbation a été accordée. En outre, Swisscom accompagnera éventuellement le client s'il souhaite utiliser une solution auditée pour permettre une signature supplémentaire auprès de l'autorité de reconnaissance. Des frais supplémentaires seront engagés.

La base de l'authentification à 2 facteurs est le fait que les deux facteurs doivent être enregistrés dans le cadre de l'authentification, c'est-à-dire qu'aucun mot de passe ne peut être choisi qui ne connaît l'application de l'abonné, mais l'abonné lui-même a été identifié avec RA-App. Une telle exception ne pourrait être imaginée que si le participant procède lui-même à une identification autorisée par délégation RA et conçoit en outre la procédure d'authentification de telle sorte que les deux facteurs (login, libération SMS) soient effectués en une session courte. Tant la procédure d'identification propre que cette procédure de session doivent être décrites en détail dans un concept d'implémentation et nécessitent une autorisation de Swisscom et de ses auditeurs. Des frais supplémentaires sont encourus ici.

Si vous avez été identifié et avez déjà utilisé PWD/OTP :

  • Si vous souhaitez utiliser l'application Mobile ID, vous devez vous ré-identifier
  • Si vous souhaitez utiliser Mobile ID (numéro de mobile suisse), vous devez vous ré-identifier

Si vous avez été identifié et avez déjà utilisé le Mobile ID :

  • Si vous souhaitez maintenant utiliser l'application Mobile ID (cela ne sera possible que sur une carte SIM qui ne prend pas en charge Mobile ID) et utiliser le code de récupération du Mobile ID, vous pouvez continuer à vous connecter
  • Si vous activez l'application SANS code de récupération, vous devez vous ré-identifier
  • Si vous souhaitez utiliser PWD/OTP, vous devez être ré-identifié

Si vous avez été identifié et avez utilisé l'application Mobile ID jusqu'à présent :

  • Si vous souhaitez maintenant utiliser le Mobile ID de la carte SIM (cela ne sera possible que sur une carte SIM suisse) et utiliser le code de récupération de l'application Mobile ID, vous pouvez continuer à vous connecter
  • Si vous activez le Mobile ID de la carte SIM SANS code de récupération, vous devez vous ré-identifier
  • Si vous souhaitez utiliser PWD/OTP, vous devez vous ré-identifier

Cela signifie que Mobile ID et Mobile ID App sont des méthodes d'authentification coordonnées, PWD/OTP est une méthode d'authentification complètement différente. La signature à distance requiert toujours que le moyen d'authentification soit inclus lors de l'enregistrement (c'est-à-dire lors de l'identification). Par conséquent, dans certains cas, une nouvelle identification sera nécessaire.

En tant qu'agent RA, vous devez informer Swisscom via la page d'assistance dans le cas où le téléphone mobile n'était pas correctement protégé contre les attaques malveillantes (comme un mot de passe avec 8 caractères, etc.) ou si vous étiez toujours connecté à la RA App car de graves problèmes de protection des données pourraient survenir . En cas de signatures, vous devez annuler votre carte SIM, éventuellement modifier vos données d'accès et cesser de signer jusqu'à ce que vous receviez votre nouvelle carte SIM.

Swisscom n'est pas en mesure de garantir suffisamment la réception du SMS. La seule responsabilité de Swisscom est d'envoyer le SMS le plus rapidement possible. Ni les conditions de réception du signal mobile ni les performances du partenaire d'itinérance interne ou externe ne peuvent être contrôlées et sont basées sur des contrats et normes télécoms internationaux

L'utilisation du nom de l'expéditeur comme « Swisscom » ou similaire serait utile pour le destinataire. Mais en effet nous avons constaté que de tels SMS sont très souvent traités comme des SMS spam par nos partenaires de roaming.

Dès le début du processus de signature, vous disposez d'un total de 15 minutes pour saisir votre mot de passe sécurisé et le code SMS unique dans le navigateur Web.

F | Validité des certificats

Oui, après 5 ans, les personnes identifiées pour les signatures avancées doivent également être nouvellement identifiées. Cependant, pour les signatures avancées, il suffit que la carte d'identité soit valide au moment de l'identification. Si celle-ci expire dans les 5 ans, aucune nouvelle identification n'est nécessaire. Pour les signatures qualifiées, en revanche, une identification est valable aussi longtemps que la carte d'identité était valable ou au maximum 5 ans après cette identification. Dans des cas particuliers, par exemple lorsque l'identification bancaire est utilisée, la validité d'une identification peut également être limitée à une période inférieure à 5 ans si la réglementation l'exige.

G | Applications possibles

Oui, c'est la seule tâche de l'application de l'abonné, qui envoie ensuite à plusieurs reprises le hachage avec la demande de signature au All-in Signing Service. N'importe quel nombre de signatures peut être généré pour le même document numérique.

Oui, mais cela nécessite 2 canaux de communication et configurations, c'est-à-dire que la signature doit d'abord être authentifiée par la personne qui signe via un canal (à la demande) puis signée de manière organisationnelle (avec un certificat statique préalablement créé) par un certificat d'authentification SSL via un deuxième canal.

Oui, plusieurs documents peuvent être signés avec une seule approbation au cours d'une session. Au maximum env. 250 signatures.

Les signatures XML selon le standard XADES peuvent se faire sur la base de sceaux mais pas sur des signatures personnelles (dans l'instant). Dans le client il faut préparer le standard XADES : L'appel d'une « signature simple » doit être mis en œuvre.

Pour les signatures dans l'espace juridique suisse : www.validator.ch (Attention, le validateur n'est pas toujours à jour). Pour les signatures dans l'espace juridique de l'UE : https://www.signatur.rtr.at/de/vd/Pruefung.html

Il convient de noter que les validateurs de l'UE sont loin d'être harmonisés. Cela signifie que les portails de test peuvent présenter une signature électronique qualifiée comme « invalide », même si elle répond aux exigences de la datation eIDAS. L'UE travaille à l'harmonisation.

Seules les signatures QES peuvent être validées. Il n'y a pas de validateurs pour les signatures AES.

Deux comptes d'utilisateur (ClamedIdentity) doivent être ouverts, chaque compte est lié au type de signature respectif, c'est-à-dire que l'application participante doit décider sur quel compte elle envoie une demande de signature. Les deux comptes peuvent être adressés via une seule interface, c'est-à-dire le même terminal. Il y a des frais de service par compte. 2 factures sont émises en fin de mois. Par conséquent, 2 contrats de service avec 2 configurations différentes et déclarations d'acceptation doivent être soumis. Si vous avez 2 domaines juridiques et 2 types de facturation, vous n'avez toujours qu'une seule interface (technique), mais 4 points d'interface d'accès au service et par là 4 fois une redevance de service. Il double à nouveau à 8 ClaimedID, si les deux niveaux de signature (QES/AES) sont prévus avec les deux types de facturation et les deux juridictions.

Oui, par exemple :

https://www.seantis.ch/blog/digitale-signatur-onegov-cloud/

https://www.bcge.ch/pdf/conditions-self-fr.pdf

De nombreux exemples sont également disponibles sur nos pages partenaires : https://trustservices.swisscom.com/partner

En principe, un horodatage mémorise également la zone (le décalage). À cet égard, tous les programmes locaux afficheront l'heure locale réelle.

En principe, Swisscom fournit un hachage signé et prend ainsi en charge les formats PADES (PDF) et, dans le cas des certificats d'organisation, les formats XADES (XML). Les fichiers Word ne sont pas signés et ne sont pas prévus à cet effet par la loi.

Non

Non, seul un horodatage commun existe.

H | Intégration et configuration de l'interface

Principalement oui. En cas d'utilisation du nom et du prénom, il doit être exactement le même que celui figurant sur la pièce d'identité ou le passeport. Mais si cela est difficile à mettre en œuvre, la fonctionnalité de modèle peut prendre en charge ( https://github.com/SCS-CBU-CED-IAM/AIS/wiki/Distinguished-Name:-Use-of-Evidence-Attributes ). Cette fonction permet de reprendre exactement le prénom et le nom qui ont été utilisés lors de l'identification en combinaison avec le service RA (SRS).

Swisscom est également en mesure de configurer le service de manière à ce que seul un pseudonyme soit utilisé à la place du nom et du prénom. De plus, le « Nom commun » (CN) pourrait être utilisé avec les noms habituellement utilisés pour cette personne (indépendants de la pièce d'identité). L'appel de vérification RA-Service vérifie dans ce cas le numéro de mobile qui a été utilisé lors de l'identification et le pays. L'utilisation du pseudonyme dans le verifyCall est indépendante de l'utilisation du pseudonyme dans l'appel de demande de signature.

Oui, il existe plusieurs bibliothèques disponibles sur le marché qui permettent une implémentation rapide d'une application de signature. Tous bénéficient également d'un support spécial pour Swisscom Service:

Intarsys est un partenaire premium de Swisscom et connaît très bien le service AIS d'un point de vue technique et peut fournir une assistance en matière de conseil.

Swisscom décline toute responsabilité quant au fonctionnement sans erreur de ces bibliothèques. Ceux-ci peuvent contenir des erreurs et nécessitent des connaissances et une expertise particulières. L'utilisation est aux risques et périls de l'abonné.

Voir https://github.com/SCS-CBU-CED-IAM/AIS/wiki/Swisscom-CA-4

Il existe un mode test et démo qui vous permet d'essayer l'application, mais aucune donnée n'est transmise. A cet effet, le numéro de téléphone mobile +41001234567 doit être renseigné dans le formulaire d'inscription et le nom de l'entreprise « demo ».

Non. Swisscom exige même que, lorsque l'écran PWD/OTP est intégré en tant qu'« iFrame », une personne externe puisse vérifier qu'il provient de Swisscom. Il est par exemple possible d'utiliser les fonctions de navigateur standard que Swisscom publie sous son lien Internet conformément au chapitre 4 des conditions d'utilisation. Pour l'intégration iFrame, consultez https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide

Il n'y a pas de prise en charge de la capture d'écran en tant qu'interface. Developers pourrait être confronté au fait que les écrans vont être changés. Elle est également contradictoire avec la mise en place d'un « contrôle unique » entre le signataire et le certificat de signature.

Oui, mais uniquement en tant qu'iFrame, les instructions peuvent être trouvées ici : https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide

Non, voir https://github.com/SCS-CBU-CED-IAM/AIS/wiki/SAS-iFrame-Embedding-Guide.

Oui, comme décrit dans le Guide de référence ( www.swisscom.com/signing-service ) sous « Méthode Step-Up » dans le champ « Message », le bloc de texte avec l'en-tête du message pour l'expression de l'intention et la langue le réglage avec « Langue » peut être configuré dans le cadre du protocole. Pour la fenêtre de saisie SMS, la langue peut également être définie avec le paramètre « Langue ».

La condition préalable à l'installation est une « déclaration de configuration et d'acceptation » signée par le client et vérifiée par l'autorité d'enregistrement mondiale. Cette déclaration contient les obligations de l'exploitant d'une application de signature (par exemple la possibilité d'afficher le document complet à signer, la sécurisation de l'accès au service), mais aussi les caractéristiques du service.

Un autre prérequis est un certificat d'accès, qui sécurise la communication de l'application de signature au service de signature.

Après vérification du document, notre Service Setup reçoit l'ordre d'activer le service avec le certificat d'accès envoyé et la spécification choisie dans la déclaration de configuration et d'acceptation. Dans le cas des signatures qualifiées, le service n'est initialement activé que pour les signatures « avancées ». Par la suite, il est demandé au contact nommé dans la déclaration de configuration et d'acceptation un exemple de signature avec la signature avancée. Si celui-ci est irréprochable, le service passe au niveau « qualifié » si nécessaire. Le client en sera également informé. Il dispose désormais de 10 jours pour signaler toute irrégularité directement à l'équipe de configuration. S'ils ne reçoivent aucune réclamation pendant ce délai, la connexion au service est acceptée. D'autres incidents peuvent ensuite être signalés à Swisscom via 1st Level Support en cas de contact direct avec Swisscom ou le partenaire revendeur.

Le certificat d'accès peut être un certificat auto-signé. Par exemple avec le logiciel openssl.

Exigences pour le nom distinctif :

  • CN=<URL du système d'abonné qui effectue la communication avec AIS ou autre identification unique du système d'abonné>
  • O=<Nom de l'organisation>
  • Email=<E-mail à des fins de notification, par exemple en cas de fin de validité>
  • C=<Pays de l'organisation>

Les exigences supplémentaires suivantes doivent être prises en compte lors de la préparation du certificat :

  • Durée maximale 3 ans
  • Algorithme de hachage minimum SHA-256
  • Longueur de clé minimale 3072 bits

Des conditions particulières s'appliquent toujours pour les certificats d'accès dans le cadre de la création de sceaux réglementés (ZertES) ou qualifiés (eIDAS): La clé privée du certificat d'accès doit être créée sur un module cryptographique lors d'une cérémonie conjointe d'un représentant de l'autorité d'enregistrement de Swisscom. Ce module doit répondre aux exigences de la norme FIPS 140-2 niveau 2 ou similaire, par exemple Yubikey, Feitan key ou Microsoft Key Vault. Alternativement, un concept peut être soumis sur la manière dont l'attribution du certificat d'accès à la personne responsable de l'organisation peut être réalisée par d'autres moyens.

Dans le cas d'un sceau, en plus de la configuration et de la déclaration d'acceptation par l'exploitant de la plateforme de signature, il nécessite également une demande de certificat pour le certificat de sceau, un certificat d'organisation. Contrairement au certificat de signature personnelle, le certificat de sceau est délivré pour trois ans. La demande de certificat doit être signée par les personnes autorisées de l'organisation. L'autorisation peut résulter du registre (par exemple procuration) ou peut également être une procuration spéciale, qui a été délivrée par exemple pour les opérateurs du centre informatique. Swisscom a besoin de la preuve de cette procuration. Ces personnes sont également identifiées personnellement au préalable par un représentant du bureau d'enregistrement de Swisscom à l'aide de la RA-App. Il peut également s'agir, par exemple, d'un agent RA d'un revendeur qui a procédé à l'identification personnelle. Cela permet à la personne de signer la demande à l'aide d'une signature électronique. La demande est envoyée à Swisscom non signée et Swisscom invite les personnes à signer électroniquement. Les prochaines étapes diffèrent désormais selon le type de joint :

Signature avancée: Le demandeur envoie à Swisscom un certificat SSL qu'il souhaite utiliser comme certificat d'accès pour l'interface avec le sceau.

Signature qualifiée/régulée : Le demandeur convient d'une date avec Swisscom pour la création conjointe d'une clé privée. Celle-ci doit être créée sur un dispositif cryptographique basé sur la qualification FIPS 140-2 niveau 2 ou similaire (ex. Yubikey, Feitan Key, Key Vault HSM Microsoft, etc.) Un certificat d'accès est alors créé sur la base de cette clé. C'est-à-dire que pour le processus de signature, l'accès doit être libéré au moyen de ce certificat. Alternativement, un concept peut être soumis sur la manière dont l'attribution du certificat d'accès à la personne responsable de l'organisation peut être réalisée par d'autres moyens.

L'intégration des hachages signés devrait être la tâche des spécialistes PDF ou des bibliothèques correspondantes. L'espace pour la signature doit être précalculé. Veuillez consulter https://github.com/SCS-CBU-CED-IAM/AIS/wiki/Swisscom-CA-4 .

La solution suivante peut fournir une solution. Nous le présentons ici sans garantie, car Swisscom se concentre uniquement sur le service et non sur l'application de signature :

  • Créer un PDF avec un champ de signature vide et pré-rempli
  • La plage d'octets doit être remplie de zéros jusqu'à la taille attendue
  • Calculer le hachage du document
  • Signez le hachage avec le All-in Signing Service
  • Remplissez le hachage signé dans le champ de signature vide
  • Itérer jusqu'au champ de signature vide
  • Déterminer la plage d'octets du champ de signature vide
  • Calculer le décalage de la plage d'octets
  • Ouvrez le document avec le champ de signature vide en mode lecture-écriture et recherchez le décalage où le hachage a été inséré

Il est également très important de suivre les directives de la norme PADES et de la validation à long terme : https://github.com/SCS-CBU-CED-IAM/AIS/wiki/PAdES-Long-Term-Validation

Dans les paramètres retournés de l'appel de vérification, le soi-disant "série" est retourné. Si cela commence par « SAS » (c'est-à-dire SASxxxxxxx), le client utilisera l'authentification PWD/OTP. S'il commence par « MID » (c'est-à-dire MIDxxxxxx), le client utilise la procédure Mobile ID. Cependant, il n'est pas possible de faire la distinction entre l'application Mobile ID et la carte SIM Mobile ID.

Néanmoins, les résultats peuvent être utilisés, par exemple pour fournir des textes d'aide particuliers (par exemple en cas d'oubli du mot de passe, etc.) au client, ou pour se référer à la déclaration de volonté sur le téléphone mobile.

Le verifyCall vous permet de vérifier si un signataire est déjà enregistré ou non. Si vous choisissez le pseudonyme, vous n'aurez besoin que du numéro de portable et du pays du signataire. https://documents.swisscom.com/product/filestore/lib/4cce2074-46e3-4e43-a1b4-ccf5d5cb7ca5/VerifyID4Signing-de.pdf

PKCS#1 n'est pris en charge que pour le format CADES et les sceaux, mais pas pour les signatures personnelles.

Non, uniquement PADES/CADES pour les sceaux et PADES pour les signatures personnelles.

Il aide Swisscom à trouver un nom pour le ClaimedID (accès au signing service).

Oui, cochez simplement la case appropriée.

I | Performance

En ce moment, nous sommes en train d'étendre nos capacités avec d'autres algorithmes (pré-génération de clés) et l'expansion matérielle. Étant donné que plusieurs clients utilisent le service, nous supposons une charge maximale d'une requête par seconde en moyenne par client. Des performances plus élevées, c'est-à-dire des capacités spécialement réservées, sont possibles en option.

Il est limité à 250 pour des raisons de sécurité plutôt que pour la capacité du service.

Veuillez noter que nous avons installé un WAF afin de protéger notre service contre les attaques par déni de service. Si vous souhaitez effectuer des tests de masse, veuillez nous contacter au préalable.

La signature doit être signée avec une déclaration de volonté (autorisation) par Mobile ID (SIM/App) ou PWD/OTP. Après avoir envoyé la demande, l'utilisateur dispose généralement de 80 secondes pour saisir l'autorisation. La valeur n'est pas réglable.

J | Facturation

Chaque signature est calculée individuellement, c'est-à-dire que dans cet exemple 5 signatures sont calculées.

Non, ils sont proposés via deux ClaimedID différents et seront facturés indépendamment.

Swisscom ne facture aucun frais pour l'envoi de Mobile ID ou de SMS. Selon le tarif du partenaire d'itinérance, des frais d'itinérance peuvent être occasionnés (ce qui arrive très rarement, par exemple lors des croisières).

Ici, deux comptes d'utilisateurs (ClamedIdentity) doivent être ouverts, chaque compte est connecté à une méthode de facturation. Cela signifie que l'application abonnée doit décider elle-même quel compte elle utilisera pour envoyer une demande de signature. Il y a des frais de service par compte. 2 factures sont émises en fin de mois.

Il n'y a pas de frais pour ces mois.

K | Protection des données

Oui, une distinction est faite entre si les signataires ont accepté les conditions d'utilisation de la Suisse ou de l'UE ou les deux. Toutes les données sont également traitées par Swisscom (Suisse) AG pour Swisscom IT Services Finance SE à Vienne.

La Suisse ne fait pas partie de l'UE et n'a donc pas introduit de législation européenne, le Règlement général sur la protection des données (RGPD). En réalité, le RGPD est également applicable si les entreprises sont basées en Suisse et proposent des services dans l'UE.

Swisscom est donc soumise aux mêmes obligations de traitement des données que toutes les autres organisations qui doivent se conformer au RGPD :

  • obtenir le consentement de la personne dont les données sont traitées
  • Garantie « Privacy by design » et « Privacy by default »
  • désigner un délégué à la protection des données
  • créer une liste des activités de traitement
  • signaler les violations de la protection des données à l'autorité de contrôle
  • effectuer une évaluation de l'impact sur la vie privée

Toutes les applications qui concernent la protection des données et sont utilisées pour le traitement des données, par exemple l'application RA également, doivent être conformes au RGPD. Swisscom informe à ce sujet sur ses pages :

Suisse : www.swisscom.com/signing-service

Autriche : www.swisscom.at

avec les déclarations de protection des données correspondantes conformément au RGPD.

La Suisse a toujours été et est considérée comme un pays tiers sûr au sens de l'art. 45 GDPR (transfert de données basé sur une décision d'adéquation), c'est-à-dire que les autorisations habituelles comme avec d'autres pays tiers (par exemple les États-Unis) ne sont pas nécessaires. Grâce à sa loi sur la protection des données et à l'adaptation en cours au RGPD, la Suisse dispose d'un « niveau de protection adéquat pour le transfert de données personnelles » conformément aux critères de l'UE, c'est-à-dire qu'elle doit en effet être traitée comme un pays de l'UE lors du transfert de données :

https://ec.europa.eu/info/law/law-topic/data-protection/data-transfers-outside-eu/adequacy-protection-personal-data-non-eu-countries_en

Dans le cadre de ses audits permanents, Swisscom doit s'assurer que toutes les exigences strictes en matière de protection des données nécessaires à l'émission de signatures numériques sont respectées, tant vis-à-vis de l'autorité de certification en Suisse que vis-à-vis de l'organisme d'évaluation de la conformité en Suisse. L'Autriche. Cela signifie qu'en plus de l'auto-déclaration, les prestataires de services de confiance et les services de certification sont tenus par la législation et les normes internationales appliquées, telles que l'ETSI 319 401, de démontrer et d'avoir audité une protection appropriée des données pour toutes les données personnelles.

Les exigences en matière de protection des données à démontrer et à auditer s'appliquent également aux activités de l'autorité d'enregistrement – une tâche d'un fournisseur de services de confiance et d'un fournisseur de services de certification. Ainsi, l'application RA dans le cadre du processus d'enregistrement doit garantir la protection des données et la confidentialité. L'application RA elle-même ne stocke aucune donnée personnelle de manière permanente. Aucune donnée ne peut être exportée non plus. Dès que l'identification est terminée, les données sont transférées signées par l'agent RA en tant que preuve. Ces preuves sont conservées au service RA de Swisscom dans des conditions de sécurité strictes (p. ex. accès à 4 yeux). Seules quelques personnes ont accès à ces données et ne peuvent les transmettre que sur décision de justice ou sont autorisées à vérifier la qualité de l'identification. Conformément à la loi, Swisscom est indéfiniment responsable de la bonne exécution de la signature et donc également de l'identification.

Les Agents RA Master ont un accès web à un portail dans lequel ils peuvent visualiser toutes les personnes identifiées par les Agents RA avec leurs nom, prénom, date d'expiration du document d'identité et numéro de téléphone portable. Les pièces d'identité et les photos (appelées « preuves ») ne sont ni accessibles ni exportables.

Swisscom est légalement tenue d'enregistrer les données personnelles pour la signature. Il est donc responsable de ces données. Cela signifie que Swisscom ne peut pas jouer le rôle de sous-traitant, même s'il reçoit par exemple des données d'employés d'une entreprise cliente pour la signature. Swisscom a un mandat légal comme celui des opérateurs télécoms ou postaux. De plus, Swisscom a une relation contractuelle légale avec les signataires avec les conditions d'utilisation. Dans cet accord, le signataire accepte également l'utilisation des données.

Avec l'application RA, Swisscom transfère l'enregistrement des données d'identité à un prestataire de services externe, qui est désigné dans les contrats sous le nom d'«agence RA». Le RGPD impose dans ce cas un contrat de traitement des commandes. L'agence RA doit donc se conformer aux obligations de traitement des données de commande.

Le respect du RGPD pour le traitement des données de commande est également requis dans les projets purement suisses. Il y a deux raisons à cela :

  • D'une part, il peut rarement être garanti que les personnes identifiées en Suisse ne sont pas des citoyens de l'UE soumis au principe de marché du RGPD,
  • D'autre part, l'application RA ne peut pas être utilisée de manière à ce que seules des personnes pour la Suisse soient identifiées, c'est-à-dire que le traitement des données de commande a toujours lieu pour Swisscom IT Services Finance SE à Vienne également.

Dans certains projets, Swisscom s'appuie sur des procédures d'identification légalement reconnues et auditées avec des tiers. Un exemple typique est une banque qui effectue une identification de présence d'une personne dans le cadre de son processus KYC. Dans ce cas, Swisscom reçoit une copie des données de la banque pour ses propres besoins commerciaux (signature). Le traitement des données de commande n'est pas nécessaire ici, car il y a deux parties responsables des données. À l'inverse, le principe de contrôle conjoint du RGPD n'est pas appliqué ici non plus, car la réactivité des données ne sert pas le même objectif commercial et les deux parties n'agissent pas de manière responsable dans le sens d'un objectif commercial commun. La banque agit pour son objectif commercial, par exemple l'ouverture d'un compte, et Swisscom poursuit son objectif commercial consistant à émettre des signatures. Néanmoins, dans ce cas, nos contrats sur la « délégation d'activité de registre » contiennent également un minimum de dispositions sur la manière de procéder en matière de protection des données et du RGPD.

Dans le cas d'une signature à distance, Swisscom conserve et gère les clés des certificats de signature en fiducie. Dans le cas d'une signature personnelle, les certificats de signature ne sont générés que pour la signature et perdent leur validité après env. 10 minutes. Les certificats d'entreprise pour les sceaux sont valables jusqu'à 3 ans. Selon la loi, la clé privée doit être stockée sur un dispositif de création de signature (qualifié). La mémoire pour cela est un appareil qui est principalement conçu pour le stockage de clés, le HSM (Hardware Security Module). Il est soumis à une réglementation stricte, à des audits, en termes de normes de sécurité et d'accès à cet appareil. Les signatures dans l'UE et en Suisse sont soumises à des normes de sécurité particulièrement élevées, qui ne sont disponibles que chez quelques fabricants HSM dans le monde.

L | Thèmes juridiques et réglementaires

Adobe est un fournisseur américain d'un logiciel permettant d'afficher des documents PDF. Le produit le plus connu et le plus répandu est le soi-disant « Adobe Acrobat Reader ». Cela permet la vérification des signatures basées sur des certificats. Qu'une signature soit valide et donc affichée avec une coche verte dépend de nombreux aspects :

  • Adobe a son propre ensemble de règles, qui classe les autorités de certification émettrices des fournisseurs de confiance ou des fournisseurs de services de certification comme « dignes de confiance ». Ceux-ci sont répertoriés dans une soi-disant liste de confiance Adobe (AATL). Même s'il n'est pas inclus dans la description du service, Swisscom s'efforce toujours d'être répertorié ici. De plus, les sociétés cotées doivent payer des frais annuels pour cette inscription et déposer leur auto-évaluation. Selon Adobe, les prestataires de services de confiance eIDAS sont considérés comme dignes de confiance s'ils ont également conclu un contrat avec Adobe.
  • Adobe propose une variété de paramètres qui peuvent conduire à une validation complètement différente : par exemple, au lieu de la liste de confiance d'Adobe, la liste de confiance de Microsoft Windows peut également être utilisée, qui ne conserve généralement que les fournisseurs de services de confiance qui émettent également des certificats SSL ou e-mail. . Cependant, le contrôle peut également être basé sur une heure donnée par l'horloge de l'ordinateur et non sur l'horodatage du document.

Cela signifie que vous ne pouvez pas vous fier à la validité d'une signature dans Adobe, mais vous obtenez des informations sur les modifications apportées au document depuis que la signature a été définie et à quoi ressemble le certificat de signature.

Les deux doivent être des informaticiens qui connaissent l'application. Il n'est pas nécessaire qu'il s'agisse d'une personne ayant le rôle officiel « Adjoint à la vie privée ». Swisscom veut simplement conserver ici le principe des 4 yeux. Les rôles sont : Pouvoir fournir des informations sur l'administration de l'application utilisateur (qui a accès, qu'est-ce qu'un administrateur pourrait manipuler, où pourrait-il y avoir un problème, connexion SSL à Swisscom) et sur des sujets tels que la protection antivirus, le contrôle d'accès en général, etc. chez le responsable de la sécurité.

D'une part, une entreprise interne peut devenir un partenaire de revente de Swisscom pour d'autres entreprises si un volume important est prévu. Dans ce cas, le flux de paiement passe directement uniquement par cette entreprise individuelle. Une entreprise peut également assumer l'entière responsabilité du fonctionnement de l'application d'abonné. Même alors, les factures ne passeront que par cette société. Il peut alors identifier les employés des autres entreprises.

Si toutes les entreprises souhaitent exploiter l'application d'abonné de manière indépendante (avec leur propre responsabilité et responsabilité) et souhaitent également fournir elles-mêmes des agents RA, un contrat distinct est requis pour chaque entreprise.

Swisscom Trust Services est un service de plate-forme pure qui fournit les services de signature légalement requis en tant que signature à distance à un grand nombre de clients en Europe de manière hautement standardisée et réglementée en utilisant des flux de travail standard pour le traitement. Le contrat type prévu à cet effet a été soumis aux autorités de tutelle et/ou audité en conséquence. Swisscom Trust Services ne fournit donc aucun service spécifique au projet dans le cadre de la signature ou de l'enregistrement ou des dépenses pour les procédures contractuelles qui s'écartent du flux de travail contractuel standard, à l'exception des services de conseil commandés séparément à l'avance.
Nous pouvons donc offrir à tous les clients et partenaires les mêmes prix avantageux selon le service et la liste de prix. Nous apprécions votre compréhension.

Ceci s'applique également à cet égard et en particulier (mais pas exclusivement) :

  • Conclusion de tous les accords et contrats supplémentaires, p. pourrait également remettre en cause les contrats standardisés et réglementés.
  • Modifications des contrats, en particulier également du droit applicable, souhaits d'assurance divergents.
  • Écarts par rapport aux processus contractuels, par exemple l'utilisation de plates-formes supplémentaires pour l'enregistrement des fournisseurs/la signature des contrats.
  • Accords spéciaux sur l'inspection de l'architecture ou la divulgation des détails de mise en œuvre (par exemple, les procédures de sauvegarde, les détails de programmation et de sécurité tels que la protection des accès, les accès, les procédures cryptographiques, la reprise après sinistre, etc.). Swisscom publie toutes les informations sur la pratique de la prestation de services dans sa CP/CPS (https://trustservices.swisscom.com/repository ) et le document de base pour la CP/CPS. Pour des raisons de sécurité, d'autres détails ne sont divulgués à aucun client, de sorte que les connaissances ne peuvent pas être accumulées pour concevoir des attaques ciblées si nécessaire.
  • Pour les demandes de connexions à la surveillance interne, Swisscom publie les pannes de son service via le site https://trustservices.swisscom.com/status-service , auquel il est également possible de s'abonner dans le cadre du protocole RSS. Pour des raisons de sécurité, aucune autre intervention dans le système à des fins de surveillance n'est autorisée.

La certification et trust services doivent décrire leurs pratiques et procédures sur la façon dont ils exécutent un service dans un document dit « CP/CPS » (Certificate Policy/Certificate Practice Statement). Les services sont audités non seulement au début de l'activité, mais régulièrement par des auditeurs reconnus par l'Etat et l'organisme de reconnaissance (Suisse) ou l'organe de surveillance (UE) de l'Etat décide sur la base des audits de l'agrément, de la poursuite de l'exploitation ou l'expansion des services de certification et trust services et ainsi assurer le standard de qualité élevé sur le marché pour tous les signataires. Outre les exigences légales générales, de nombreuses normes des organismes européens de normalisation ETSI et CEN doivent être respectées.
L'État publie la conformité aux normes et standards d'audit et donc également l'approbation en tant que service de certification ou de confiance reconnu sur ses sites Internet :

Non, uniquement pour le fonctionnement de l'application de signature aucune certification et aucun audit n'est requis. Dans le cadre d'une « déclaration de configuration et d'acceptation », le client fait une auto-déclaration de bon fonctionnement de l'application de signature, c'est-à-dire de ne pas échanger le hachage d'un document et d'afficher effectivement le document à signer au client (WYSIWYS = « Ce que vous voyez est ce que vous signez »). Le trafic de données entre l'application de signature et Swisscom doit être crypté et une protection de base contre les virus et les attaques doit être garantie comme pour tout autre système. Un audit officiel avec certification ne peut être nécessaire que si le système dispose de sa propre identification, notamment par rapport à sa propre méthode d'authentification. En Suisse, l'identification avec les méthodes d'authentification de Swisscom peut être traitée de manière simplifiée au moyen d'un « concept d'implémentation » approprié soumis par le client et approuvé par Swisscom; dans l'UE, un audit officiel est généralement nécessaire. En règle générale, une méthode d'authentification doit toujours être certifiée, car cela doit assurer un « contrôle exclusif » au certificat de signature (appelé « contrôle exclusif » dans le contexte ETSI).

En principe, la société doit désigner des représentants. Ces représentants doivent être soit les représentants inscrits selon le registre du commerce ou des entreprises, soit des employés munis de procurations appropriées signées par les représentants inscrits. Dans tous les cas, les personnes doivent être personnellement identifiées avec notre RA-App. En Suisse, seules les entreprises inscrites au registre UID peuvent commander des scellés. Avec le sceau, le certificat d'accès SSL entre l'application de signature chez le client et Swisscom sert d'authentification de l'entreprise. Le certificat d'accès doit donc être remis par le représentant de l'organisation. Avec le sceau avancé, une simple livraison suffit ; avec le sceau qualifié, une cérémonie de remise conjointe a lieu au cours de laquelle le certificat d'accès est généré conjointement. La clé privée doit être stockée sur un dispositif cryptographique (FIPS 140-2 niveau 2 minimum).

En principe, Swisscom a une responsabilité illimitée en vertu de la loi pour l'émission incorrecte de certificats qualifiés. Dans le cas de certificats avancés, cette responsabilité peut être limitée. Swisscom est également obligatoirement assurée à cet effet. En cas d'erreurs dans l'application de la signature (par exemple l'échange d'un hachage d'un document) ou d'erreurs d'identification par des registres tiers, Swisscom engage à son tour la responsabilité de ces tiers. Afin d'éviter les risques de responsabilité, des exigences élevées sont imposées au processus d'émission et de contrat et la possibilité d'auditer les tiers impliqués est généralement requise.

La législation suisse, c'est-à-dire la loi fédérale sur la signature électronique (ZertES/SCSE), définit les exigences que les organisations doivent remplir pour être reconnues en tant que service de certification. L'organisme d'accréditation accrédité pour l'accréditation de Swisscom en tant que service de certification en Suisse est KPMG (Accreditation No. SCESm 0071). Elle délivre un certificat d'évaluation de la conformité (disponible sur www.swisscom.com/signing-service). Le Service d'accréditation suisse SAS tient à jour une liste des services de certification accrédités : Lien

Avec l'entrée en vigueur du règlement sur l'identification électronique et les _services_de_confiance_ pour les transactions électroniques dans le marché intérieur de l'Union européenne (eIDAS), la base a été créée pour une communication électronique juridiquement valable et une identification électronique sécurisée dans toute l'Europe. À l'aide de _services_de_confiance_ tels que les signatures électroniques, les sceaux, les horodatages, les services de livraison et les certificats d'authentification, les entreprises, les administrations et les particuliers peuvent échanger des documents numériques tels que des offres, des commandes, des contrats, etc. au sein de l'Union européenne sur une base juridique uniforme . Ainsi, le nouveau règlement de l'UE remplace la loi nationale sur les signatures et les règlements sur les signatures.

En vertu de ce règlement (CE) n° 910/2014/UE (règlement eIDAS) , les listes de confiance nationales ont un effet constitutif. En d'autres termes, un fournisseur de services de confiance et les _services_de_confiance_ qu'il fournit ne seront qualifiés que s'ils figurent dans les listes de confiance. Par conséquent, les utilisateurs (citoyens, entreprises ou administrations publiques) ne bénéficieront de l'effet juridique associé à un service de confiance qualifié donné que si ce dernier est répertorié (comme qualifié) dans les Listes de Confiance.

La filiale de Swisscom en Autriche « Swisscom IT Services Finance SE », Vienne a été incluse dans cette liste de confiance avec des certificats et des sceaux qualifiés :

https://webgate.ec.europa.eu/tl-browser/#/tl/AT

Swisscom IT Services Finance SE a mandaté Swisscom (Suisse) SA pour l'exploitation du service de confiance et a également délégué les activités d'autorité de registre à Swisscom (Suisse) SA. Swisscom (Suisse) SA propose ainsi le service au marché et accepte également les documents contractuels pour le compte de Swisscom IT Services Finance SE.

Swisscom ne peut que confirmer qu'elle peut émettre des signatures qualifiées dans les deux systèmes juridiques conformément au règlement eIDAS de l'UE et à la loi ZertES de la Suisse. Les signatures qualifiées suisses ne sont reconnues comme qualifiées qu'en Suisse et les signatures qualifiées eIDAS dans l'UE.

La conformité de la signature qualifiée pour tout contrat doit toujours être vérifiée par un avocat. Swisscom ne peut fournir aucune information juridique à cet égard. Ceci n'est pas seulement lié à la signature, mais aussi à d'autres points qui peuvent être convenus dans les contrats. Par exemple, l'exigence de « retour par courrier recommandé » peut signifier qu'une signature électronique ne peut pas du tout être exécutée, car un itinéraire papier postal est obligatoire.

Dans les systèmes juridiques de l'UE et de la Suisse, le renversement de la charge de la preuve (et en Allemagne également la preuve prima facie par rapport à la preuve visuelle) s'applique en principe aux signatures qualifiées. Cela signifie qu'une partie adverse doit prouver que la signature qualifiée n'a pas été correctement exécutée si elle est contestée. Et bien entendu, Swisscom peut fournir des vérifications certifiées KPMG pour prouver que la signature qualifiée a été dûment exécutée.

Les délais de conservation pour la vérification d'identité et le journal d'activité et donc également les délais de preuve sont de 11 ans en Suisse et de 35 ans dans l'UE. Swisscom utilise généralement le standard de validation à long terme de l'ETSI (LTV).

La validation à long terme consiste à valider une signature de manière à ce qu'elle reste valable longtemps. La validation LTV n'autorise la validation que tant que le certificat racine de l'horodatage n'a pas expiré. Il est donc conseillé d'horodater à nouveau les documents avant l'expiration si des preuves à long terme doivent être préservées, afin que l'intégrité et la signification de la preuve de signature continuent d'être assurées.

En principe, les documents PDF devraient également être gérés dans des archives sécurisées. Une situation peut survenir dans 5, 10 ou 20 ans dans laquelle les algorithmes de signature sont « crackés », c'est-à-dire que l'intégrité ou l'authenticité ne pourraient plus être garanties. De bons systèmes d'archivage prévoient donc une démission régulière, par exemple avec un horodatage, qui utilise toujours l'algorithme le plus récent et garantit ainsi l'intégrité du document.

Le web propose différents liens avec des procédures optimisées pour cela, par exemple « Archisig ». Le BSI allemand a également publié une directive technique « Conservation de la valeur probante des documents signés cryptographiquement ». Il s'agit de la spécification des exigences techniques de sécurité pour la préservation à long terme de la valeur probante des documents et données électroniques signés cryptographiquement ainsi que des données administratives électroniques associées (métadonnées).

Un middleware défini à ces fins (middleware TR-ESOR) au sens de cette directive comprend tous les modules et interfaces qui sont utilisés pour sécuriser et maintenir l'authenticité et prouver l'intégrité des documents et données stockés.

L'expérience a montré que les périodes de transition peuvent durer de 3 mois à 2 ans.

Non.

Après la résiliation du contrat, les certificats de sceau valides existants seront révoqués.

La manière dont un tel scénario de « shutdown » doit être réalisé est réglementée par la loi : la CP/CPS du service de certification ou du service de confiance décrit les procédures exactes. Il doit y avoir un plan de fermeture et l'autorité de surveillance notifiée ou l'OFCOM désignera généralement un successeur qui pourrait offrir le service aux clients. Ce successeur recevra normalement également la Certificate Revocation List et donc la liste de validité des certificats, à condition que Swisscom ne les publie pas elle-même. La liste continuera à fonctionner pendant des années, afin que la validité des signatures puisse continuer à être vérifiée. Les preuves sur les enregistrements pour le service doivent être conservées selon les périodes de conservation même après une résiliation de plus de 11 ou même 35 ans, Swisscom ou un successeur désigné doit établir un système d'archivage pour cela, afin que ces informations puissent également être utilisées dans les négociations juridiques . Les identifications fournies ne peuvent plus être utilisées avec un éventuel successeur, c'est-à-dire que de nouvelles inscriptions sont nécessaires dans ce cas.

Les signatures électroniques peuvent être présentées comme preuve dans le cadre d'un litige. En règle générale, à l'exception de la signature qualifiée, ils sont soumis à l'appréciation libre des preuves. Les signatures électroniques « simples » et « avancées » étant à peine ou seulement grossièrement définies par la loi, il appartient au tribunal d'accepter ou non une telle signature. La partie qui souhaite présenter ces signatures comme valables doit fournir les preuves pertinentes. Dans le cas de Swisscom, il est utile que les signatures avancées soient également soumises à un audit très strict selon la norme ETSI pour les signatures « NCP+ » et que de tels rapports d'audit puissent donc être utilisés. Dans le cas d'une signature qualifiée, le renversement de preuve s'applique. Étant donné que la signature qualifiée est précisément déterminée par la loi et que, par exemple, la Suisse et l'Autriche proposent des validateurs pour la validité de ces signatures sur le Web, ces signatures sont considérées comme valables jusqu'à ce qu'une partie prouve le contraire et prouve ainsi que l'autorité de surveillance ou l'OFCOM ainsi que les commissaires aux comptes n'ont pas respecté leurs obligations. Après 11 ans en Suisse ou 35 ans en Autriche, la preuve peut également poser des difficultés dans le domaine qualifié, car les documents d'enregistrement doivent être détruits. Néanmoins, la signature est toujours visible comme « qualifiée ».

Dans le cadre d'une preuve après de nombreuses années, il convient également de noter que les documents archivés électroniquement doivent être horodatés à plusieurs reprises de temps à autre. Il peut arriver que les algorithmes ne soient plus aussi robustes. Un horodatage scelle le document avec les derniers algorithmes, protégeant l'intégrité du document, y compris les signatures.

Les signatures eIDAS qualifiées ne sont considérées comme « qualifiées » que dans la zone UE (et EEE), et les signatures ZertES/SigE sont également considérées comme qualifiées uniquement dans la juridiction suisse. Cela signifie que lorsqu'un État tiers choisit la loi, ces signatures ne peuvent plus atteindre leur effet « qualifié » ou, le cas échéant, le devenir. même pas reconnu.

Suisse (QES), ZertES :

La CP/CPS prévoit que l'identification et la documentation conservée peuvent être utilisées pendant une durée maximale de 5 ans, plus courte si la période de validité de la carte d'identité/du passeport présenté se termine avant la période de cinq ans ou si la procédure d'identification de la part de l'auditeur n'accorde pas 5 ans.

La durée de conservation prévue à l'article 11.1 de l'ordonnance du SigE/ZertES (journal d'activité) s'applique : « Les prestataires agréés conservent les enregistrements relatifs à leurs activités et les pièces justificatives les concernant pendant onze ans. Swisscom comprend également cette période comme une période de conservation pour les documents soumis dans le processus d'identification, en particulier une copie de l'ID.

Une réserve d'un an a été ajoutée comme « tampon de sécurité » afin d'éviter que les agences RA de Swisscom puissent calculer les 11 années différemment, ce qui signifierait que Swisscom n'aurait plus de documentation dans des cas spécifiques, notamment en application de l'article 17 SigE/ZertES (responsabilité illimitée).

  • En résumé, la durée d'archivage est de 17 ans, ce qui est également indiqué dans les conditions d'utilisation.

Europe, (QES), eIDAS :

Il s'agit de la même justification et dérivation que dans le cas du QES en Suisse, à la différence près qu'en Autriche, la période de conservation légale est de 30 ans. L'article 10.1 de la loi SVG (Signature and Trust Services Act) prévoit :

Droits d'accès et durée de conservation

10. (1) À la demande des tribunaux ou d'autres autorités, un FST qualifié donne accès à la documentation conformément à l'article 24, paragraphe 2, allumé. h eIDAS-VO et sa base de données de certificats.

(2) […].

(3) La documentation est fournie par le TSP qualifié pendant 30 ans, à compter de la date de saisie du certificat qualifié en fin de validité ou, à défaut, 30 ans à compter de la date à laquelle les informations pertinentes sur les données délivrées et reçu par le VDA qualifié dans le cadre de ses activités est encouru.

  • En résumé, la durée d'archivage est de 36 ans, ce qui est également indiqué dans les conditions d'utilisation d'eIDAS.

Signatures avancées (eIDAS, ZertES)

La CP/CPS prévoit que l'identification et la documentation archivée peuvent être utilisées pendant une durée maximale de 5 ans, plus courte si la durée de validité de la carte présentée se termine avant la période de cinq ans ou si la procédure d'identification ne permet pas 5 ans.

Il n'y a pas de délais de conservation légaux dans le domaine AES, car les délais de conservation ne sont pas réglementés par la loi. Cependant, les normes ETSI prévoient une durée de 7 ans. Ces informations sont dérivées de la directive ETSI EN 319 411-01 :

6.4.6 Archivage des dossiers

Les exigences particulières suivantes s'appliquent :

REMARQUE : ETSI TS 101 533-1 [i.13] suggère des dispositions sur la façon de préserver les objets de données numériques.

a) Le FST doit conserver les éléments suivants pendant au moins sept ans après qu'un certificat basé sur ces enregistrements cesse d'être valide :
i) journal de tous les événements relatifs au cycle de vie des clés gérées par l'AC, y compris toutes les paires de clés concernées

généré par l'AC (voir la clause 6.4.5, point g));

ii) la documentation telle qu'identifiée à la clause 6.3.4.

Une réserve d'un an a été ajoutée en tant que «tampon de sécurité» afin d'éviter que les agences Swisscom RA puissent calculer les 11 ans différemment.

  • En résumé, la durée d'archivage est de 13 ans, ce qui est également indiqué dans les conditions d'utilisation d'eIDAS.

Pour les certificats personnels, Swisscom n'émet que des certificats à court terme (certificats dits « one-shot ») qui ont une durée de vie de 10 minutes et ne sont utilisés que pour une seule demande de signature. La probabilité que le certificat ait été compromis pendant ces 10 minutes est pratiquement inexistante. Après cela, le certificat n'est plus valide et ne peut pas être compromis. Grâce à la validation à long terme, les signatures avec ce certificat restent valables et peuvent également être validées pour des périodes de temps après expiration.

Si l'ensemble du CA (c'est-à-dire le certificat racine) du service de certification et de confiance a été compromis, il existe un processus que Swisscom décrit dans son CP/CPS (voir Downloads Area – Repository).

Si un signataire perd son support d'authentification ou découvre que son identité a été mal déterminée, notre équipe d'assistance doit en être informée immédiatement. Dans une relation contractuelle avec l'un de nos partenaires, veuillez contacter le partenaire avec lequel vous avez fourni votre signature ou identification. Il prendra alors des mesures supplémentaires pour bloquer cette identification. Si un certificat de sceau a été compromis, veuillez utiliser les coordonnées fournies sur https://www.swisscom.ch/de/business/enterprise/angebot/security/digital_certificate_service.html#tab-revozierung .

  1. Contrat conclu oralement : Très difficile à prouver (uniquement avec témoin d'autres personnes)
  2. Signé par une signature simple, par exemple une image de signature scannée : même problème. Le processus de génération de cette signature doit être analysé en justice et en raison de la faiblesse de la procédure, le témoin d'autres personnes ou d'autres indices jouera un rôle majeur pour prouver la procuration.
  3. AES : pour la vérification d'une signature valide, les parties doivent à nouveau saisir le tribunal. Le tribunal demandera à un spécialiste d'enquêter sur la signature électronique avancée de Swisscom. Grâce aux audits effectués par Swisscom, le spécialiste peut en bénéficier. Néanmoins l'AES est plus faible que le QES par exemple concernant la manière d'identifier/enregistrer les personnes, le temps d'archivage (seulement 7 ans), et l'authentification à 1 facteur pour la signature contrairement à une authentification à 2 facteurs (donc un mobile volé smartphone pourrait être utilisé pour une signature)
  4. QES : la vérification d'une signature valide peut se faire directement via https://validator.ch ou https://www.signatur.rtr.at/de/vd/Pruefung.html Les parties n'ont pas à saisir la justice en cas de doute. Seulement si quelqu'un doute généralement du service de confiance audité et ce sera une preuve irréfutable …. Les preuves de signature QES et les journaux seront conservés aussi longtemps que prévu pour tous les documents commerciaux et fiscaux du dossier commercial : plus de 10 ans en Suisse et 35 ans dans l'UE.

En raison de la réglementation GDPR et du fait que les filiales ne font pas automatiquement partie d'un accord de traitement des données, nous devons signer avec chaque filiale un contrat d'agence RA supplémentaire.

Nous recommandons l'utilisation de la norme PAdES LTA (voir ETSI TS 103 172) à des fins de validation à long terme. Veuillez trouver plus d'indices ici : https://github.com/SCS-CBU-CED-IAM/AIS/wiki/PAdES-Long-Term-Validation . Les fichiers PDF doivent être conformes à la norme PDF/A.

Dans le cas d'une signature à distance, Swisscom gère vos clés pour les certificats de signature en fiducie. Avec une signature personnelle, les certificats de signature ne sont générés que pour la signature et perdent leur validité après env. 10 minutes. Ainsi, nous évitons la notification d'une compromission du certificat par le signataire, c'est-à-dire qu'un certificat ne peut pas être compromis. La procédure présente plusieurs avantages :

L'utilisateur final n'a pas besoin de contacter Swisscom (par ex. un compte utilisateur pour révoquer des certificats).

Les destinataires de documents signés n'ont pas à traiter de listes de révocation et d'OCSP (contrôle de validité des certificats en ligne).

Les problèmes de sécurité avec les applications qui reposent uniquement sur des mises à jour régulières de la liste de révocation sont évités.

Les requêtes OCSP entraînent des délais pour le destinataire.

De plus, un certificat à court terme fournit toujours une réponse positive – une requête OCSP ne peut jamais fournir qu'une réponse négative.

 

Important, la signature qui a été faite avec le QES est bien entendu toujours valable, quel que soit le certificat.

 

Les certificats de courte durée sont émis sur la base des enregistrements du service d'enregistrement, c'est-à-dire qu'ils sont basés sur une authentification forte. Un certificat à court terme n'est généré que s'il y a authentification (libération) dans la procédure 2FA.

Exemple d'analogie dans l'environnement papier : je signe un contrat avec un stylo à encre. L'encre du stylo est vide après la signature. Le contrat reste bien entendu valable.

 

Lors de la signature avec un QES, les périodes d'archivage des preuves suivantes s'appliquent :

Les durées de conservation des preuves d'identification et du journal d'activité pour les signatures de l'UE en Autriche (où nous sommes accrédités) sont de 35 ans et de 10 ans en Suisse.

Grâce à la norme PAdES B LTA, les signatures peuvent également être validées longtemps après leur expiration sur la base de certificats à court terme.

Les algorithmes de hachage (formation de la somme de contrôle) et de cryptage du hachage suivent les recommandations de la norme ETSI ETSI TS 119 312, qui à son tour suit également les normes NIS. Ces algorithmes ont certaines hypothèses sur des périodes de 1 à 6 ans pendant lesquelles ils sont stables. Cependant, des développements (par exemple le craquage d'algorithmes) peuvent aussi rapidement conduire à des changements ici. Swisscom Trust Services, par exemple, modifie à nouveau sa racine CA pour se conformer aux exigences > 6 ans. Une nouvelle édition du cahier des charges est à nouveau attendue cet automne.

Pour une validation à long terme, il est donc nécessaire de s'assurer régulièrement de l'intégrité sur la base des derniers algorithmes, par exemple l'horodatage annuel de tous les documents ou l'utilisation de solutions d'archivage adaptées. Mot-clé « conservation de la valeur probante » – voir DIN 31647:2015-05.

Selon le règlement eIDAS, les TSP doivent être accrédités au niveau national et respecter les lois, règles et réglementations nationales données par l'organisme de surveillance national dans la mesure où aucun autre règlement à l'échelle de l'UE n'a défini certaines règles, comme les décisions d'application de la Commission européenne. , par exemple, pour les normes ADES ou les niveaux de sécurité de l'eID ou certaines règles du règlement eIDAS lui-même. Ainsi, chaque pays a des normes nationales différentes pour ses PST ; par exemple, en Allemagne, le BSI doit approuver certains aspects, ou en France, l'institut ANSII. Dans certains pays, par exemple, l'identification vidéo est entièrement autorisée. Interdit dans d'autres, et dans les pays tiers, autorisé uniquement avec des certificats à court terme.

Mais le règlement de l'UE eIDAS prévoit que toutes les signatures électroniques qualifiées de tout TSP accrédité au niveau national dans n'importe quel pays de l'UE doivent être acceptées par tous les membres de l'UE. Ainsi, un TSP accrédité en France peut vendre son QES sur la base des règles et réglementations françaises en Allemagne, et un TSP autrichien, comme Swisscom, n'a qu'à suivre les règles et réglementations autrichiennes et peut vendre ses signatures qualifiées dans d'autres pays de l'UE. . La liste de confiance de l'UE est l'ancre standard et confirme qu'une signature qualifiée émise par l'un des TSP qui y sont répertoriés doit être acceptée.

Avec la version 2 du règlement eIDAS, les pays de l'UE essaieront d'harmoniser de plus en plus les parties de l'accréditation, par exemple, la manière de s'inscrire à un service, et ils veulent même créer un portefeuille électronique européen comme base pour de futurs identification pour tout service de confiance.

M | Application Mobile ID et Mobile ID

Vous pouvez trouver une FAQ détaillée sur le site Web Mobile ID pour votre dépannage.

Veuillez consulter la FAQ Mobile ID , où vous trouverez des réponses à de nombreuses questions sur Mobile ID.

N | Docusign Connector

Principales questions

Cette fonctionnalité est désactivée. Veuillez accepter les cookies fonctionnels pour utiliser notre service.

Comment résoudre vous-même les problèmes de signature

Cette fonctionnalité est désactivée. Veuillez accepter les cookies fonctionnels pour utiliser notre service.

Comment accepter les conditions d'utilisation de Signing Service en utilisant Mobile ID

Cette fonctionnalité est désactivée. Veuillez accepter les cookies fonctionnels pour utiliser notre service.

Comment accepter les conditions d'utilisation de Signing Service en utilisant le mot de passe – méthode du code SMS

Cette fonctionnalité est désactivée. Veuillez accepter les cookies fonctionnels pour utiliser notre service.

Comment signer un document avec QES en utilisant Mobile ID

Cette fonctionnalité est désactivée. Veuillez accepter les cookies fonctionnels pour utiliser notre service.

Génération de certificat avec OpenSSL

Cette fonctionnalité est désactivée. Veuillez accepter les cookies fonctionnels pour utiliser notre service.

Qu'est-ce qu'une identité revendiquée

Avons-nous pu vous aider ?

Nous sommes heureux d’avoir pu vous aider.

Il est dommage que nous n’ayons pas encore pu vous apporter la réponse dont vous avez besoin. Notre équipe d’ assistance se fera un plaisir de vous aider.


Nous souhaitons vous fournir dès que possible le contenu d'aide le plus récent dans votre langue. Cette page a été traduite automatiquement et peut contenir des erreurs grammaticales ou des inexactitudes. Vous pouvez visiter la page où nous prenons le contenu original de ici afin d'éviter les malentendus potentiels.

Zoom