DefaultDigestAlgorithmIdentifierFinder throws NPE for Composite Sigs

[Akretsch]

org.bouncycastle.operator.DefaultDigestAlgorithmIdentifierFinder.find(MiscObjectIdentifiers.id_MLDSA44_RSA2048_PSS_SHA256) triggers NullPointerException("digest OID is null") in
org.bouncycastle.operator.DefaultDigestAlgorithmIdentifierFinder.find(ASN1ObjectIdentifier).

I would expect org.bouncycastle.operator.DefaultDigestAlgorithmIdentifierFinder.find(MiscObjectIdentifiers.id_MLDSA44_RSA2048_PSS_SHA256) returning null in such case.

[roy-basmacier]

Hello @Akretsch,
I tried reproducing the error, but

org.bouncycastle.operator.DefaultDigestAlgorithmIdentifierFinder.find(MiscObjectIdentifiers.id_MLDSA44_RSA2048_PSS_SHA256)

is returning the corresponding AlgorithmIdentifier.

Can you provide more information on how you are producing the NPE

[Akretsch]

Sorry, my code was not complete. This snippet triggers the NPE:

package com.siemens.pki.bctest;

import org.bouncycastle.asn1.x509.AlgorithmIdentifier;
import org.bouncycastle.operator.DefaultDigestAlgorithmIdentifierFinder;
import org.bouncycastle.operator.DigestAlgorithmIdentifierFinder;

public class FinderTest {

	private static final DigestAlgorithmIdentifierFinder DIG_ALG_FINDER = new DefaultDigestAlgorithmIdentifierFinder();

	public static void main(String[] args) {
		try {
			System.out.println(DIG_ALG_FINDER
					.find(new AlgorithmIdentifier(
							org.bouncycastle.asn1.misc.MiscObjectIdentifiers.id_MLDSA44_RSA2048_PSS_SHA256))
					.getAlgorithm());
		} catch (NullPointerException ex) {
			ex.printStackTrace();
		}
	}
}

I use the 1.79-SNAPSHOT version.

[roy-basmacier]

Hello @Akretsch,
Thanks for sharing the code snippet. I was able to recreate it.

I would expect org.bouncycastle.operator.DefaultDigestAlgorithmIdentifierFinder.find(MiscObjectIdentifiers.id_MLDSA44_RSA2048_PSS_SHA256) returning null in such case.

Should the expected value be the Digest Algorithm Identifier used by the CMS signer?
Or would it be more reasonable to return null?

[Akretsch]

Hello @roy-basmacier,

I have to deal with certHash generation in CMP cert confirmations, see
https://www.ietf.org/archive/id/draft-ietf-lamps-rfc4210bis-12.html#section-5.3.18 . So if a certificate signature algorithm does not specify or enforce a specific hash algorithm, the DefaultDigestAlgorithmIdentifierFinder shall return null.

But maybe CMS needs it in another way?

Thanks for testing!

Andreas

[dghgit]

Yes, so CMS uses the class for identify the digest algorithm to use in SignedData. As it happens, while reviewing it was realised the lookup was wrong (well sometimes), the digest for composite was always SHA-512 (a good bet) but some signatures use SHA-256 and SHAKE-256 instead. Serendipity. This is now fixed. Latest up on https://www.bouncycastle.org/betas