IGC-Santé Etape 1 Les gabarits des certificats X.509 et ...igc-sante.esante.gouv.fr/DA/DA-CONTRATS-TYPE-V1.0.pdf · 1 Introduction L’ASIP-Santé prépare la mise en place de l’IGC-Santé

IGC-Santé Etape 1

Les gabarits des certificats X.509 et des CRLs

Gamme Elémentaire

Domaines Personnes et Organisations

Identification du document

Référence ASIPSanté - Certificats X.509 et CRL - Gamme Elémentaire - Etape 1 - V 1.0.1 interne .docx

Date de création 11/07/2013

Date de dernière mise à jour 08/10/2013

Etat En cours

Rédaction (R) ASIP Santé / PTS / PSCE

Version V 1.0.1

Vérification ASIP Santé / PTS / PSCE

Validation finale (A) ASIP Santé / PTS / PSCE

Classification Document public

Nombre de pages 63

ASIP Santé IGC-Santé – Etape 1 - Gabarits des Certificats et des CRLErreur ! Source du renvoi introuvable.

Classification : Document public 2 / 63

Documents de référence – ASIP-Santé

[1] Politiques de Certification (PC) de l’IGC-Santé Dernières versions publiées sur : http://igc-sante.esante.gouv.fr/PC (à venir)

[2] Annuaire CPS – Schéma DIT Version 8.1.6 du 19/08/2013 (ou supérieure)

Standards applicables

[3] RFC-5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile Ce document annule et remplace les RFC 2459 et 3280.

[4] RFC-2253 - UTF-8 String Representation of Distinguished Names Décembre 1997

Historique du document

Version Date Auteur Commentaires

V 0.0.1 11/07/2013 PTS/PCSE Version initiale du document

V 0.0.2 à

V0.0.8 24/09/2013 PTS/PCSE Versions de travail interne

V 1.0.0 27/09/2013 PTS/PCSE Version validée

V 1.0.1 08/10/2013 PTS/PCSE § A 4.3.2 et A 4.3.3 Correction URL des (delta-)CRL de Test



Sommaire

1 Introduction ...................................... ....................................................................... 5

1.1 L’architecture de l’IGC-Santé ............................................................................................... 6

2 Schéma de nommage des Autorités de Certification .. ......................................... 7

2.1 Gamme Elémentaire ............................................................................................................ 7

2.2 Gamme Standard ................................................................................................................ 8

2.3 Gamme Fort ........................................................................................................................ 8

3 Schéma de nommage des porteurs dans les certificats ...................................... 9

3.1 Schéma de nommage des personnes physiques ............................................................... 10

3.2 Schéma de nommage des certificats d’organisation .......................................................... 11

3.3 Représentation d’un DN sous la forme d’une chaîne de texte............................................ 11

3.4 Les DN des certificats utilisateur et l’Annuaire CPS ........................................................... 12

4 Les gabarits des certificats de l’IGC-Santé ....... .................................................. 13

4.1 La structure d'un certificat X.509 version 3 ........................................................................ 13

4.1.1 Les champs de base ............................................................................................................ 13

4.1.2 Les extensions de certificat .................................................................................................. 14

4.1.3 Les différents types d’extension ........................................................................................... 14

4.1.4 Conventions de notation pour les gabarits des certificats .................................................... 14

4.2 Les certificats Racine de l’IGC-Santé ................................................................................ 15

4.4 Les certificats des AC Intermédiaires de l’IGC-Santé......................................................... 16

4.5 Les certificats OCSP des AC Intermédiaires ...................................................................... 17

4.6 Les certificats utilisateur de personnes physiques ............................................................. 18

4.6.1 Certificats de signature et d’authentification d’une personne physique ............................... 19

4.6.2 Certificat de chiffrement d’une personne physique .............................................................. 20

4.7 Les certificats utilisateur d’organisations ............................................................................ 21

4.7.1 Certificats de cachet et d’authentification d’une structure .................................................... 22

4.7.2 Certificats d’authentification serveur et de chiffrement d’une structure ............................... 23

4.7.3 Certificat S/MIME d’une structure ......................................................................................... 24

5 Les structures des CRLs de l’IGC-Santé ............ ................................................. 25

5.1 La structure d'une CRL X.509 version 2 ............................................................................ 25

5.1.1 Les champs de base ............................................................................................................ 26

5.1.2 Extensions d’entrée de CRL ................................................................................................. 26

5.1.3 Extensions de CRL ............................................................................................................... 26

5.2 Les CRL de l’IGC-Santé .................................................................................................... 27

5.2.1 La structure des CRL............................................................................................................ 27

5.2.2 La structure des delta-CRL .................................................................................................. 27

6 L’IGC-Santé de Test ............................... ............................................................... 28

6.1 Schéma de nommage des AC de Test .............................................................................. 28

Annexe 1 Conventions, Abréviations et définitions .......... ....................................... 29

A 1.1 Conventions de notation ......................................................................................... 29

A 1.2 Définitions .............................................................................................................. 30

A 1.3 Abréviations ........................................................................................................... 31

Annexe 2 La syntaxe des certificats et CRL de l’IGC-Santé .. .................................. 32



A 2.1 La syntaxe des Certificats X.509 v3 de l’IGC-Santé ............................................... 32

A 2.1.1 Extensions standards utilisées dans les certificats de l’IGC-Santé ..................................... 33

A 2.1.2 Extensions privées utilisées dans les certificats de l’IGC-Santé .......................................... 40

A 2.2 La syntaxe des CRL de l’IGC-Santé ....................................................................... 43

A 2.2.1 crlEntryExtensions ................................................................................................................ 44

A 2.2.2 crlExtensions ........................................................................................................................ 44

Annexe 3 Les identifiants d’objet (OID) .................... ................................................. 45

A 3.1 Les identifiants d'objet standards utilisés dans l’IGC-Santé .................................... 46

A 3.2 Les identifiants d'objets privés utilisés dans l’IGC-Santé ........................................ 47

A 3.2.1 Les identifiants d'objets attribués par le GIP-CPS ............................................................... 47

A 3.2.2 Les identifiants d'objets attribués par l’ASIP-Santé.............................................................. 48

Annexe 4 Les URL référencés dans les certificats de l’IGC-Sa nté ......................... 49

A 4.1 Les URL dans les certificats de Production ............................................................ 49

A 4.1.1 Production : Les URL pointant vers les certificats ACR et ACI ............................................ 49

A 4.1.2 Production : Les URL des CRL (crlDistribitionPoints) ......................................................... 49

A 4.1.3 Production : Les URL des delta-CRL (freshestCRL) ........................................................... 50

A 4.2 Production : Les URL divers ................................................................................................. 50

A 4.3 Les URL dans les certificats de Test ...................................................................... 51

A 4.3.1 Test : Les URL pointant vers les certificats ACR et ACI ...................................................... 51

A 4.3.2 Test : Les URL des CRL (crlDistribitionPoints) ................................................................... 51

A 4.3.3 Test : Les URL des delta-CRL (freshestCRL) ..................................................................... 52

A 4.4 Test : Les URL divers ............................................................................................. 52

Annexe 5 Gestion des objets ASN.1 .......................... ................................................ 53

A 5.1 Les grands principes de l’ASN.1 ............................................................................ 53

A 5.1.1 La notation ASN.1 ................................................................................................................ 53

A 5.1.2 Codification des objets en ASN.1 ......................................................................................... 53

A 5.1.3 Codification des tags ............................................................................................................ 53

A 5.1.4 Valeurs des TAGs universels ............................................................................................... 54

A 5.1.5 Codification des longueurs des objets.................................................................................. 54

A 5.1.6 Précisions sur la construction d'objets ................................................................................. 54

Annexe 6 Exemples de codage dans les certificats de l’IGC-Sa nté ........................ 56

A 6.1 Exemples de codage des DN des porteurs de certificats ........................................ 56

A 6.1.1 Exemples de codage des DN des Personnes physiques .................................................... 56

A 6.1.2 Exemples de codage des DN des Organisations ................................................................. 60

A 6.2 Exemples de codage des extensions privées ......................................................... 62

A 6.2.1 Exemple de codage de « productCategory » ....................................................................... 62

A 6.2.2 Exemple de codage de « productType » ............................................................................. 62

A 6.2.3 Exemple de codage de « tokenID » ..................................................................................... 62

A 6.2.4 Exemple de codage de « professionCode » ........................................................................ 62

A 6.2.5 Exemple de codage de « futureProfessionCode » ............................................................... 62

A 6.2.6 Exemple de codage de « oldPS_IDNat » ............................................................................. 62

A 6.2.7 Exemple de codage de « specialitesRPPS » ....................................................................... 63

A 6.2.8 Exemple de codage de « tableauxPharmacien » ................................................................. 63

A 6.2.9 Exemple de codage de « SubjectAltName » avec UPN pour une CPx ............................... 63



1 Introduction L’ASIP-Santé prépare la mise en place de l’IGC-Santé dont la nouvelle offre de produits de certification répond aux enjeux suivants :

• Emettre sous une IGC unique l’ensemble des produits de certification de l’ASIP Santé ;

• Offrir, quand l’offre produits sera complètement déployée, un recouvrement total avec les usages des IGC actuelles (IGC-CPS2bis et IGC-CPS2ter) ;

• Offrir des niveaux de confiance adaptés aux contextes d’utilisations ;

• Permettre une modularité des usages en fonction de l’utilisateur final ;

• Offrir des mécanismes cryptographiques au niveau de l’état de l’art.

L’IGC-Santé sera mise en place en plusieurs étapes :

• Etape 1 : Mise en production de l’IGC-Santé sur la nouvelle Plateforme de Fourniture de Certificats dite « PFC-NG » (Plateforme de Fourniture de Certificats - Nouvelle Génération)

o reprise du périmètre fonctionnel de l’IGC-CPS2bis (certificats logiciels des Classes 4 et 5 à l’exception de la Classe-6),

o extension de l’offre actuelle avec des certificats logiciels pour personnes physiques et organisations.

L’étape 1 sera opérationnelle dans le 2ème semestre 2014 pour garantir la continuité de service de l’IGC-CPS2bis qui entrera alors dans sa phase de « fin de vie ».

• Etapes ultérieures (fin 2014 – début 2015) :

o production de cartes CPS3 avec des certificats IGC-Santé embarqués (arrêt de l’IGC-CPS2ter - certificats des Classes 0 à 3),

o extension de l’offre des certificats logiciels pour des personnes physiques et des organisations.

Le présent document ne spécifie que l’offre de prod uits correspondant à l’étape 1



1.1 L’architecture de l’IGC-Santé L’architecture de l’IGC-Santé offre 3 gammes de certificats, correspondant à autant de niveaux de confiance :

• Gamme « Fort » :

o Ce niveau de confiance vise un référencement RGS ** ;

o Il permettra la prise en compte des certificats qualifiés pour la signature sécurisée grâce à un référencement ETSI (signature présumée fiable) et de figurer sur la Trusted List ;

o La Gamme Fort ne délivrera que des certificats à embarquer sur des cartes CPx.

• Gamme « Standard » :

o Ce niveau de confiance vise un référencement RGS * ;

o Il permettra la prise en compte des certificats qualifiés pour la signature sécurisée grâce à un référencement ETSI (signature présumée fiable) et de figurer sur la Trusted List.

• Gamme « Elémentaire » :

o Ce niveau minimum permet d’offrir des services avec des certificats pour lesquels les niveaux ci-dessus ne sont pas exigés.

Chaque gamme dispose de 2 domaines :

• Domaine « Personnes » , pour les personnes physiques. Les certificats peuvent être embarqués dans des cartes CPx ou être « logiciels ».

• Domaine « Organisations », pour les structures. Les certificats sont « logiciels ».

Le schéma ci-dessus montre l’architecture de l’IGC-Santé et les potentiels porteurs de certificats.

L’architecture de l’IGC-Santé

Notes :

• La Gamme Fort émettra uniquement des certificats dans le Domaine Personnes à embarquer dans des cartes CPx ; elle n’émettra donc pas de certificats dans le Domaine Organisations.

• Les certificats de test sont émis par une IGC de test (avec une hiérarchie identique) pour assurer un cloisonnement par rapport à l’IGC de production.



2 Schéma de nommage des Autorités de Certification L’émetteur (issuer) et le porteur (subject) dans chaque certificat X.509 sont chacun identifiés par un Distinguished Name (DN) qui est unique dans l’IGC-Santé.

Ce paragraphe traite du nommage des Autorités de Certification Racine (ACR) de chaque gamme et de celui des Autorités de Certification Intermédiaire (ACI) de chaque Domaine.

Note : Pour le schéma de nommage de l’IGC-Santé de Test, cf. § 6 « L’IGC-Santé de Test ».

2.1 Gamme Elémentaire

Nom gabarit DN des Autorités de Certification

EL-ACR DN du certificat racine Elémentaire

c= FR o= ASIP-SANTE

ou= 0002 187512751 ou= IGC-SANTE cn= AC RACINE IGC-SANTE ELEMENTAIRE

EL-PP-ACI DN du certificat racine intermédiaire - P ersonnes Physiques c= FR o= ASIP-SANTE

ou= 0002 187512751 ou= IGC-SANTE cn= AC IGC-SANTE ELEMENTAIRE PERSONNES

EL-ORG-ACI DN du certificat racine intermédiaire - Organisations c= FR o= ASIP-SANTE

ou= 0002 187512751 ou= IGC-SANTE cn= AC IGC-SANTE ELEMENTAIRE ORGANISATIONS



2.2 Gamme Standard


ST-ACR DN du certificat racine Standard

c= FR o= ASIP-SANTE

ou= 0002 187512751 ou= IGC-SANTE cn= AC RACINE IGC-SANTE STANDARD

ST-PP-ACI DN du certificat racine intermédiaire - P ersonnes Physiques

c= FR o= ASIP-SANTE

ou= 0002 187512751 ou= IGC-SANTE cn= AC IGC-SANTE STANDARD PERSONNES

ST-ORG-ACI DN du certificat racine intermédiaire - Organisations c= FR o= ASIP-SANTE

ou= 0002 187512751 ou= IGC-SANTE cn= AC IGC-SANTE STANDARD ORGANISATIONS

2.3 Gamme Fort


FO-ACR DN du certificat racine Fort

c= FR o= ASIP-SANTE

ou= 0002 187512751 ou= IGC-SANTE cn= AC RACINE IGC-SANTE FORT

FO-PP-ACI DN du certificat racine intermédiaire - P ersonnes Physiques c= FR o= ASIP-SANTE

ou= 0002 187512751 ou= IGC-SANTE cn= AC IGC-SANTE FORT PERSONNES

Note :

• Il n’y a pas de Domaine Organisations dans la Gamme Fort.



3 Schéma de nommage des porteurs dans les certifica ts L’émetteur (issuer) et le porteur (subject) dans chaque certificat X.509 sont chacun identifiés par un Distinguished Name (DN) qui est unique dans l’IGC-Santé.

Ce paragraphe traite du nommage des porteurs dans les certificats utilisateur.

L’IGC-Santé distingue les porteurs de certificats utilisateur suivants :

• Personnes physiques (Domaines Personnes) :

o Professionnel de Santé réglementé et Professionnel de Santé en Formation Le DN contient l’identité nationale du porteur, il est indépendant de toute activité professionnelle ;

o Professionnel de Santé réglementé et Professionnel de Santé en Formation rattaché à une structure Le DN contient l’identité nationale du porteur ainsi que celle de la structure à laquelle le porteur est rattaché (où il exerce une activité professionnelle) ;

o Personnel de structure Le DN contient l’identité nationale du porteur, employé d’une structure, ainsi que celle de la structure de l’employeur ;

