Aoo 89-2022 - RC V4

BARID AL-MAGHRIB
REGLEMENT DE CONSULTATION
Appel d’Offres Ouvert
N°89/2022
Relatif à :
Acquisition, mise en service et maintenance d’une

plateforme intégrée des services de confiance
qualifiés pour les transactions électroniques.
(Marché à Tranches Conditionnelles)
Contact :
Direction Achats
Division Achats
Service Achats Fournitures et Équipements
8, rue Dayet Erroumi, Agdal à Rabat
E-mail : z.otmani@poste.ma, l.boumhaoued@poste.ma ;
Sites web: www.marchespublic.gov.ma; www.poste.ma ;
Portail Fournisseurs de BAM : www.barid-suppliers.ma.
BARID AL-MAGHRIB
Direction Achats AOO 89/2022
TABLE DES MATIERES
CAHIER DES PRESIPTIONS SPECIALES ........................................................................................................ 1

ARTICLE 1 : OBJET DU REGLEMENT DE CONSULTATION................................................................ 3
ARTICLE 2 : MAÎTRE D’OUVRAGE ............................................................................................................ 3
ARTICLE 3 : REPARTITION EN LOTS ........................................................................................................ 3
ARTICLE 4 : MONNAIE .................................................................................................................................. 3
ARTICLE 5 : LANGUE ..................................................................................................................................... 3
ARTICLE 6 : CONDITIONS REQUISES DES CONCURRENTS ............................................................... 3
ARTICLE 7 : GROUPEMENTS ....................................................................................................................... 4
ARTICLE 8 : COMPOSITION DU DOSSIER D’APPEL D’OFFRES......................................................... 4
ARTICLE 9 : LISTE DES PIECES JUSTIFIANT LES CAPACITES ET LES QUALITES DES
CONCURRENTS ET PIECES COMPLEMENTAIRES ........................................................ 4
ARTICLE 10 : OFFRE TECHNIQUE ............................................................................................................. 6
ARTICLE 11 : OFFRE FINANCIÈRE ............................................................................................................ 7
ARTICLE 12 : CAUTIONNEMENT PROVISOIRE...................................................................................... 8
ARTICLE 13 : ECHANTILLONS, PROTOTYPES, PROSPECTUS, NOTICES ET AUTRES
DOCUMENTS TECHNIQUES .................................................................................................. 8
ARTICLE 14 : INFORMATION ET DEMANDE D’ÉCLAIRCISSEMENTS ............................................ 8
ARTICLE 15 : RÉUNION D’INFORMATION OU VISITE DES LIEUX ................................................... 8
ARTICLE 16 : MODIFICATIONS DANS LE DOSSIER D’APPEL D’OFFRES ....................................... 8
ARTICLE 17 : OFFRES VARIANTES ............................................................................................................ 9
ARTICLE 18 : PRESENTATION DES DOSSIERS DES CONCURRENTS ............................................... 9
ARTICLE 19 : DEPOT DES PLIS DES CONCURRENTS ........................................................................... 9
ARTICLE 20 : RETRAIT DES PLIS ............................................................................................................. 10
ARTICLE 21 : OUVERTURE, EXAMEN ET EVALUATION DES OFFRES DES CONCURRENTS 10
21.1 : EXAMEN DES DOSSIERS ADMINISTRATIF, TECHNIQUE ET ADDITIF ........................................................... 10
21.2 : ÉVALUATION DES OFFRES TECHNIQUES .............................................................................................................. 10
21.3 : ÉVALUATION DES OFFRES FINANCIÈRES ............................................................................................................. 13
ARTICLE 22 : VALIDITE DES OFFRES ..................................................................................................... 14
ARTICLE 23 : RESULTAT DEFINITIF DE L'APPEL D’OFFRES .......................................................... 14
ANNEXES 15
ANNEXE 1 : CADRE DU CV POUR L’ÉQUIPE DU CONCURRENT ................................................................................ 15
ANNEXE 2 : MODÈLE DU PLAN DE CHARGE .................................................................................................................... 16
ANNEXE 3 : TABLEAU DES CONFORMITÉS ........................................................................................................................ 17
Acquisition, mise en service et maintenance d’une plateforme intégrée des services de confiance qualifiés pour les transactions électroniques.
Règlement de consultation 2
BARID AL-MAGHRIB
ARTICLE 1 : OBJET DU REGLEMENT DE CONSULTATION

Le présent règlement de consultation concerne l’appel d’offres ouvert n°89/2022 ayant pour objet
l’acquisition, la mise en service et la maintenance d’une plateforme intégrée des services de confiance
qualifiés pour les transactions électroniques :
- Tranche ferme : Acquisition et mise en service d’une plateforme intégrée des services de
confiance qualifiés pour les transactions électroniques ;
- Tranche conditionnelle n°1 : Mise en conformité selon la loi 43.20 de l’ensemble des services
de confiance objet de la tranche ferme ;
- Tranche conditionnelle n°2 : Mise en œuvre du service de confiance qualifié de validation de
signatures électroniques et des cachets électroniques ;
- Tranche conditionnelle n°3 : Mise en œuvre du service de confiance qualifié de conservation
de signatures électroniques, de cachets électroniques ou de certificats relatifs à ces services ;
- Tranche conditionnelle n°4 : Mise en œuvre des services de signature à la volée ;
- Tranche conditionnelle n°5 : Mise en œuvre des services de signature qualifiée en remote ;
- Tranche conditionnelle n°6 : Maintenance de la plateforme intégrée des services de confiance
qualifiés pour les transactions électroniques objet de la tranche ferme ;
- Tranche conditionnelle n°7 : Maintenance du service de confiance objet de la tranche
conditionnelle n°2 ;
- Tranche conditionnelle n°8 : Maintenance du service de confiance objet de la tranche
conditionnelle n°3 ;
- Tranche conditionnelle n°9 : Maintenance des services de signature à la volée objet de la
tranche conditionnelle n°4 ;
- Tranche conditionnelle n°10 : Maintenance des services de signature qualifiée en remote objet
de la tranche conditionnelle n°5.
Il a été établi en vertu des dispositions du règlement des marchés de BAM du 04/04/2017 relatif aux
conditions et forme de passation des marchés de Barid Al-Maghrib.
ARTICLE 2 : MAÎTRE D’OUVRAGE
Le Maître d’Ouvrage du marché qui sera passé à la suite du présent appel d’offres ouvert est BAM S.A.,
représenté par le Pôle Support.
ARTICLE 3 : REPARTITION EN LOTS
Le présent appel d’offres est lancé en lot unique.
ARTICLE 4 : MONNAIE
Le concurrent non installé au Maroc a la faculté de formuler et d’exprimer ses prix en monnaie
étrangère. Dans ce cas, pour être évaluées et comparées, les montants des offres exprimées en monnaie
étrangère doivent être convertis en dirhams. Cette conversion doit s’effectuer sur la base du cours
vendeur du dirham en vigueur le premier jour ouvrable de la semaine précédant celle du jour
d’ouverture des plis, tel que donné par Bank Al Maghrib.
ARTICLE 5 : LANGUE
Les pièces des dossiers et des offres doivent être établies en langue française.
ARTICLE 6 : CONDITIONS REQUISES DES CONCURRENTS
Conformément aux dispositions de l’article 24 du règlement des marchés de BAM précité :
1- Seules peuvent participer au présent appel d’offres les personnes physiques ou morales qui :
BARID AL-MAGHRIB
▪ justifient des capacités juridiques, techniques et financières requises ;

