Hi all,

i am implementing the pkcs#7 signing/verifying via the Bouncy Castle API. I am following the sample method "testDetachedVerification" under the CMS package "SignedDataTest" (bcmail-jdk15-143). I realised that when we performed the signature verification, we are using the public cert of the "_signCert". This is exactly the procedure listed in the Public key cryptopgraphy.

As i am also referencing the implementation ("SignedDataExample.java" and "SignedDataProcessor.java") from the book "Beginning Cryptography with Java by David Hook", and i found out one interesting step the sample code include is the cert path validation on the public cert we used to validate the signature. Such cert path validation is not included in the "SignedDataTest" in BouncyCastle Sample.

The way i intend to implement the signature validation logic is quite similiar from the sample in "Beginning Crypto with Java" and is depicted as follow


Pre-requisite: User insert the signer subject cert, its related CA cert into Truststore (cacerts under "jre150_05\lib\security")

1) Extract the Signer Info. As the actual signer cert may not need to exist in the signature (as per RFC3852), i will base on the signer info to locate the actual sign cert from the Truststore (cacerts under "jre150_05\lib\security").

2) construct a PKIXCertPathBuilderResult given the SignCert i located from truststore.

3) invoke signerInfo.verify(signCert, "BC")


My question is whenever we verifying the signature, do we need to perform Cert Path validation checking on the public cert we use? Based on the way i intend to impl, it seems that there will be some overhead as for each validation of signature, i need to load cert from the truststore and construct a CertPathBuilder.

Is it possible for me to omit step 2 and just do step 1) and 3) ? I will perform cert path validation on the "Pre-requisite" step, how do you guys think?

Really appreciate your input!

Regards
Yangguo

With the path validation - you only need to do it if you are trying to validate a signature from the certificate stored in the message. If you already know the certificate is trusted you can skip the check if the signature validates against the certificate you trust, and the serial number/issuer indicates that it was that certificate that was used.

Regards,

David