o Carte de service attachée à une structure hors étape 1 Le DN contient l’identité nationale d’un pseudonyme attribué par la structure (la carte n’est pas détenue par une personne nominative) ainsi que celle de la structure elle-même.

• Organisations (Domaines Organisations) :

o Structure Le DN contient l’identité nationale de la structure ;

o Entité dans une structure hors étape 1 Le DN contient l’identité nationale de la structure avec le nom et le type d’entité détentrice du certificat.

o Carte CPx – certificat d’authentification pour mode sans contact hors étape 1 Le DN est celui d’un certificat d’authentification sans contact, il est lié à l’objet carte et ne contient aucune information concernant son porteur.

Notes :

• L’authentification CPx en mode sans contact est considérée comme une fonction liée à une structure (le certificat correspondant contient l’identité du support et non celle du porteur de la carte). C’est pour cette raison que ces certificats sont émis dans le Domaine Organisations de la Gamme Elémentaire.

• Dans la suite du présent document on distingue 2 catégories de structures :

o Les « structures santé ou social » : ces structures font traditionnellement partie du périmètre où les personnes ont droit aux cartes CPS, CPF, CDE et CPE (nominatives) et aux certificats logiciels de l’IGC-Santé.

o Les « structures autorisées » : ces structures ne prennent pas en charge des patients. Néanmoins, sur dossier, certaines structures peuvent être autorisées à demander des cartes de type CDA et CPA ainsi que des certificats logiciels de l’IGC-Santé. Exemples : les hébergeurs de données de santé agréés et les organisations d’Assurance Maladie.

• Les RDN dans les tableaux ci-après respectent le même ordre que celui dans les certificats.



3.1 Schéma de nommage des personnes physiques Toute personne physique : professionnel de santé, employé ou pseudonyme dispose d’une identité nationale unique, désigné par « PS_IdNat ».

DN de personnes physiques

Professionnel de Santé réglementé ou Professi onnel de Santé en Formation c= FR title= < Profession ou Future Profession >

gn= < prénom usuel > sn= < nom d'exercice > Les RDN gn, sn et cn sont groupés dans un RDN multi-valué cn= < PS_IdNat >

Professionnel de Santé réglementé ou Professi onnel de Santé en Formation rattaché à une structure c= FR st= < Nom département (N°) > o= < Raison sociale Structure > ou= < Struct_IdNat > title= < Profession > ou < Future Profession >

gn= < prénom usuel > sn= < nom d'exercice > Les RDN gn, sn et cn sont groupés dans un RDN multi-valué cn= < PS_IdNat >

Personnel de structure c= FR st= < Nom département (N°) > o= < Raison sociale Structure > ou= < Struct_IdNat > title= « Personnel santé ou social » ou « Personnel autorisé » *

gn= < prénom usuel > sn= < nom d'exercice > Les RDN gn, sn et cn sont groupés dans un RDN composé cn= < PS_IdNat >

Carte de Service attachée à une Structure hors étape 1 c= FR st= < Nom département (N°) > o= < Raison sociale Structure > ou= < Struct_IdNat > title= « Carte de service santé ou social » ou « Carte de service autorisée » *

pseudo = < pseudonyme > Les RDN pseudo et cn sont groupés dans un RDN multi-valué

cn= < PS_IdNat >

* : Le texte dépend uniquement de la nature de la structure de rattachement, respectivement une « structure santé ou social » ou une « structure autorisée ».

Note :

• Pour la codification des RDN multi-valué, se reporter au chapitre Annexe 6 « Exemples de codage dans les certificats de l’IGC-Santé ».

• Une Carte de Service embarque un certificat de signature et un certificat d’authentification. L’identifiant du porteur du certificat n’étant pas nominatif, il n’est pas possible de demander des certificats logiciels pour ces porteurs.



3.2 Schéma de nommage des certificats d’organisatio n Toute structure dispose d’une identité nationale unique, désigné par « Struct_IdNat ».

DN des certificats détenus par des organisations

DN d’un certificat applicatif de structure c= FR st= < Nom département (N°)> o= < Raison sociale Structure > ou= < Struct_IdNat > cn= < Nom applicatif >

DN d’un certificat applicatif d’une entité dans une structure hors étape 1 c= FR st= < Nom département (N°)> o= < Raison sociale Structure > ou= < Struct_IdNat >

ou= < Type d’entité > L’usage de ces RDN sera précisé lors d’une étape ultérieure.

ou= < Nom d’entité >

cn= < Nom applicatif >

DN d’un certificat d’authentification CPx pour mode sans contact hors étape 1 c= FR o= ASIP-SANTE cn= < IAS Serial Number >

Note :

• Pour les certificats de type serveur SSL, le < Nom applicatif > doit contenir un FQDN, pour les autres certificats, ce nom peut être librement défini par son demandeur.

3.3 Représentation d’un DN sous la forme d’une chaî ne de texte

Lorsqu’on doit renseigner un DN sous la forme d’une chaîne de texte, par exemple dans un champ du VIHF pour accéder au DMP d’un patient, il faut respecter le standard RFC-2253 [4].

Rappel des règles de RFC-2253 :

• Chaîne de texte en format UTF-8 ;

• Les RDN (chaînes séparées par des ",") doivent apparaître dans l'ordre inverse du certificat ;

• L’ordre des RDN à l'intérieur d'un RDN multi-valué est quant à lui indifférent. Les RDN à l’intérieur d’un RDN multi-valué sont séparés par des "+".

Le DN de médecin Jean DUPONT avec l’identifiant RPPS 810000123456 peut donc avoir plusieurs représentations :

cn=810000123456+sn=DUPONT+gn=JEAN,titre=Médecin,c=FR

ou

sn=DUPONT+gn=JEAN+cn=810000123456,titre=Médecin,c=FR

ou

gn=JEAN+sn=DUPONT+cn=810000123456,titre=Médecin,c=FR

etc. (6 combinaisons possibles)



3.4 Les DN des certificats utilisateur et l’Annuair e CPS Les certificats de l’IGC-Santé sont publiés dans l’Annuaire-CPS dont, à terme, le RASS (Répertoire des Acteurs Santé-Sociale) va prendre la relève.

Pour cette raison, les DN (Distinguished Names) des certificats utilisateurs de l’IGC-Santé ont été redéfinis afin de mieux respecter les pratiques courantes quant à l’usage des RDN (Relative Distinguished Names).

Les DN des certificats utilisateur de l’IGC-Santé ne correspondent plus au DIT (Directory Information Tree) de l’Annuaire-CPS actuel.

Il n’est donc plus possible de faire des recherches LDAP en utilisant des DN des certificats utilisateur « tels quels ».

Les clés uniques d’accès aux personnes physiques et structures sont leurs identifiants nationaux, respectivement PS_IdNat et Struct_IdNat.

Le schéma ci-dessous montre le DIT de l’Annuaire-CPS [2] avec des exemples de certificats utilisateur.

Les textes en rouge mettent en évidence les différences entre le DIT de l’Annuaire-CPS et les DN des certificats utilisateur :

• Les certificats ne contiennent plus le RDN « o=GIP-CPS » ;

• Pour les certificats PS et PF, la < (future) Profession > est dorénavant renseignée dans le RDN « title » ;

• Pour les certificats des personnes dans les structures et les certificats de structure : o Le < Département (N°) > est dorénavant renseigné dans le RDN « state » ; o Ils contiennent un nouveau RDN « organisation » renseigné avec la < Raison sociale >.

Notes : • Il est déconseillé d’utiliser la Raison sociale dans les recherches LDAP ; seul l’identifiant national de la structure

(Struct_IdNat) est garanti unique et stable dans le temps.

• Il est déconseillé d’utiliser des RDN composés (cn=<PS_IdNat>+sn=<nom d’exercice>+gn=<prénom usuel>) dans les recherches LDAP ; il est possible d’utiliser les RDN cn, sn et gn individuellement.



4 Les gabarits des certificats de l’IGC-Santé

4.1 La structure d'un certificat X.509 version 3 Un certificat est composé de 2 parties :

• Les données à certifier (TBS = To Be Signed). Elles contiennent les champs de base et les extensions.

• La signature du certificat : sa valeur et les informations sur l’algorithme de signature.

CERTIFICAT

TBS – To Be Signed Version 3

Numéro de série du certificat

Informations sur l’algorithme de signature du certificat

Nom de l’émetteur du certificat

Période de validité du certificat

Nom du porteur de certificat

Clé publique du porteur de certificat

Extensions du Certificat

Identifiant du type de l’extension Criticité (oui / non) Valeur



…

Signature du certificat par l’AC

Informations sur l’algorithme de signature du certificat

Valeur de la signature numérique du certificat par l’Autorité de Certification

Schéma du contenu d'un certificat X.509 version 3

La syntaxe des certificats de l’IGC-Santé est spécifiée en Annexe, § A 2.1 « La syntaxe des Certificats X.509 v3 de l’IGC-Santé ».

4.1.1 Les champs de base

Les champs de base d’un certificat renseignent les informations suivantes :

• la version de la structure du certificat (version = 3),

• le numéro de série,

• les informations sur la signature du certificat (algorithmes et paramètres),

• le nom de l’émetteur du certificat,

• la période de validité du certificat,

• le nom du porteur de certificat,

• la clé publique (valeur de la clé publique, algorithme et paramètres).



4.1.2 Les extensions de certificat

La possibilité d’ajouter des extensions à un certificat a été créée par la version 3 du standard « RFC-5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile » [3].

Une implémentation de la norme choisira parmi les extensions proposées celles qui sont pertinentes pour son application et les ajoutera aux champs de base du certificat.

La séquence d’extension(s) adjointe aux champs de base du certificat est une collection d’éléments dont le cardinal peut être nul. Par conséquent, un certificat X.509v3 peut ne contenir aucune extension.

Si la norme définit plusieurs types d’extensions, d’autres extensions, dites « privées » peuvent être ajoutées pour correspondre aux besoins d’une implémentation particulière.

Chaque extension est caractérisée par trois informations :

• l’identifiant de l’extension considérée = ObjectIDentifier (OID), • le fait que l’extension soit critique ou non 1, • la valeur de l’extension (au format spécifié par l’OID).

4.1.3 Les différents types d’extension

Les extensions de certificat permettent de spécifier plus précisément les caractéristiques suivantes :

• informations sur les clés, • informations sur les politiques de certification, • informations complémentaires sur l’émetteur et le porteur de certificat, • contraintes sur le chemin de certification.

Des extensions spécifiques peuvent être définies à travers une recommandation de l’ITU-T ou par un organisme qui en exprime le besoin. L’identificateur de l’objet qui identifie une extension peut alors être défini selon la procédure décrite dans la norme ISO 9834.

4.1.4 Conventions de notation pour les gabarits des certificats

Dans les gabarits des certificats spécifiés dans ce document, le sigle < Gamme > symbolise une des gammes suivantes : Elémentaire , Standard ou Fort .

et le sigle < Domaine > symbolise un des domaines suivants : Personnes ou Organisations .

Le champ « certPolicyId » dans l’extension certificatePolicies est une information composée :

en fonction de la gamme, < GG > prend les valeurs suivantes : � si gamme = Elémentaire : < GG > = EL

� si gamme = Standard : < GG > = ST

� si gamme = Fort : < GG > = FO

en fonction du domaine, < DD > prend les valeurs suivantes : � si domaine = Personnes : < DD > = PP

� si domaine = Organisations : < DD > = ORG

1 Quand une extension est critique, le vérificateur du certificat doit traiter l’information qu’elle contient.

S’il ne connaît pas sa signification de l’extension, il doit systématiquement refuser le certificat.



4.2 Les certificats Racine de l’IGC-Santé Il y a 3 certificats racine (ACR) dans l’IGC-Santé, un pour chaque gamme.

Ces certificats sont auto-signés 2, ils servent :

• à signer les certificats AC Intermédiaires de ses domaines (Personnes et Organisations), • à signer les CRL pour l’éventuelle révocation des certificats ACI de ses domaines.

Objet Format Données du certificat de l’AC RACINE < Gamme >

Certificate Sequence TbsCertificate Sequence version Integer 2 (version 3) serialNumber Integer n° de certificat signature OID Sha2-WithRSAencryption

issuer

PrintString c=FR

UTF8String

o=ASIP-SANTE ou=0002 187512751 ou=IGC-SANTE cn=AC RACINE IGC-SANTE < Gamme >

validity UTC-Time NotBefore : mardi 25 juin 2013 02:00:00 NotAfter : samedi 25 juin 2033 02:00:00

subject

PrintString c=FR

UTF8String


subjectPublicKeyInfo Sequence algorithmIdentifier OID RSAencryption (Parameter = NULL) subjectPublicKey BitString clé publique de 4.096 bits + exposant publique ( = 2E16+1) extensions Sequence authorityKeyId OctString SHA1 de subjectPublicKey subjectKeyId OctString SHA1 de subjectPublicKey keyUsage Sequence critical Boolean true value BitString '06' : keyCertSign + crlSign extendedKeyUsage Sequence extension absente subjectAltName Sequence extension absente certificatePolicies Sequence certPolicyId OID any-policy certPolicyQualifier OID http://igc-sante.esante.gouv.fr/PC basicConstraints Sequence critical Boolean true CA Boolean true pathLenConstraint Integer absent crlDistributionPoint Sequence extension absente authorityInfoAccess Sequence extension absente signatureAlgorithm OID Sha2-WithRSAencryption signatureValue BitString Signature par ACR < Gamme >

2 Un certificat "auto-signé" a les caractéristiques suivantes : - DN issuer = DN subject,

- l’extension authorityKeyId = subjectKeyId.



4.4 Les certificats des AC Intermédiaires de l’IGC- Santé Il y a 2 domaines « Personnes » et « Organisations » par gamme, sauf pour la Gamme Forte qui n’a pas de Domaine « Organisations ».

Chaque domaine est matérialisé par un certificat d’autorité intermédiaire (ACI).

Ces certificats sont signés par le certificat ACR de leur gamme, ils servent :

• à signer les certificats utilisateur (certificats end-user et OCSP), • à signer les CRL pour la révocation des certificats utilisateur.

Objet Format Données du certificat de l’AC Intermédiaire < Gamme > < Domaine >


issuer

PrintString c=FR

UTF8String


validity UTC-Time NotBefore : mardi 25 juin 2013 02:00:00 NotAfter : vendredi 24 juin 2033 02:00:00

subject

PrintString c=FR

UTF8String

o=ASIP-SANTE ou=0002 187512751 ou=IGC-SANTE cn=AC IGC-SANTE < Gamme > < Domaine >

subjectPublicKeyInfo Sequence algorithmIdentifier OID RSAencryption (Parameter = NULL) subjectPublicKey BitString clé publique de 4.096 bits + exposant publique ( = 2E16+1) extensions Sequence authorityKeyId OctString subjectKeyId du certificat ACR < Gamme > subjectKeyId OctString SHA1 de subjectPublicKey keyUsage Sequence critical Boolean true value BitString '06' : keyCertSign + crlSign extendedKeyUsage Sequence extension absente subjectAltName Sequence extension absente certificatePolicies Sequence certPolicyId OID any-policy certPolicyQualifier OID http://igc-sante.esante.gouv.fr/PC basicConstraints Sequence critical Boolean true CA Boolean true pathLenConstraint Integer 0 : ACI « terminale » crlDistributionPoint Sequence URL CRL ACR < Gamme > (HTTP + LDAP) authorityInfoAccess Sequence extension absente signatureAlgorithm OID Sha2-WithRSAencryption signatureValue BitString Signature par ACR < Gamme >



