Une bi-clé, 2 certificats sur la même bi-clé et cryptage, question ...

Erwann Abalea

22/02/2010 à 15:40

Bonjour,

neopale a écrit :

Voici mon problème en qqes points :
0 - J'ai une "mini" PKI basée sur OpenSSL et qqes scripts qui vont bien.
1 - Je génère une bi-clé (RSA 3DES et 1024b)
2 - Je créée le CSR
3 - Je signe la CSR par la CA et j'ai mon certificat correspondant à mes clés
4 - Au passage, je fabrique un pkcs12 (ou pfx) contenant le certif et la clé
privé

Je crypte un fichier avec ce certif via la clé publique bien sur puis je
décrypte en passant en paramètre le p12 --> Ok tout est propre. Je conserve ce
fichier crypté dans 1 coin.

Maintenant, mon problème : je me pose dans la situation de la révocation/fin de
validité de mon certif. Je souhaitais simplement regénérer une CSR puis
signature etc à partir de la même bi-clé et du même DN puis décrypter mon
fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec le certif N°1)
avec le certif N°2 qui a la même bi-clé et bien ca pete !!!

Qui pourrait me donner 1 explication du pourquoi ?

Vous avez fourni des détails sur la fabrication de votre clé, certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième certificat.

Ce que tout ça m'évoque, c'est un chiffrement avec du PKCS#7 (ou CMS, S/MIME,
tout ça c'est pareil). Dans ce cas, le récipiendaire de l'objet chiffré
(l'entité capable de le déchiffrer) est identifié par un couple:
- le nom de son émetteur (donc le nom de votre AC)
- son numéro de série

Puisque vous avez un deuxième certificat, vous avez un deuxième numéro de série
(c'est la norme qui veut ça, un numéro de série ne doit *pas* être réutilisé).
Et là, ça pète, comme vous dites, le logiciel vous dit qu'il n'est pas
destinataire de ce fichier, en gros.

Mais tout ça est hypothétique, dans l'attente de plus d'informations de votre part.

--
Erwann.

Bruno Tréguier

23/02/2010 à 01:20

Le 22/02/2010 à 15:40, Erwann Abalea a écrit :

Vous avez fourni des détails sur la fabrication de votre clé, certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième certificat.

Bonsoir Erwann,

Rha, zut, je viens de tomber sur votre message, j'ai répondu pour ma
part dans fr.comp.securite, je n'avais pas fait attention au double post
(sans crosspost ni fu2)...

Mais tout ça est hypothétique, dans l'attente de plus d'informations de votre part.

Idem. Je n'avais pas pensé que le numéro de série pourrait avoir une
influence, car j'étais parti sur l'hypothèse (a priori fausse) que
toutes les opérations, y compris celles relatives au
chiffrement/déchiffrement, avaient été faites avec openssl (en utilisant
la fonctionnalité "rsautl" pour ce cas précis). Dans un tel cas, en
effet, le déchiffrement se faisant avec la clef privée directement (et
non avec un fichier PKCS#12), il faut faire l'opération en 2 temps:
1) extraction de la clef privée du PKCS#12
2) déchiffrement du fichier avec la clef privée

Et dans ce cas, le numéro de série n'intervient absolument pas.

J'ai tenté de voir ce que ça donnait avec des .p12 sous Thunderbird,
mais celui-ci refuse systématiquement d'importer des certificats
auto-signés. :-)

Cordialement,

Bruno

Erwann Abalea

23/02/2010 à 14:45

Bonjour,

Bruno Tréguier a écrit :

Le 22/02/2010 à 15:40, Erwann Abalea a écrit :
Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.

Rha, zut, je viens de tomber sur votre message, j'ai répondu pour ma
part dans fr.comp.securite, je n'avais pas fait attention au double post
(sans crosspost ni fu2)...

Pareil. Mais comme je ne suivais pas fr.comp.securite, je n'avais rien remarqué.
Si vous savez ajouter un le fu2, faites-le, je n'ai pas trouvé comment faire ça
avec Thunderbird (je sais, ça n'est pas exactement le meilleur lecteur de news).

Mais tout ça est hypothétique, dans l'attente de plus d'informations
de votre part.

Idem. Je n'avais pas pensé que le numéro de série pourrait avoir une
influence, car j'étais parti sur l'hypothèse (a priori fausse) que
toutes les opérations, y compris celles relatives au
chiffrement/déchiffrement, avaient été faites avec openssl (en utilisant
la fonctionnalité "rsautl" pour ce cas précis). Dans un tel cas, en
effet, le déchiffrement se faisant avec la clef privée directement (et
non avec un fichier PKCS#12), il faut faire l'opération en 2 temps:
1) extraction de la clef privée du PKCS#12
2) déchiffrement du fichier avec la clef privée