▪ sont en situation fiscale régulière, pour avoir souscrit leurs déclarations et réglé les sommes
exigibles dûment définitives ou, à défaut de règlement, constitué des garanties jugées
suffisantes par le comptable chargé du recouvrement ;
▪ sont affiliées à la Caisse Nationale de Sécurité Sociale (CNSS) ou à un régime particulier de
prévoyance sociale, et souscrivent de manière régulière leurs déclarations de salaires et sont en
situation régulière auprès de ces organismes.
2- Ne sont pas admises à participer à la présente consultation :
▪ les personnes en liquidation judiciaire ;
▪ les personnes en redressement judiciaire, sauf autorisation spéciale délivrée par l’autorité
judiciaire compétente ;
▪ les personnes ayant fait l’objet d’une exclusion temporaire ou définitive prononcée dans les
conditions fixées à l’article 142 du règlement des marchés de BAM précité ;
▪ les personnes qui représentent plus d’un concurrent dans une même procédure de passation des
marchés.
ARTICLE 7 : GROUPEMENTS
Les propositions effectuées en groupement devront se conformer aux exigences de l’article 140 du
règlement des marchés de BAM concernant, notamment, la justification des capacités juridiques,
techniques et financières requises pour chaque membre du groupement, les cautionnements à constituer
et, le cas échéant, les certificats de qualification et/ou de classification à présenter.
ARTICLE 8 : COMPOSITION DU DOSSIER D’APPEL D’OFFRES
Conformément aux dispositions du §1 de l’article 19 du règlement des marchés de BAM précité, le
dossier d’appel d’offres comprend :
- Une copie de l’avis d’appel à la concurrence ;
- Un exemplaire du Cahier des Prescriptions Spéciales (CPS) comprenant le bordereau des prix -
détail estimatif ;
- Le modèle de l’acte d’engagement prévu à l’article 27 du règlement des marchés ;
- Le modèle de la déclaration sur l’honneur ;
- Le présent Règlement de Consultation (RC).
ARTICLE 9 : LISTE DES PIECES JUSTIFIANT LES CAPACITES ET LES QUALITES DES
CONCURRENTS ET PIECES COMPLEMENTAIRES
Conformément aux dispositions de l’article 25 du règlement des marchés de BAM précité, les pièces à
fournir par les concurrents sont :
1- Un dossier administratif comprenant :
A. Pour chaque concurrent, au moment de la présentation des offres :
a) La déclaration sur l'honneur, en un exemplaire unique, qui doit comporter les mentions
prévues à l’article 26 du règlement des marchés de BAM précité ;
b) L’original du récépissé du cautionnement provisoire ou l'attestation de la caution personnelle
et solidaire en tenant lieu, le cas échéant ;
c) Pour les groupements, une copie légalisée de la convention constitutive du groupement
prévue à l’article 140 du règlement des marchés de BAM précité.
d) Lorsque le concurrent est un établissement public, il doit fournir une copie du texte
l’habilitant à exécuter les prestations objet du marché
B. Pour le concurrent auquel il est envisagé d’attribuer le marché, dans les conditions fixées à
l’article 40 du règlement des marchés de BAM :
BARID AL-MAGHRIB
a) la ou les pièces justifiant les pouvoirs conférés à la personne agissant au nom du concurrent.
Ces pièces varient selon la forme juridique du concurrent :
- s’il s’agit d’une personne physique agissant pour son propre compte, aucune pièce n’est exigée ;
- s’il s’agit d’un représentant, celui-ci doit présenter :
▪ Une copie conforme de la procuration légalisée lorsqu'il agit au nom d'une personne
physique ;
▪ Un extrait des statuts de la société et/ou le procès-verbal de l'organe compétent lui
donnant pouvoir selon la forme juridique de la société, lorsqu'il agit au nom d'une
personne morale ;
▪ L’acte par lequel la personne habilitée délègue son pouvoir à une tierce personne, le cas
échéant.
b) une attestation ou sa copie certifiée conforme à l’originale délivrée depuis moins d'un an par
l'Administration compétente du lieu d'imposition certifiant que le concurrent est en situation
fiscale régulière ou à défaut de paiement qu'il a constitué les garanties prévues à l'article 24 du
règlement des marchés de BAM précité. Cette attestation doit mentionner l'activité au titre de
laquelle le concurrent est imposé ;
c) une attestation ou sa copie certifiée conforme à l’originale délivrée depuis moins d'un an par la
CNSS certifiant que le concurrent est en situation régulière envers cet organisme conformément
aux dispositions prévues à cet effet à l'article 24 du règlement des marchés de BAM ou de la
décision du ministre chargé de l’emploi ou sa copie certifiée conforme à l’originale, prévue
par le dahir portant loi n° 1-72-184 du 15 joumada II 1392 (27 juillet 1972) relatif au régime
de sécurité sociale assortie de l’attestation de l’organisme de prévoyance sociale auquel le
concurrent est affilié et certifiant qu’il est en situation régulière vis-à-vis dudit organisme ;
La date de production des pièces prévues aux b) et c) ci-dessus sert de base pour l’appréciation
de leur validité.
d) le certificat d’immatriculation au registre de commerce (original ou copie certifiée conforme)
pour les personnes assujetties à l’obligation d’immatriculation conformément à la législation
en vigueur.
Toutefois, les concurrents non installés au Maroc sont tenus de fournir l’équivalent des attestations
visées aux paragraphes b, c et d ci-dessus, délivrées par les administrations ou les organismes
compétents de leurs pays d’origine ou de provenance.
A défaut de la délivrance de tels documents par les administrations ou les organismes compétents de
leur pays d’origine ou de provenance, lesdites attestations peuvent être remplacées par une déclaration
faite par l’intéressé devant une autorité judiciaire ou administrative, un notaire ou un organisme
professionnel qualifié du pays d’origine ou de provenance.
2- Un dossier technique comprenant :
- Une note indiquant les moyens humains et techniques du concurrent et mentionnant éventuellement,
le lieu, la date, la nature et l’importance des prestations à l’exécution desquelles le concurrent a
participé et la qualité de sa participation ;
- Des attestations ou leurs copies certifiées conformes à l’originale délivrées par les maîtres
d’ouvrage publics ou privés ou par les hommes de l'art sous la direction desquels le concurrent a
exécuté lesdites prestations. Chaque attestation précise notamment la nature des prestations, leur
montant et l’année de réalisation ainsi que le nom et la qualité du signataire et son appréciation ;
3- Un dossier additif comprenant :
- Le CPS signé et cacheté à la dernière page avec la mention manuscrite « lu et accepté » et paraphé
sur toutes les pages ;
- Le présent RC signé et cacheté à la dernière page et paraphé sur toutes les pages ;
- La charte RSE signée par le soumissionnaire (la présente charte est annexée au Cahier des
Prescriptions Spéciales) ;
BARID AL-MAGHRIB
- La Déclaration d’Intégrité signée par le soumissionnaire (ladite déclaration est annexée au Cahier
des Prescriptions Spéciales)
- Attestation de référencement au portail fournisseurs de Barid Al-Maghrib « Barid Suppliers ».
Ladite attestation est téléchargeable depuis le portail via le lien suivant : https://barid-suppliers.ma.
ARTICLE 10 : OFFRE TECHNIQUE
En conformité avec les dispositions de l’article 28 du règlement des marchés de BAM précité, le
soumissionnaire doit déposer une offre technique répondant aux exigences du chapitre n°2 du CPS qui
comprend notamment :
• Attestation des éditeurs/constructeurs de l’ensemble des composants de la solution proposée
autorisant le soumissionnaire à répondre au présent appel d’offres ;
• Attestation de support des éditeurs/constructeurs de l’ensemble des composants de la solution
proposée durant la période de réalisation du projet, la période de garantie et la période de la
maintenance ;
• Engagement du soumissionnaire (ou de tous les membres en cas de groupement) de ne pas se
positionner en tant que QTSP au Maroc au moins pour une durée de cinq années minimums à
partir de la date de la mise en service de la plateforme cible. Dans le cas où la société
soumissionnaire est une filiale d’une société mère, cette dernière doit déposer le même
engagement aussi. Il est à préciser notamment qu’au moment de l’évaluation des offres reçues
des soumissionnaires, le dépôt soit de deux engagements séparés (filiales & Sté Mère) soit le
dépôt d’un seul document mentionnant l’engagement des deux parties (filiales & Sté Mère) est
accepté. Tandis que le commencement de l’exécution du marché issu du présent appel d’offres
est tributaire de la réception des deux engagements séparés (filiales & Sté Mère) ;
• Engagement du soumissionnaire que son offre sera, au minimum, dans le même ordre de
grandeur (en termes de budget et de délai) pour tout autre client qui souhaite se positionner en
tant que prestataire des services de confiances pour les services objet du présent appel d’offres ;
• Les références de l’utilisation de la solution qu’il propose chez des QTSPs agrées selon eIDAS et
qu’ils l’utilisent pour les services de confiance objet du présent appel d’offres, appuyés par les
attestations des éditeurs (au minimum une référence par service) :
o Fourniture des certificats qualifiés pour signature et cachet électronique et pour
l’authentification des sites internet ;
o Fourniture des services d’horodatage qualifié ;
o Fourniture des services qualifié de validation de signature ;
o Fourniture des services de conservation qualifiée des signatures et des cachets
électroniques qualifiés.
• Un mémoire technique incluant une présentation détaillée des choix technologiques, avec
description détaillée des fonctionnalités offertes et de l’architecture technique et indication du
mode d’intégration des données et d’interfaçage avec les SIs de BAM. De plus, ladite
présentation doit particulièrement détailler les points suivants :
o L’architecture technique et fonctionnelle à mettre en place ;
o Pour les ACs :
▪ Pour l’AC racine, le soumissionnaire doit préciser l’architecture et dispositifs de
sécurité (sauvegarde, contrôle d’accès, cérémonies, …) les mieux adapter au
scope du présent projet avec les justificatifs ;
▪ Pour l’AC intermédiaire, le soumissionnaire doit préciser l’architecture et
dispositifs de sécurité (sauvegarde, contrôle d’accès, cérémonies, …) les mieux
adapter au scope du présent projet avec les justificatifs. Il doit aussi préciser s’il
faut avoir un seul AC intermédiaire dans le site de production ou plusieurs ;
▪ Pour les ACs émettrices, le soumissionnaire doit préciser l’architecture et
dispositifs de sécurité (sauvegarde, contrôle d’accès, cérémonies, …) les mieux
adapter au scope du présent projet avec les justificatifs. Il doit aussi préciser le
BARID AL-MAGHRIB
nombre des ACs nécessaires pour la bonne exploitation des services cibles ;
▪ Le soumissionnaire doit proposer aussi dans son offre une solution permettant de
fournir un service de séquestre dans l’état de l’art et en respectant les
spécifications du CPS et les dispositions réglementaires afférentes.
o L’ensemble des CMS supportés par la solution proposée ;
o Le niveau de conformité de la solution proposée (Pour un ou plusieurs services de
confiances) avec des cadres réglementaires internationaux (ex : USA (UETA Act & E-
Sign Act), CHINE (E-signature Law), L’INDE (IT ACT 2000), BRESIL (Medida
provisoria 2.200-2), …), le soumissionnaire peut, le cas échéant, citer quelques
références d’utilisation de sa solution globale ou une partie par un opérateur de service de
confiance à l’international ;
o Le Roadmap des différents matériels/logiciels fournis et qui doivent être récents et à la
pointe de la technologie ;
o Les prérequis techniques pour le fonctionnement de la solution proposée (configuration
matérielle minimales, système d’exploitation, …) en détaillant :
▪ Le besoin en termes d’hébergement de sa solution selon une architecture en HA
High Availability (actif/ actif de préférence) & DR. (/Disaster Recovery) ;
▪ Le besoin en termes d’infrastructure réseaux pour sa solution en respectant les
mesures de la haute disponibilité et de conformité aux référentiels de sécurité et
de la confiance numérique (FW, WAF, ...).
o Les performances détaillées de la solution proposée.
• Tableau des critères obligatoires de la solution proposée dûment servi (Annexe 3) ;
• Tableau des critères complémentaires de la solution proposée dûment servi (Annexe 4) ;
• L’offre de formation, selon les exigences du CPS, en détaillant particulièrement les points
suivants :
o La liste des modules proposés pour chaque formation demandée ;
o Le plan de chaque formation ;
o La durée de chaque formation.
• Une note présentant la démarche proposée, et ce pour toutes les tranches du marché, pour assurer
la réalisation du projet clé en main ainsi que les prestations de services y afférent ;
• Le détail de l'organisation qu'il mettra en place (nombre de personnes, qualifications, …) afin de
remplir ses obligations. Et doit présenter la liste des moyens humains à mobiliser accompagnée
de CV cosignés, selon le cadre donné en Annexe 1, datés et cosignés par les concernés et le
concurrent. L’équipe proposée doit être composée au minimum des profils énoncés au
niveau de l’article 2.8 du CPS ;
• Le plan de charge envisagé par le prestataire pour l’exécution du projet selon les spécifications
du cahier des charges et le cadre donné en Annexe 2 ;
• Un Plan Assurance Qualité (PAQ)
• Les modalités de maintenance selon les exigences du CPS.
L’offre technique doit être accompagnée par un état des pièces qui la constituent.
ARTICLE 11 : OFFRE FINANCIÈRE
En conformité avec les dispositions de l’article 27 du règlement des marchés de BAM précité, l’offre
financière à fournir par les concurrents est composée de :
- L'acte d'engagement dûment rempli, et comportant le relevé d'identité bancaire (RIB), est signé par
le concurrent ou son représentant habilité, sans qu'un même représentant puisse représenter plus
d'un concurrent à la fois pour le même marché ;
- Un bordereau des prix, dûment signé et cacheté établi conformément au cadre défini dans le CPS et
dont les indications doivent être en parfaite concordance avec celles de l’acte d’engagement.
BARID AL-MAGHRIB
L'acte d'engagement et le bordereau des prix unitaires - détail estimatif sont annexés au DCE du
présent appel d’offres.
En cas de groupement conjoint, le groupement doit présenter un acte d’engagement unique qui indique
le montant total du marché et précise la ou les parties des prestations que chaque membre du
groupement conjoint s’engage à réaliser.
En cas de groupement solidaire, le groupement doit présenter un acte d’engagement unique qui indique
le montant total du marché et l’ensemble des prestations que les membres du groupement s’engagent
solidairement à réaliser, étant précisé que cet acte d’engagement peut, le cas échéant, indiquer les
prestations que chaque membre s’engage à réaliser dans le cadre dudit marché.
ARTICLE 12 : CAUTIONNEMENT PROVISOIRE
Le soumissionnaire doit fournir une caution provisoire ou une attestation de caution personnelle et
solidaire dans son dossier administratif. Le montant du cautionnement est défini dans l’avis d’appel à la
concurrence. Il doit être établi par un établissement agréé à cet effet par le Ministère marocain chargé
des finances et ne doit exprimer aucune restriction ou réserve sous peine d’être rejetée par la
Commission d’appel d’offres. De plus, en cas de groupement, le cautionnement doit être constitué selon
les dispositions de l’article 140 - paragraphe C du règlement des marchés de BAM précité.
ARTICLE 13 : ECHANTILLONS, PROTOTYPES, PROSPECTUS, NOTICES ET AUTRES

DOCUMENTS TECHNIQUES
Sans objet.
ARTICLE 14 : INFORMATION ET DEMANDE D’ÉCLAIRCISSEMENTS
L’information et la réponse aux demandes d’éclaircissements des concurrents sont régies par les
dispositions de l’article 22 du règlement des marchés de BAM précité.
Les demandes d’informations et d’éclaircissements doivent être adressées à la Direction Achats par l’un
des moyens suivants :
- Par courrier porté avec accusé de réception ou par lettre recommandée avec accusé de réception à
l’adresse suivante : 8, Rue Dayet Erroumi, Agdal -Rabat ;
- Par courrier électronique à l’adresse mail : z.otmani@poste.ma, l.boumhaoued@poste.ma ;
- Par courrier électronique via le portail « Barid Suppliers » : https://barid-suppliers.ma/ pour les
entreprises déjà inscrites.
ARTICLE 15 : RÉUNION D’INFORMATION OU VISITE DES LIEUX
Pour permettre à l’ensemble des soumissionnaires de prendre connaissance du projet et pouvoir
apprécier la consistance des prestations demandées, une réunion d’information est prévue selon l’article
23 du règlement des marchés de BAM précité. Celle-ci aura lieu en date indiquée dans l’avis d’appel
d’offres.
La participation à cette réunion d’information est facultative.
Un procès-verbal, dressé par Barid al Maghrib et mentionnant les demandes d’éclaircissement et les
réponses formulées lors de cette réunion, sera communiqué à l’ensemble des concurrents ayant retirés le
dossier de l’Appel d’Offres.
ARTICLE 16 : MODIFICATIONS DANS LE DOSSIER D’APPEL D’OFFRES
Conformément aux dispositions du §7 de l’article 19 du règlement des marchés de BAM précité, des
modifications peuvent être introduites dans le dossier d’appel d’offres.
Les modifications ne peuvent en aucun cas changer l’objet de l’appel d’offres.
Si des modifications sont introduites dans le dossier d’appel d’offres, elles seront communiquées à tous
les concurrents ayant retiré ledit dossier et introduites dans les dossiers mis à la disposition des autres
concurrents.
BARID AL-MAGHRIB
Lorsque les modifications nécessitent la publication d’un avis modificatif, celui-ci sera publié
conformément aux dispositions du §I-2 de l’article 20 du règlement des marchés de BAM précité.
Ces modifications peuvent intervenir à tout moment à l’intérieur du délai initial de publicité de l’avis
d’appel d’offres sous réserve que la séance d’ouverture des plis ne soit tenue que dans un délai
minimum de dix (10) jours à compter du lendemain de la date de la dernière publication de l’avis
rectificatif au portail des marchés publics et dans le journal paru le deuxième, sans que la date de la
nouvelle séance ne soit antérieure à celle prévue par l’avis de publicité initial.
ARTICLE 17 : OFFRES VARIANTES
La présentation d’offres variantes par rapport à la solution de base prévue par le CPS n’est pas autorisée.
ARTICLE 18 : PRESENTATION DES DOSSIERS DES CONCURRENTS
L’ensemble des éléments de l’offre de chaque concurrent est mis dans un pli fermé portant :
- Le nom et l’adresse du concurrent ;
- L'objet du marché et, éventuellement, l'indication du ou des lots en cas de marché alloti ;
- La date et l’heure de la séance d’ouverture des plis ;
- L’avertissement que « le pli ne doit être ouvert que par le président de la commission d’appel
d’offres lors de la séance publique d’ouverture des plis ».
Ce pli doit contenir les enveloppes comprenant ce qui suit :
1. La première enveloppe : elle contient le dossier administratif, le dossier technique et le dossier
additif constitués conformément à l’article 9 du présent RC. Cette enveloppe doit être cachetée et
porter de façon apparente, outre les indications portées sur le pli, la mention « dossiers
administratif, technique et additif ».
2. La deuxième enveloppe : elle contient l’offre technique du soumissionnaire constituée
conformément à l’article 10 du présent RC. Cette enveloppe doit être cachetée et porter de façon
apparente, outre les indications portées sur le pli, la mention « offre technique ».
3. La troisième enveloppe : elle contient l'offre financière constituée conformément à l’article 11 du
présent RC. Elle doit être cachetée et porter de façon apparente, outre les indications portées sur le
pli, la mention « offre financière ».
ARTICLE 19 : DEPOT DES PLIS DES CONCURRENTS
Conformément aux dispositions de l’article 31 du règlement des marchés de BAM précité, les plis sont
au choix des concurrents :
- soit déposés, contre récépissé auprès de la Direction Achats de BAM ;
- soit envoyés par courrier recommandé avec accusé de réception à la Direction précitée ;
- soit remis, séance tenante, au président de la commission d’appel d’offres au début de la séance et
avant l’ouverture des plis.
- soit déposés électroniquement au niveau du portail des marchés publics
(www.marchespublics.gov.ma) selon les conditions d’utilisation dudit portail.
Le délai pour la réception des plis expire à la date et l’heure fixées par l’avis d’appel d’offres pour la
séance d’examen des offres. Les plis déposés ou reçus postérieurement au jour et à l’heure fixés ne sont
pas admis.
A leur réception, les plis sont enregistrés par le Maître d’Ouvrage dans leur ordre d’arrivée, sur un
registre spécial. Le numéro d’enregistrement ainsi que la date et l’heure d’arrivée sont portées sur le pli
remis.
Les plis resteront cachetés et tenus en lieu sûr jusqu’à leur ouverture dans les conditions prévues à
l’article 36 du règlement des marchés de BAM précité.
BARID AL-MAGHRIB
ARTICLE 20 : RETRAIT DES PLIS