4.5 Les certificats OCSP des AC Intermédiaires Les certificats OCSP sont des certificats utilisateur particuliers ; ils servent à signer les réponses des répondeurs OCSP.

Il y a une URL unique pour interroger le répondeur OCSP de l’IGC-Santé.

Toutefois, chaque domaine dispose de son propre certificat OCSP pour signer ses réponses.

Objet Format Données du certificat OCSP de l’ACI < Gamme > < Domaine > Gabarits : < GG >-< DD >-OCSP


issuer

PrintString c=FR

UTF8String

o=ASIP-SANTE ou=0002 187512751 ou=IGC-SANTE cn=AC IGC-SANTE < Gamme > < Domaine >

validity UTC-Time NotBefore : date/heure de génération NotAfter : date NotBefore + 3 mois

subject

PrintString c=FR

UTF8String

o=ASIP-SANTE ou=0002 187512751 ou=IGC-SANTE cn=SERVICE OCSP IGC-SANTE < Gamme > < Domaine >

subjectPublicKeyInfo Sequence algorithmIdentifier OID RSAencryption (Parameter = NULL) subjectPublicKey BitString clé publique de 2.048 bits + exposant publique ( = 2E16+1) extensions Sequence authorityKeyId OctString subjectKeyId du certificat ACI < Gamme > < Domaine > subjectKeyId OctString SHA1 de subjectPublicKey keyUsage Sequence critical Boolean true value BitString '80' : digitalSignature extendedKeyUsage Sequence id-kp-OCSPSigning subjectAltName Sequence extension absente certificatePolicies Sequence certPolicyId OID PC-< GG >-< DD >-OCSP certPolicyQualifier OID http://igc-sante.esante.gouv.fr/PC basicConstraints Sequence critical Boolean false CA Boolean false pathLenConstraint Integer absent crlDistributionPoint Sequence extension absente

authorityInfoAccess Sequence id-pkix-ocsp-nocheck = NULL Sequence URL du certificat ACI < Gamme > < Domaine >

productCategory OctString '02' : Module de sécurité (production) productType Integer extension absente tokenID PrintString extension absente signatureAlgorithm OID Sha2-WithRSAencryption signatureValue BitString Signature par ACI < Gamme > < Domaine >



4.6 Les certificats utilisateur de personnes physiq ues L’étape 1 de l’IGC-Santé offre dans le Domaine « Personnes » de la Gamme « Elémentaire » les produits suivants :

o certificat de signature gabarit : EL-PP-CL-SIGN,

o certificat d’authentification gabarit : EL-PP-CL-AUTH,

o certificat de chiffrement gabarit : EL-PP-CL-CONF.

Note : Il n’y a pas de recouvrement de clés privées de chiffrement en étape 1.



4.6.1 Certificats de signature et d’authentificatio n d’une personne physique

Objet Format Certificat de signature gabarit : EL-PP-CL-SIGN

Certificat d’authentification gabarit : EL-PP-CL-AUTH


issuer

PrintString c=FR

UTF8String

o=ASIP-SANTE ou=0002 187512751 ou=IGC-SANTE cn=AC IGC-SANTE ELEMENTAIRE PERSONNES

validity UTC-Time NotBefore : date de génération du certificat NotAfter : date NotBefore + 3 ans + 1 mois

NotBefore : date de génération du certificat NotAfter : date NotBefore + 3 ans

subject

PrintString country

UTF8String autres RDN

DN d'un PS ou PF ou

DN d'un PS ou PF rattaché à une structure ou

DN d'un Personnel de structure

subjectPublicKeyInfo Sequence algorithmIdentifier OID RSAencryption (Parameter = NULL) subjectPublicKey BitString clé publique de 2.048 bits + exposant publique ( = 2E16+1) extensions Sequence authorityKeyId OctString subjectKeyId du certificat ACI ELEMENTAIRE PERSONNES subjectKeyId OctString SHA1 de subjectPublicKey keyUsage Sequence critical Boolean true true value BitString '40' : nonRepudiation '80' : digitalSignature extendedKeyUsage Sequence id-kp-emailProtection id-kp-clientauth + szoid_kp_smartcard_logon

privKeyUsagePeriod GenTime NotBefore : date de génération du certificat NotAfter : date NotBefore + 3 ans

extension absente

subjectAltName Sequence rfc822Name= @ mail - optionnel rfc822Name = @ mail - optionnel othername = UPN - optionnel

certificatePolicies Sequence certPolicyId OID PC-EL-PP-CL-SIGN PC-EL-PP-CL-AUTH certPolicyQualifier OID http://igc-sante.esante.gouv.fr/PC basicConstraints Sequence critical Boolean false CA Boolean false pathLenConstraint Integer absent crlDistributionPoint Sequence URL CRL ACI EL-PP (HTTP + LDAP) freshestCrl Sequence URL delta-CRL ACI EL-PP (LDAP)

authorityInfoAccess Sequence http://ocsp.esante.gouv.fr (répondeur OCSP) Sequence URL du certificat ACI EL-PP

QCStatements Sequence extension absente productCategory OctString '03' : certificat logiciel (production) productType Integer extension absente tokenID PrintString extension absente professionCode Integer code de la profession - optionnel - que pour les PS futureProfessionCode Integer code de la future profession - optionnel - que pour les PF oldPS_IDNat PrintString Ancien PS_IdNat - optionnel - que pour les PS avec identifiant RPPS specialiteRPPS Sequence Spécialité RPPS - optionnelle - que pour les Médecins et Chirurgiens-dentistes tableauxPharmacien Sequence Tableau(x) pharmacien - optionnel(s) - que pour les Pharmaciens signatureAlgorithm OID Sha2-WithRSAencryption signatureValue BitString Signature par ACI ELEMENTAIRE PERSONNES

Notes :

• Certificat de signature : signature S/MIME possible si subjectAltName contient « rfc822Name= @ mail ».

• Certificat d’authentification : Windows SC-Logon possible si subjectAltName contient « othername = UPN » et si le certificat est embarqué dans une CPx ou un support compatible PC/SC.



4.6.2 Certificat de chiffrement d’une personne phys ique

Objet Format Certificat de chiffrement gabarit : EL-PP-CL-CONF


issuer

PrintString c=FR

UTF8String

o=ASIP-SANTE ou=0002 187512751 ou=IGC-SANTE cn=AC IGC-SANTE ELEMENTAIRE PERSONNES

validity UTC-Time NotBefore : date de génération du certificat NotAfter : date NotBefore + 3 ans

subject

PrintString country


DN d'un PS ou PF ou

DN d'un PS ou PF rattaché à une structure ou

DN d'un Personnel de structure

subjectPublicKeyInfo Sequence algorithmIdentifier OID RSAencryption (Parameter = NULL) subjectPublicKey BitString clé publique de 2.048 bits + exposant publique ( = 2E16+1) extensions Sequence authorityKeyId OctString subjectKeyId du certificat ACI ELEMENTAIRE PERSONNES subjectKeyId OctString SHA1 de subjectPublicKey keyUsage Sequence critical Boolean true value BitString '20' : keyEncipherment extendedKeyUsage Sequence id-kp-emailProtection + anyExtendedKeyUsage privKeyUsagePeriod GenTime Extension absente subjectAltName Sequence rfc822Name= @ mail - optionnel certificatePolicies Sequence certPolicyId OID PC-EL-PP-CL-CONF certPolicyQualifier OID http://igc-sante.esante.gouv.fr/PC basicConstraints Sequence critical Boolean false CA Boolean false pathLenConstraint Integer absent crlDistributionPoint Sequence URL CRL ACI EL-PP (HTTP + LDAP) freshestCrl Sequence URL delta-CRL ACI EL-PP (LDAP)

authorityInfoAccess Sequence http://ocsp.esante.gouv.fr (répondeur OCSP) Sequence URL du certificat ACI EL-PP

QCStatements Sequence extension absente productCategory OctString '03' : certificat logiciel (production) productType Integer extension absente tokenID PrintString extension absente professionCode Integer code de la profession - optionnel - que pour les PS futureProfessionCode Integer code de la future profession - optionnel - que pour les PF oldPS_IDNat PrintString Ancien PS_IdNat - optionnel - que pour les PS avec identifiant RPPS specialiteRPPS Sequence Spécialité RPPS - optionnelle - que pour les Médecins et Chirurgiens-dentistes tableauxPharmacien Sequence Tableau(x) pharmacien - optionnel(s) - que pour les Pharmaciens signatureAlgorithm OID Sha2-WithRSAencryption signatureValue BitString Signature par ACI ELEMENTAIRE PERSONNES

Note :

• Certificat de chiffrement : chiffrement S/MIME possible si subjectAltName contient « rfc822Name= @ mail ».



4.7 Les certificats utilisateur d’organisations L’étape 1 de l’IGC-Santé offre dans le Domaine « Organisations » de la Gamme « Elémentaire » les produits suivants :

o certificat de cachet (signature par serveur) gabarit : EL-ORG-CL-SIGN,

o certificat d’authentification client gabarit : EL-ORG-CL-AUTH_CLI,

o certificat d’authentification serveur et client gabarit : EL-ORG-CL-SSL_SERV,

o certificat de chiffrement gabarit : EL-ORG-CL-CONF,

o certificat S/MIME (signature + chiffrement) gabarit : EL-ORG-CL-SMIME.

Note : Il n’y a pas de recouvrement de clés privées de chiffrement en étape 1.



4.7.1 Certificats de cachet et d’authentification d ’une structure

Objet Format Certificat de cachet gabarit : EL-ORG-CL-SIGN

Certificat d’authentification Client gabarit : EL-ORG-CL-AUTH_CLI


issuer

PrintString c=FR

UTF8String

o=ASIP-SANTE ou=0002 187512751 ou=IGC-SANTE cn=AC IGC-SANTE ELEMENTAIRE ORGANISATIONS


NotBefore : date de génération du certificat NotAfter : date NotBefore + 3 ans

subject

PrintString country


DN d'un certificat de structure

subjectPublicKeyInfo Sequence algorithmIdentifier OID RSAencryption (Parameter = NULL) subjectPublicKey BitString clé publique de 2.048 bits + exposant publique ( = 2E16+1) extensions Sequence authorityKeyId OctString subjectKeyId du certificat ACI ELEMENTAIRE ORGANISATIONS subjectKeyId OctString SHA1 de subjectPublicKey keyUsage Sequence critical Boolean true true value BitString 'C0' : digitalSignature + nonRepudiation '80' : digitalSignature extKeyUsage Sequence id-kp-emailProtection id-kp-clientauth


extension absente

subjectAltName Sequence rfc822Name = @ mail - optionnel rfc822Name = @ mail - optionnel certificatePolicies Sequence certPolicyId OID PC-EL-PP-CL-SIGN PC-EL-PP-CL-AUTH_CLI certPolicyQualifier OID http://igc-sante.esante.gouv.fr/PC basicConstraints Sequence critical Boolean false CA Boolean false pathLenConstraint Integer absent crlDistributionPoint Sequence URL CRL ACI EL-ORG (HTTP + LDAP) freshestCrl Sequence URL delta-CRL ACI EL-ORG (LDAP)

authorityInfoAccess Sequence http://ocsp.esante.gouv.fr (répondeur OCSP) Sequence URL du certificat ACI EL-ORG

QCStatements Sequence extension absente productCategory OctString '03' : certificat logiciel (production) productType Integer extension absente tokenID PrintString extension absente signatureAlgorithm OID Sha2-WithRSAencryption signatureValue BitString Signature par ACI ELEMENTAIRE ORGANISATIONS

Notes :

• Certificat de cachet : signature S/MIME possible si subjectAltName contient « rfc822Name= @ mail ».



4.7.2 Certificats d’authentification serveur et de chiffrement d’une structure

Objet Format Certificat Authentification Serveur gabarit : EL-ORG-CL-SSL_SERV

Certificat de chiffrement gabarit : EL-ORG-CL-CONF


issuer

PrintString c=FR

UTF8String


validity UTC-Time NotBefore : date de génération du certificat NotAfter : date NotBefore + 3 ans

subject

PrintString country


DN d'un certificat de structure (le cn doit contenir un FQDN)


subjectPublicKeyInfo Sequence algorithmIdentifier OID RSAencryption (Parameter = NULL) subjectPublicKey BitString clé publique de 2.048 bits + exposant publique ( = 2E16+1) extensions Sequence authorityKeyId OctString subjectKeyId du certificat ACI ELEMENTAIRE ORGANISATIONS subjectKeyId OctString SHA1 de subjectPublicKey keyUsage Sequence critical Boolean true true value BitString 'A0' : digitalSignature + keyEncipherment '20' : keyEncipherment extendedKeyUsage Sequence id-kp-serverAuth + id-kp-clientauth id-kp-emailProtection + anyExtendedKeyUsage privKeyUsagePeriod GenTime Extension absente

subjectAltName Sequence

dnsName=FQDN dans cn Le dnsName peut être multi-valué, celui en 1ère position doit contenir le FQDN du cn.

rfc822Name= @ mail - optionnel

rfc822Name= @ mail - optionnel

certificatePolicies Sequence certPolicyId OID PC-EL-ORG-CL-SSL_SERV PC-EL-ORG-CL-CONF certPolicyQualifier OID http://igc-sante.esante.gouv.fr/PC basicConstraints Sequence critical Boolean false CA Boolean false pathLenConstraint Integer absent crlDistributionPoint Sequence URL CRL ACI EL-ORG (HTTP + LDAP) freshestCrl Sequence URL delta-CRL ACI EL-ORG (LDAP)



Note :

• Certificat de chiffrement : chiffrement S/MIME possible si subjectAltName contient « rfc822Name= @ mail ».



4.7.3 Certificat S/MIME d’une structure

Objet Format Certificat S/MIME gabarit : EL-ORG-CL-SMIME


issuer

PrintString c=FR

UTF8String



subject

PrintString country



subjectPublicKeyInfo Sequence algorithmIdentifier OID RSAencryption (Parameter = NULL) subjectPublicKey BitString clé publique de 2.048 bits + exposant publique ( = 2E16+1) extensions Sequence authorityKeyId OctString subjectKeyId du certificat ACI ELEMENTAIRE ORGANISATIONS subjectKeyId OctString SHA1 de subjectPublicKey keyUsage Sequence critical Boolean true value BitString '60' : nonRepudiation + keyEncipherment extendedKeyUsage Sequence id-kp-emailProtection


subjectAltName Sequence rfc822Name= @ mail - obligatoire certificatePolicies Sequence certPolicyId OID PC-EL-ORG-CL-SMIME certPolicyQualifier OID http://igc-sante.esante.gouv.fr/PC basicConstraints Sequence critical Boolean false CA Boolean false pathLenConstraint Integer absent crlDistributionPoint Sequence URL CRL ACI EL-ORG (HTTP + LDAP) freshestCrl Sequence URL delta-CRL ACI EL-ORG (LDAP)





5 Les structures des CRLs de l’IGC-Santé

5.1 La structure d'une CRL X.509 version 2 Une CRL est composée de 2 parties :

• Les données à certifier. Elles contiennent les champs de base, la liste de certificats à révoquer et les extensions.

• La signature de la CRL : sa valeur et les informations sur l’algorithme de signature.

CRL (Certification Revocation List)

Données de la CRL

Version 2

Informations sur la signature de la CRL par l’AC (algorithmes et paramètres)

Nom de l’émetteur de la CRL

Date d’émission de la CRL

Date d’émission de la prochaine CRL

Liste des certificats révoqués

Numéro de série du certificat révoqué

Date de révocation

Extensions d’entrée de CRL



…

Numéro de série du certificat révoqué

Date de révocation

Extensions d’entrée de CRL



…

…

Extensions du CRL




…

Signature de la CRL par l’AC