Lisant que l'OP parlait de "fichiers", j'ai moi aussi pensé de cette manière
(rsautl). Mais ça aurait nécessité de savoir générer une clé de session,
chiffrer le dit fichier en symétrique, puis chiffrer la clé de session, et
évidemment l'inverse pour le déchiffrement. C'est un poil plus que simplement se
faire un certificat sur une PKI à la main avec OpenSSL, sans vouloir froisser l'OP.

Et dans ce cas, le numéro de série n'intervient absolument pas.

J'ai tenté de voir ce que ça donnait avec des .p12 sous Thunderbird,
mais celui-ci refuse systématiquement d'importer des certificats
auto-signés. :-)

Et en important le certificat seul, en tant qu'AC, en lui attribuant les droits,
puis en important le P12? Ça m'étonnerait que ça passe, mais on ne sait jamais.

--
Erwann.

Bonjour,

Bruno Tréguier a écrit :

Le 22/02/2010 à 15:40, Erwann Abalea a écrit :

Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.

Rha, zut, je viens de tomber sur votre message, j'ai répondu pour ma
part dans fr.comp.securite, je n'avais pas fait attention au double post
(sans crosspost ni fu2)...

Pareil. Mais comme je ne suivais pas fr.comp.securite, je n'avais rien remarqué.
Si vous savez ajouter un le fu2, faites-le, je n'ai pas trouvé comment faire ça
avec Thunderbird (je sais, ça n'est pas exactement le meilleur lecteur de news).

Mais tout ça est hypothétique, dans l'attente de plus d'informations
de votre part.

Idem. Je n'avais pas pensé que le numéro de série pourrait avoir une
influence, car j'étais parti sur l'hypothèse (a priori fausse) que
toutes les opérations, y compris celles relatives au
chiffrement/déchiffrement, avaient été faites avec openssl (en utilisant
la fonctionnalité "rsautl" pour ce cas précis). Dans un tel cas, en
effet, le déchiffrement se faisant avec la clef privée directement (et
non avec un fichier PKCS#12), il faut faire l'opération en 2 temps:
1) extraction de la clef privée du PKCS#12
2) déchiffrement du fichier avec la clef privée

Lisant que l'OP parlait de "fichiers", j'ai moi aussi pensé de cette manière
(rsautl). Mais ça aurait nécessité de savoir générer une clé de session,
chiffrer le dit fichier en symétrique, puis chiffrer la clé de session, et
évidemment l'inverse pour le déchiffrement. C'est un poil plus que simplement se
faire un certificat sur une PKI à la main avec OpenSSL, sans vouloir froisser l'OP.

Et dans ce cas, le numéro de série n'intervient absolument pas.

J'ai tenté de voir ce que ça donnait avec des .p12 sous Thunderbird,
mais celui-ci refuse systématiquement d'importer des certificats
auto-signés. :-)

Et en important le certificat seul, en tant qu'AC, en lui attribuant les droits,
puis en important le P12? Ça m'étonnerait que ça passe, mais on ne sait jamais.

--
Erwann.

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

Bruno Tréguier a écrit :

Le 22/02/2010 à 15:40, Erwann Abalea a écrit :
Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.

Rha, zut, je viens de tomber sur votre message, j'ai répondu pour ma
part dans fr.comp.securite, je n'avais pas fait attention au double post
(sans crosspost ni fu2)...

Pareil. Mais comme je ne suivais pas fr.comp.securite, je n'avais rien remarqué.
Si vous savez ajouter un le fu2, faites-le, je n'ai pas trouvé comment faire ça
avec Thunderbird (je sais, ça n'est pas exactement le meilleur lecteur de news).

Mais tout ça est hypothétique, dans l'attente de plus d'informations
de votre part.

Idem. Je n'avais pas pensé que le numéro de série pourrait avoir une
influence, car j'étais parti sur l'hypothèse (a priori fausse) que
toutes les opérations, y compris celles relatives au
chiffrement/déchiffrement, avaient été faites avec openssl (en utilisant
la fonctionnalité "rsautl" pour ce cas précis). Dans un tel cas, en
effet, le déchiffrement se faisant avec la clef privée directement (et
non avec un fichier PKCS#12), il faut faire l'opération en 2 temps:
1) extraction de la clef privée du PKCS#12
2) déchiffrement du fichier avec la clef privée