Conformément aux dispositions de l’article 32 du règlement des marchés de BAM précité, tout pli
déposé ou reçu peut être retiré antérieurement au jour et à l’heure fixée pour l’ouverture des plis.
Le retrait du pli fait l’objet d’une demande écrite par le concurrent ou son représentant dûment habilité
adressée au maître d’ouvrage. La date et l’heure du retrait sont enregistrées par le Maître d’Ouvrage
dans le même registre spécial visé à l’article 19 du règlement des marchés de BAM précité.
Les concurrents ayant retiré leurs plis peuvent présenter de nouveaux plis dans les conditions de dépôt
des plis fixées à l’article 31 du règlement des marchés de BAM précité.
ARTICLE 21 : OUVERTURE, EXAMEN ET EVALUATION DES OFFRES DES
CONCURRENTS
L’ouverture, l’examen et l’évaluation des offres des concurrents s’effectuent conformément aux
dispositions prévues dans les articles 36, 37, 38, 39 et 40 du règlement des marchés de BAM précité.
21.1 : EXAMEN DES DOSSIERS ADMINISTRATIF, TECHNIQUE ET ADDITIF
L’examen des dossiers administratif, technique et additif tend à :
- S’assurer de leur conformité au présent Règlement de Consultation et aux dispositions du règlement
des marchés précité ;
- S’assurer de leur référencement et préqualification au portail Barid Supplier de Barid Al Maghrib
(https://barid-suppliers.ma/) ;
- Apprécier la capacité des concurrents à répondre aux stipulations du CPS. Pour ce faire, la
Commission d’appel d’offres prendra en considération leur expérience dans les prestations de même
nature.
Pour être admissible techniquement, un concurrent doit présenter, au minimum, une (01)
attestation de référence valide dont le montant est supérieur ou égal à 5 000 000,00 DH/TTC dans
le domaine de la mise en œuvre des services de confiance similaires à ceux demandés au niveau du
présent appel d’offres.
Au terme de cet examen, la commission d’appel d’offres aboutie, pour chaque offre reçue d’un
concurrent, à l’une des conclusions suivantes :
- Admission du concurrent (sans réserve) ;
- Admission du concurrent sous réserve de l'introduction des rectifications nécessaires des erreurs
matérielles ou des discordances dans les pièces du dossier administratif, et ce dans les conditions
prévues dans l'article 40 du règlement des marchés précité ;
- Élimination du concurrent non retenu.
21.2 : ÉVALUATION DES OFFRES TECHNIQUES
- Étape 1 : Examen des critères obligatoires :
L'examen des offres techniques concerne les seuls concurrents admis à l'issue de l'examen des pièces du
dossier administratif, du dossier technique et du dossier additif. À ce propos, si un concurrent ne fournit
pas, dans son offre technique et, le cas échéant, après demande de précisions, les éléments suffisants
pour apprécier un ou plusieurs critères ou sous-critères, son offre sera automatiquement éliminée.
En outre, seules les offres techniques des concurrents satisfaisant les critères obligatoires, énoncés à
l’article 10 du présent règlement de consultation, seront retenus pour cette étape.
- Étape 2 : Notation des offres techniques :
L’étape de notation des offres techniques concerne les seuls concurrents admis à l'issue de l’étape n°1.
BARID AL-MAGHRIB
TRES IMPORTANT
- Seules les offres conformes aux spécifications du CPS et ayant obtenu une note technique égale
ou supérieure à 70 points seront retenues pour l’évaluation financière.
- Une offre technique non conforme aux spécifications du CPS ou obtenant une note strictement
inférieure à 70 points entraîne l’élimination de l’offre du concurrent.
En outre, le système de notation des offres techniques est comme suit :
Sous-critère Barème
10 points au maximum alloués, comme indiqué ci-après, selon la qualité et la pertinence des
éléments fournis dans l’offre technique du soumissionnaire :
- 10 points si les éléments fournis montrent une bonne compréhension du contexte, des
Compréhension du attentes et des besoins de BAM à travers l’intégration et l’enrichissement, sur la base du
contexte, des retour d’expérience du concurrent, des éléments formulés dans le dossier d’appel d’offres.
attentes et des
- 5 points si les éléments fournis consistent en une simple reprise des éléments du dossier
besoins de BAM
d’appel d’offres, sans apport particulier.
(10 points)
- 0 point si aucun élément n’est fourni par le concurrent au sujet du contexte, des attentes et
des besoins de BAM ou si les éléments fournis montrent des lacunes dans leur
compréhension.
10 points au maximum alloués, comme indiqué ci-après, selon la qualité et la pertinence des
éléments fournis dans l’offre technique du soumissionnaire :
- 10 points si la démarche de mise en place est détaillée (phases, étapes, livrables, délais de
Démarche de mise
réalisation, …) et qu’elle est pertinente.
en place de la
- 5 points si la démarche de mise en place n’est pas détaillée ou manque de pertinence sur
solution (10 points)
certains volets.
- 0 point si la démarche de mise en place n’est pas fournie ou manque totalement de
pertinence.
5 points au maximum alloués comme suit :
- 5 points si un planning est fourni et que celui-ci couvre en détail les phases de réalisation,
indique les charges et les livrables, qu’il est cohérent et qu’il met en avant le chemin
Planification critique.
- 2.5 points si un planning est fourni, qu’il est cohérent et détaille les phases de réalisation,
(5 points) mais qu’il n’indique pas les charges et les livrables et/ou ne met pas en avant le chemin
critique.
- 0 point s’il n’y a pas de planning fourni ou que celui fourni ne détaille pas les phases et/ou
comporte des incohérences
Disponibilité des exigences techniques complémentaires mentionnées au niveau de l’Annexe
n°4 :
▪ 30 points si solution répond à la totalité des exigences techniques complémentaires ;
▪ 0,5 point sera soustrait pour chaque exigence technique complémentaire non
Qualité technique disponible.
de la solution Les références de l’utilisation de la solution qu’il propose chez des QTSPs agrées selon eIDAS
proposée et qu’ils l’utilisent pour les services de confiance objet du présent appel d’offres, appuyés par
(40 points) les attestations des éditeurs (au minimum une référence par service) :
▪ Trois références par service auprès de QTSPs et plus : 10 points
▪ Deux références per service auprès de QTSPs : 4 points
▪ Une seule référence par service : 0 point
BARID AL-MAGHRIB
5 points au maximum alloués selon la pertinence de planning de formation, y inclus les
formations officielles de l’éditeur pour les solutions proposées :
▪ 5 points si le plan et le contenu des actions de formation sont particulièrement
Formation des pertinents
équipes de BAM (5
▪ 2.5 points si le plan et le contenu des actions de formation sont moyennement
points)
pertinents
▪ 0 point si le plan et/ou de contenu des actions de formation sont faiblement pertinents.
Chef de projet (5 points) :

5 points au maximum alloués, comme indiqué ci-après, sur la base du CV :
- Niveau de formation : Bac+5 dans un domaine technique ou de gestion.
- Qualification du Chef de projet :
▪ Nombre d’années d’expérience en tant que Chef de projet dans le domaine IT :
0,5 point par année additionnelle à 10 ans d’expérience dans ce domaine, avec un
maximum de 2 points.
▪ Exercice de la fonction de Chef de projet dans le domaine objet du présent appel
d’offres : 0,5 point à partir du 3ème projet avec un maximum de 3 points.
Expert technique PKI (5 points) :
- Niveau de formation : Bac+5 dans le domaine informatique.
Formation de base - Qualification de l’Expert :
et qualification de ▪ Nombre d’années d’expérience en tant qu’Expert technique PKI : 0,5 point par année
l’équipe projet additionnelle à 6 ans d’expérience dans ce domaine, avec un maximum de 2 points ;
▪ Projets PKI réalisés : 0,5 point à partir du 6ème projet avec un maximum de 3 points.
(30 points)
N.B : Si le prestataire propose plusieurs Expert technique PKI, la note finale à attribuer à ce
profil est la moyenne des notes données à chacun des Experts retenus.
Expert fonctionnel PKI (5 points) :

- Qualification de l’Expert :
▪ Nombre d’années d’expérience en tant qu’Expert fonctionnel : 0,5 point par année
additionnelle à 6 ans d’expérience dans ce domaine, avec un maximum de 2 points ;
▪ Projets PKI réalisés : 0,5 point à partir du 6ème projet avec un maximum de 3 points.
N.B : Si le prestataire propose plusieurs Expert fonctionnel PKI, la note finale à attribuer à ce
profil est la moyenne des notes données à chacun des Experts retenus.
BARID AL-MAGHRIB
Expert technique Signature électronique & Workflow de signature (5 points) :
- Qualification de l’Expert technique :
▪ Nombre d’années d’expérience en tant qu’Expert technique Signature électronique &
Workflow de signature : 0,5 point par année additionnelle à 6 ans d’expérience dans
ce domaine avec un maximum de 2 points.
▪ Projets d’implémentation des solutions de signatures/eParapheur réalisés : 0,5 point à
partir du 6ème projet avec un maximum de 3 points.
N.B : Si le prestataire propose plusieurs Experts techniques en Signature électronique &
Workflow de signature, la note finale à attribuer aux Experts techniques est la moyenne des
notes données à chacun des profils retenus.
Expert fonctionnel Signature électronique & Workflow de signature (5 points) :
- Qualification de l’Expert fonctionnel :
▪ Nombre d’années d’expérience en tant qu’Expert fonctionnel en Signature
électronique & Workflow de signature : 0,5 point par année additionnelle à 6 ans
d’expérience avec un maximum de 2 points.
▪ Projets d’implémentation des solutions de signatures/eParapheur réalisés : 0,5 point à
partir du 6ème projet avec un maximum de 3 points.
N.B : Si le prestataire propose plusieurs Experts fonctionnels en Signature électronique &

Workflow de signature, la note finale à attribuer aux Experts techniques est la moyenne des
notes données à chacun des profils retenus.
Expert dans la rédaction et la mise à niveau des procédures afférentes au scope de ce
projet (5 points) :
- Qualification de l’Expert :
▪ Nombre d’années d’expérience en tant qu’Expert dans la rédaction et la mise à
niveaux des procédures dans le domaine IT : 0,5 point par année additionnelle à 6 ans
d’expérience avec un maximum de 2 points.
▪ Projets de mise en place de procédures réalisés dans le domaine objet du présent
marché : 0,5 point à partir du 6ème projet avec un maximum de 3 points.
N.B : Si le prestataire propose plusieurs Experts dans la rédaction des procédures, la note
finale à attribuer aux Experts est la moyenne des notes données à chacun des profils retenus.
21.3 : ÉVALUATION DES OFFRES FINANCIÈRES

Ne sont prises en compte pour l’évaluation des offres financières que les concurrents retenus à l’issue
de l’évaluation des offres techniques.
L’évaluation des offres financières se fera en dirhams. Les coûts en monnaie étrangère cités par les
concurrents seront convertis en Dirhams conformément à l’article 4 ci-avant.
Sous réserve d’application des dispositions régissant les offres anormalement basses ou excessives et
de satisfaction des observations formulées dans la lettre d’invitation et, notamment, la production,
BARID AL-MAGHRIB
dans le délai et selon la forme définie, des pièces exigées en complément du dossier administratif, l’offre
la moins-disante sera retenue.
ARTICLE 22 : VALIDITE DES OFFRES
Il sera fait application des dispositions des articles 33 et 136 du règlement des marchés de BAM précité.
Les concurrents restent engagés par leurs offres pendant un délai de soixante-quinze (75) jours, à
compter de la date de la séance d'ouverture des plis.
Si pendant ce délai, le choix de l’attributaire n’est pas arrêté, le maître d’ouvrage peut saisir les
concurrents, avant l'expiration de ce délai par lettre recommandée avec accusé de réception, par fax
confirmé ou par tout autre moyen de communication écrit pouvant donner date certaine, et leur proposer
une prorogation pour un nouveau délai qu’il fixe.
Seuls les concurrents ayant donné leur accord par lettre recommandée avec accusé de réception, par fax
confirmé ou par tout autre moyen de communication écrit pouvant donner date certaine, avant la date
limite fixée par ce dernier, restent engagés pendant ce nouveau délai.
ARTICLE 23 : RESULTAT DEFINITIF DE L'APPEL D’OFFRES
A/ BAM n'est pas tenu de donner suite au présent appel d’offres.
B/ Le marché devant résulter du présent appel d’offres n’est valable et définitif qu'après son approbation
par l’Autorité Compétente de BAM et à la suite de la notification de cette approbation.
C/ Aucun soumissionnaire ne peut prétendre à une indemnité, si son offre n’est pas acceptée ou s'il n'est
pas donné suite à l’appel d’offres.
Dressé par Signé au nom du Maître d’Ouvrage
Lu et approuvé par le soumissionnaire

(Date, nom, qualité et visa, avec la mention manuscrite ‘lu et approuvé’)
BARID AL-MAGHRIB
ANNEXES
ANNEXE 1 : CADRE DU CV POUR L’ÉQUIPE DU CONCURRENT
Rôle proposé dans le Marché :
1. Nom de famille :
2. Prénom (s) :
3. Diplômes et certifications :
Période Niveau
Institution Titre (s) ou Diplôme (s) obtenu (s) correspondant
(date à date) (Bac+…)
4. Connaissances linguistiques : Indiquer les connaissances sur une échelle de 1 à 5.

(1 : niveau excellent - 5 : niveau rudimentaire)
Langue Lu Parlé Ecrit
5. Qualifications principales :(pertinentes par rapport au rôle attribué au Marché)

6.Autres compétences :(par exemple, connaissances informatiques, etc.)
7.Situation présente :
8. Année d’ancienneté auprès de l’employeur :
9. Expérience professionnelle :
Période (date à date) Lieu Entreprise Fonction Description
10. Projet(s) similaire réalisé(s) :

Intitulé de la Rôle dans le
Période (date à date) Client Principales réalisations
mission projet
11. Autres informations utiles (par exemple, publications) :

Nous soussignons, certifions, par la présente, que les renseignements ci-dessus rendent fidèlement compte de
la situation, des qualités et de l’expérience du concerné.
Signature du concerné Signature du concurrent
BARID AL-MAGHRIB
ANNEXE 2 : MODÈLE DU PLAN DE CHARGE
Désignation, affectation et nombre

d’hommes jours (H/J) de Total en H/J
mobilisation de l’équipe du concurrent
Nom et prénom
N° phase Chef de
Libellé de la phase / … … (*)
/ Étape projet
Étape
1
1.x …. (2*)
2
2.x …. (2*)
3
3.x …. (2*)
4
4.x …. (2*)
(*) : Le cas échéant, à prévoir et à répéter autant de fois selon l’équipe projet proposée
(2*) : A compléter par le soumissionnaire selon la démarche de mise en œuvre proposée
Fait à …………….le…………….
Signature et cachet du soumissionnaire
BARID AL-MAGHRIB
ANNEXE 3 : TABLEAU DES CRITÈRES OBLIGATOIRES (ÉLIMINATOIRES)
Numéro de page au
Réponse du
Brique / Module Normes / Standards Référentiels / Certification niveau de l’offre
soumissionnaire
technique
Exigences générales
applicables pour
ETSI EN 319 401
tous les services de
confiances
Certification EAL4+ selon le profil de protection CEN EN
HSMs
419 221-5
Remote signature CEN EN 419 241-1 & CEN EN 419 241-2
Certification et Horodatage Qualifié
ETSI EN 319 411-1
Autorité de ETSI EN 319 411-2
certification ETSI EN 319 412-1/2/3/4/5 (X.509) pour les profils de
certificat
Autorité ETSI EN 319 421
d’Horodatage ETSI EN 319 422 (RFC 3161)
Services autour de la signature
Création et Validation de signature

Electronic Signatures and Infrastructures (ESI);
Procedures for Creation and Validation of AdES Digital
ETSI EN 319 102 Signatures;
- Part 1: Creation and Validation ;
- Part 2 : Signature Validation Report.
ETSI TR 119 100
The framework for standardization of signatures: overview
ETSI TS 119 101 Policy and security requirements for applications for
signature creation and signature validation
Procedures for Creation and Validation of AdES Digital
ETSI TS 119 102 Signatures :
Part 1 : Signature creation and validation
Part 2 : Signature Validation Report
Validation de signature
ETSI TS 119 441 Policy requirements for TSP providing signature validation
services
ETSI TS 119 442 Protocol profiles for trust service providers providing
AdES digital signature validation services
Format de signature
Norme pour les
ETSI EN 319 132
formats XAdES
Norme pour les
ETSI EN 319 142
formats PAdES
Normes pour les
ETSI EN 319 102 (Pour environnement Mobile)
formats AdES
Remote signature
- TSP service components operating a remote QSCD /
ETSI TS 119 431-1 SCDev
ETSI TS 119 431-2 - TSP service components supporting AdES digital
signature creation
BARID AL-MAGHRIB
ETSI TS 119 432 - Protocols for remote digital signature creation
- Trustworthy Systems Supporting Server Signing - Part 1:
CEN EN 419 241-1 General System Security Requirements
CEN EN 419 241-2 - Trustworthy Systems Supporting Server Signing - Part 2:
Protection profile for QSCD for Server Signing
Conservation de signature
Policy and security requirements for trust service
ETSI TS 119 511 providers providing long-term preservation of
digital signatures or general data using digital
signature techniques
ETSI TS 119 512 Protocols for trust service providers providing long-term
data preservation services
Cryptographie
• Signer Certificates (IETF RFC 5280 [i.9] and IETF RFC
3279 [7]).
• Certificate Revocation Lists (IETF RFC 5280 [i.9] and
IETF RFC 3279 [7]).
• OCSP responses (IETF RFC 6960 [13]).
• Certification Authority Certificates (IETF RFC 5280 [i.9]
and IETF RFC 3279 [7]).
• Self-signed certificates for CA certificates (IETF RFC
ETSI TS 119 312
5280 [i.9] and IETF RFC 3279 [7]).
• Time-Stamping Tokens (TSTs) (IETF RFC 3161 [12]
and ETSI EN 319 422 [i.15]).
• Time-Stamping Unit certificates (IETF RFC 3161 [12]
and ETSI EN 319 422 [i.15]).
• Self-signed certificates for TSU Certificates (IETF RFC
5280 [i.9] and IETF RFC 3279 [7]).
•…
• PKCS#1 RSA Cryptography Standard;
• PKCS#3 Diffie-Hellman Key Agreement Standard ;
• PKCS#5 Password Based Cryptography Standard ;
• PKCS#7 Cryptographic Message Syntax standard ;
• PKCS#8 Private Key Information Syntax standard ;
• PKCS#9 Selected Attribute Types ;
PKCS (Public Key
• PKCS#10 Certification Request Syntax standard ;
Cryptography
Standard) • PKCS#11 Cryptographic Token Interface Standard ;
• PKCS#12 Personal Information Exchange Syntax
standard ;
• PKCS#13 : Elliptic Curve Cryptography Standard ;
• PKCS#15 Cryptographic Token Information Format
Standard ;
• …
BARID AL-MAGHRIB
SPÉCIFICATIONS TECHNIQUES POUR LES SERVICES DE CERTIFICATION :
- Spécifications techniques générales de la solution :

ID Numéro de page
Réponse du
Spécifications techniques au niveau de
soumissionnaire
l’offre technique
Spécifications générales
1. Mise en service d’une solution PKI complète : matériel, logiciel, politiques
(Certification, Horodatage, signatures électronique, …), services professionnels aux
clients …
2. Solution scalable et évolutive.
3. Une solution qui fournit une approche globale de la gestion des risques dans les
transactions numériques en combinant la politique, le cadre juridique, les
opérations et la technologie.
4. La solution est capable d’assurer des services disponibles 24 heures x 365 jours. Si
une maintenance planifiée est requise, la solution doit s'exécuter via l’un des nœuds du
cluster pendant que la maintenance s’exécute sur l’autre nœud.
5. La solution garantit une haute disponibilité pouvant fonctionner en cas de panne
matérielle/logicielle, que ce soitsur le site de production ou celui du backup.
6. La solution fournit un service en haute disponibilité en mode actif-actif à équilibrage de
charge.
7. Capacité du Prestataire à fournir un support/soutien cost-effective pour répondre aux
éventuels besoins futurs debusiness ou de conformité.
8. La solution proposée est reconnue comme un produit phare. Le soumissionnaire doit
également commenter son état selon le dernier rapport/examen PKI publié.
9. La solution doit être conforme globalement tant sur le plan technique que juridique (Loi
43.20, Décrets, …).
10. Pour maximiser le retour sur investissement de BAM, le Prestataire doit
recommander une consolidation des ressources matérielles pour faire fonctionner le
système, sans compromettre sa conformité, sa fiabilité, sa hautedisponibilité et ses
performances.
Opérationnel, Juridique, Normes & Conformité
11. Le type et la force de l'algorithme pour la clé de signature de l'autorité de certification
racine seront configurables et doivent actuellement prendre en charge un minimum de
4096 et 6144 bits, avec la possibilité d'utiliser des forces de clé plus élevées
conformément aux normes approuvées (exemple Cryptographie sur courbes elliptiques
ECC).
12. Le type et la force de l'algorithme pour la clé de signature de la politique, de
l'autorité de certification
subordonnée seront configurables et doivent actuellement prendre en charge un
minimum de RSA 4096 bits et lapossibilité d'utiliser des forces de clé plus élevées
conformément aux normes approuvées.
13. Le type d'algorithme et la force de la clé de signature privée des certificats (utilisateur,
pour cachet serveur, …) doivent être configurables et prendre en charge un minimum
de RSA 2048 bits actuellement et la possibilité d'utiliser des forces de clé plus élevées
14. Le type d'algorithme et la force de la clé de signature du répondeur OCSP seront
configurables et accepterontactuellement un minimum de RSA 2048 bits et la
possibilité d'utiliser des forces de clé plus élevées
15. Le type et la force des algorithmes pour le hachage seront au minimum SHA-2 et seront
adaptés et configurables,avec la possibilité d'utiliser des forces de clé plus élevées
Durée de vie des clés et des certificats
16. Les durées de vie de toutes les clés et certificats doivent être configurables et répondre
aux exigences de durée devie minimale pour un fonctionnement approprié.
17. La durée de vie du certificat pour les nouveaux certificats doit être configurable.
BARID AL-MAGHRIB
Génération et stockage de clés