Informations sur l’algorithme de signature de la CRL

Valeur de la signature numérique de la CRL par l’Autorité de Certification

Schéma du contenu d'une CRL version 2 La syntaxe des CRL de l’IGC-Santé est spécifiée en Annexe § A 2.2 « La syntaxe des CRL de l’IGC-Santé ».



5.1.1 Les champs de base

Les champs de base d’une CRL renseignent les informations suivantes :

• la version de la structure de la CRL (version = 2),

• les informations sur la signature de la CRL par l’AC (algorithmes et paramètres),

• le nom de l’émetteur de la CRL,

• la date de l’émission de la CRL,

• la date de l’émission de la prochaine CRL,

• la liste de certificats révoqués composée :

- du numéro de série du certificat révoqué,

- de la date de révocation,

- des extensions d’entrée de CRL (optionnel).

5.1.2 Extensions d’entrée de CRL

Une extension d’entrée de CRL permet de donner plus d’information quant aux conditions de la révocation d’un certificat, i.e. :

• Code raison (valeur par défaut = '0' : undefined)

• Date (supposée) d'incident provoquant la révocation

Note :

Les extensions d’entrée de CRL ne sont pas renseignées dans l’IGC-Santé.

5.1.3 Extensions de CRL

Les extensions de CRL permettent de spécifier plus précisément les caractéristiques de la CRL :

• le numéro de CRL,

• l’indicateur delta-CRL,

• les informations sur la clé du signataire de la CRL,

• le nom alternatif de l’émetteur de la CRL.



5.2 Les CRL de l’IGC-Santé

5.2.1 La structure des CRL

Objet Format CRL d’une < Gamme > (ACR) CRL d’un < Domaine > (ACI)

CertificateList Sequence TbsCertList Sequence Version Integer 1 (version 2) signature OID Sha2-WithRSAencryption

issuer UTF8String

cn=AC RACINE IGC-SANTE < Gamme > ou=IGC-SANTE ou=0002 187512751 o=ASIP-SANTE

cn=AC IGC-SANTE < Gamme > < Domaine > ou=IGC-SANTE ou=0002 187512751 o=ASIP-SANTE

PrintString c=FR c=FR thisUpdate UTC-Time « date / heure d'émission CRL » nextUpdate UTC-Time « date / heure d'émission prévue prochaine CRL »

revokedCertificates Sequence integer Time

Séquence avec liste de certificats révoqués, pour chaque entrée : (séquence absente si vide) userCertificate revocationDate

crlExtensions Sequence authorityKeyId OctString subjectKeyId du certificat ACR < Gamme > subjectKeyId du certificat ACI < Gamme > < Domaine > crlNumber Integer n° séquentiel de la CRL (la numérotation est indépendante pour toutes les ACR et ACI) deltaCrlIndicator Sequence extension absente

freshestCrl Sequence extension absente URL delta-CRL ACI < Gamme > < Domaine >

(LDAP) signatureAlgorithm OID Sha2-WithRSAencryption signatureValue BitString Signature par ACR < Gamme > Signature par ACI < Gamme > < Domaine > "

5.2.2 La structure des delta-CRL

A chaque publication d’une CRL par une ACI, une delta-CRL doit être publiée simultanément.

Par rapport à la CRL elle contient :

• le même contenu pour les extensions thisUpdate, nextUpdate et crlNumber,

• une extension deltaCrlIndicator avec le crlNumber de la CRL précédente,

• la liste des certificats révoqués depuis la publication de la CRL précédente.

Objet Format delta-CRL d’un < Domaine > (ACI)

CertificateList Sequence TbsCertList Sequence Version Integer 1 (version 2) signature OID Sha2-WithRSAencryption

issuer UTF8String

cn=AC IGC-SANTE < Gamme > < Domaine > ou=IGC-SANTE ou=0002 187512751 o=ASIP-SANTE

PrintString c=FR thisUpdate UTC-Time « date / heure d'émission CRL » nextUpdate UTC-Time « date / heure d'émission prévue prochaine CRL »

revokedCertificates Sequence integer Time

Séquence avec liste de certificats révoqués, pour chaque entrée : (séquence absente si vide) userCertificate revocationDate

crlExtensions Sequence authorityKeyId OctString subjectKeyId du certificat ACI < Gamme > < Domaine > crlNumber Integer n° séquentiel de la CRL de référence deltaCrlIndicator Sequence critical Boolean true baseCrlNumber BitString n° séquentiel de la CRL précédente freshestCrl Sequence extension absente signatureAlgorithm OID Sha2-WithRSAencryption signatureValue BitString Signature par ACI < Gamme > < Domaine > "



6 L’IGC-Santé de Test Pour des besoins de test, une IGC-Santé de Test est créée avec exactement la même architecture que l’IGC-Santé de Production.

Les certificats de test se distinguent sur les points suivants :

• Les DN des autorités émettrices (ACR et ACI) ont les RDN « cn » et « ou » qui contiennent le mot « TEST ». Les DN des utilisateurs finaux ne contiennent pas d’information permettant de distinguer un certificat de Production d’un certificat de Test.

• Il y a une seule PC, et donc un OID unique, pour tous les certificats utilisateur de l'IGC-Santé de Test. Cf. § A 3.2.2 « Les identifiants d'objets attribués par l’ASIP-Santé ».

• L’extension productCategory : Le bit de poids fort de sa valeur est égal à ‘1’. Cf. § A 2.1.2.1 « productCategory ».

• L’UPN dans l’extension subjectAltName : Pour les certificats d’authentification embarqués dans les CPx de Test, le domaine de l’UPN est « test.carte-cps ». Cf. § A 2.1.1.6 « subjectAltName ».

6.1 Schéma de nommage des AC de Test Les DN des ACR et ACI de Test se distinguent par les RDN « cn » et « ou » qui contiennent le mot « TEST ».

Nom gabarit DN des Autorités de Certification de Test

<Gamme>-ACR DN du certificat racine <Gamme>

c= FR o= ASIP-SANTE

ou= 0002 187512751 ou= IGC-SANTE TEST cn= TEST AC RACINE IGC-SANTE <Gamme>

<Gamme>-PP-ACI DN du certificat racine intermédiair e - Personnes Physiques c= FR o= ASIP-SANTE

ou= 0002 187512751 ou= IGC-SANTE TEST cn= TEST AC IGC-SANTE <Gamme> PERSONNES

<Gamme>-ORG-ACI DN du certificat racine intermédiai re - Organisations c= FR o= ASIP-SANTE

ou= 0002 187512751 ou= IGC-SANTE TEST cn= TEST AC IGC-SANTE <Gamme> ORGANISATIONS

Une application doit détecter les certificats et CRL de Test en vérifiant si le « cn » de l’autorité émettrice commence par « TEST ».



Annexe 1 Conventions, Abréviations et définitions

A 1.1 Conventions de notation

ASCII 1 octet hexadécimal contenant un caractère au standard ASCII

bcd binary coded decimal quartet (4 bits) pouvant prendre la valeur de ‘0’ à ‘9’

octet 8 bits hexadécimaux pouvant prendre la valeur de ‘00’ à ‘FF’ (0 à 255 décimal)

quartet 4 bits hexadécimaux pouvant prendre la valeur de ‘0’ à ‘F’ (0 à 15 décimal)

printableString chaîne de caractères ASCII pouvant contenir les caractères suivants : A, B, ..., Z a, b, ..., z 0, 1, ..., 9 espace ' ( ) + , - . / : = ?

UTF8String chaîne de caractères internationaux d'Unicode

octetString chaîne d’octets hexadécimaux

bool booléen (1 bit) pouvant prendre la valeur ‘0’ ou ‘1’

0 à 9 caractères décimaux

'0' à '9' et 'A' à 'F' caractères hexadécimaux

'xxx' chaîne de quartets hexadécimaux

"ABC" chaîne de caractères alpha-numériques

|| concaténation

≠ différent

[ ] paramètre optionnel



A 1.2 Définitions Les définitions formulées dans ce paragraphe adaptées au contexte de l’IGC-Santé.

� IGC : Une Infrastructure de Gestion de Clefs est un ensemble de composants physiques (des ordinateurs, des équipements cryptographiques ou HSM, des cartes à puces), de procédures humaines (vérifications, validations) et de logiciels (systèmes et applications) en vue de gérer le cycle de vie des clés et certificats électroniques.

Une IGC est notamment composée d'au moins une autorité de certification et d’au moins une autorité d'enregistrement chargée de vérifier les données d'identification des utilisateurs de certificat électronique, et de contrôler les droits liés à l'utilisation des certificats électroniques conformément à la politique de certification.

Pour le terrain, une IGC est caractérisée par sa ch aîne de confiance, nécessaire pour la validation des certificats utilisateur (vérifica tion que les certificats ont bien été émis par une IGC de confiance).

� Certificat : c'est une pièce d'identité électronique dont l'objet est de lier une entité physique (personne ou serveur) à une entité numérique. Il est émis par une autorité de certification qui joue le rôle de tiers de confiance et qui atteste du lien entre l'identité physique et l'entité numérique. Un certificat contient, outre l'identité du porteur, sa clé publique et son usage autorisé (signature, chiffrement, …) � certificat racine (ACR) : c'est le certificat qui atteste l'identité de l'autorité de certification à

l’origine de la chaîne de confiance. Il est auto-signé ce qui explique que l'introduction d'un tel certificat dans une base de confiance nécessite une validation explicite par l'administrateur d'un système.

� certificat intermédiaire (ACI) : c'est le certificat qui atteste l'identité d'une « sous-autorité de certification » responsable de la signature des certificats utilisateur pour un domaine donné. Il est signé par le certificat racine de l'autorité de certification.

� certificat utilisateur : c'est une identité numérique dont le porteur est une personne, une organisation ou un serveur applicatif. Dans l'IGC-Santé, un tel certificat est signé par l'autorité intermédiaire responsable du domaine de certificats à laquelle il appartient.

� Gabarit d’un certificat : spécification d’un certificat, détaillant sa structure, l’ensemble des champs le composant ainsi que son paramétrage.

� Chaîne de confiance : une chaîne de confiance est constituée d'autorités de certification intermédiaires et du certificat racine d'une autorité de certification.

� Parenté : la parenté d'un certificat est une chaîne propre à ce certificat constituée du certificat de l'autorité intermédiaire du domaine à lequel il appartient et du certificat racine de l'autorité de certification.



A 1.3 Abréviations

AC Autorité de Certification

ACI Autorité de Certification Intermédiaire

ACR Autorité de Certification Racine

CRL Certification Revocation List ou Liste de Certificats Révoqués (LCR)

ARL Authority Certification Revocation List ou Liste de certificats Autorité Révoqués (LAR) Dans ce document on utilise uniquement le terme CRL.

CDE Carte de Directeur d'Etablissement de Santé

CPA Carte de Personnel Autorisé

CPE Carte de Personnel d'Etablissement

CPF Carte de Professionnel de Santé en Formation

CPS Carte de Professionnel de Santé

CPx N’importe quel type de carte dans la famille CPS

CPS3 Carte de Professionnel de Santé de la 3ème génération

CDA Carte de Directeur d'un Etablissement autre que ES (ou CPA-Responsable)

DN Distinguished Name – identifiant unique du porteur d’un certificat

IGC Infrastructure de Gestion de Clés

KP Clé Publique

PC Politique de Certification

PE Personnel(s) d’Etablissement

PF Professionnel(s) de Santé en Formation

PFC-NG Plate-Forme de Certification – Nouvelle Génération

PS Professionnel(s) de Santé

RDN Relative Distinguished Name

UPN UserPrincipalName



Annexe 2 La syntaxe des certificats et CRL de l’IGC -Santé

A 2.1 La syntaxe des Certificats X.509 v3 de l’IGC- Santé Certificate ::= SEQUENCE {

TbsCertificate TBSCertificate,

SignatureAlgorithm AlgorithmIdentifier,

SignatureValue BIT STRING }

tbsCertificate ::= SEQUENCE {

version [0] Version (v3),

serialNumber CertificateSerialNumber,

signature AlgorithmIdentifier,

issuer Name,

validity Validity,

subject Name,

subjectPublicKeyInfo SubjectPublicKeyInfo,

extensions [3] Extensions }

Version ::= INTEGER v3( valeur = 2 )

CertificateSerialNumber ::= INTEGER

AlgorithmIdentifier ::= SEQUENCE {

Algorithm OBJECT IDENTIFIER,

Parameters ANY DEFINED BY Algorithm OPTIONAL }

