I just did some more tests. I noticed that if I export the private key and the certificates contained in the (non-distributable) p12 file with the following commands
openssl pkcs12 -nokeys -in client.p12 > certs.pem openssl pkcs12 -nocerts -in client.p12 > keys.pem and then create an new p12 file with openssl pkcs12 -in certs.pem -inkey keys.pem -export -out client_new.p12 I can import it without any issues using gpgsm --import To investigate what the difference between the newly created p12 file and the old one is I diffed the output of openssl pkcs12 -in old.p12 -nodes -info and openssl pkcs12 -in new.p12 -nodes -info The result is the following 47c47 < Bag Attributes: <Empty Attributes> --- > Bag Attributes: <No Attributes> 89c89 < Bag Attributes: <Empty Attributes> --- > Bag Attributes: <No Attributes> 124c124 < Bag Attributes: <Empty Attributes> --- > Bag Attributes: <No Attributes> This means that in the old p12 file the string "Empty Attributes" is used to indicate that there are no attributes, whereas in the newly created p12 file they use "No Attributes" I do not know how gpgsm checks if there are additional attributes. May this observation also hints into the direction of the error. Regards, Nils Nils Schween <nils.schw...@mpi-hd.mpg.de> writes: > Thanks for joining the discussion. I changed the value of the salt length > to 32. That did not change anything. However, I tried to get some more > information. I used gpsm -vv --import for both certificates and a > difference appeared: > > When I am importing the self-created certificate the import process is > skipping shrouded_key_bag.attribute_set when reaching the private key. > Here the output: > > gpgsm: enabled compatibility flags: > gpgsm: processing bag.encryptedData > gpgsm: 1536 bytes of AES256 encrypted text > gpgsm: processing certBag > gpgsm: certificate already in DB > gpgsm: skipping bag.attribute_set > gpgsm: processing bag data > gpgsm: processing shrouded_key_bag > gpgsm: 2384 bytes of AES256 encrypted text > gpgsm: skipping shrouded_key_bag.attribute_set > > Whereas the import of the (non-distributable) certificate yields > > gpgsm: bad length of salt (32) for AES > gpgsm: parse_shrouded_key_bag(shrouded_key_bag.pkcs5PBES2-params): lvl=16 > (tlv_expect_octet_string): Erfolg - Ungültige Länge > gpgsm: parse_bag_data(data.oid): lvl=16 (tlv_expect_octet_string): Erfolg - > Ungültige Länge > gpgsm: p12_parse(bag.data): @6724 lvl=16 tlv_expect_octet_string: Erfolg - > Ungültige Länge > gpgsm: error parsing or decrypting the PKCS#12 file > > The import is not skipping shrouded_key_bag.attribute_set. > > That the error goes away when I change the salt array length in > parse_shrouded_key_bag, makes from sense from this perspective. > > Unfortunately, I do not know how I can change my self-created certificate > such that the gpgsm --import command does not skip the shrouded_key_bag > attribute when importing the private key. Do you have any idea what > options I need to set when creating the key or the p12 file to set the > shrouded_key_bag attribute? > > Thank you. > Nils > > Jakob Bohm via Gnupg-users <gnupg-users@gnupg.org> writes: > >> Dear Nils, >> >> Given the error message in the subject line above, the step to reproduce may >> be >> to pass 32 instead of 64 to the openssl command that makes the test >> certificate. >> >> Otherwise, look for a command that can dump out the formatting details of the >> (non-distributable) problematic pkcs12 file to see what values it actually >> uses. >> >> On 2024-09-20 12:02, Nils Schween wrote: >>>> Given the brittleness of pkcs#12/minip12.c I would really appricate to >>>> have a sample file. But the worst thing which could happen is that the >>>> 64 bit salt does not work anymore in the future. It is unlikey, though. >>> I do understand. I tried to create one this morning, but I was not able >>> to reproduce the error when importing my self created certificate. >>> >>> I used the following commands to create the certificate: >>> >>> openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -sha384 -days 365 >>> -out certificate.pem >>> >>> openssl pkcs12 -inkey key.pem -in certificate.pem -export -macsaltlen 64 >>> -iter 20000 -out certificate.p12 >>> >>> To compare my own certificate with the one issued by the certificate >>> provider I used the following two commands: >>> >>> openssl pkcs12 -in certificate.p12 -noout -info >>> openssl x509 -text -noout -in certificate.p12 >>> >>> I could not find any significant difference in the output. Though the >>> one from the certificate provider causes the error when imported with >>> gpgsm while my own certificate does not. >>> >>> Since I am not very knowledgeable when it comes to S/MIME certificates, >>> it is riddle to me why the error appears: My certificate and the one >>> from the provider have a salt length of 64bit and that was the only >>> thing I changed in minip12.c >>> >>> So, I have to say that I am sorry, I cannot reproduce the error with a >>> self-created certificate. >>> >>>> Please give me some days to apply the patch. >>> No hurry, for now I have a personal work around. >>> >>> Thank you, >>> Nils >>> >>> Werner Koch <w...@gnupg.org> writes: >>> >>>> On Thu, 19 Sep 2024 13:42, Nils Schween said: >>>> >>>>> If it is necessary, I can try to create a certificate with openssl, that >>>>> reproduces the error. >>>> Given the brittleness of pkcs#12/minip12.c I would really appricate to >>>> have a sample file. But the worst thing which could happen is that the >>>> 64 bit salt does not work anymore in the future. It is unlikey, though. >>>> >>>> Please give me some days to apply the patch. >>>> >>>> >>>> Salam-Shalom, >>>> >>>> Werner >> >> Enjoy >> >> Jakob -- Nils Schween PhD Student Phone: +49 6221 516 557 Mail: nils.schw...@mpi-hd.mpg.de PGP-Key: 4DD3DCC0532EE96DB0C1F8B5368DBFA14CB81849 Max Planck Institute for Nuclear Physics Astrophysical Plasma Theory (APT) Saupfercheckweg 1, D-69117 Heidelberg https://www.mpi-hd.mpg.de/mpi/en/research/scientific-divisions-and-groups/independent-research-groups/apt
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