Lisant que l'OP parlait de "fichiers", j'ai moi aussi pensé de cette manière
(rsautl). Mais ça aurait nécessité de savoir générer une clé de session,
chiffrer le dit fichier en symétrique, puis chiffrer la clé de session, et
évidemment l'inverse pour le déchiffrement. C'est un poil plus que simplement se
faire un certificat sur une PKI à la main avec OpenSSL, sans vouloir froisser l'OP.

Et dans ce cas, le numéro de série n'intervient absolument pas.

J'ai tenté de voir ce que ça donnait avec des .p12 sous Thunderbird,
mais celui-ci refuse systématiquement d'importer des certificats
auto-signés. :-)

Et en important le certificat seul, en tant qu'AC, en lui attribuant les droits,
puis en important le P12? Ça m'étonnerait que ça passe, mais on ne sait jamais.

--
Erwann.

Bruno Tréguier

23/02/2010 à 15:36

Le 23/02/2010 à 14:45, Erwann Abalea a écrit :

Bonjour,

Bonjour,

Si vous savez ajouter un le fu2, faites-le, je n'ai pas trouvé comment faire ça
avec Thunderbird (je sais, ça n'est pas exactement le meilleur lecteur de news).

Moui... J'utilise aussi TB histoire de ne pas me disperser, c'est vrai
qu'il y a mieux, mais je ne suis pas accro à usenet à ce point. En fait
il suffit apparemment d'aller sur le champ "Forum" (dans la version Fr),
et le changer en "Faire suivre à". J'ai positionné le fu2 vers
fr.misc.cryptologie, qui me semble plus adapté, on verra si ça marche.

Lisant que l'OP parlait de "fichiers", j'ai moi aussi pensé de cette manière
(rsautl). Mais ça aurait nécessité de savoir générer une clé de session,
chiffrer le dit fichier en symétrique, puis chiffrer la clé de session, et
évidemment l'inverse pour le déchiffrement. C'est un poil plus que simplement se
faire un certificat sur une PKI à la main avec OpenSSL, sans vouloir froisser l'OP.

C'est sûr. J'avais d'ailleurs déduit des explications données (peut-être
abusivement, du coup) qu'il n'utilisait pas de clef de session, ce qui
n'est pas vraiment "académique".

J'ai tenté de voir ce que ça donnait avec des .p12 sous Thunderbird,
mais celui-ci refuse systématiquement d'importer des certificats
auto-signés. :-)

Et en important le certificat seul, en tant qu'AC, en lui attribuant les droits,
puis en important le P12? Ça m'étonnerait que ça passe, mais on ne sait jamais.

J'avais essayé ça aussi, mais non, malheureusement, ça ne passe pas: il
me dit (assez curieusement) que cette AC est déjà présente dans ma liste
! ;-)

Cordialement,

Bruno

neopale

26/02/2010 à 09:54

Erwann Abalea a écrit le 22/02/2010 à 15h40 :

Bonjour,

neopale a écrit :
Voici mon problème en qqes points :
0 - J'ai une "mini" PKI basée sur OpenSSL et qqes scripts qui
vont bien.
1 - Je génère une bi-clé (RSA 3DES et 1024b)
2 - Je créée le CSR
3 - Je signe la CSR par la CA et j'ai mon certificat correspondant à
mes clés
4 - Au passage, je fabrique un pkcs12 (ou pfx) contenant le certif et la
clé
privé

Je crypte un fichier avec ce certif via la clé publique bien sur puis
je
décrypte en passant en paramètre le p12 --> Ok tout est
propre. Je conserve ce
fichier crypté dans 1 coin.

Maintenant, mon problème : je me pose dans la situation de la
révocation/fin de
validité de mon certif. Je souhaitais simplement
regénérer une CSR puis
signature etc à partir de la même bi-clé et du même
DN puis décrypter mon
fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec
le certif N°1)
avec le certif N°2 qui a la même bi-clé et bien ca pete !!!

Qui pourrait me donner 1 explication du pourquoi ?

Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.