Name ::= CHOICE {RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguished Name

RelativeDistinguishedName ::= SET OF AttributeTyp eAndValue

AttributeTypeAndValue ::= SEQUENCE {

type AttributeType,

value AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY DEFINED BY AttributeType

Validity ::= SEQUENCE {

notBefore UTCTime,

notAfter UTCTime } 3

SubjectPublicKeyInfo ::= SEQUENCE {

algorithm AlgorithmIdentifier,

subjectPublicKey BIT STRING }

Extensions ::= SEQUENCE OF Extension

Extension ::= SEQUENCE {

extnId OBJECT IDENTIFIER,

critical BOOLEAN, (default = FALSE)

extnValue OCTET STRING }

3 Format du champ UTCTime : « YYMMDDMMSS »



A 2.1.1 Extensions standards utilisées dans les cer tificats de l’IGC-Santé Les extensions contiennent des informations complémentaires du certificat.

Ce paragraphe contient les extensions standards utilisées dans les Certificats X.509 de l’IGC-Santé.

Sauf mention spécifique, les extensions sont non cr itiques.

A 2.1.1.1 authorityKeyIdentifier

Cette extension identifie la clé publique à utiliser pour la vérification de la signature du certificat.

AuthorityKeyIdentifier ::= SEQUENCE {

keyIdentifier [0] KeyIdentifier OPTIONAL,

authorityCertIssuer [1] GeneralNames OPTIONAL,

authorityCertSerialNumber [2] CertificateSerialNumb er OPTIONAL }

KeyIdentifier ::= OCTET STRING

Dans les certificats de l’IGC-Santé, l’extension AuthorityKeyIdentifier est le hash de la séquence complète RSAPublicKey .

A 2.1.1.2 subjectKeyIdentifier

Cette extension identifie la clé publique qui est certifiée. Elle permet de différencier plusieurs clés d'un porteur identifié par un même DN.

SubjectKeyIdentifier ::= KeyIdentifier


Dans les certificats de l’IGC-Santé, l’extension SubjectKeyIdentifier est le hash de la séquence complète RSAPublicKey .

A 2.1.1.3 keyUsage - extension critique

Cette extension définit la fonction de base autorisée du bi-clé dont la clé publique est certifiée.

KeyUsage ::= BIT STRING {

digitalSignature (0), '80' authentification

nonRepudiation (1), '40' signature électronique

keyEncipherment (2), '20' chiffrement de clés

dataEncipherment (3), non utilisée

keyAgreement (4), non utilisée

keyCertSign (5), '04' signature de certificats

crlSign (6), '02' signature de CRLs

encipherOnly (7), non utilisée

decipherOnly (8) } non utilisée



A 2.1.1.4 extendedKeyUsage

Cette extension définit l'utilisation applicative autorisée du bi-clé dont la clé publique est certifiée.

C’est un complément d'information à l'extension keyUsage.

ExtendedKeyUsage ::= SEQUENCE SIZE (1..MAX) OF KeyP urposeId

KeyPurposeId ::= OBJECT IDENTIFIER

anyExtendedKeyUsage tout utilisation étendue est a utorisée

id-kp-serverAuth TLS Web authentification serveur

id-kp-clientAuth TLS Web authentification client

id-kp-codeSigning signature de code (téléchargeabl e)

id-kp-emailProtection protection messagerie électr onique

id-kp-timeStamping horodatage (signature)

id-kp-OCSPSigning répondeur OCSP (signature)

szoid_kp_smartcard_logon smartCardLogon (Microsoft )

Note : L’extendedKeyUsage SmartCardLogon est présent dans tous les certificats d’authentification de personnes physiques. La fonction Windows SmartCardLogon ne peut être mise en œuvre que si le certificat d’authentification est embarqué dans une carte CPx ou un autre support compatible PC-SC.

A 2.1.1.5 privateKeyUsagePeriod

Cette extension définit la période d'utilisation de la clé privée, dans le cas où cette période est différente de celle de validité du certificat.

Dans l’IGC-Santé, cette extension est uniquement présente dans les certificats utilisateur permettant la signature électronique (certificats avec keyUsage = nonRepudiation).

Elle réduit l’usage de la clé privée de signature d’un mois par rapport à la date de fin de validité du certificat. Grâce à ce mécanisme, la « non-révocation » des certificats de signature peut être vérifiée jusqu’à un mois après la date de fin de validité ( = date fin de l’usage) de la clé privée.

PrivateKeyUsagePeriod ::= SEQUENCE {

NotBefore [0] GeneralizedTime : 1 st day of validity

NotAfter [1] GeneralizedTime : last day of validity } 4

Il est recommandé aux applications d’exploiter cette extension et, par conséquent, ne pas utiliser la clé privée de signature en dehors de la période spécifiée qui finit 1 mois avant la fin de validité du certificat.

Faute de quoi, le destinataire d’un objet signé risque de rejeter la signature lors de sa vérification ; en effet, le destinataire ne pourra plus vérifier la non-révocation d’un certificat si ce dernier a expiré car il aura été supprimé de la CRL.

4 Format du champ GeneralizedTime : « YYYYMMDDMMSS » (heure GMT).



A 2.1.1.6 subjectAltName

Cette extension peut contenir un ou plusieurs noms alternatifs pour le porteur du certificat.

SubjectAltName ::= GeneralNames

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralN ame

GeneralName ::= CHOICE {

othername [0] AnotherName,

rfc822Name [1] IA5String,

dNSName [2] IA5String,

x400Address [3] ORAddress,

directoryName [4] Name,

ediPartyName [5] EDIPartyName,

uniformResourceIdentifier [6] IA5String,

iPAddress [7] OCTET STRING,

registeredID [8] OBJECT IDENTIFIER }

Cette extension n'est pas utilisée dans les certificats des AC.

Dans l’IGC-Santé, les extensions suivantes sont utilisées dans les certificats utilisateur :

• rfc822Name (adresse mail) :

o obligatoire pour les gabarits S/MIME (messagerie sécurisée),

o optionnelle pour les autres gabarits.

• dNSName (nom de domaine) :

o obligatoire pour les gabarits SSL serveur et VPN serveur.

• othername contenant un UserPrincipalName (nom d’utilisateur pour Windows SmartCardLogon),

o obligatoire pour les certificats d’authentification embarqués dans des CPx,

o optionnelle pour les certificats d’authentification logiciels de personnes physiques,

o interdit dans tous les autres certificats.

Dans les certificats d’authentification logiciels d e personnes physiques , UPN est fourni par le demandeur du certificat. L’UPN doit être conforme au format : < nom_utilisateur > @< nom_domaine >

Dans une carte CPx , l’UPN est construit à partir de l’identifiant national du porteur de la carte (PS_IdNat), selon les règles énoncées ci-dessous.

Pour les PS et PF , le PS_IdNat du porteur de la carte est structuré comme suit :

<Type d’identifiant><Identifiant du registre nation al>

A partir de cet identifiant, leur UPN est construit comme suit :

<Type d’identifiant>.<Identifiant du registre natio nal>@carte-cps.fr

Notes :

• Un point est inséré dans le PS_IdNat entre le type d’identifiant et la suite de l’identifiant. • Le PS_IdNat d’un porteur fait au maximum 31 caractères. L’UPN fait donc au maximum 46 caractères. • Pour les CPx de Test, le nom de domaine est « test.carte-cps.fr » .

Exemples d’UPN pour des PS : • [email protected] UPN construit à partir du PS_IdNat 0751012344 • [email protected] UPN construit à partir du PS_IdNat 899700000011



Pour le personnel de structure , le PS_IdNat du porteur de la carte est structuré comme suit :

<Type d’identifiant><Identifiant de la structure>/< Identifiant du registre interne>

A partir de cet identifiant, leur UPN est construit comme suit :

<Type d’identifiant>.<Identifiant de la structure>. <Identifiant du registre interne>@carte-cps.fr

Notes :

• Un point est inséré dans le PS_IdNat entre le type d’identifiant et la suite de l’identifiant. • Le « / » est remplacé par un point. • Le PS_IdNat d’un porteur fait au maximum 31 caractères. L’UPN fait donc au maximum 46 caractères. • Pour les CPx de Test, le nom de domaine est « test.carte-cps.fr » .

Exemples d’UPN pour du personnel de structure : • [email protected] UPN construit à partir du PS_IdNat 118751275100039/0000010 • [email protected] UPN construit à partir du PS_IdNat 3123456789/0000321

A 2.1.1.7 certificatePolicies

Dans l’IGC-Santé, cette extension définit :

• la Politique de Certification dont le certificat dépend (policyIdentifier),

• un pointeur « Certificate Policy Statement URI » (cPSuri) vers une page web contenant :

o des informations génériques sur l'IGC-Santé de Production,

o les PC et les Conditions d'utilisation,

o les liens pour télécharger les certificats ACR et ACI ainsi que leurs CRL et delta-CRL.

Notes :

• Certificats de production : il y a une PC distincte pour chaque type de certificat de chaque domaine,

• Certificats de Test : il y une seule PC pour l’ensemble des certificats de Test de l’IGC-Santé. Le § A 3.2.2 « Les identifiants d'objets attribués par l’ASIP-Santé » donne les OID des PC de l’IGC-Santé.

CertificatePolicies ::= SEQUENCE OF PolicyInformati on

PolicyInformation ::= SEQUENCE {

policyIdentifier CertPolicyId, policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL }

CertPolicyId ::= OBJECT IDENTIFIER

PolicyQualifierInfo ::= SEQUENCE {

policyQualifierId PolicyQualifierId, qualifier ANY DEFINED BY policyQualifierId }

PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

Qualifier ::= CHOICE {

cPSuri CPSuri,

userNotice UserNotice }

CPSuri ::= IA5String Note :

• L’objet « UserNotice » n’est pas utilisé dans l’IGC-Santé.



A 2.1.1.8 basicConstraints - extension critique pour les certificats AC

Cette extension précise si le certificat appartient à une Autorité de Certification (Racine ou Intermédiaire) ou à un utilisateur final. Dans le premier cas, l’extension permet également de spécifier le nombre de niveaux hiérarchiques autorisés.

BasicConstraints ::= SEQUENCE {

CA BOOLEAN (default = FALSE)

pathLenConstraint INTEGER }

Dans l’IGC-Santé, cette extension est présente dans tous les certificats.

Pour les certificats des Autorités de Certification (ACR et ACI) :

• l’extension est critique,

• CA = "TRUE",

• pathLenConstraint :

o certificats ACR : valeur absente, indiquant qu’il n’y a pas de limite sur le nombre de niveaux ACI,

o certificats ACI : « valeur = ‘0’ » indique que le certificat ne peut qu’être utilisé pour signer des certificats d’utilisateurs finaux.

Pour les certificats des utilisateurs finaux :

• l’extension n’est pas critique,

• CA = "FALSE",

• pathLenConstraint interdit.

A 2.1.1.9 crlDistributionPoint

Cette extension définit l’adresse du point de distribution des CRL.

CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {

distributionPoint [0] DistributionPointName, OPTION AL}

DistributionPointName ::= CHOICE {

fullName [0] GeneralNames,

nameRelativeToCRLIssuer [1] RelativeDistinguishedNa me }

Dans l’IGC-Santé, les adresses des points de distribution de CRL sont des identifiants de ressource (URI) désignant un point d’accès HTTP et un point d’accès LDAP.

Dans l’IGC-Santé, les CRL sont publiées quotidiennement.



A 2.1.1.10 freshestCRL (Delta-CRL Distribution Poi nt)

Cette extension définit l’adresse du point de distribution de delta-CRL. Elle a la même syntaxe ASN.1 que l’extension crlDistributionPoint.

Quand l’IGC-Santé publie une CRL, une delta-CRL avec le même numéro de séquence est publiée simultanément. Cette dernière contient alors tous les numéros de série des certificats révoqués depuis la publication de la CRL précédente.

FreshestCRL ::= CRLDistributionPoints

Dans l’IGC-Santé, l’adresse du point de distribution de delta-CRL est un identifiant de ressource (URI) désignant un point d’accès LDAP.

L’IGC-Santé publie avec chaque CRL de domaine ses 7 dernières delta-CRL.

Dans l’annuaire-CPS, les delta-CRL sont multi-valuées ; la réponse à une requête LDAP contient toutes les delta-CRL disponibles permettent aux applications de « rattraper » 7 jours sans devoir charger une CRL complète.

Les applications doivent tenir compte que ce nombre de 7 delta-CRL publiées est susceptible de varier (en plus et en moins).

A 2.1.1.11 authorityInfoAccess

Cette extension, présente uniquement dans des certificats utilisateur, contient 2 descriptions d’accès (type et méthode) fournissant de l’information additionnelle sur l’autorité ACI émettrice du certificat contenant cette extension :

• OCSP o pour les certificats OCSP : cette description d’accès contient l’indication que ce certificat ne

peut être vérifié par un répondeur OCSP (id-pkix-ocsp-nocheck),

o pour les autres certificats utilisateur, cette description d’accès contient l’URL du répondeur OCSP,

• caIssuers o cette description contient un URL HTTP pointant sur le certificat de l’ACI émettrice.

AuthorityInfoAccess ::= SEQUENCE SIZE (1..MAX) OF A ccessDescription

AccessDescription ::= SEQUENCE {

accessMethod OBJECT IDENTIFIER,

accessLocation GeneralName }

id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }



A 2.1.1.12 QCStatements

Cette extension peut contenir deux OID : • qcs-QcCompliance : indique que le certificat émis est qualifié conformément à la législation en

vigueur dans le pays dans lequel est établie l’AC,

• qcs-QcSSCD : indique que la clé privée correspondante est stockée dans un dispositif sécurisé de création de signature électronique (SSCD).

qcStatements ::= SEQUENCE OF QCStatement

QCStatement ::= SEQUENCE {

statementId QC-STATEMENT.&Id({SupportedStatements} ),

statementInfo QC-STATEMENT.&Type

({SupportedStatements}{@statementId}) OPTIONAL }

SupportedStatements QC-STATEMENT ::= { qcStatement- 1,...}



A 2.1.2 Extensions privées utilisées dans les certi ficats de l’IGC-Santé Les extensions privées contiennent des informations complémentaires du certificat ; leurs valeurs sont spécifiées dans la nomenclature de référence publiée par l’ASIP-Santé sur le site http://esante.gouv.fr 5.

Ce paragraphe spécifie les extensions privées utilisées dans les Certificats X.509 de l’IGC-Santé.

Aucune extension privée n’est critique.

A 2.1.2.1 productCategory

Cette extension, toujours présente, contient la catégorie de produit qui contient la clé privée.

Elle permet également de distinguer les produits de production des produits de Test.

productCategory ::= OctetString

'00' : Carte de la famille CPS

'80' : Carte de la famille CPS de TEST

'02' : Module de sécurité physique

'82' : Module de sécurité physique de TEST

'03' : Certificat logiciel

'83' : Certificat logiciel de TEST

Nomenclature : Table G01 – Catégories produits

A 2.1.2.2 productType

Selon la valeur de productCategory, cette extension est présente : (hors étape 1)

• toujours dans les certificats embarqués dans des cartes CPS ;

• optionnellement pour les modules de sécurité physiques ;

• jamais pour les certificats logiciels des certificats utilisateur de la Gamme Elémentaire.

Pour les certificats embarqués dans les cartes CPS (productCategory = ‘00’ ou ‘80’), elle contient le type de la carte.

productType ::= Integer

'00' : CPS

'01' : CPF

'02' : CPE ou CDE

'03' : CPA ou CDA (CPA-Responsable)

Nomenclature : Table G02 – Types de cartes CPS

Pour les certificats embarqués dans des Modules de sécurité physiques (productCategory = ‘02’ ou ‘82’), les valeurs de productType restent à définir. (hors étape 1)

5 Fichier ZIP actuellement disponible sur la page désignée par l’URL :

http://esante.gouv.fr/services/referentiels/interoperabilite/ci-sis-interoperabilite-semantique-composants-telechargeables



A 2.1.2.3 tokenID (extension conditionnelle)

Selon la valeur de productCategory, cette extension est présente : (hors étape 1)

• toujours dans les certificats embarqués dans des cartes CPS ;

• optionnellement pour les modules de sécurité physiques ;

• jamais pour les certificats logiciels des certificats utilisateur de la Gamme Elémentaire.

Si présente, cette extension contient l’identification de l'émetteur du token et son numéro de série.

tokenID ::= PrintableString

Pour les cartes CPS, elle contient l'identification de l'émetteur (Issuer Identification Number = IIN), spécifié et le numéro de série de la carte avec un « / » comme séparateur :

Format : "8025000001/9999999999" 80 250 00001 = l’IIN de l’ASIP-Santé 9999999999 = N° de série de la carte sur 10 chiffres

Pour les certificats embarqués dans des Modules de sécurité (productCategory = ‘02’ ou ‘82’), les valeurs de tokenID restent à définir. (hors étape 1)

A 2.1.2.4 professionCode (extension conditionnelle)

Cette extension contient le code profession du porteur de certificat, elle n’est présente que dans les certificats des Professionnels de Santé réglementés.

professionCode ::= Integer

Nomenclature : Table G15 – Professions

A 2.1.2.5 futureProfessionCode (extension condition nelle)

Cette extension contient le code de la future profession du porteur de certificat, elle n’est présente que dans les certificats des Professionnels de Santé en Formation.

futureProfessionCode ::= Integer

Nomenclature : Table G16 – Futures professions

A 2.1.2.6 oldPS_IDNat (extension conditionnelle)

Cette extension peut uniquement être présente dans des certificats des Domaines « Personnes ».

Elle est présente lorsque l’identification nationale du porteur « PS_IdNat » (l’attribut CN du DN subject) contient un identifiant basé sur un N° RPPS et lorsque le porteur avait un ancien identifiant basé sur un N° ADELI. Cela concerne :

• les PS qui ont migré du répertoire ADELI vers le répertoire RPPS,

• les employés d’un cabinet libéral d’un PS qui a migré du répertoire ADELI vers le répertoire RPPS.

Si présente, elle contient le dernier identifiant national du porteur « PS_IdNat » basé sur un N° ADELI.

oldPS_IDNat ::= PrintableString



A 2.1.2.7 specialitesRPPS (extension conditionnelle )

Cette extension conditionnelle est présente uniquement si le porteur est un PS et que son Ordre a enregistré une spécialité d’exercice RPPS :

• elle est obligatoire pour les Médecins qui disposent d’une spécialité d’exercice RPPS (absence dans cas rares) ;

• elle est facultative pour les Chirurgiens-Dentistes ; • elle est absente pour toutes les autres professions.

specialitesRPPS ::= SEQUENCE SIZE (0..1) OF special iteRPPS

specialiteRPPS ::= UTF8String

Nomenclature : Table R01 – Spécialités RPPS

A 2.1.2.8 tableauxPharmacien (extension conditionne lle)

Cette extension n’est présente que dans les certificats des Pharmaciens.

L’extension contient les tableaux sur lesquels le Pharmacien est inscrit par le Conseil National de l’Ordre des Pharmaciens (CNOP). Le nombre de tableaux dépend du fait que le certificat du Pharmacien est attaché ou non à une structure :

• certificat non attaché à une structure : tous les tableaux sur lesquels le Pharmacien est inscrit minimum = 0, maximum = 5 tableaux différents,

• certificat attaché à une structure : le tableau qui correspondant à l’activité dans la structure minimum = 0, maximum = 1 tableau.

tableauxPharmacien ::= SEQUENCE SIZE (1..5) OF tabl eauPharmacien

tableauPharmacien ::= UTF8String

Nomenclature : Table G05 – Tableaux des pharmaciens



A 2.2 La syntaxe des CRL de l’IGC-Santé CertificateList ::= SEQUENCE {

tbsCertList TBSCertList,

signatureAlgorithm AlgorithmIdentifier,

signatureValue BIT STRING }

tbsCertList ::= SEQUENCE {

version Version OPTIONAL, if present, shall be v2

signature AlgorithmIdentifier,

issuer Name,

thisUpdate Time,

nextUpdate Time OPTIONAL,

revokedCertificates SEQUENCE OF SEQUENCE {

userCertificate CertificateSerialNumber,

revocationDate Time,

crlEntryExtensions Extensions OPTIONAL,

} OPTIONAL,

crlExtensions [0] EXPLICIT Extensions OPTIONAL, if present, shall be v2

}

Version ::= INTEGER v2(1)

AlgorithmIdentifier ::= SEQUENCE {

Algorithm OBJECT IDENTIFIER,

Parameters ANY DEFINED BY Algorithm OPTIONNAL }

Name ::= CHOICE {RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguished Name

RelativeDistinguishedName ::= SET OF AttributeTyp eAndValue

AttributeTypeAndValue ::= SEQUENCE {

type AttributeType,

value AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY DEFINED BY AttributeType

Extensions ::= SEQUENCE OF Extension

Extension ::= SEQUENCE {

extnId OBJECT IDENTIFIER,

critical BOOLEAN, (default = FALSE)

extnValue OCTET STRING }

CertificateSerialNumber ::= INTEGER

Note :

• Lorsqu'une (delta)-CRL est vide (pas de certificats révoqués); la séquence revokedCertificates est absente.



A 2.2.1 crlEntryExtensions Les crlEntryExtensions peuvent contenir des informations complémentaires concernant le contexte de révocation de chaque certificat.

Les crlEntryExtensions (reasonCode et invalidationDate) ne sont pas utilisées dans l’IGC-Santé.

A 2.2.2 crlExtensions Les crlExtensions contiennent des informations complémentaires de la CRL, les crlExtensions ci-après sont utilisées dans les CRLs de l’IGC-Santé.

Sauf mention spécifique, les crlExtensions sont non critiques.

A 2.2.2.1 authorityKeyIdentifier

Cette extension identifie la clé publique à utiliser pour la vérification de la signature du CRL.

AuthorityKeyIdentifier ::= SEQUENCE {

keyIdentifier [0] KeyIdentifier OPTIONAL,

authorityCertIssuer [1] GeneralNames OPTIONAL,

authorityCertSerialNumber [2] CertificateSerialNumb er OPTIONAL }


A 2.2.2.2 crlNumber

Cette extension donne un numéro croissant séquentiel pour chaque (delta)-CRL émise par une Autorité de Certification.

Les crlNumbers sont gérés de façon indépendante pour chaque émetteur de CRL (les ACR et les ACI).

crlNumber ::= INTEGER

A 2.2.2.3 deltaCRLIndicator - extension critiqu e

Cette extension identifie la CRL comme étant une delta-CRL.

L’émission d’une delta-CRL se fait obligatoirement en même temps qu'une CRL complète (les deux ont le même crlNumber).

Une delta-CRL ne contient que les changements intervenus depuis la dernière CRL dont le numéro apparaît dans le champ baseCRLNumber .

deltaCRLIndicator ::= BaseCRLNumber

BaseCRLNumber ::= crlNumber

A 2.2.2.4 freshestCRL (delta-CRL Distribution Po int)

Cette extension uniquement présente dans les CRL émises par les ACI, contient l’URL de la delta-CRL associée.

FreshestCRL ::= CRLDistributionPoints Note :

Dans l’Annuaire-CPS, les delta-CRL sont multi-valuées ; la réponse à la requête LDAP peut donc contenir plusieurs delta-CRL (en général il y en 7). Pour identifier la delta-CRL émise simultanément avec la CRL contenant cette extension, l’application devra sélectionner celle qui a le même N° séquentiel (le même crlNumber).



Annexe 3 Les identifiants d’objet (OID) A l'intérieur des certificats, les objets sont identifiés par des identifiants d’objet (Object Identifier : OID).

Ces OID sont organisés au niveau international sous la forme d’un arbre.

Chaque pays ou organisation (telle que la France ou l’ISO) se voit attribuer une branche. Un identifiant est attribué définitivement et peut identifier n’importe quel type d’objet.

L’AFNOR a attribué les identifiants suivants :

• 1.2.250.1.71 au GIP-CPS (sa gestion a été reprise par l’ASIP-Santé),

• 1.2.250.1.213 à l’ASIP-Santé.

GIP-CPS (71)

type-org (1)

France (250) usa (840)

member-body(2)

iso (1)

Racine

joint iso/itu-t (2) itu-t (0)

ASIP-Santé (213)

Les détenteurs de ces identifiants peuvent donc affecter des identifiants aux objets de leur choix dans leur propre sous-branche.



A 3.1 Les identifiants d'objet standards utilisés d ans l’IGC-Santé

Object Object Identifier (OID) Object Identifier (hex)

id-at : AttributeType { joint iso/itu-t(2) directoryX500(5) AttributeType(4) } 55 04 commonName { id-at 3 } 55 04 03 surName { id-at 4 } 55 04 04 serialNumber { id-at 5 } 55 04 05 countryName { id-at 6 } 55 04 06 localityName { id-at 7 } 55 04 07 stateOrProvinceName { id-at 8 } 55 04 08 organizationName { id-at 10 } 55 04 0A organizationalUnitName { id-at 11 } 55 04 0B title { id-at 12 } 55 04 0C givenName { id-at 42 } 55 04 2A pseudonyme { id-at 65 } 55 04 41

id-ce : extensions { joint iso/itu-t(2) directoryX500(5) extension(29) } 55 1D subjectKeyIDentifier { id-ce 14} 55 1D 0E keyUsage { id-ce 15} 55 1D 0F privateKeyUsagePeriod { id-ce 16} 55 1D 10 subjectAltName { id-ce 17} 55 1D 11 basicConstraints { id-ce 19} 55 1D 13 crlNumber { id-ce 20} 55 1D 14 deltaCRLIndicator { id-ce 27} 55 1D 1B certificatePolicies { id-ce 32} 55 1D 20 CRLDistributionPoints { id-ce 31} 55 1D 1F authorityKeyIdentifier { id-ce 35} 55 1D 23 extendedKeyUsage { id-ce 37} 55 1D 25 freshestCRL { id-ce 46} 55 1D 2E

PKCS-1 { iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 1 } 2A 86 48 86 F7 0D 01 01 RsaEncryption { PKCS-1 1 } 2A 86 48 86 F7 0D 01 01 01 sha-1WithRSAEncryption { PKCS-1 5 } 2A 86 48 86 F7 0D 01 01 05 sha-256WithRSAEncryption { PKCS-1 11 } 2A 86 48 86 F7 0D 01 01 0B

id-pkix { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

2B 06 01 05 05 07

id-pe (private extensions) { id-pkix 1} 2B 06 01 05 05 07 01 authorityInfoAccess { id-pe 1} 2B 06 01 05 05 07 01 01 qcStatements { id-pe 3} 2B 06 01 05 05 07 01 03 id-kp (extended keyPurposes) { id-pkix 3} 2B 06 01 05 05 07 03 id-kp-serverAuth { id-kp 1} 2B 06 01 05 05 07 03 01 id-kp-clientAuth { id-kp 2} 2B 06 01 05 05 07 03 02 id-kp-codeSigning { id-kp 3} 2B 06 01 05 05 07 03 03 id-kp-emailProtection { id-kp 4} 2B 06 01 05 05 07 03 04 id-kp-timeStamping { id-kp 8} 2B 06 01 05 05 07 03 08 id-kp-OCSPSigning { id-kp 9} 2B 06 01 05 05 07 03 09 id-ad (access descriptors) { id-pkix 48} 2B 06 01 05 05 07 30 id-ad-caIssuers { id-ad 1} 2B 06 01 05 05 07 30 01 id-ad-ocsp { id-ad 2} 2B 06 01 05 05 07 30 02 id-pkix-ocsp-nocheck { id-ad 5} 2B 06 01 05 05 07 30 05

Microsoft Enrollment Infrastructure

{ iso(1) identified-organization(3) dod(6) internet(1) private(4) IANA registred private entreprises(1) microsoft(311) enrollment infrastructure(20) }

2B 06 01 04 01 82 37 14

enroll_certype_extension { microsoft_enrollment_infrastructure enroll_certype (2) } 2B 06 01 04 01 82 37 14 02 szoid_kp_smartcard_logon { enroll_certype_extension(2) } 2B 06 01 04 01 82 37 14 02 02

ETSI { ITU-T(0) identified-organization(4) etsi(0) } 04 00 qcs-QcCompliance { id- etsi qc-profile(1862) qcs(1) qcs-QcCompliance(1) } 04 00 8E 46 01 01 qcs-public-with-SSCD { id- etsi qc-profile(1862) qcs(1) qcp-public-with-sscd(4) } 04 00 8E 46 01 04



A 3.2 Les identifiants d'objets privés utilisés dan s l’IGC-Santé

A 3.2.1 Les identifiants d'objets attribués par le GIP-CPS Les OID attribués par le GIP-CPS et utilisés dans les certificats de l’IGC-Santé sont listés dans le tableau ci-dessous.


id-gip { iso(1) member-body(2) France(250) type-org(1) gip-cps(71) } 2A 81 7A 01 47

id-gip-carte { id-gip 1 } 2A 81 7A 01 47 01 id-gip-carte-at (attribute) { id-gip-carte 2 } 2A 81 7A 01 47 01 02 obsolète { id-gip-carte-at 1 } 2A 81 7A 01 47 01 02 01 productType (ex gipCardType)

{ id-gip-carte-at 2 } 2A 81 7A 01 47 01 02 02

tokenId (ex gipCardID)

{ id-gip-carte-at 3 } 2A 81 7A 01 47 01 02 03

obsolète { id-gip-carte-at 4 } 2A 81 7A 01 47 01 02 04 productCategory (ex gipCardCategory)

{ id-gip-carte-at 5 } 2A 81 7A 01 47 01 02 05

obsolète { id-gip-carte-at 6 } 2A 81 7A 01 47 01 02 06 professionCode { id-gip-carte-at 7 } 2A 81 7A 01 47 01 02 07 futureProfessionCode { id-gip-carte-at 8 } 2A 81 7A 01 47 01 02 08 obsolète { id-gip-carte-at 9 } 2A 81 7A 01 47 01 02 09 id-gip-ext { id-gip 4 } 2A 81 7A 01 47 04 id-gip-ext-at (attribute) { id-gip-ext 2 } 2A 81 7A 01 47 04 02 oldPS_IDNat { id-gip-ext-at 3 } 2A 81 7A 01 47 04 02 03 specialitesRPPS { id-gip-ext-at 5 } 2A 81 7A 01 47 04 02 05 tableauxPharmacien { id-gip-ext-at 6 } 2A 81 7A 01 47 04 02 06



A 3.2.2 Les identifiants d'objets attribués par l’A SIP-Santé Les OID attribués par l’ASIP-Santé et utilisés dans les certificats de l’IGC-Santé sont listés dans le tableau ci-dessous (ne concerne que les OID des Politiques de Certification).

Les OID des Politiques de Certification sont structurés comme suit :

• id-asipsante-PC Racine OID des Politiques de certification IGC-Santé { id-asipsante 1 7 }

• Construction de l’OID d’une PC { id-asipsante-PC a b c d v }

a : 1 = Branche Production 2 = Branche de Test (les index b, c et d sont alors non significatifs)

b : 1 = Branche Gamme Elémentaire 2 = Branche Gamme Standard 3 = Branche Gamme Fort

c : 1 = Branche ACI Personnes Physiques 2 = Branche ACI Organisations

d : Référence gabarit dans la branche

v : N° de version de la PC Dans le tableau ci-dessous, v=1 désignant la première version de chaque PC.


id-asipsante { iso(1) member-body(2) France(250) type-org(1) asip-sante(213) }

2A 81 7A 01 D5

id-asipsante-PC { id-asipsante 1 7 } 2A 81 7A 01 D5 01 07

id-asipsante-PC-Prod { id-asipsante-PC 1 } 2A 81 7A 01 D5 01 07 01

id-asipsante-PC-Prod-EL { id-asipsante-PC-Prod 1} 2A 81 7A 01 D5 01 07 01 01

id-asipsante-PC-Prod-EL-PP { id-asipsante-PC-Prod-EL 1} 2A 81 7A 01 D5 01 07 01 01 01 PC-EL-PP-OCSP v1 { id-asipsante-PC-Prod-EL-PP 1 1} 2A 81 7A 01 D5 01 07 01 01 01 01 01 PC-EL-PP-CL-SIGN v1 { id-asipsante-PC-Prod-EL-PP 4 1} 2A 81 7A 01 D5 01 07 01 01 01 04 01 PC-EL-PP-CL-AUTH v1 { id-asipsante-PC-Prod-EL-PP 5 1} 2A 81 7A 01 D5 01 07 01 01 01 05 01 PC-EL-PP-CL-CONF v1 { id-asipsante-PC-Prod-EL-PP 6 1} 2A 81 7A 01 D5 01 07 01 01 01 06 01

id-asipsante-PC-Prod-EL-ORG { id-asipsante-PC-Prod-EL 2} 2A 81 7A 01 D5 01 07 01 01 02 PC-EL-ORG-OCSP v1 { id-asipsante-PC-Prod-EL-ORG 1 1} 2A 81 7A 01 D5 01 07 01 01 02 01 01 PC-EL-ORG-CL-SIGN v1 { id-asipsante-PC-Prod-EL-ORG 3 1} 2A 81 7A 01 D5 01 07 01 01 02 03 01 PC-EL-ORG-CL-AUTH_CLI v1 { id-asipsante-PC-Prod-EL-ORG 4 1} 2A 81 7A 01 D5 01 07 01 01 02 04 01 PC-EL-ORG-CL-SSL_SERV v1 { id-asipsante-PC-Prod-EL-ORG 5 1} 2A 81 7A 01 D5 01 07 01 01 02 05 01 PC-EL-ORG-CL-CONF v1 { id-asipsante-PC-Prod-EL-ORG 6 1} 2A 81 7A 01 D5 01 07 01 01 02 06 01 PC-EL-ORG-CL-SMIME v1 { id-asipsante-PC-Prod-EL-ORG 8 1} 2A 81 7A 01 D5 01 07 01 01 02 08 01

id-asipsante-PC-Test { id-asipsante-PC 2 } 2A 81 7A 01 D5 01 07 02 PC-Test v1 { id-asipsante-PC-Test 1 1 1 1} 2A 81 7A 01 D5 01 07 02 01 01 01 01

id-asipsante-PC-Documentation { id-asipsante 1 8 } 2A 81 7A 01 D5 01 08

Il y a une seule PC pour l'IGC-Santé de Test.

L’OID unique correspondant est renseigné dans tous les certificats utilisateur de test.



Annexe 4 Les URL référencés dans les certificats de l’IGC-Santé

En étape 1, seuls les URL correspondant à la Gamme Elémentaire seront opérationnels.

Notes génériques concernant les URL de Production e t de Test :

• Les espaces dans les URL HTTP sont remplacés par la chaîne "%20" dans les certificats.

• Le sous-domaine "annuaire-igc.esante.gouv.fr" est rerouté sur "annuaire.gip-cps.fr".

A 4.1 Les URL dans les certificats de Production

A 4.1.1 Production : Les URL pointant vers les cert ificats ACR et ACI

Noms dans gabarits URL dans les certificats de Production

certificat ACR EL http://igc-sante.esante.gouv.fr/AC/ACR-EL.cer

certificat ACI EL-PP http://igc-sante.esante.gouv.fr/AC/ACI-EL-PP.cer

certificat ACI EL-ORG http://igc-sante.esante.gouv.fr/AC/ACI-EL-ORG.cer

certificat ACR ST http://igc-sante.esante.gouv.fr/AC/ACR-ST.cer

certificat ACI ST-PP http://igc-sante.esante.gouv.fr/AC/ACI-ST-PP.cer

certificat ACI ST-ORG http://igc-sante.esante.gouv.fr/AC/ACI-ST-ORG.cer

certificat ACR FO http://igc-sante.esante.gouv.fr/AC/ACR-FO.cer

certificat ACI FO-PP http://igc-sante.esante.gouv.fr/AC/ACI-FO-PP.cer

A 4.1.2 Production : Les URL des CRL (crlDistribitionPoints)


CRL ACR EL http://igc-sante.esante.gouv.fr/CRL/ACR-EL.crl

ldap://annuaire-igc.esante.gouv.fr/cn=AC RACINE IGC-SANTE ELEMENTAIRE, ou=IGC-SANTE,ou=0002 187512751,o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACI EL-PP

http://igc-sante.esante.gouv.fr/CRL/ACI-EL-PP.crl

ldap://annuaire-igc.esante.gouv.fr/cn=AC IGC-SANTE ELEMENTAIRE PERSONNES, ou=AC RACINE IGC-SANTE ELEMENTAIRE,ou=IGC-SANTE,ou=0002 187512751, o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACI EL-ORG

http://igc-sante.esante.gouv.fr/CRL/ACI-EL-ORG.crl

ldap://annuaire-igc.esante.gouv.fr/cn=AC IGC-SANTE ELEMENTAIRE ORGANISATIONS, ou=AC RACINE IGC-SANTE ELEMENTAIRE,ou=IGC-SANTE,ou=0002 187512751, o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACR ST http://igc-sante.esante.gouv.fr/CRL/ACR-ST.crl

ldap://annuaire-igc.esante.gouv.fr/cn=AC RACINE IGC-SANTE STANDARD, ou=IGC-SANTE,ou=0002 187512751,o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACI ST-PP

http://igc-sante.esante.gouv.fr/CRL/ACI-ST-PP.crl

ldap://annuaire-igc.esante.gouv.fr/cn=AC IGC-SANTE STANDARD PERSONNES, ou=AC RACINE IGC-SANTE STANDARD,ou=IGC-SANTE,ou=0002 187512751, o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACI ST-ORG

http://igc-sante.esante.gouv.fr/CRL/ACI-ST-ORG.crl

ldap://annuaire-igc.esante.gouv.fr/cn=AC IGC-SANTE STANDARD ORGANISATIONS, ou=AC RACINE IGC-SANTE STANDARD,ou=IGC-SANTE,ou=0002 187512751, o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACR FO http://igc-sante.esante.gouv.fr/CRL/ACR-FO.crl

ldap://annuaire-igc.esante.gouv.fr/cn=AC RACINE IGC-SANTE FORT, ou=IGC-SANTE,ou=0002 187512751,o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACI FO-PP

http://igc-sante.esante.gouv.fr/CRL/ACI-FO-PP.crl

ldap://annuaire-igc.esante.gouv.fr/cn=AC IGC-SANTE FORT PERSONNES, ou=AC RACINE IGC-SANTE FORT,ou=IGC-SANTE,ou=0002 187512751, o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA



A 4.1.3 Production : Les URL des delta-CRL (freshestCRL) Les delta-CRL sont uniquement émises par les AC Intermédiaires.


delta-CRL ACI EL-PP ldap://annuaire-igc.esante.gouv.fr/cn=AC IGC-SANTE ELEMENTAIRE PERSONNES,

ou=AC RACINE IGC-SANTE ELEMENTAIRE,ou=IGC-SANTE,ou=0002 187512751, o=ASIP-SANTE,c=FR?deltacertificaterevocationlist;binary?base?objectClass=pkiCA

delta-CRL ACI EL-ORG ldap://annuaire-igc.esante.gouv.fr/cn=AC IGC-SANTE ELEMENTAIRE ORGANISATIONS,

ou=AC RACINE IGC-SANTE ELEMENTAIRE,ou=IGC-SANTE,ou=0002 187512751, o=ASIP-SANTE,c=FR?deltacertificaterevocationlist;binary?base?objectClass=pkiCA

delta-CRL ACI ST-PP ldap://annuaire-igc.esante.gouv.fr/cn=AC IGC-SANTE STANDARD PERSONNES,

ou=AC RACINE IGC-SANTE STANDARD,ou=IGC-SANTE,ou=0002 187512751, o=ASIP-SANTE,c=FR?deltacertificaterevocationlist;binary?base?objectClass=pkiCA

delta-CRL ACI ST-ORG ldap://annuaire-igc.esante.gouv.fr/cn=AC IGC-SANTE STANDARD ORGANISATIONS,

ou=AC RACINE IGC-SANTE STANDARD,ou=IGC-SANTE,ou=0002 187512751, o=ASIP-SANTE,c=FR?deltacertificaterevocationlist;binary?base?objectClass=pkiCA

delta-CRL ACI FO-PP ldap://annuaire-igc.esante.gouv.fr/cn=AC IGC-SANTE FORT PERSONNES,

ou=AC RACINE IGC-SANTE FORT,ou=IGC-SANTE,ou=0002 187512751, o=ASIP-SANTE,c=FR?deltacertificaterevocationlist;binary?base?objectClass=pkiCA

A 4.2 Production : Les URL divers


certPolicyQualifier http://igc-sante.esante.gouv.fr/PC

Répondeur OCSP http://ocsp.esante.gouv.fr Il y a un seul répondeur OCSP pour tous les certificats utilisateur (Production et Test)



A 4.3 Les URL dans les certificats de Test

A 4.3.1 Test : Les URL pointant vers les certificat s ACR et ACI


certificat ACR EL http://igc-sante.esante.gouv.fr/AC TEST/ACR-EL-TEST.cer

certificat ACI EL-PP http://igc-sante.esante.gouv.fr/AC TEST /ACI-EL-PP-TEST.cer

certificat ACI EL-ORG http://igc-sante.esante.gouv.fr/AC TEST /ACI-EL-ORG-TEST.cer

certificat ACR ST http://igc-sante.esante.gouv.fr/AC TEST /ACR-ST-TEST.cer

certificat ACI ST-PP http://igc-sante.esante.gouv.fr/AC TEST /ACI-ST-PP-TEST.cer

certificat ACI ST-ORG http://igc-sante.esante.gouv.fr/AC TEST /ACI-ST-ORG-TEST.cer

certificat ACR FO http://igc-sante.esante.gouv.fr/AC TEST /ACR-FO-TEST.cer

certificat ACI FO-PP http://igc-sante.esante.gouv.fr/AC TEST /ACI-FO-PP-TEST.cer

A 4.3.2 Test : Les URL des CRL (crlDistribitionPoints)


CRL ACR EL http://igc-sante.esante.gouv.fr/CRL TEST/ACR-EL-TEST.crl

ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC RACINE IGC-SANTE ELEMENTAIRE,ou=IGC-SANTE TEST, ou=0002 187512751,o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACI EL-PP

http://igc-sante.esante.gouv.fr/CRL TEST/ACI-EL-PP-TEST.crl

ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC IGC-SANTE ELEMENTAIRE PERSONNES, ou=TEST AC RACINE IGC-SANTE ELEMENTAIRE,ou=IGC-SANTE TEST,ou=0002 187512751, o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACI EL-ORG

http://igc-sante.esante.gouv.fr/CRL TEST/ACI-EL-ORG-TEST.crl

ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC IGC-SANTE ELEMENTAIRE ORGANISATIONS, ou=TEST AC RACINE IGC-SANTE ELEMENTAIRE,ou=IGC-SANTE TEST,ou=0002 187512751, o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACR ST http://igc-sante.esante.gouv.fr/CRL TEST/ACR-ST-TEST.crl

ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC RACINE IGC-SANTE STANDARD,ou=IGC-SANTE TEST, ou=0002 187512751,o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACI ST-PP

http://igc-sante.esante.gouv.fr/CRL TEST/ACI-ST-PP-TEST.crl

ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC IGC-SANTE STANDARD PERSONNES, ou=TEST AC RACINE IGC-SANTE STANDARD,ou=IGC-SANTE TEST, ou=0002 187512751,o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACI ST-ORG

http://igc-sante.esante.gouv.fr/CRL TEST/ACI-ST-ORG-TEST.crl

ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC IGC-SANTE STANDARD ORGANISATIONS, ou=TEST AC RACINE IGC-SANTE STANDARD,ou=IGC-SANTE TEST, ou=0002 187512751,o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACR FO http://igc-sante.esante.gouv.fr/CRL TEST/ACR-FO-TEST.crl

ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC RACINE IGC-SANTE FORT,ou=IGC-SANTE TEST, ou=0002 187512751,o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA

CRL ACI FO-PP

http://igc-sante.esante.gouv.fr/CRL TEST/ACI-FO-PP-TEST.crl

ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC IGC-SANTE FORT PERSONNES, ou=TEST AC RACINE IGC-SANTE FORT,ou=IGC-SANTE TEST, ou=0002 187512751,o=ASIP-SANTE,c=FR?certificaterevocationlist;binary?base?objectClass=pkiCA



A 4.3.3 Test : Les URL des delta-CRL (freshestCRL) Les delta-CRL sont uniquement émises par les AC Intermédiaires.


delta-CRL ACI EL-PP ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC IGC-SANTE ELEMENTAIRE PERSONNES,

ou=TEST AC RACINE IGC-SANTE ELEMENTAIRE,ou=IGC-SANTE TEST, ou=0002 187512751,o=ASIP-SANTE,c=FR?deltacertificaterevocationlist;binary?base?objectClass=pkiCA

delta-CRL ACI EL-ORG ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC IGC-SANTE ELEMENTAIRE ORGANISATIONS,

ou=TEST AC RACINE IGC-SANTE ELEMENTAIRE,ou=IGC-SANTE TEST, ou=0002 187512751,o=ASIP-SANTE,c=FR?deltacertificaterevocationlist;binary?base?objectClass=pkiCA

delta-CRL ACI ST-PP ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC IGC-SANTE STANDARD PERSONNES,

ou=TEST AC RACINE IGC-SANTE STANDARD,ou=IGC-SANTE TEST, ou=0002 187512751,o=ASIP-SANTE,c=FR?deltacertificaterevocationlist;binary?base?objectClass=pkiCA

delta-CRL ACI ST-ORG ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC IGC-SANTE STANDARD ORGANISATIONS,

ou=TEST AC RACINE IGC-SANTE STANDARD,ou=IGC-SANTE TEST, ou=0002 187512751,o=ASIP-SANTE,c=FR?deltacertificaterevocationlist;binary?base?objectClass=pkiCA

delta-CRL ACI FO-PP ldap://annuaire-igc.esante.gouv.fr/cn=TEST AC IGC-SANTE FORT PERSONNES,

ou=TEST AC RACINE IGC-SANTE FORT,ou=IGC-SANTE TEST, ou=0002 187512751,o=ASIP-SANTE,c=FR?deltacertificaterevocationlist;binary?base?objectClass=pkiCA

A 4.4 Test : Les URL divers


certPolicyQualifier http://igc-sante.esante.gouv.fr/PC TEST

Répondeur OCSP http://ocsp.esante.gouv.fr Il y a un seul répondeur OCSP pour tous les certificats utilisateur (Production et Test)



Annexe 5 Gestion des objets ASN.1

A 5.1 Les grands principes de l’ASN.1

A 5.1.1 La notation ASN.1 L’ISO décrit à travers le modèle OSI (Open Systems Interconnection) une architecture standardisée régissant les interconnections de systèmes informatiques. La description de ce système complexe nécessite un haut niveau d’abstraction. La méthode utilisée dans le cadre de l’OSI pour spécifier des objets abstraits est appelée ASN.1 (Abstract Syntax Notation One). Chaque objet est identifié par un code qui lui est attribué de manière définitive.

A 5.1.2 Codification des objets en ASN.1 Chaque objet a le format TLV (Tag – Length – Value) :

• le champ Tag indique le type d'objet,

• le champ Length indique la longueur de l'objet,

• le champ Value contient la valeur de l'objet.

A 5.1.3 Codification des tags Les bits 8 et 7 indiquent la classe.

Le bit 6 indique si le tag est construit (bit 6 = 1) ou simple (bit 6 = 0) ; un objet construit contient un ou plusieurs autres objets.

Les bits 5 à 1 donnent le numéro de tag.

Classe Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1

Universal 0 0 X

Numéro du tag Application 0 1 X

Context-specific 1 0 X

Private 1 1 X

Note : Le terme « template » désigne des objets construits (bit 6 = 1).



A 5.1.4 Valeurs des TAGs universels Type d'objet Tag number (hexa)

End-of-contents (length = 0) ‘00’

BOOLEAN ‘01’

INTEGER ‘02’

BIT STRING ‘03’

OCTET STRING ‘04’

NULL ‘05’

OBJECT IDENTIFIER ‘06’

SEQUENCE and SEQUENCE OF (simple) ‘10’

SEQUENCE and SEQUENCE OF (constructed) ‘30’ (‘10’ + ‘20’)

SET and SET OF (simple) ‘11’

SET and SET OF (constructed) ‘31’ (‘11’ + ‘20’)

UTF8String ‘0C’

PrintableString ‘13’

T61String ‘14’

IA5String ‘16’

UTCTime ‘17’

Generalised-time ‘18’

A 5.1.5 Codification des longueurs des objets Longeur L 1 er octet 2 ème octet 3 ème octet 4 ème octet

L ≤ ‘7F’ L

‘7F’ < L ≤ ’FF’ ‘81’ L

‘FF’< L ≤ ‘FF FF’ ‘82’ L1 L2

‘FF FF’< L ≤ ‘FF FF FF’ ‘83’ L1 L2 L3

Note : « L= '80' » indique une longueur indéfinie (non utilisée dans le contexte de l’IGC-Santé).

A 5.1.6 Précisions sur la construction d'objets Les "INTEGER" sont codés sur n octets signés, exemples :

Valeur à coder Format de l'objet

0 02 01 00

127 02 01 7F

128 02 02 00 80

256 02 02 01 00

-128 02 01 80

-129 02 02 FF 7F

Note : Dans l'encodage "DER" utilisé dans les certificats, la taille de l'objet doit être optimisée : tous les octets de poids fort à 0 inutiles doivent être supprimés. La valeur de l'objet ne peut que commencer avec un 0 pour éviter qu'un integer positif soit interprété comme une valeur négative (cf. exemple pour la valeur 128).



Une "BIT STRING" commence par un octet donnant le nombre de bits non utilisés à la fin de la chaîne des octets.


1 bit à '1' 03 02 07 80

7 bits à '1' 03 02 01 FE

Un "BOOLEAN" est codé comme suit :


TRUE 01 01 FF

FALSE 01 01 00



Annexe 6 Exemples de codage dans les certificats de l’IGC-Santé Le codage ASN.1 des certificats de l’IGC-Santé respecte le RFC 5280 [3].

Le § A 2.1.1 « Extensions standards utilisées dans les certificats de l’IGC-Santé » donne un rappel de la syntaxe et spécifie, si besoin, les options retenues pour l’IGC-Santé.

La présente annexe donne des exemples de codage en ASN.1 des DN des porteurs de certificats ainsi que des extensions privées de l’IGC-Santé.

A 6.1 Exemples de codage des DN des porteurs de cer tificats

A 6.1.1 Exemples de codage des DN des Personnes phy siques A 6.1.1.1 DN d’un professionnel de santé (non attac hé à une structure)

Professionnel de Santé réglementé c= FR title= Médecin

gn= MARIE sn= DUPONT Les RDN gn, sn et cn sont groupés dans un RDN multi-valué cn= 899700000011

30 53 -- SEQUENCE OF (RelDistName) 31 0B -- SET OF (AttValueAssertion) 30 09 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 06 -- country 13 02 -- PRINTABLE STRING 46 52 -- «FR» 31 10 -- SET OF (AttValueAssertion) 30 0E -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0C -- title 0C 07 -- UTF8String 4D E9 64 65 63 69 6E -- « Médecin » 31 32 -- SET OF (AttValueAssertion)

30 0C -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 2A -- givenName 0C 05 -- UTF8String 4D 41 52 49 45 -- « MARIE »

30 0F -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 04 -- surName 0C 07 -- UTF8String 44 55 50 4F 4E 54 -- « DUPONT »

30 11 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 03 -- commonName 0C 0C -- UTF8String 38 39 39 37 30 30 30 30 30 30 31 31 -- PS_IdNat = RPPS « 899700000011 »



A 6.1.1.2 DN d’un professionnel de santé rattaché à une structure

Professionnel de Santé en Formation rattaché à une structure c= FR st= Ain (01) o= PHARMACIE DU PARC ou= 1123456789 (FINESS) title= Pharmacien en formation

gn= JEAN sn= LEGRAND Les RDN gn, sn et cn sont groupés dans un RDN multi-valué cn= 9200001234

30 81 A4 -- SEQUENCE OF (RelDistName) 31 0B -- SET OF (AttValueAssertion) 30 09 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 06 -- country 13 02 -- PRINTABLE STRING 46 52 -- « FR » 31 10 -- SET OF (AttValueAssertion) 30 0E -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 08 -- stateOrProvinceName 0C 08 -- UTF8String 41 69 6E 20 28 30 31 29 -- « Ain (01) » 31 1A -- SET OF (AttValueAssertion) 30 18 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0A -- organisation 0C 11 -- UTF8String 50 48 41 52 4D 41 43 49 45 20 44 55 20 50 41 52 43 -- « PHARMACIE DU PARC » 31 13 -- SET OF (AttValueAssertion) 30 11 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0B -- organisationalUnit 0C 0A -- UTF8String 31 31 32 33 34 35 36 37 38 39 -- Struct_IdNat = « 1123456789 » 31 20 -- SET OF (AttValueAssertion) 30 1E -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0C -- title 0C 17 -- UTF8String 50 68 61 72 6D 61 63 69 65 6E 20 65 6E 20 66 6F 72 6D 61 74 69 6F 6E -- « Pharmacien en formation » 31 30 -- SET OF (AttValueAssertion)

30 0B -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 2A -- givenName 0C 04 -- UTF8String 4A 45 41 4E -- « JEAN »

30 0E -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 04 -- surName 0C 07 -- UTF8String 4C 45 47 52 41 4E 44 -- « LEGRAND »

30 11 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 03 -- commonName 0C 0C -- UTF8String 39 02 30 30 30 30 31 32 33 34 -- PS_IdNat = N° Etudiant « 9200001234 »



A 6.1.1.3 DN d’un Personnel de structure

Personnel de structure c= FR st= Orne (61) o= DMP REGIONAL ou= 312345678900010 (SIRET) title= Personnel autorisé

gn= PIERRE sn= MARTIN Les RDN gn, sn et cn sont groupés dans un RDN composé cn= 512345678900010/PMA

30 41 -- SEQUENCE OF (RelDistName) 31 0B -- SET OF (AttValueAssertion) 30 09 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 06 -- country 13 02 -- PRINTABLE STRING 46 52 -- « FR » 31 12 -- SET OF (AttValueAssertion) 30 10 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 08 -- stateOrProvinceName 0C 09 -- UTF8String 4F 72 6E 65 20 28 36 31 29 -- « Orne (61) » 31 13 -- SET OF (AttValueAssertion) 30 11 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0A -- organisation 0C 0A -- UTF8String 44 4D 50 20 52 45 47 49 4F 4E 41 4C -- « DMP REGIONAL » 31 17 -- SET OF (AttValueAssertion) 30 15 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0B -- organisationalUnit 0C 0E -- UTF8String 33 31 32 33 34 35 36 37 39 30 30 30 31 30 -- Struct_IdNat = « 312345678900010 » 31 1A -- SET OF (AttValueAssertion) 30 18 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0C -- title 0C 11 -- UTF8String 50 65 72 73 6F 6E 65 6C 20 61 75 74 6F 72 69 73 E9 -- « Personnel autorisé » 31 3E -- SET OF (AttValueAssertion)

30 0F -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 2A -- givenName 0C 06 -- UTF8String 50 49 45 52 52 45 -- « PIERRE »

30 0F -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 04 -- surName 0C 06 -- UTF8String 4D 41 52 54 49 4E -- « MARTIN »

30 1A -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 03 -- commonName 0C 13 -- UTF8String 35 31 32 33 34 35 36 37 38 39 30 30 30 31 30 2F 50 4D 41 -- PS_IdNat = « 512345678900010/PMA »



A 6.1.1.4 DN d’une Carte de Service attachée à une Structure

Carte de Service attachée à une Structure hors étape 1 c= FR st= Lot (46) o= LABORATOIRE DE LA GARE ou= 1467654321 (FINESS) title= Carte de service santé ou social

pseudo = EMPLOYE 01 Les RDN pseudo et cn sont groupés dans un RDN multi-valué

cn= 3467654321/0023

30 81 -- SEQUENCE OF (RelDistName) 31 0B -- SET OF (AttValueAssertion) 30 09 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 06 -- country 13 02 -- PRINTABLE STRING 46 52 -- « FR » 31 11 -- SET OF (AttValueAssertion) 30 0F -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 08 -- stateOrProvinceName 0C 08 -- UTF8String 4C 6F 74 20 28 34 36 29 -- « Lot (46) » 31 1D -- SET OF (AttValueAssertion) 30 1B -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0A -- organisation 0C 16 -- UTF8String 4C 41 42 4F 52 41 54 4F 49 52 45 20 44 45 20 4C 41 20 47 41 52 45 -- « LABORATOIRE DE LA GARE » 31 13 -- SET OF (AttValueAssertion) 30 11 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0B -- organisationalUnit 0C 0A -- UTF8String 31 34 36 37 36 35 34 33 32 31 -- Struct_IdNat = « 1467654321 » 31 2B -- SET OF (AttValueAssertion)

30 11 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 41 -- pseudonyme 0C 0A -- UTF8String 45 4D 50 4C 4F 59 45 20 30 31 -- « EMPLOYE 01 »

30 16 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 03 -- commonName 0C 0F -- UTF8String 33 34 36 37 36 35 34 33 32 31 2F 30 30 32 33 -- PS_IdNat = « 3467654321/0023 »



A 6.1.2 Exemples de codage des DN des Organisations A 6.1.2.1 DN d’un certificat applicatif de structur e

DN d’un certificat applicatif de structure c= FR st= Jura (39) o= HOPITAL REGIONAL ou= 1390000009 (FINESS) cn= PROXY DMP

30 65 -- SEQUENCE OF (RelDistName) 31 0B -- SET OF (AttValueAssertion) 30 09 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 06 -- country 13 02 -- PRINTABLE STRING 46 52 -- « FR » 31 12 -- SET OF (AttValueAssertion) 30 10 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 08 -- stateOrProvinceName 0C 09 -- UTF8String 4A 75 72 61 20 28 33 39 29 -- « Jura (39) » 31 19 -- SET OF (AttValueAssertion) 30 17 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0A -- organisation 0C 10 -- UTF8String 48 4F 50 49 54 41 4C 20 52 45 47 49 4F 4E 41 4C -- « HOPITAL REGIONAL » 31 13 -- SET OF (AttValueAssertion) 30 11 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0B -- organisationalUnit 0C 0A -- UTF8String 31 33 39 30 30 30 30 30 30 39 -- Struct_IdNat = « 1390000009 » 31 12 -- SET OF (AttValueAssertion) 30 10 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 03 -- commonName 0C 09 -- UTF8String 50 52 4F 58 59 20 44 4D 50 -- Nom applicatif = « PROXY DMP »



A 6.1.2.2 DN d’un certificat applicatif d’une entit é dans une structure

DN d’un certificat applicatif d’une entité dans une structure hors étape 1 c= FR st= < Nom département (N°)> o= < Raison sociale Structure > ou= < Struct_IdNat >

ou= < Type d’entité > L’usage de ces RDN sera précisé lors d’une étape ultérieure.

ou= < Nom d’entité >

cn= < Nom applicatif >

Hors étape 1 – L’exemple de codage de ce DN sera fourni lorsque l’usage des RDN Type et Nom d’entité sera précisé.

A 6.1.2.3 DN d’un certificat d’authentification CPX pour mode sans contact

DN d’un certificat d’authentification CPx pour mode sans contact hors étape 1 c= FR o= ASIP-SANTE cn= 8025000001000055605F (IAS Serial Number)

30 41 -- SEQUENCE OF (RelDistName) 31 0B -- SET OF (AttValueAssertion) 30 09 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 06 -- country 13 02 -- PRINTABLE STRING 46 52 -- « FR » 31 13 -- SET OF (AttValueAssertion) 30 11 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 0A -- organisation 0C 0A -- UTF8String 41 53 49 50 2D 53 41 4E 54 45 -- « ASIP-SANTE » 31 1D -- SET OF (AttValueAssertion) 30 1B -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 04 03 -- commonName 0C 14 -- UTF8String 38 30 32 35 30 30 30 30 30 31 30 30 30 30 35 35 36 30 35 46 -- IAS Serial Number: « 8025000001000055605F »



A 6.2 Exemples de codage des extensions privées Ci-dessous quelques exemples de codage des extensions privées absentes dans l’exemple ci-dessus.

A 6.2.1 Exemple de codage de « productCategory » Exemple de codage de l’extension productCategory avec la valeur ‘00’ pour désigner une carte de la famille CPS :

30 0F -- SEQUENCE

06 08 -- OBJECT IDENTIFIER

2A 81 7A 01 47 01 02 05 -- productCategory

04 03 -- OCTET STRING

04 01 -- OCTET STRING

00 -- ‘00’ = Carte PS

A 6.2.2 Exemple de codage de « productType » Exemple de codage de l’extension productType avec la valeur ‘00’ pour désigner une carte CPS : 30 0F -- SEQUENCE 06 08 -- OBJECT IDENTIFIER 2A 81 7A 01 47 01 02 02 -- productType 04 03 -- OCTET STRING 02 01 -- INTEGER 00 -- ‘00’ = CPS

A 6.2.3 Exemple de codage de « tokenID » Exemple de codage de l’extension tokenID d’une carte de la famille CPS, émis par l’ASIP-Santé, identifié par « 8025000001 » avec un numéro de série « 7777777777 » : 30 33 -- SEQUENCE 06 08 -- OBJECT IDENTIFIER 2A 81 7A 01 47 01 02 03 -- tokenId 04 17 -- OCTET STRING: issuerID/cardse rialn° 13 15 -- PRINTABLE STRING 38 30 32 35 30 30 30 30 30 31 2F 37 37 37 37 37 37 37 37 37 37 -- « 8025000001/7777777777 »

A 6.2.4 Exemple de codage de « professionCode » Exemple de codage de l’extension professionCode d’un certificat dont le porteur est « Médecin ». 30 0F -- SEQUENCE 06 08 -- OBJECT IDENTIFIER 2A 81 7A 01 47 01 02 07 -- professionCode 04 03 -- OCTET STRING 02 01 -- INTEGER 0A -- 10 = Médecin

A 6.2.5 Exemple de codage de « futureProfessionCode » Exemple de codage de l’extension futureProfessionCode d’un certificat dont le porteur est « Future Chirurgien-dentiste » : 30 0F -- SEQUENCE 06 08 -- OBJECT IDENTIFIER 2A 81 7A 01 47 01 02 08 -- futureProfessionCode 04 03 -- OCTET STRING 02 01 -- INTEGER 28 -- 40 = Chirurgien-dentiste

A 6.2.6 Exemple de codage de « oldPS_IDNat »



Exemple de codage de l’extension oldPS_IDNat d’un PS, registré dans le RPPS, dont l’ancienne identité était le N° Adeli « 0751012345 » : 30 18 -- SEQUENCE 06 08 -- OBJECT IDENTIFIER 2A 81 7A 01 47 04 02 03 -- oldINatPS 04 0C -- OCTET STRING: 13 0A -- printable string 30 37 35 31 30 31 32 33 34 35 -- PS_IdNat Adeli = « 0751012345 »

A 6.2.7 Exemple de codage de « specialitesRPPS » Exemple de codage de l’extension specialitesRPPS d’un Médecin dont la spécialité d’exercice est « SM26 » (Qualifié en Médecine Générale) : 30 14 -- SEQUENCE 06 08 -- OBJECT IDENTIFIER 2A 81 7A 01 47 04 02 05 -- specialitesRPPS 04 08 -- OCTET STRING 30 06 -- SEQUENCE 0C 04 -- UTF8 string 53 4D 32 36 -- Spécialite RPPS = « SM26 »

A 6.2.8 Exemple de codage de « tableauxPharmacien » Exemple de codage de l’extension tableauxPharmacien d’un Pharmacien qui est inscrit sur les tableaux A (Pharmacien titulaire d'officine) et C (Pharmacien d'une entreprise - Distribution en gros) : 30 1C -- SEQUENCE 06 08 -- OBJECT IDENTIFIER 2A 81 7A 01 47 04 02 06 -- tableauxPharmacien 04 08 -- OCTET STRING 30 06 -- SEQUENCE 0C 01 -- UTF8 string: 41 -- Tableau Pharmacien 1 : « A » 0C 01 -- UTF8 string: 43 -- Tableau Pharmacien 2 : « C »

A 6.2.9 Exemple de codage de « SubjectAltName » ave c UPN pour une CPx Exemple de codage de l’extension subjectAltName dans le certificat d’authentification d’une carte CPx contenant un UPN construit à partir d’un identifiant RPPS « 899700000011 » : 30 35 -- SEQUENCE 06 03 -- OBJECT IDENTIFIER 55 1D 11 -- subjectAltName 04 2E -- OCTET STRING 30 2C -- sequence of generalName A0 2A -- Other Name 06 0A -- OID 2B 06 01 04 01 82 37 14 -- Microsoft UPN 02 03 A0 1C -- SEQUENCE 0C 1A –- UTF8 string 38 2E 39 39 37 30 30 30 30 30 30 31 31 40 63 61 72 74 65 2D 63 70 73 2E 66 72 -- « [email protected] »