18. Algorithme de génération de la clé de signature d’AC devrait être conforme au
minimum à ETSI TS 119 312.
19. Les clés de signature des ACs doivent être stockés dans un HSM certifié au minimum
EAL 4+ augmenté par les profils de protection correspondants. Le HSM sera soumis
à des contrôles d'accès pour s'assurer que seul le personnel ayant l'autorité appropriée
peut accéder au module et au contenu.
20. L'AC conservera le contrôle de la clé de signature de l'AC pendant la génération.
Cela se déroulera dans unemplacement physique sécurisé à l'aide de modules
cryptographiques conformes et sera soumis à au moins un
double contrôle.
21. Une seule clé racine CA doit être stockée dans une seule partition HSM/HSM (Au
minimum une seule AC Racine avec son backup).
22. Le système doit être résilient aux défaillances de tout ou partie des composants
individuels.
23. La clé racine hors ligne doit pouvoir être déplacée en toute sécurité d'un endroit à
un autre sur instruction deBarid eSign en cas de besoin et conformément aux
engagements avec l’Autorité Nationale.
Installations d'essais
24. Le Prestataire devra proposer une plateforme PKI de test/préproduction similaire à la
plateforme de production(sans la haute disponibilité) pour ACs, LDAP, HSM, OCSP,
TSA, …
25. BAM doit avoir la possibilité de tester toutes les mises à niveau
logicielles/matérielles avant qu'elles ne soientpromues dans un environnement réel.
26. Le Prestataire guidera BAM sur les impacts opérationnels ou utilisateur de tout
nouveau logiciel et les domainesnécessitant des tests d'acceptation par l'utilisateur
(UAT).
Fiabilité et disponibilité
27. Le système prendra en charge l'automatisation et la gestion des interfaçages avec
d'autres systèmes avec lesquelsil échange des données.
28. Le système devrait avoir une disponibilité de 99,9 % sur une base annuelle.
Performance
29. Le système fournira des performances entièrement évolutives capables de répondre aux
prévisions de volumes d'utilisateurs. La technologie ainsi que la solution fournie
doivent être évolutives pour répondre aux exigences du futur et elles doivent être
suffisamment flexibles pour absorber les nouveaux développements avec un
remplacement minimal de composants.
30. Le système comporte des outils de monitoring et de diagnostic.
31. Les configurations matérielles/logicielles seront évolutives dans un environnement
virtualisé (commel'environnement VMware).
Standards
Algorithmes asymétrique (au minimum)
32. Prise en charge de RSA (2048, 4096, 6144).
33. Prise en charge de DSA (2048, 4096).
34. Prise en charge de ECC (224, 256, 384).
Algorithmes de signature numérique
35. Prise en charge de DSA conformément à la norme de signature numérique, IEEE P1363
et ISO/IEC 14888-3.
36. Prise en charge de ECDSA conformément à ANSI X9.62, IEEE P1363, ISO/IEC 14888-
3.
37. Prise en charge de RSA conformément à la spécification des normes cryptographiques à
clé publique (PKCS)PKCS#1 Version 2.0, IEEE P1363 et ISO/IEC 14888-3.
Fonctions de hachage à sens unique
38. Support au minimum SHA-2.
Algorithmes d'échange de clés
39. Prise en charge de l’échange de clé Elliptic Curve Diffie-Hellman (ECDH) selon
plusieurs normes/standards(exemple : ANSI X9.63, NIST SP 800-56A, …).
40. Prise en charge des dernières versions SSL et TLS.
Techniques d'intégrité symétrique
41. Prise en charge MAC conformément à ANSI X9.19 et autres.
BARID AL-MAGHRIB
- Spécifications techniques des principales composantes de la solution :
Numéro de page
Réponse du
ID Spécifications techniques au niveau de
soumissionnaire
l’offre technique
1. Autorité de certification racine (AC racine)
42. L'autorité de certification racine doit fonctionner sur une architecture dédiée (serveur,
HSM, ...).
43. L'autorité de certification racine doit être maintenue hors ligne.
44. La solution doit prendre en charge plusieurs systèmes d'exploitation (OSs) tels que
Windows, Linux (Redhat, ouautre, …) sous les versions récentes et supportées par leurs
éditeurs respectives.
Le Prestataire s’engage à assurer les migrations, en cas de besoin (Conformité,
Sécurité, …), vers une éventuelleévolution des OSs utilisés.
L'administration de la politique de sécurité doit être cohérente sur toutes les plateformes.
45. La solution doit prendre en charge différentes plates-formes de système d'exploitation.
46. Le certificat de l'autorité de certification racine doit être un certificat X.509 version 3
auto-signé conformément àla RFC 5280 et éventuellement ses mises à jour si c’est
nécessaire.
47. Les clés privées de l'autorité de certification racine doivent être cryptées et prendre
en charge le module desécurité matérielle pour le stockage et l'utilisation de la clé
privée de signature de l'autorité de certification. Le HSM doit avoir au minimum la
validation critères communs EAL4+ Protection Profil. (Une certification selon FIPS
serait un plus souhaité).
48. L'accès à la clé privée de l'AC racine doit nécessiter plusieurs autorisations et des
mesures de sécurité strictes.
49. L'administrateur de l'AC racine ne sera autorisé à exécuter diverses tâches sur le
serveur de l'AC racine qu'aprèsune authentification stricte et l'obtention de plusieurs
autorisations.
50. La clé de l’AC racine doit avoir une longueur de 2048/4096/6144 bits au minimum.
51. Les certificats émis par l'autorité de certification racine doivent être des certificats
X.509 version 3 conformémentà la RFC 5280 et éventuellement ses mises à jour si
c’est nécessaire.
52. Il devrait y avoir des procédures testées en place pour traiter la révocation de la clé de
l'autorité de certificationracine et toutes les actions associées.
2. Autorités de certification intermédiaire (ou de politique)
53. La ou les Autorités de certification de politique (Intermédiaire ou Niveau -1)
doivent s'exécuter sur unearchitecture dédiée.
54. L'AC de politique doit être conservée hors ligne.
55. L'autorité de certification de politique doit avoir la capacité d'émettre des certificats
conformes à la version 3 de
X.509 V3.
56. L'autorité de certification de politique doit prendre en charge toutes les extensions de
certificat X.509 standard.
57. L'autorité de certification de politique doit permettre d'émettre des listes de
révocation de certificats (CRL)conformes à la version 2 de X.509.
58. La solution doit prendre en charge différents systèmes d'exploitation (OSs) tels que
Windows, Linux (Redhat, …)sous les versions récentes et supportées par leurs éditeurs
respectives.
59. L'autorité de certification de politique doit prendre en charge les algorithmes ECC, RSA
et DSA pour la signaturenumérique des certificats.
60. La clé de l'autorité de certification de politique doit avoir une longueur minimale de
2048/4096 bits.
61. L'AC de politique doit prendre en charge l'émission de certificats des ACs
subordonnées.
BARID AL-MAGHRIB
62. L'autorité de certification de politique doit être en mesure de générer et de publier
une liste de révocation decertificats mise à jour dans un référentiel de certificats
immédiatement après la révocation d'un certificat.
63. Les clés privées de l'AC de politique doivent être chiffrées et stockées dans un HSM
qui doit avoir au minimumla validation critères communs EAL4+ augmenté par les
profils de protection correspondants. (Une certification selon FIPS serait un plus).
64. L'administrateur de l'AC de politique ne sera autorisé à exécuter diverses tâches sur le
serveur de l'AC subordonnée qu'après une authentification stricte et l'obtention de
plusieurs autorisations selon les politiques qui seront mises en place.
65. L'accès d’administration de l'autorité de certification de politique doit utiliser un
accès M sur N à clé partagéepour effectuer toutes les opérations cryptographiques.
66. L'AC de politique doit prendre en charge les rôles pour la séparation et la délégation
des fonctions administrativesprivilégiées.
3. Autorité de certification subordonnée (AC subordonnée) - AC émettrice
67. Les CA subordonnées doivent fonctionner sur un matériel dédié conservé dans un
environnement hautementsécurisé.
68. Les AC subordonnées doivent être maintenues en ligne.
69. L'AC subordonnée doit être accessible uniquement par des agents d'AC limités qui
doivent être authentifiés àl'aide de cartes à puce ou de jetons, avec l'application de
plusieurs autorisations et de mesures de sécurité strictes.
70. La base de données de l'autorité de certification émettrice et les autres logiciels requis
doivent être sauvegardés demanière sécurisée et efficace.
71. Le certificat de l’AC émettrice doit être un certificat X.509 version 3 conformément
à la RFC 5280 etéventuellement ses mises à jour si c’est nécessaire signé par la CA
racine.
72. Les clés privées de l'AC subordonnée doivent être chiffrées et stockées dans un HSM
qui doit avoir au minimumla validation critères communs EAL4+ augmenté par les
profils de protection correspondants. (Une certification selon FIPS serait un plus
souhaité).
73. L'administrateur de l'AC subordonnée ne sera autorisé à exécuter diverses tâches sur
le serveur de l'ACsubordonnée qu'après une authentification stricte et l'obtention de
plusieurs autorisations.
74. La clé de CA subordonnée doit avoir une longueur de 2048/4096 bits au minimum.
75. Les ACs émettrices (ou subordonnées) doivent prendre en charge l'émission de
plusieurs types de certificats (parexemple, certificats d'authentification, de signature de
cachet de signature, de chiffrement, d’authentification de
sites web, …).
76. L'AC Subordonnée prendra en charge la génération on-token (sur cartes à puce et clés
USB) et off-token (horscartes à puce et clés USB) des clés privées de déchiffrement de
l'Abonné.
77. Les certificats émis par l'AC subordonnée doivent être des certificats X.509 version 3
conformément à la RFC
5280 (Certificat d'infrastructure à clé publique Internet X.509 et profil CRL) et
éventuellement ses mises à jour sic’est nécessaire.
78. L'AC Subordonnée publiera les certificats de l'Abonné dans le référentiel et mettra à
jour les services devalidation lors de l'émission des certificats.
79. L'AC Subordonnée déclarera les certificats de l'Abonné comme invalides ou révoqués et
mettra à jour les servicesde validation lors de la révocation des certificats.
80. L'AC subordonnée doit supporter la certification des ACs subordonnées (ACs
déléguées) et procéder à lacertification croisée avec d'autres AC.
81. L'AC subordonnée doit prendre en charge la séparation des rôles et appliquer un double
contrôle sur les fonctionsd’administrations sensibles.
82. L'autorité de certification subordonnée doit supporter plusieurs autorités
d'enregistrement et AEDs.
83. L'AC subordonnée doit certifier les clés sur demande uniquement des AEs autorisées.
84. Les opérations de l'autorité de certification subordonnée doivent être limitées par
des politiques définies parl’Autorité Nationale.
85. La solution doit prendre en charge différents systèmes d'exploitation (OSs) tels que
Windows, Linux (Redhat, …)sous les versions récentes et supportées par leurs éditeurs
respectives.
BARID AL-MAGHRIB
4. Autorité d'enregistrement (AE) ou AED