Ce que tout ça m'évoque, c'est un chiffrement avec du PKCS#7 (ou
CMS, S/MIME,
tout ça c'est pareil). Dans ce cas, le récipiendaire de l'objet
chiffré
(l'entité capable de le déchiffrer) est identifié par un
couple:
- le nom de son émetteur (donc le nom de votre AC)
- son numéro de série

Puisque vous avez un deuxième certificat, vous avez un deuxième
numéro de série
(c'est la norme qui veut ça, un numéro de série ne doit
*pas* être réutilisé).
Et là, ça pète, comme vous dites, le logiciel vous dit
qu'il n'est pas
destinataire de ce fichier, en gros.

Mais tout ça est hypothétique, dans l'attente de plus
d'informations de votre part.

--
Erwann.

Désolé pour le cross post... Petite erreur d'évaluation de groupe;-( En tout cas merci pour vos réponses

Sinon concernant le cas qui m'interesse, je pense avoir la réponse néanmoins, voici les éléments complémentaires demandés :
- Rappel : L'objectif est d'évaluer la possibilité de voir si 2 certif sur une meme bi-clé et naivement voir si un doc/mail via smime crypté avec le premier certif peut etre décrypté avec le second - ie voir si seule la clé privée est nécessaire ou pas (Dans un contexte d'utilisation normal - Outlook, thunderbird etc ...)
- Sinon, j'utilise une suite de script basé sur OpenSSL pour me construire : la CA, une bi-clé et le certif associé avec un DN systématiquement le même codé dans dans un fichier de conf.
- L'API que j'utilise pour prototyper le tout est CAPICOM version script (ultra facile pour prototyper) sinon normalement on utilise BouncyCastle plutot via PKCS11 ...
- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le certif N°1 - contenant la clé publique), c'est la ou j'ai mon explication bien sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le p12 avec la clé privée et le certif associé N°2 dans le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par défaut tape dans "my" et c'est ici que j'ai l'erreur "no recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif N°1, le fichier est décrypté.

NB : Effectivement, si je descends au niveau plus bas en utilisant simplement la bi-clé, mon problème est nul et non avenu car cela fonctionnera mais ne me renseigne pas sur l'usage dans un thunderbird par exemple,

Enfin, cela implique qu'un certif revoqué doit etre conservé pour décrypter les messages anciens car, dans le cas ou les msg sont conservés cryptés par les mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui me chagrine, comment géré simplement cela :-(

Vos avis et expériences sont les bienvenues

Merci

Erwann Abalea a écrit le 22/02/2010 à 15h40 :

Bonjour,

neopale a écrit :

Voici mon problème en qqes points :
0 - J'ai une "mini" PKI basée sur OpenSSL et qqes scripts qui
vont bien.
1 - Je génère une bi-clé (RSA 3DES et 1024b)
2 - Je créée le CSR
3 - Je signe la CSR par la CA et j'ai mon certificat correspondant à
mes clés
4 - Au passage, je fabrique un pkcs12 (ou pfx) contenant le certif et la
clé
privé

Je crypte un fichier avec ce certif via la clé publique bien sur puis
je
décrypte en passant en paramètre le p12 --> Ok tout est
propre. Je conserve ce
fichier crypté dans 1 coin.

Maintenant, mon problème : je me pose dans la situation de la
révocation/fin de
validité de mon certif. Je souhaitais simplement
regénérer une CSR puis
signature etc à partir de la même bi-clé et du même
DN puis décrypter mon
fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec
le certif N°1)
avec le certif N°2 qui a la même bi-clé et bien ca pete !!!

Qui pourrait me donner 1 explication du pourquoi ?

Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.

