(This concerns Bouncy Castle Java v1.56 but there seems to have been no updates regarding this issue in v1.57)
I have been working with the BCPQC provider as part of my master's thesis and I have noticed a bug when generating X.509 certificates containing SPHINCS public keys (and most likely any other post-quantum algorithm key).
When generating an X509Certificate containing a post-quantum key using the JcaX509v3CertificateBuilder and JcaX509CertificateConverter classes, calling X509Certificate.getPublicKey() returns a null reference.
An example for the checkCreation6 test in CertTest.java:
X509Certificate baseCert = new JcaX509CertificateConverter().setProvider(BC).getCertificate(certGen.build(sigGen));
System.out.println(baseCert.getPublicKey()); //baseCert.getPublicKey() returns a null reference
The problem seems to be that the BC and BCPQC providers are separated and thus the mappings added in SPHINCS.java are not recognised when dealing with X.509 certificates. I have found that the only solution is to add Sphincs256KeyFactorySpi as a KeyInfoConverter in the BC provider as such:
ASN1ObjectIdentifier sphincsOID = PQCObjectIdentifiers.sphincs256;
AsymmetricKeyInfoConverter sphincsKeyInfoConverter = new Sphincs256KeyFactorySpi();
I am wondering what the reason is for separating the two providers? With post-quantum algorithms becoming increasingly relevant it seems counter-productive to keep them in a separate provider.
Thank you for taking your time to read and answer this e-mail.
Yes, it's a good point, I think we could definitely do a better job with this one. There does need to be a way unifying the certificate handling. The providers are separate for historical reasons - the first version of the BCPQC provider was based on donated code and also quite experimental - we are heading into terrain where this is no longer the full picture though.
You'll need to give us a bit of time on this one... I'll get back to you.
On 24/05/17 23:47, Mikael Sjöberg wrote:
|Free forum by Nabble||Edit this page|