NB. Dans ce paragraphe les exigences pour vont concerner les AEs et/ou les AEDs ou les
deux selon le cas
Généralité
86. Les AEs doivent être certifiées par l'AC correspondante et doivent prendre en
charge la réduction des droitsd'accès pour l'opération conformément à la PC
correspondante.
87. L'AE doit être conçue et mise en œuvre pour prendre en charge l'exécution de
certaines fonctions de gestion du
cycle de vie des clés/certificats, telles que le lancement d'une demande de
révocation/suspension ou une opérationde récupération de clé au nom de l'Abonné.
88. L’AE doit être conçue et mise en œuvre pour garantir que toutes les communications
entre l’AE et les autres composants PKI soient cryptées. Toutes ses communications
seront signées numériquement avec la clé de signature privée de l'AE. Ces demandes
doivent être conformes aux normes afférentes.
89. L'AE doit pouvoir s'exécuter sur différentes plates-formes ou systèmes
d'exploitation, pour permettre ledéploiement sur les différentes AC.
5. Sauvegarde des clés
90. Les clés de signature privées des abonnés ne seront pas sauvegardées.
91. Le service de sauvegarde doit permettre les fonctionnalités suivantes :
• Stocker en toute sécurité les certificats actifs et la clé privée de déchiffrement ;
• Récupérez en toute sécurité les certificats perdus ou corrompus et la clé privée
de déchiffrement.
92. La solution PKI doit garantir que les ACs sauvegardent les certificats actifs et les clés
de déchiffrement dans lecadre du processus d'émission.
6. Les référentiels
93. Les référentiels doivent être utilisés pour rendre les informations PKI disponibles.
Voici des exemplesd'informations PKI à contenir dans les référentiels :
• Certificats numériques des utilisateurs ;
• Les parties de confiance ;
• Les autorités de certification ;
• Listes de révocation de certificats (CRL) ;
• Listes de révocation d'autorité (ARL) ;
• …
BARID AL-MAGHRIB
94. Les référentiels doivent être dans une architecture HA/DR à l’instar de l’ensemble des
composants en ligne.
95. Chaque AC doit disposer d'un référentiel pour ses certificats et CRL générés.
96. Le service d'annuaire hébergeant le référentiel doit être conforme à l'ensemble des
normes d'annuaire LDAP v3pour les services d'annuaire et hébergerait un annuaire
basé sur LDAP.
97. Il doit y avoir deux types de référentiels : Protégé et Public. Les référentiels protégés
ne seront accessibles qu'auxcomposants PKI de BAM, contenant toutes les
informations destinées à un usage public en plus des informations
exclusives destinées à un usage interne.
98. Les référentiels publics seront accessibles par les parties utilisatrices et les abonnés
conformément aux PCs des
ACs émettrices. Ils contiennent une copie des informations destinées à un usage
public et reproduisent lesdonnées avec les référentiels privés correspondants au
moyen d'un shadowing (X500).
99. Pour les exigences de haute disponibilité, de tolérance aux pannes et d'équilibrage
de charge, les serveurs duréférentiel doivent être équilibrés en charge via l'utilisation
d'un équilibreur de charge sensible à la session.
100. Des mesures de sécurité appropriées doivent être activées pour les serveurs de
référentiel, telles que la prise encharge de la communication sécurisée et l'application
des contrôles d'accès.
101. Le référentiel doit prendre en charge la surveillance à distance au niveau de
l'application (par exemple, SYSLOG,SNMP, …).
102. Le référentiel doit permettre d’auditer les actions administratives.
7. Services de validation
103. Le service de validation doit prendre en charge au minimum les éléments suivants :
• CRL (Voir sa liste des conformités ci-dessous) ;
• OCSP (Voir sa liste des conformités ci-dessous).
Certificate Revocation List (CRL)
104. Les CRL doivent être, au minimum, accessibles via des protocoles tels que : LDAP,
LDAPS, HTTPS, HTTP.
105. Les listes de révocation de certificats peuvent résider sur un serveur d'annuaire
distinct ou faire partie d'un serveur de référentiel.
106. La solution doit avoir un mécanisme de gestion des CRLs permettant une
exploitation optimale des CRLs. Ceci
est essentiel pour optimiser l’exploitation et le temps de réponse des services tiers
internes et externe (Exemple :l’OCSP, Adobe, Applications clients, …).
107. Le profil CRL doit être conforme au profil X.509 CRL v2 et aux extensions CRL
X.509 v3 qui sont spécifiées parla RFC 5280 et éventuellement ses mises à jour si
c’est nécessaire.
108. La mise à jour de la liste CRL doit être configurée pour minimiser le délai entre
la révocation effective ducertificat et la publication de la révocation.
109. Les CRL doivent être signées par les ACs correspondantes.
110. La publication manuelle des informations de révocation ainsi que la possibilité
d'automatiser l'émission des CRLdoivent être prises en charge.
111. La mise en cache des CRL avec des vérifications de mise à jour appropriées doit être
prise en charge.
Online Certificate Status Protocol (OCSP)
112. Un répondeur OCSP de confiance doit être utilisé pour traiter les demandes
d'informations de vérification etd'état.
113. Le répondeur OCSP doit répondre aux demandes via le protocole OCSP
conformément à la RFC 6960 etéventuellement ses mises à jour si c’est nécessaire.
114. La validation OCSP mise en œuvre dans la solution PKI doit prendre en charge
la signature numérique desdemandes et/ou réponses OCSP.
115. Les réponses OCSP doivent être signées par la clé de l'un des éléments suivants :
• L'AC qui a émis le certificat en question ;
• Répondeur autorisé par AC qui détient un certificat spécialement marqué
délivré directement par l’AC indiquant que le répondeur est digne de
confiance pour émettre des réponses OCSP pour cette AC.
BARID AL-MAGHRIB
116. Les messages de demande et de réponse OCSP doivent être correctement structurés
et traités conformément à la RFC 6960 et éventuellement ses mises à jour. De
plus, les messages d'erreur doivent être traités efficacement pour éviter les réponses
fictives conformément à la RFC 6960 et éventuellement ses mises à jour si c’est
nécessaire.
117. Les réponses OCSP doivent également contenir des informations appropriées sur
l'horodatage conformément à laRFC 6960 et éventuellement ses mises à jour si c’est
nécessaire.
118. La demande OCSP doit contenir au minimum le nom de l'AC, le numéro de série du
certificat et le numéro de version du protocole et la réponse doit contenir au
minimum les informations d'état du certificat, la période de validité des informations,
l'identifiant du certificat et les informations d'horodatage.
119. Les services OCSP seront protégés contre l'accès par du personnel non autorisé
(exemple : une attaque DDoS,
…).
120. L'OCSP doit avoir la capacité de maintenir des journaux d'audit détaillés qui
enregistrent des informations telles que les demandes de validation, les réponses de
validation, les exceptions ou les erreurs et les actions administratives.
121. L'autorité de validation doit exiger une authentification forte (c'est-à-dire
cryptographique) d'un opérateur avantd'autoriser l'exécution de fonctions privilégiées.
122. Toutes les interfaces basées sur un navigateur dans l'autorité de validation doivent
prendre en charge lesnavigateurs standard actuels, avec la capacité de s'adapter aux
futures technologies de navigateur.
123. L'autorité de validation doit prendre en charge la surveillance à distance au niveau de
l'application (par exempleSNMP, MIB, …).
124. Le répondeur OCSP doit supporter la vérification de statut des certificats en temps
réel (realtime CRL databasechecking).
125. Le répondeur OCSP doit offrir un mécanisme d’authentification forte basé sur les
tokens pour uneadministration sécurisée.
8. Application Program Interfaces (APIs)
126. Des API doivent être fournies avec la solution pour faciliter l’intégration PKI dans
diverses applications.
127. Les API s’intègrent de manière transparente à la solution PKI et aux applications
installées sur le système cible.
128. Les API doivent prendre en charge les standards des services web REST ou SAOP.
9. Services d’horodatage (Time Stamping Services)
129. Les fonctionnalités d’horodatage offertes par le service d’horodatage comprennent
l’horodatage de la date et de
l’heure locales ainsi que l’horodatage de l’heure universelle ou de la différence
entre l’heure locale et l’heureuniverselle.
130. Le service d’horodatage doit être hautement disponible (HA/DR).
131. Les réponses du TSA doivent être signées par le TSA.
132. Le TSA doit utiliser une source de temps digne de confiance (Dans notre cas serait les
serveurs NTP fournis dansle cadre de cet AO).
133. Le TSA doit inclure une valeur temporelle fiable pour chaque jeton d’horodatage.
134. Le TSA doit inclure un entier unique pour chaque jeton d’horodatage nouvellement
généré.
135. Le TSA doit produire un jeton d’horodatage à la réception d’une demande valide du
demandeur.
136. La TSA ne doit horodater qu’une représentation de hachage des données hachées par
une fonction de hachageunidirectionnelle résistante aux collisions et identifiée de
manière unique par un OID.
137. Les opérations TSA doivent être conformes à la RFC 3161.
138. Le service TSA doit offrir nativement un mécanisme d’authentification forte
base sur les tokens pour uneadministration sécurisée.
139. Le service TSA doit supporter la séparation des rôles et permissions.
140. Le service TSA doit supporter le double contrôle pour les opérations critiques.
141. Le service TSA doit supporter l’autoarchivage sécurisé des journaux de la base de
données.
142. Mode d’accès au service d’horodatage possible en http et en https.
143. Possibilité de limiter le nombre des jetons à consommer par un client /application.
BARID AL-MAGHRIB
144. Disposer des reporting des consommations par client par dates et intervalles de temps
exportables en format CSVet PDF.
10. Object Identifiers (OIDs)
145. Les OID doivent être utilisés à partir de l'arc OID alloué par l'autorité
d'enregistrement des OID de BAM (BarideSign).
11. Hardware Security Module (HSM)
146. Les HSMs doivent être connectés aux AC et aux CA de politique/émettrice pour
sécuriser les clés privées de l'AC et les opérations cryptographiques. Ces connexions
doivent être effectuer dans la conformité totale des exigences du régulateur et des
spécifications du présent marché.
147. Les HSM doivent être des entités physiquement séparées qui doivent communiquer
avec les composants PKI demanière sécurisée.
148. Les HSMs proposés doivent permettre au minimum 400 signatures par seconde avec
une clé RSA d’une longueurde 2048 bits.
149. Les HSM doivent utiliser des API conçues spécifiquement pour les opérations
cryptographiques, telles quePKCS#11, CNG, Java JCE et Open SSL.
150. Des mesures strictes de sécurité, d'authenticité et de confidentialité des applications
doivent être prises lors de lacommunication entre les ACs et leurs HSM pour éviter
les vulnérabilités ou qu’ils soient compromis.
151. La génération de la clé privée doit être effectuée exclusivement dans les limites
sécurisées du HSM.
152. Les clés privées doivent être stockées à tout moment dans le HSM pour assurer leur
sécurité et leur intégrité.
153. Les clés privées doivent être sauvegardées directement via les HSM.
154. Toutes les opérations de signature et de chiffrement de certificat par les ACs
doivent être effectuéesexclusivement au sein des HSM.
155. Les HSM doivent fournir les fonctions de répartition de charges « Load balancing
capability » (La synchronisation des clés HSM doit être automatique).
156. Le HSM disposera d’un système d’authentification n parmi m pour les fonctions
de création, suppression et export de clés.
Lorsqu’il est en ligne, l’utilisation de certaines clés pourra être réalisée via une
authentification simple (AC «filles » par exemple).
157. Les clés stockées dans le Hardware Security Module devront pouvoir être
conservées pour une durée minimumde 40 ans.
158. Possibilité d'administrer d'une manière sécurisée les HSM localement ou à distance
incluant le M of N.
159. Une application & interface d’administration graphique et ergonomique doit être
fournie pour administrer lesHSM.
12. Multi-langue
160. La solution doit supporter l’UTF-8.
13. Network Time Servers
161. Plusieurs serveurs de temps doivent être situés dans le centre de données de la PKI.
162. Les serveurs de temps doivent être utilisés doivent fonctionner comme des serveurs
NTP et s'adapter à SNTPconformément à la RFC 5905.
163. L'heure doit être offerte au format UTC.
164. Les formats des messages échangés entre les clients et les serveurs doivent être
conformes à la RFC 5905 pour lacommunication basée sur NTP et à la RFC 5905
pour la communication basée sur SNTP.
14. Logging
165. Le système de journalisation doit prendre en charge la génération de divers
rapports et doit fournir lesinformations nécessaires pour auditer les opérations telles
que décrites dans la RFC 3647.
BARID AL-MAGHRIB
166. Le système de journalisation doit contenir, au minimum, un historique de :

