cert path validation with CRL checking enabled fails, sigProvider is always null

[GoogleCodeExporter]

What steps will reproduce the problem?
1.
I'm trying to create a XAdES-C signature. I'm using the 
ValidationDataFromCertValidationProvider to obtain the validation data. This 
provider finds the validation data by validating the certificate path with a 
PKIXCertificateValidationProvider. Since the XAdES-C profile forces me to 
provide the CRLs, I need to enable CRL checking. Unfortunately, validation 
fails because the signature validation on the CRLs fails. That's because the 
sigProvider of the PKIXBuilderParameters used by 
PKIXCertificateValidationProvider is always null. The call 
Signature.getInstance(alg, null) always throws with an 
IllegalArgumentException("missing provider"). Since none of the CRLs are 
acceptable, the whole path validation fails.

2.
3.

What is the expected output? What do you see instead?
We need a method to set the sigProvider in the 
PKIXCertificateValidationProvider so that certificate path validation with CRL 
enabled works.

What version of the product are you using? On what operating system?
1.2.0
Windows 7

Please provide any additional information below.
The work-around is to copy the PKIXCertificateValidationProvider and add the 
code to set the sigProvider. This causes maintenance problems and licensing 
issues. I think adding the sigProvider parameter is the best solution. Another 
improvement could be to move the creation of the PKIXBuilderParameters into a 
protected method. This would allow subclassing.

Is there a junit that tests the PKIXCertificateValidationProvider with CRL 
checking enabled?

Original issue reported on code.google.com by clementp...@gmail.com on 3 Nov 2011 at 2:38

[GoogleCodeExporter]

May I request that this issue be raised above Medium. This is the most 
important issue for us at the moment.

Original comment by clementp...@gmail.com on 14 Nov 2011 at 8:01

[GoogleCodeExporter]

I have attached a sample application that reproduces this problem. If you call 
the batch file doit.cmd without an argument, it will run the class without a 
provider and the signature will be created correctly. If you run the batch file 
with an argument like this: doit.cmd BC,  it will create the KeyStores and 
CertStores with that JCE provider and the signature will fail. You will need to 
download the BouncyCastle jar from 
http://www.bouncycastle.org/latest_releases.html

Original comment by clementp...@gmail.com on 6 Dec 2011 at 5:02

Attachments:

• issue16.zip

[GoogleCodeExporter]

When running your app with the BC provider I'm getting an InvalidKeyException 
(illegal key size). Here's the stack trace:

Exception in thread "main" java.io.IOException: exception unwrapping private 
key - java.security.InvalidKeyException: Illegal key size
        at org.bouncycastle.jce.provider.JDKPKCS12KeyStore.unwrapKey(Unknown Source)
        at org.bouncycastle.jce.provider.JDKPKCS12KeyStore.engineLoad(Unknown Source)
        at java.security.KeyStore.load(KeyStore.java:1185)
        at Issue16.main(Issue16.java:55)

Do you have any quick hint on this? Some problem with the .p12 keystore? I'll 
look into it later, and possibly create a test for this scenario (using the BC 
provider).

Original comment by luis.fgoncalv on 7 Feb 2012 at 10:05

[GoogleCodeExporter]

Did you install the Unlimited Strength Jurisdiction Policy Files?

Original comment by clementp...@gmail.com on 8 Feb 2012 at 9:28

[GoogleCodeExporter]

I hadn't installed the files, thanks! It now behaves as you described. 

Original comment by luis.fgoncalv on 8 Feb 2012 at 11:03

• Changed state: Started

[GoogleCodeExporter]

Original comment by luis.fgoncalv on 8 Feb 2012 at 11:03

[GoogleCodeExporter]

I made some tests and couldn't figure out the requirements in terms of 
providers yet. I tried different combinations of providers (on the different 
JCE components in use) and the problem only seems to come up when the provider 
of the CertificateFactory (for the CRL's) is BC and the cert path builder is 
SUN's. If BC's cert path builder is used, the problem never comes up, even if 
everything else is using SUN's provider. I can't really tell that whether it's 
working because of the BC provider.. I need to go further on the cert path 
building steps.

You mentioned Signature.getInstance(alg, null)..you're referring to somewhere 
in the PKIXCertPathBuilder code?

Original comment by luis.fgoncalv on 12 Feb 2012 at 9:12

[GoogleCodeExporter]

You can put a breakpoint on Signature.getInstance to see where it is being 
called. My guess is it will be called by the CertPathBuilder when verifying the 
Issuer signature in a certificate.

Have you tried hard-coding the Signature provider in the PKIX parameters just 
to see if that makes it work with the SUN CertPathBuilder?

This bug is not asking you to debug why the Sun cert path builder is not 
working with BC. I believe all you have to do is expose a parameter for the 
Signature provider. You should also show how users could choose the 
CertPathBuilder provider. This way a user could choose to use BC everywhere and 
have a consistent environment.

Original comment by clementp...@gmail.com on 15 Feb 2012 at 4:11

[GoogleCodeExporter]

I was looking into provider combinations to try to figure out if I could use 
some of the supplied providers (e.g. from the trust anchors key store) to get 
the CertPathBuilder. But the best solution probably is to just allow the 
provider configuration, as you suggested.

Original comment by luis.fgoncalv on 16 Feb 2012 at 9:49

[GoogleCodeExporter]

You mentioned the CertPathBuilder provider.. do you suggest adding another 
parameter for this?  

I'm starting to wonder if a more centralized way to define providers would be 
useful, also considering issue 19. Maybe something per engine class. But it 
seems overkill and might not be easy to make that config available on xades4j 
providers such as PKIXCertificateValidationProvider.

Original comment by luis.fgoncalv on 24 Feb 2012 at 8:33

[GoogleCodeExporter]

Just for reference, the problem seems to be that SUN's X509CRL implementation 
checks for null provider argument on verify(PublicKey k, String sigProvider) 
and calls the appropriate Signature.getInstance overload, while BC's doesn't.

Original comment by luis.fgoncalv on 25 Feb 2012 at 11:27

[GoogleCodeExporter]

On Feb 29 2012, I sent an email on the BouncyCastle mailing list to report the 
bug in X509CRLObject.verify() when it calls 
Signature.getInstance(String,String) with null in the second argument. It 
should improve things if they fix their bug, though it is still important to 
allow the configuration of the JCE provider in XAdES4J.

Original comment by clementp...@gmail.com on 29 Feb 2012 at 9:45

[GoogleCodeExporter]

I agree. The XAdES4j providers that use JCE have been updated to include 
constructor arguments to specify the JCE provider. Maybe in the future a wider 
configuration of JCE providers could be considered.

Original comment by luis.fgoncalv on 29 Feb 2012 at 10:46

• Changed state: Fixed