Ce que tout ça m'évoque, c'est un chiffrement avec du PKCS#7 (ou
CMS, S/MIME,
tout ça c'est pareil). Dans ce cas, le récipiendaire de l'objet
chiffré
(l'entité capable de le déchiffrer) est identifié par un
couple:
- le nom de son émetteur (donc le nom de votre AC)
- son numéro de série

Puisque vous avez un deuxième certificat, vous avez un deuxième
numéro de série
(c'est la norme qui veut ça, un numéro de série ne doit
*pas* être réutilisé).
Et là, ça pète, comme vous dites, le logiciel vous dit
qu'il n'est pas
destinataire de ce fichier, en gros.

Mais tout ça est hypothétique, dans l'attente de plus
d'informations de votre part.

--
Erwann.

Désolé pour le cross post... Petite erreur d'évaluation de groupe;-( En tout cas merci pour vos réponses

Sinon concernant le cas qui m'interesse, je pense avoir la réponse néanmoins, voici les éléments complémentaires demandés :
- Rappel : L'objectif est d'évaluer la possibilité de voir si 2 certif sur une meme bi-clé et naivement voir si un doc/mail via smime crypté avec le premier certif peut etre décrypté avec le second - ie voir si seule la clé privée est nécessaire ou pas (Dans un contexte d'utilisation normal - Outlook, thunderbird etc ...)
- Sinon, j'utilise une suite de script basé sur OpenSSL pour me construire : la CA, une bi-clé et le certif associé avec un DN systématiquement le même codé dans dans un fichier de conf.
- L'API que j'utilise pour prototyper le tout est CAPICOM version script (ultra facile pour prototyper) sinon normalement on utilise BouncyCastle plutot via PKCS11 ...
- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le certif N°1 - contenant la clé publique), c'est la ou j'ai mon explication bien sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le p12 avec la clé privée et le certif associé N°2 dans le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par défaut tape dans "my" et c'est ici que j'ai l'erreur "no recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif N°1, le fichier est décrypté.

NB : Effectivement, si je descends au niveau plus bas en utilisant simplement la bi-clé, mon problème est nul et non avenu car cela fonctionnera mais ne me renseigne pas sur l'usage dans un thunderbird par exemple,

Enfin, cela implique qu'un certif revoqué doit etre conservé pour décrypter les messages anciens car, dans le cas ou les msg sont conservés cryptés par les mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui me chagrine, comment géré simplement cela :-(

Vos avis et expériences sont les bienvenues

Merci

Vous avez filtré cet utilisateur ! Consultez son message

Erwann Abalea a écrit le 22/02/2010 à 15h40 :

Bonjour,

neopale a écrit :
Voici mon problème en qqes points :
0 - J'ai une "mini" PKI basée sur OpenSSL et qqes scripts qui
vont bien.
1 - Je génère une bi-clé (RSA 3DES et 1024b)
2 - Je créée le CSR
3 - Je signe la CSR par la CA et j'ai mon certificat correspondant à
mes clés
4 - Au passage, je fabrique un pkcs12 (ou pfx) contenant le certif et la
clé
privé

Je crypte un fichier avec ce certif via la clé publique bien sur puis
je
décrypte en passant en paramètre le p12 --> Ok tout est
propre. Je conserve ce
fichier crypté dans 1 coin.

Maintenant, mon problème : je me pose dans la situation de la
révocation/fin de
validité de mon certif. Je souhaitais simplement
regénérer une CSR puis
signature etc à partir de la même bi-clé et du même
DN puis décrypter mon
fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec
le certif N°1)
avec le certif N°2 qui a la même bi-clé et bien ca pete !!!

Qui pourrait me donner 1 explication du pourquoi ?

Vous avez fourni des détails sur la fabrication de votre clé,
certificat, etc,
mais trop peu sur la méthode de chiffrement de votre fichier, et sur
l'erreur
exacte que vous obtenez lors du déchiffrement avec le deuxième
certificat.