- Provisionnement des comptes administrateur ;
- Provisionnement du compte utilisateur ;
- Abonnés et AC Clés/Certificats Opérations du cycle de vie ;
- Abonnés et AC clés/certificats cycle de vie des opérations autorisations Sauvegarde /
Restauration ;
- Activités des administrateurs, authentification et tentatives de connexion
infructueuses ;
- Tentatives d'accès non autorisées ;
- Opérations de validation ;
- Opérations d'accès aux répertoires/référentiels ;
- Opérations PKI (chiffrement, signature, authentification) ;
- Accès aux clés/certificats à l'aide de la fonction de sauvegarde/archivage
- Accès aux clés/certificats à l'aide de la fonction d'entiercement ;
- Utilisation des clés des ACs ;
- Accès aux clés stockées sur les HSM ou d'autres types de supports ;
- Utilisation des HSM ;
- Opérations de certification croisée ;
- Informations sur la demande de certificat.
Le Prestataire s’engage à inclure d’autres logs si ceci sera exigé par le régulateur ;
Pour les éventuels logs supplémentaires qui peuvent être demandée par BAM, ils
seront discutés et validés encommun accord avec le Prestataire en validant
l’ensemble des modalités (échéances, charge, …).
167. Chaque entrée de journal doit contenir au minimum les éléments suivants :
- Date et heure de l'entrée ;
- Numéro de série ou de séquence de l'entrée ;
- Composant générant l'entrée ;
- Source de l'entrée (utilisateur, port, terminal, etc.) ;
-…
168. . Les journaux d'audit doivent être infalsifiables et cryptés.
16. Intégration
169. La solution proposée doit se composer des logiciels standards et transparents qui
seront facilement interfaçableavec les applications BAM existantes et avec un effort
de développement ou de configuration minimale.
170. Lors de la mise en œuvre/configuration des AC émettrices, elles doivent être
intégrées à l'infrastructureinformatique existante, mais principalement au workflow
https://online.baridesign.ma.
BARID AL-MAGHRIB
SPÉCIFICATIONS TECHNIQUES POUR LES SERVICES AUTOUR DE LA SIGNATURE :
ID Numéro de page au
Réponse du
Spécifications techniques niveau de l’offre
soumissionnaire
technique
17. Exigences de sécurité
171. La solution proposée doit fournir un système d’accès sécurisé basé sur les rôles. Ce
système doit aussi flexible,audité et précis.
172. La solution doit être complétement cloisonnée avec la prise en charge de plusieurs
niveaux d'autorisations pour empêcher les clients, des départements et des
groupes d'utilisateurs distincts d'accéder aux données et aux processus métier des
uns et des autres.
173. Le client doit être en mesure de proposer plusieurs options d'authentification pour
authentifier la ou les personnes distantes qui signent le document. Les options
disponibles doivent inclure l'e-mail, le mot de passe AD, le code PIN, le certificat
numérique, les protocoles d'authentification tiers, le secret partagé, l'authentification
par SMS OTP, la signature numérisée, l'authentification d'identité Web tierce,
l'authentification basée sur les connaissances
et le service de confirmation d'identité tiers (Notamment celui de la DGSN via OpenID
Connect).
174. La modification ou la falsification d'un document signé électroniquement devrait
invalider l'authenticité dudocument et des signatures. Lors de la visualisation d'un
document modifié, il doit être clairement marqué comme
étant invalide.
175. La solution doit s'assurer que les données et les dossiers sont toujours protégés
contre tout accès non autorisé.Cela inclura toute personne qui peut avoir accès aux
systèmes qui stockent ou transportent les données.
176. Toutes les opérations et communications de la solution de signature électronique
doivent respecter les normes desécurité et les meilleures pratiques de l'industrie (Ex.
rfc8446, …). La solution proposée ne devrait pas présenter
de risque de sécurité ou opérationnel pour BAM et ses clients utilisateurs de
plateforme.
18. Exigences de sécurité liées à la nature cloud de la solution
177. Le Prestataire doit, à l’instar de la plateforme PKI, installer la solution de
signature/Workflow de signature dans une architecture HA (actif-actif) / DR (sur site
de backup de BAM). Il doit aussi fournir un plan de reprise après sinistre et de
sécurité de l'information incluant la réplication sur le site de backup.
178. Toutes les informations (données et processus sous-jacents) doivent rester dans les
datacenters de BAM (siteprincipal et backup). Aucune données ou information ne
doit transiter ou être traitée par un module externe.
179. Toutes les données (en transit et au repos) doivent être cryptées selon les normes de
l'industrie.
19. Exigences d'intégration et de compatibilité
180. La solution doit être parfaitement intégrée avec la PKI et le Portail des services de
confiances. Toutes les interactions/interfaçages doivent être conforme en termes de
sécurité et selon les dispositions de la loi 43.20 et les exigences de l’Autorité
Nationale.
181. La solution proposée doit fournir des APIs et doit supporter les standards des services
web pour que BAM puissecréer des fonctionnalités supplémentaires et pour
interfacer la solution avec d’autres systèmes opérants
(Commercial, référentiels de données, …).
182. La solution doit permettre l'exportation de documents signés vers une autre
plateforme dédiée à l’archivage
électronique (légal et/ou à long terme) via des webservices tout en garantissant
l’intégrité, la confidentialité et lasécurité.
183. La solution doit être capable de s’interfacer, à travers des APIs, de s’interfacer avec
les SIs (CRM, …) des clientsde BAM en garantissant l’intégrité, la confidentialité et
la sécurité.
BARID AL-MAGHRIB
184. La solution proposée doit supporter la communication (dans les deux sens) des
informations nécessaires au SI commercial de BAM (gestion des contrats et de
facturation) pour la gestion de la facturation. La solution doit aussi permettre
l’extraction de ces données sur des fichiers standards (EX : XML, csv, json, …). Un
petit module
de gestion de la facturation dans la solution, serait vivement souhaitable.
185. La solution doit supporter le traitement de la signature des documents PDF en
garantissant les caractéristiques etles fonctions suivantes :
- Signatures visibles ;
- Différents niveaux de certification ;
- Demande et intégration de réponses d'horodatage ;
- Demande et intégration de CRLs ;
- Demander et intégrer des réponses OCSP ;
- …
186. Format de signatures
- XML (XMLdSig)
- XAdES (XAdES-BES and XAdES-T)
- PADES
- CMS/PKCS#7
- CMS signing avec support de l’Horodatage ;
- …
20. Exigences techniques et standards
187. La solution proposée doit supporter le relookage de l’image (rebranding).
188. Au-delà de la signature, la solution proposée doit aussi inclure le rôle de quelqu'un qui
doit approuver.
189. La solution proposée doit offrir la possibilité de sauvegarder et réutiliser des scenarios
de workflows.
190. La solution proposée doit offrir la possibilité d’envoyer des messages individuels
destinés à chaque intervenantdans le workflow avec la possibilité d’utilisation des
Templates d’emails au format HTML.
191. La solution proposée doit offrir la possibilité de rajouter un mot de passe à un
document avant son ouverture.
BARID AL-MAGHRIB
ANNEXE 4 : TABLEAU DES CRITÈRES COMPLÉMENTAIRES
SPÉCIFICATIONS TECHNIQUES POUR LES SERVICES DE CERTIFICATION :
- Spécifications techniques générales de la solution :
Numéro de page au
Réponse du
ID Spécifications techniques niveau de l’offre
soumissionnaire
technique
Opérationnel, Juridique, Normes & Conformité
192. L’éditeur possède une politique cryptographique post-quantique.
Génération et stockage de clés
193. Les autorités de certifications sont certifiées EAL 4+
194. Les autorités de certifications sont certifiées selon FIPS niveau 3
195. Les clés de signature des ACs sont stockés dans un HSM certifié selon FIPS niveau
3
Standards
Fonctions de hachage à sens unique
196. Prise en charge des fonctions de hachage SHA-224, SHA-256, SHA-384 et
SHA-512 conformément àplusieurs normes (FIPS 180-2, FIPS 180-3, ANSI
X9.30 Part 2, …).
Algorithmes d'échange de clés
197. Prise en charge de l'authentification SPKM (Simple Public-Key GSS-API
Mechanism) et de l'accord de clé conformément à RFC 2025, ISO/IEC 9798-
3, …
198. Prise en charge du transfert de clé RSA conformément aux RFC 1421 et RFC
1423 (PEM), PKCS#1 Version 2.0 et IEEE P1363.
Techniques d'intégrité symétrique
199. Prise en charge de HMAC conformément à la RFC 2104 et FIPS 198-1, …
Générateur de nombres pseudo-aléatoires
200. Générateur de nombres pseudo-aléatoires conformément à ANSI X9.17 et FIPS 186-
3.
201. Générateur d'aléa déterministe :
Support de plusieurs normes/standards. Exemple (SP800-90A, ISO18031, …).
- Spécifications techniques des principales composantes de la solution :
Numéro de page
Réponse du
soumissionnaire
l’offre technique
1. Autorité de certification racine (AC racine)
202. Prise en charge des SGBDs ci-dessous :
- PostgreSQL
- Microsoft SQL
- Oracle
Le choix de la base de données sera fixé durant les ateliers d’ingénierie.
203. L'AC racine effectue ses opérations conformément à la RFC 4210 et éventuellement
ses mises à jour si c’estnécessaire.
2. Autorités de certification intermédiaire (ou de politique)
204. Prise en charge des SGBDs ci-dessous :
- Postgres
- Microsoft SQL
- Oracle
3. Autorité de certification subordonnée (AC subordonnée) - AC émettrice
BARID AL-MAGHRIB
205. Une AC émettrice prend en charge plusieurs modèles (ex : une paire de clés, deux
paires de clés et troispaires de clés, …).
206. L'AC Subordonnée validera les demandes envoyées par les AEs avant de prendre
des mesures ultérieures (ex.émission de certificats, révocation de certificats). Par
exemple, l'AC s'assure que les demandes ont été envoyées par l’AE et non par
quelqu'un d'autre.
207. L'autorité de certification subordonnée est capable de générer plusieurs types de
certificats sous une seulepolitique et action d'enregistrement.
208. L'autorité de certification subordonnée prend en charge la possibilité de définir
des extensionspersonnalisées de certificat.
209. La solution d'autorité de certification subordonnée prend en charge différentes
plates-formes de système d'exploitation. Les solutions basées sur l’Appliance ne
sont pas préférées étant donné que le client peut utiliser son matériel / système
d'exploitation existant et également pour plus de flexibilité.
210. Prise en charge les bases de données suivantes :
- PostgreSQL
- Microsoft SQL
- Oracle
4. Autorité d'enregistrement (AE) ou AED
NB. Dans ce paragraphe les exigences concernent les AEs et/ou les AEDs ou les deux
selon le cas
Généralité
211. L’AE permet une flexibilité dans les certificats, pour prendre en charge les
extensions de certificat. La solution permet l'inclusion des extensions
personnalisées dans les certificats émis par l'autorité de certification.
212. L'AE dispose d'une flexibilité de création du Common Name (CN) de
certificat. C'est-à-dire à partir
d'informations saisies par l'utilisateur sur un formulaire HTML lors de
l'inscription, ou à partir d'entréescontenues dans un annuaire LDAP.
Gestion des utilisateurs
213. L’autorité d’enregistrement de la solution proposée est dotée d’une interface Web
permettant aux administrateurs de gérer les comptes d'utilisateurs, elle permet aux
administrateurs ayant le rôle et les
autorisations appropriées de créer et de gérer des comptes d'utilisateurs, et de traiter
les demandes des utilisateursfinaux ou d'autres administrateurs.
214. Le processus AE prend en charge plusieurs méthodes d'inscription, notamment :
l'inscription en ligne,l'inscription en masse, l'inscription automatique et l'inscription
en face à face.
215. Les AEs supportent deux options pour l'enregistrement des utilisateurs : la création
par lots et la créationutilisateur par utilisateur.
Gestion des certificats Web et des CSRs
216. L’autorité d’enregistrement de la solution proposée propose un service Web
permettant de soumettre des demandes de certificat, télécharger des certificats et
vérifier l'état des demandes en attente, ainsi que pour vérifier, approuver et traiter
les demandes de certificat en attente.
217. L’autorité d’enregistrement de la solution proposée propose une interface Web
permettant aux administrateurs de soumettre des demandes de certificats, de
télécharger des certificats et de vérifier l'état des
demandes en attente.
218. L’autorité d’enregistrement de la solution proposée fourni un mécanisme pour
automatiser la notificationd'expiration et le renouvellement des certificats.
Notamment pour les certificats des serveurs Web et les serveurs
VPN.
219. L’autorité d’enregistrement de la solution proposée fourni des applications
d'administration basées sur le
Web qui interagissent avec une ou plusieurs AC gérées pour soumettre et traiter
les demandes de signature decertificat.
Service de gestion des dispositifs mobiles (MDM) et équipements réseaux
220. L’autorité d’enregistrement de la solution proposée offre un service Web de
gestion des dispositifs mobiles (MDM), il s’agit d’un service Web qui
BARID AL-MAGHRIB
communique avec un produit de gestion des dispositifs mobiles.
221. L’autorité d’enregistrement de la solution proposée est dotée d’un protocole de

communication PKI qui permet aux périphériques réseau de s'inscrire dans une PKI
et d'obtenir un certificat pour établir des connexions authentifiées sécurisées avec
d'autres composants du réseau. Ce service Web traite les demandes des
périphériques réseau et les soumettre à l'autorité de certification gérée pour
traitement.
Fonctionnalités d’administrations
222. La solution proposée est dotée d’un client capable de faire la gestion du cycle de
vie automatisée desadministrateurs de la plateforme.
Ce client offre des fonctionnalités cryptographiques de chiffrement et signature à
l’administrateur.
223. Le logiciel AE permet aux administrateurs d'effectuer l'auto-enrôlement, l'auto-
récupération et la gestion du cycle de vie de leurs certificats d’une manière
automatisées.
224. L'AE prend en charge la révocation/le renouvellement automatisés des certificats
des administrateurs de la plateforme.
225. L’autorité d’enregistrement de la solution proposée offre une interface Web
permettant auxadministrateurs de créer et de gérer leurs propres comptes et leurs
identifiants numériques.
5. Sauvegarde des clés
226. Les abonnés ou leurs représentants autorisés pourront récupérer leur clé privée de
décryptage et récupérer leurscertificats en cas de corruption ou de perte de l'un
d'entre eux.
227. Lorsqu'un certificat ou une demande de récupération de clé est émis, l'AC autorise la
demande et émettre un ordre pour récupérer la clé/le certificat demandé auprès du
service de sauvegarde, et le retourner au demandeur.
228. Toutes les clés archivées d'un utilisateur (c'est-à-dire l'historique complet des clés
de l'utilisateur) sont récupérées en une seule étape sans que les utilisateurs et
administrateurs n'aient à effectuer des opérations
manuelles pour chaque paire de clés récupérée.
6. Les référentiels
229. Les référentiels protégés sont conservés dans un environnement sécurisé et
sauvegardés régulièrement.
230. Le logiciel d'annuaire LDAP prend en charge l'observation, le chaînage et la
requête/réponse client.
231. La solution proposée prend en charge l'intégration avec un référentiel existant
déjà rempli de noms etd'attributs.
232. Le référentiel prend en charge les rôles pour la séparation et la délégation des
fonctions administrativesprivilégiées.
7. Services de validation
233. La solution PKI est à l'épreuve du temps et allouer un support pour les
développements futurs tels que lestechnologies de vérification basées sur XML
(exemple : XKMS, …).
Certificate Revocation List (CRL)
234. Support des CRLs partitionnées et les CRL combinées.
Online Certificate Status Protocol (OCSP)
235. Conformité de l’OCSP à la RFC 8954 (pour réduire le risque de déni de service).
236. L'autorité de validation prend en charge la mise en miroir pour l'équilibrage de
charge et la tolérance auxpannes.
237. Le Prestataire dispose des outils applications logicielles pour intégrer le processus
de demande de validation de certificat dans les applications de confiance.
238. Le répondeur OCSP prend en charge la republication des CRLs dans un Serveur
Web comme moyen desecours.
239. Le répondeur OCSP prend en charge le monitoring automatique de plusieurs
émetteurs de CRL en vérifiant et validant les CRL avant l’importation.
240. Le répondeur OCSP prend en charge la notification en temps réel du statut de
l’importation des CRLs,comme en cas d’indisponibilité à titre d’exemple.
BARID AL-MAGHRIB
241. Le répondeur OCSP prend en charge plusieurs formats de CRL (CRLs combinées,
les Delta CRLs, CRLspartitionnées, …).
242. Le répondeur OCSP supporte l’authentification des clients par filtrage IP,
l’authentification X509 basée surdes certificats SSL/TLS, ou en signant les requêtes
OCSP.
243. Pour renforcer la sécurité le répondeur OCSP supporte le mode gateway pour
minimiser les risques liés à lapublication.
244. Le répondeur OCSP assure la séparation des rôles et permissions.
245. Le répondeur OCSP supporte le double contrôle pour les opérations critiques.
246. Tous les enregistrements des logs de la base de données sont protégés
cryptographiquement pour empêcher la modification, la suppression ou l’ajout
d’enregistrements avec un process automatique pour valider leur intégrité.
247. Le répondeur OCSP supporte l’auto-archivage sécurisé des journaux de la base de
données.
248. Le répondeur OCSP supporte les fonctions de hachage SHA-2 et SHA-3.
249. Le répondeur OCSP supporte l’externalisation des logs via syslog et permettre le
repli automatique vers undeuxième serveur syslog en cas d’indisponibilité du
premier.
250. Support de plusieurs modèles de confiances par le serveur OCSP.
251. Conformité de l’OCSP au CWA 14167-1 (Pour son exploitation pour offrir des
services qualifiés et avancés).
8. Application Program Interfaces (APIs)
252. Les API sont développées et fournies par le même éditeur de la solution PKI ou le
cas échéant avoir un cadre desupport avec l’éditeur des APIs.
253. Fournir une preuve d’intégration transparente avec la solution PKI et les
applications installées sur le système cible, ainsi que des études de cas et des
références si les API ne sont pas développées et fournies par l’éditeur dela solution
PKI.
254. Les API fournies prennent en charge plusieurs langages de programmation et de
script, framework dedéveloppement et systèmes d’exploitation.
Exemple :
- C/C++
- C# / ASP / PHP
- J2EE et .NET Framework.
255. Les API prennent en charge des applications s’exécutant sur différents OS et
Plateformes :
• Windows / MAC OS / Linux
• Unix
• Navigateurs & Application Mobile
• …
256. Prise en charge d’une stratégie de limitation de débit des requêtes contre les
attaques de déni de service et debrute force.
9. Services d’horodatage (Time Stamping Services)
257. Le Service TSA peut offrir la possibilité de transférer la demande
d'horodatage à un autre TSA externeLe Service TSA peut faire office de
concentrateur pour les demandes d'horodatage.
258. Pour des raisons de scalabilité du système, il est souhaitable que le service TSA
supporte plus de 1000 TPS enutilisant des clés RSA 2048 stocké dans un HSM.
259. Prise en charge des SGBDs ci-dessous par le serveur TSA :
- PostgreSQL
- Microsoft SQL
- Oracle.
260. La TSA permet d’inclure (Option configurable) dans chaque jeton d’horodatage
un identifiant pourindiquer de manière unique la politique de sécurité en vertu de
laquelle le jeton a été créé.
261. La TSA examine l’OID de la fonction de hachage unidirectionnelle résistante aux
collisions et vérifier que la longueur de la valeur de hachage est cohérente avec
l’algorithme de hachage.
262. Le TSA n’inclut aucune identification de l’entité demandeuse dans les jetons
d’horodatage.
263. Le service TSA offre la possibilité de ne traiter que les demandes émanant
d’identifiants de politiquesautorisées.
BARID AL-MAGHRIB
264. Le service TSA offre la possibilité de mettre en place une liste blanche des
algorithmes de hachage autorisés.
265. Le service TSA supporte la suite NIST ECDSA.
266. Le service TSA prend en charge le protocoles TLS 1.2 et TLS 1.3.F
267. Le service TSA supporte le partage des secrets en assurant un contrôle MofN.
268. Tous les enregistrements des logs de la base de données sont protégés
cryptographiquement pour empêcher la modification, la suppression ou l'ajout
d'enregistrements avec un process automatique pour valider leur intégrité.
269. Le service TSA supporte les fonctions de hachage SHA-2 et SHA-3.
270. Le service TSA supporte l’externalisation des logs via syslog et permettre le
basculement automatique versun deuxième serveur syslog en cas d’indisponibilité
du premier.
271. Le service TSA supporte plusieurs serveurs NTP (Exemple : Stratum2 et 3,
Serveur NTP GPS, …) pourgarantir une heure précise et fiable.
272. Le service TSA supporte les jetons d’horodatage Authenticode.
11. Hardware Security Module (HSM)
273. Le logiciel des composants PKI utilise les services cryptographiques du HSM via
une API.
274. Possibilité de mettre en œuvre plusieurs HSM virtuels/partitions dans le même HSM
physique (Au minium Trois HSM virtuel/partitions pour chaque HSM physique).
275. Les HSM prend en compte l’alimentation électrique redondante.
12. Multi-langue
276. Pour que BAM puisse répondre aux exigences des clients en matière de langue,
notamment les languesofficielles, l’Arabe et l’Amazigh. La solution PKI supporte
plusieurs langues dans les standards du multi-
lang (ex. Support de l’UTF8).
277. L'AC, l'AE, les annuaires, les applications côté client et serveur et les API
permettent la prise en charge de la langue arabe et Amazigh en plus du français et
l'anglais.
278. Les certificats permettent de coder les informations en Anglais, Français,
Arabe et Amazigh et lescomposants PKI sont capables de reconnaître les codages
pour les différentes langues.
279. Le codage pour l'Arabe et l’Amazigh est effectué à l'aide du schéma de codage
UTF-8. Les rédacteurs et lesanalyseurs syntaxiques UTF-8.
13. Network Time Servers
280. Le serveur de temps d'une zone de sécurité supérieure se synchronise avec un
serveur d'une zone de sécuritéinférieure.
281. L'interrogation des serveurs d'horloge atomique est transmise de manière
séquentielle aux autres serveurs encas d'échec de la réponse.
282. Les serveurs de temps qui seront utilisés peuvent communiquer avec d'autres
serveurs de temps.
283. Les serveurs de temps prennent en charge plusieurs systèmes d’exploitation et
dans plusieurs versions(Unix, Linux, Windows, …).
284. Les serveurs de temps offrent une interface utilisateur graphique pour la gestion.
285. Les serveurs de temps peuvent enregistrer des événements détaillés.
286. Le serveur NTP est capable de diffuser l'heure en réponse aux requêtes des
clients actifs et l'heure dediffusion aux clients passifs.
287. Les clients NTP peuvent interroger activement les serveurs de temps ou rester
passifs pour être mis à jourpar le serveur.
288. Prise en charge des fonctionnalités de NTP v4 (En particulier : Authentification
basée sur la clé publique IPversion 6).
14. Logging
289. Le système de journalisation conserve une archive de toutes les transactions PKI
effectuées sur lescomposants PKI.
290. Le système de journalisation prend en charge la publication de journaux d'audit
personnalisés via le
protocole SNMP (Simple Network Management Protocol) vers des solutions de
gestion de réseau tierces et ce,dans le respect total des normes de sécurité exigée
pour les PKI.
291. Le système de journalisation prévoit la délégation et la séparation des tâches
administratives afin de garantirqu'aucun administrateur ne puisse compromettre
BARID AL-MAGHRIB
l'intégrité du système.
292. Le système de journalisation est capable d'importer/exporter les informations de