Ce que tout ça m'évoque, c'est un chiffrement avec du PKCS#7 (ou
CMS, S/MIME,
tout ça c'est pareil). Dans ce cas, le récipiendaire de l'objet
chiffré
(l'entité capable de le déchiffrer) est identifié par un
couple:
- le nom de son émetteur (donc le nom de votre AC)
- son numéro de série

Puisque vous avez un deuxième certificat, vous avez un deuxième
numéro de série
(c'est la norme qui veut ça, un numéro de série ne doit
*pas* être réutilisé).
Et là, ça pète, comme vous dites, le logiciel vous dit
qu'il n'est pas
destinataire de ce fichier, en gros.

Mais tout ça est hypothétique, dans l'attente de plus
d'informations de votre part.

--
Erwann.

Désolé pour le cross post... Petite erreur d'évaluation de groupe;-( En tout cas merci pour vos réponses

Sinon concernant le cas qui m'interesse, je pense avoir la réponse néanmoins, voici les éléments complémentaires demandés :
- Rappel : L'objectif est d'évaluer la possibilité de voir si 2 certif sur une meme bi-clé et naivement voir si un doc/mail via smime crypté avec le premier certif peut etre décrypté avec le second - ie voir si seule la clé privée est nécessaire ou pas (Dans un contexte d'utilisation normal - Outlook, thunderbird etc ...)
- Sinon, j'utilise une suite de script basé sur OpenSSL pour me construire : la CA, une bi-clé et le certif associé avec un DN systématiquement le même codé dans dans un fichier de conf.
- L'API que j'utilise pour prototyper le tout est CAPICOM version script (ultra facile pour prototyper) sinon normalement on utilise BouncyCastle plutot via PKCS11 ...
- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le certif N°1 - contenant la clé publique), c'est la ou j'ai mon explication bien sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le p12 avec la clé privée et le certif associé N°2 dans le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par défaut tape dans "my" et c'est ici que j'ai l'erreur "no recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif N°1, le fichier est décrypté.

NB : Effectivement, si je descends au niveau plus bas en utilisant simplement la bi-clé, mon problème est nul et non avenu car cela fonctionnera mais ne me renseigne pas sur l'usage dans un thunderbird par exemple,

Enfin, cela implique qu'un certif revoqué doit etre conservé pour décrypter les messages anciens car, dans le cas ou les msg sont conservés cryptés par les mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui me chagrine, comment géré simplement cela :-(

Vos avis et expériences sont les bienvenues

Merci

Erwann Abalea

26/02/2010 à 15:40

Bonjour,

neopale a écrit :
[...]

- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif N°1, le
fichier est décrypté.

Merci pour les détails complémentaires, qui confirment ce que je pensais, vous
faites du CMS/PKCS#7/SMIME. Et dans ce mode, le récipiendaire est désigné par
son certificat.

NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,

Enfin, cela implique qu'un certif revoqué doit etre conservé pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui me
chagrine, comment géré simplement cela :-(

Vos avis et expériences sont les bienvenues

Il n'y a pas de mystère, si votre environnement est un logiciel de courrier, et
si l'échange de documents chiffrés se fait par des mails chiffrés façon S/MIME,
alors vous devez en accepter les règles. Cela signifie que l'utilisateur doit
conserver ses certificats, même les expirés, même les révoqués, s'il souhaite
déchiffrer un mail.

Si vous ne pouvez pas garantir cela (trop d'utilisateurs, et qui parfois
réinstallent eux-même leur poste, sans trop faire attention), alors vous pouvez
envisager un service de séquestre de clés, et dans ce cas, un utilisateur aura
plusieurs certificats+clés, avec le même DN, mais pour des usages différents.

Un tiers de séquestre peut générer la clé de chiffrement ou la recevoir du
demandeur, il la conserve précieusement. S'il l'a générée, il en fournit une
copie au demandeur pour qu'il effectue la demande de certificat, voire il fait
la demande lui-même, et fournit un PKCS#12 complet au demandeur. De son côté, le
demandeur fait pour son propre compte une demande de certificat de signature
et/ou authentification, avec une clé privée qu'il est le seul à détenir.

--
Erwann.

Bonjour,

neopale a écrit :
[...]

- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif N°1, le
fichier est décrypté.

Merci pour les détails complémentaires, qui confirment ce que je pensais, vous
faites du CMS/PKCS#7/SMIME. Et dans ce mode, le récipiendaire est désigné par
son certificat.

NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,

Enfin, cela implique qu'un certif revoqué doit etre conservé pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui me
chagrine, comment géré simplement cela :-(

Vos avis et expériences sont les bienvenues

Il n'y a pas de mystère, si votre environnement est un logiciel de courrier, et
si l'échange de documents chiffrés se fait par des mails chiffrés façon S/MIME,
alors vous devez en accepter les règles. Cela signifie que l'utilisateur doit
conserver ses certificats, même les expirés, même les révoqués, s'il souhaite
déchiffrer un mail.

Si vous ne pouvez pas garantir cela (trop d'utilisateurs, et qui parfois
réinstallent eux-même leur poste, sans trop faire attention), alors vous pouvez
envisager un service de séquestre de clés, et dans ce cas, un utilisateur aura
plusieurs certificats+clés, avec le même DN, mais pour des usages différents.

Un tiers de séquestre peut générer la clé de chiffrement ou la recevoir du
demandeur, il la conserve précieusement. S'il l'a générée, il en fournit une
copie au demandeur pour qu'il effectue la demande de certificat, voire il fait
la demande lui-même, et fournit un PKCS#12 complet au demandeur. De son côté, le
demandeur fait pour son propre compte une demande de certificat de signature
et/ou authentification, avec une clé privée qu'il est le seul à détenir.

--
Erwann.

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

neopale a écrit :
[...]

- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif N°1, le
fichier est décrypté.

Merci pour les détails complémentaires, qui confirment ce que je pensais, vous
faites du CMS/PKCS#7/SMIME. Et dans ce mode, le récipiendaire est désigné par
son certificat.

NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,

Enfin, cela implique qu'un certif revoqué doit etre conservé pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui me
chagrine, comment géré simplement cela :-(

Vos avis et expériences sont les bienvenues

Il n'y a pas de mystère, si votre environnement est un logiciel de courrier, et
si l'échange de documents chiffrés se fait par des mails chiffrés façon S/MIME,
alors vous devez en accepter les règles. Cela signifie que l'utilisateur doit
conserver ses certificats, même les expirés, même les révoqués, s'il souhaite
déchiffrer un mail.

Si vous ne pouvez pas garantir cela (trop d'utilisateurs, et qui parfois
réinstallent eux-même leur poste, sans trop faire attention), alors vous pouvez
envisager un service de séquestre de clés, et dans ce cas, un utilisateur aura
plusieurs certificats+clés, avec le même DN, mais pour des usages différents.

Un tiers de séquestre peut générer la clé de chiffrement ou la recevoir du
demandeur, il la conserve précieusement. S'il l'a générée, il en fournit une
copie au demandeur pour qu'il effectue la demande de certificat, voire il fait
la demande lui-même, et fournit un PKCS#12 complet au demandeur. De son côté, le
demandeur fait pour son propre compte une demande de certificat de signature
et/ou authentification, avec une clé privée qu'il est le seul à détenir.

--
Erwann.

neopale

01/03/2010 à 19:00

Erwann Abalea a écrit le 26/02/2010 à 15h40 :

Bonjour,

neopale a écrit :
[...]
- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon
explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans
le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no
recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif
N°1, le
fichier est décrypté.

Merci pour les détails complémentaires, qui confirment ce que je
pensais, vous
faites du CMS/PKCS#7/SMIME. Et dans ce mode, le récipiendaire est
désigné par
son certificat.

NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela
fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,

Enfin, cela implique qu'un certif revoqué doit etre conservé
pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés
cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui
me
chagrine, comment géré simplement cela :-(

Vos avis et expériences sont les bienvenues

Il n'y a pas de mystère, si votre environnement est un logiciel de
courrier, et
si l'échange de documents chiffrés se fait par des mails
chiffrés façon S/MIME,
alors vous devez en accepter les règles. Cela signifie que l'utilisateur
doit
conserver ses certificats, même les expirés, même les
révoqués, s'il souhaite
déchiffrer un mail.

Si vous ne pouvez pas garantir cela (trop d'utilisateurs, et qui parfois
réinstallent eux-même leur poste, sans trop faire attention),
alors vous pouvez
envisager un service de séquestre de clés, et dans ce cas, un
utilisateur aura
plusieurs certificats+clés, avec le même DN, mais pour des usages
différents.

Un tiers de séquestre peut générer la clé de
chiffrement ou la recevoir du
demandeur, il la conserve précieusement. S'il l'a
générée, il en fournit une
copie au demandeur pour qu'il effectue la demande de certificat, voire il fait
la demande lui-même, et fournit un PKCS#12 complet au demandeur. De son
côté, le
demandeur fait pour son propre compte une demande de certificat de signature
et/ou authentification, avec une clé privée qu'il est le seul
à détenir.

--
Erwann.

Merci beaucoup pour votre réponse, ces éclaircissements et pour cette confirmation qui est en sommes toute logique mais qui, si on regarde de plus près les principes de base (cryptage avec clé publique/décryptage avec clé privée), n'est pas forcément aussi naturelle.

Merci encore
Jean-Louis

Erwann Abalea a écrit le 26/02/2010 à 15h40 :

Bonjour,

neopale a écrit :
[...]

- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon
explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans
le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no
recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif
N°1, le
fichier est décrypté.

Merci pour les détails complémentaires, qui confirment ce que je
pensais, vous
faites du CMS/PKCS#7/SMIME. Et dans ce mode, le récipiendaire est
désigné par
son certificat.

NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela
fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,

Enfin, cela implique qu'un certif revoqué doit etre conservé
pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés
cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui
me
chagrine, comment géré simplement cela :-(

Vos avis et expériences sont les bienvenues

Il n'y a pas de mystère, si votre environnement est un logiciel de
courrier, et
si l'échange de documents chiffrés se fait par des mails
chiffrés façon S/MIME,
alors vous devez en accepter les règles. Cela signifie que l'utilisateur
doit
conserver ses certificats, même les expirés, même les
révoqués, s'il souhaite
déchiffrer un mail.

Si vous ne pouvez pas garantir cela (trop d'utilisateurs, et qui parfois
réinstallent eux-même leur poste, sans trop faire attention),
alors vous pouvez
envisager un service de séquestre de clés, et dans ce cas, un
utilisateur aura
plusieurs certificats+clés, avec le même DN, mais pour des usages
différents.

Un tiers de séquestre peut générer la clé de
chiffrement ou la recevoir du
demandeur, il la conserve précieusement. S'il l'a
générée, il en fournit une
copie au demandeur pour qu'il effectue la demande de certificat, voire il fait
la demande lui-même, et fournit un PKCS#12 complet au demandeur. De son
côté, le
demandeur fait pour son propre compte une demande de certificat de signature
et/ou authentification, avec une clé privée qu'il est le seul
à détenir.

--
Erwann.

Merci beaucoup pour votre réponse, ces éclaircissements et pour cette confirmation qui est en sommes toute logique mais qui, si on regarde de plus près les principes de base (cryptage avec clé publique/décryptage avec clé privée), n'est pas forcément aussi naturelle.

Merci encore
Jean-Louis

Vous avez filtré cet utilisateur ! Consultez son message

Erwann Abalea a écrit le 26/02/2010 à 15h40 :

Bonjour,

neopale a écrit :
[...]
- Mode opératoire :
. je crypte en ajoutant un récipiendaire (addRecipient(...) avec le
certif N°1 - contenant la clé publique), c'est la ou j'ai mon
explication bien
sur!!!
.Je simule une situation "normale" dans le monde MS, et j'importe le
p12 avec la clé privée et le certif associé N°2 dans
le magasin "my"
. La j'utilise simplement le decrypt() sur le fichier crypté qui par
défaut tape dans "my" et c'est ici que j'ai l'erreur "no
recipents found ...."
. La bien sur si pose le p12 avec la même bi-clé + certif
N°1, le
fichier est décrypté.

Merci pour les détails complémentaires, qui confirment ce que je
pensais, vous
faites du CMS/PKCS#7/SMIME. Et dans ce mode, le récipiendaire est
désigné par
son certificat.

NB : Effectivement, si je descends au niveau plus bas en utilisant simplement
la bi-clé, mon problème est nul et non avenu car cela
fonctionnera mais ne me
renseigne pas sur l'usage dans un thunderbird par exemple,

Enfin, cela implique qu'un certif revoqué doit etre conservé
pour décrypter les
messages anciens car, dans le cas ou les msg sont conservés
cryptés par les
mailers, leur lecture future ne sera plus possible. Et c'est bien ce cas qui
me
chagrine, comment géré simplement cela :-(

Vos avis et expériences sont les bienvenues

Il n'y a pas de mystère, si votre environnement est un logiciel de
courrier, et
si l'échange de documents chiffrés se fait par des mails
chiffrés façon S/MIME,
alors vous devez en accepter les règles. Cela signifie que l'utilisateur
doit
conserver ses certificats, même les expirés, même les
révoqués, s'il souhaite
déchiffrer un mail.

Si vous ne pouvez pas garantir cela (trop d'utilisateurs, et qui parfois
réinstallent eux-même leur poste, sans trop faire attention),
alors vous pouvez
envisager un service de séquestre de clés, et dans ce cas, un
utilisateur aura
plusieurs certificats+clés, avec le même DN, mais pour des usages
différents.

Un tiers de séquestre peut générer la clé de
chiffrement ou la recevoir du
demandeur, il la conserve précieusement. S'il l'a
générée, il en fournit une
copie au demandeur pour qu'il effectue la demande de certificat, voire il fait
la demande lui-même, et fournit un PKCS#12 complet au demandeur. De son
côté, le
demandeur fait pour son propre compte une demande de certificat de signature
et/ou authentification, avec une clé privée qu'il est le seul
à détenir.

--
Erwann.

Merci beaucoup pour votre réponse, ces éclaircissements et pour cette confirmation qui est en sommes toute logique mais qui, si on regarde de plus près les principes de base (cryptage avec clé publique/décryptage avec clé privée), n'est pas forcément aussi naturelle.

Merci encore
Jean-Louis

Une bi-clé, 2 certificats sur la même bi-clé et cryptage, question ...

7 réponses

Veuillez sélectionner un problème