rapport dans une application définie par BAM via ODBC pour des requêtes
supplémentaires.
15. Paires de clés
293. La solution prend en charge les utilisateurs avec une seule paire de clés, deux
paires de clés et plusieurs paires de clés.
294. Les paires de clés pour la signature et le chiffrement ont des dates d'expiration
indépendantes.
16. Intégration
295. La solution proposée est techniquement intégrable à d'autres applications telles que
le système de gestion decarte.
SPÉCIFICATIONS TECHNIQUES POUR LES SERVICES AUTOUR DE LA SIGNATURE :
Numéro de page
Réponse du
soumissionnaire
l’offre technique
17. Exigences de sécurité
296. La solution fournit plusieurs modes d'authentification préalable pour confirmer
l'identité du signataire distantavant de permettre à la personne d'accéder au(x)
document(s) en ligne.
297. Les administrateurs des clients sont en mesure de paramétrer le mode
d’authentification selon leurs besoins (valeur juridique, sensibilité, exigences de
sécurité, …) pour exiger d'un signataire ou utilisateur distant qu'il fournisse des
types d'authentification nécessaires (Certificat électronique, e-mail, mot de passe,
SMS, …).
298. La solution prend en charge un système d'authentification unique (SSO) pour la
gestion des comptesutilisateur. Le système fournit un mécanisme d'ajout et de
suppression automatisés et manuels de comptes
d'utilisateurs sans intervention de BAM ou du soumissionnaire retenu.
299. La solution de signature électronique permet (en fonction des choix des clients de
BAM de ce service) de conserver une copie des documents ou leurs hash signés
électroniquement avec le dossier de preuves avec des durées de rétention
paramétrables où les mettre à disposition d’un système d’archivage électronique
avec des métadonnées supplémentaires pour les besoins d’archivage (Nom client
BAM, Type document, Format, duré de
conservation, …).
300. La solution garde la traçabilité de toutes les actions des utilisateurs (Audit trails),
ces traces sont sécurisées, générées par ordinateur et horodatées pour enregistrer de
manière indépendante la date et l'heure des entrées et des actions de l'opérateur.
301. Le système est en mesure de restreindre ou d'activer l'accès des utilisateurs aux
modèles de signature électronique ou aux documents partagés, ou de récupérer des
documents en fonction des groupes définis par les clients de BAM dans ses espaces
respectifs. Il permet également d'octroyer différents niveaux de privilèges en
fonction des groupes (ou rôles) définis par les clients.
302. La solution est capable de capturer les informations sur l'appareil/le système du
signataire distant pour des mesures de sécurité supplémentaires et une assistance
opérationnelle (EX. : système d'exploitation installé, les informations du navigateur,
l'adresse IP, la carte réseau, la géolocalisation, ...).
303. La solution est en mesure de stocker toutes les données saisies dans les
documents et rendre ces données disponibles etrécupérables, si c’est nécessaire,
selon les besoins et conformément aux règles de sécurité et de conformité.
18. Exigences de sécurité liées à la nature cloud de la solution
304. La solution traite en toute sécurité, et selon les normes de l’industrie, toutes les
données en fonction de sespolitiques de conservation réglementaires.
19. Exigences d'intégration et de compatibilité
BARID AL-MAGHRIB
305. Il serait souhaitable que la solution proposée possède des modules

d’interfaçage avec les plates-formes decollaboration de contenu courantes
(OneDrive, GoogleDrive, DropBox, …).
20. Exigences techniques et standards
306. La solution utilise des langages de programmation et des Framework de
développement standard et connu.
307. Les APIs fournies ou à développer prennent en charge plusieurs langages de
programmation et de script,Framework de développement et systèmes
d'exploitation.
Exemple :
C/C++
C# / ASP / PHP
J2EE et .NET Framework.
308. Support des formats standards pour :
- PAdES :
• PDF Advanced Electronic Signature ETSI TS 102 778 ; incluant le
format LTV (part 4) et le visuel designature (part6) ;
• Support de PAdES-B-B, PAdES-B-T, PAdES-B-LT and PAdES-B-LTA
et ce, selon la norme ETSI TS103 172 ;
• PAdES (PDF Advanced Electronic Signature ETSI EN 319 142-1&2).
- XAdES : XML Advanced Electronic Signature ETSI TS 101 903 ;

• Support de XAdES-B-B, XAdES-B-T, XAdES-B-LT and XAdES-B-LTA
et ce, selon la norme ETSI TS103 171 ;
• XAdES (XML Advanced Electronic Signature ETSI EN 319 132-1&2) ;
• CAdES : CMS Advanced Electronic Signature ETSI TS 101 733 ;
• Support de CAdES-B-B, CAdES-B-T, CAdES-B-LT and CAdES-B-LTA et
ce, selon ETSI TS 103 173
• CAdES (CMS Advanced Electronic Signature ETSI EN 319 122-1&2).
309. Support des formats standards généré :
- ISO 32000-1, (PDF/A, PDF/E, PDF/X et PDF/H).
310. Support des formats et normes de Validation de signature :
- Prise en charge de la validation XML et XAdES (XAdES-BES et XAdES-
T) ;
311. Algorithmes supportés par la solution proposée :
- RSA : Clés jusqu'à 8192 bits ;
- DSA : Clés jusqu'à 1024 bits ;
- ECDSA ;
- Algorithmes de hachage : SHA-2, SHA-3
- …
312. Le parapheur permet aux utilisateurs de demander un niveau d'assurance par
signature (LoA).
313. La solution proposée supporte le standard CSC (Cloud Signature Consortium)
notamment la Signature &cachet électronique à distance.
314. La solution proposée supporte la langue arabe nativement. Le support natif de
la langue Amazigh estvivement souhaitable.
315. La solution proposée fournit une application mobile IOS et Android.
316. La solution proposée supporte les standards OpenID Connect, OAuth, SAML 2.O
IDP's.
317. La solution proposée supporte le workflow en série, en parallèle, individuel et un
hybride de ceux-ci.
318. La solution proposée supporte la norme PAdES Part 4 Long-term signatures.
Il s'agit de signatures spéciales à long terme pour lesquelles la preuve intégrée peut
être continuellement étenduedans le temps pour que, les signatures n'expirent jamais.
319. La solution proposée exige le consentement.
21. Exigences techniques pour la validation/Conservation de signature/Cachet
électronique
320. Support des normes de la validation de signature :
- ETSI TS 102 853 ;
- ETSI TS 119 101.

Aoo 89-2022 - RC V4

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Aoo 89-2022 - RC V4

Transféré par

Droits d'auteur :

Formats disponibles

BARID AL-MAGHRIB

Acquisition, mise en service et maintenance d’une

TABLE DES MATIERES

CAHIER DES PRESIPTIONS SPECIALES ........................................................................................................ 1

ARTICLE 1 : OBJET DU REGLEMENT DE CONSULTATION

▪ justifient des capacités juridiques, techniques et financières requises ;

ARTICLE 13 : ECHANTILLONS, PROTOTYPES, PROSPECTUS, NOTICES ET AUTRES

ARTICLE 20 : RETRAIT DES PLIS

- Étape 1 : Examen des critères obligatoires :

- Étape 2 : Notation des offres techniques :

Chef de projet (5 points) :

Expert fonctionnel PKI (5 points) :

N.B : Si le prestataire propose plusieurs Experts fonctionnels en Signature électronique &

21.3 : ÉVALUATION DES OFFRES FINANCIÈRES

Dressé par Signé au nom du Maître d’Ouvrage

Lu et approuvé par le soumissionnaire

4. Connaissances linguistiques : Indiquer les connaissances sur une échelle de 1 à 5.

5. Qualifications principales :(pertinentes par rapport au rôle attribué au Marché)

10. Projet(s) similaire réalisé(s) :

11. Autres informations utiles (par exemple, publications) :

ANNEXE 2 : MODÈLE DU PLAN DE CHARGE

Désignation, affectation et nombre

Signature et cachet du soumissionnaire

ANNEXE 3 : TABLEAU DES CRITÈRES OBLIGATOIRES (ÉLIMINATOIRES)

Création et Validation de signature

SPÉCIFICATIONS TECHNIQUES POUR LES SERVICES DE CERTIFICATION :

- Spécifications techniques générales de la solution :

Génération et stockage de clés

- Spécifications techniques des principales composantes de la solution :

4. Autorité d'enregistrement (AE) ou AED

166. Le système de journalisation doit contenir, au minimum, un historique de :

SPÉCIFICATIONS TECHNIQUES POUR LES SERVICES AUTOUR DE LA SIGNATURE :

ANNEXE 4 : TABLEAU DES CRITÈRES COMPLÉMENTAIRES

SPÉCIFICATIONS TECHNIQUES POUR LES SERVICES DE CERTIFICATION :

- Spécifications techniques générales de la solution :

- Spécifications techniques des principales composantes de la solution :

communique avec un produit de gestion des dispositifs mobiles.

221. L’autorité d’enregistrement de la solution proposée est dotée d’un protocole de

292. Le système de journalisation est capable d'importer/exporter les informations de

SPÉCIFICATIONS TECHNIQUES POUR LES SERVICES AUTOUR DE LA SIGNATURE :

305. Il serait souhaitable que la solution proposée possède des modules

- XAdES : XML Advanced Electronic Signature ETSI TS 101 903 ;

Vous aimerez peut-être aussi