IBM Crypto Education Community

 View Only

 Digital Signature Verify (DSV) failed with 8/894

Mark Vollmer's profile image
Mark Vollmer posted Wed November 05, 2025 07:47 PM

I'm calling the DSV with a message (TBS data), a 256 byte signature to validate and a PKCS#7 wrapped CA certificate. I'm using the following rules: 

RSA

PKCS-1.1

MESSAGE

SHA-256

PKI-NONE

RFC-5280

The error tells me: A required extension is not supplied.

Since there isn't a parameter called "extension" for this call, what is this error code telling me?   I just need a little help pointing me in the right direction.

I've confirmed that the message, signature and ca cert are sized properly and in the parameter fields correctly.  At least to the best of my knowledge.

Any help would be appreciated.

Sincerely,

Mark Vollmer

Eric Rossman's profile image
Eric Rossman

I see how this could be confusing. Reason code 894 is documented as "A required certificate extension was not supplied." The most likely answer is that the CRL in the X.509 CA cert you provided is missing one of the required CRL extensions. I didn't dig all the way down, but I saw two extensions that are always required by CCA: authorityKeyIdentifier and cRLNumber. If the X.509 certificate you are providing doesn't have both of those, it will fail RFC-5280 processing.

Mark Vollmer's profile image
Mark Vollmer

Eric,

Thanks for helping me out on this.  I appreciate it.   

Is the cRLNumber only valid on CRL documents and not part of a certificate?

Sincerely,

Mark

Mark Vollmer's profile image
Mark Vollmer

Eric,

I cannot find any extension starting with 2.5.29.x in my certificate.   Here is a partial tail end of my certificate.

Does this look like something that ICSF DSV call would have trouble with?

Sincerely,

Mark

Mark Vollmer's profile image
Mark Vollmer

Eric,

When asking the vendor about the certificate they supplied and the extension, they replied thus:

The certificates provided are generated on HSM devices according to a standard called X.509.
Not only our company, but also the Internet and other companies generate, parse, and verify certificates according to this standard.

It seems they are basically telling me that they meet the x.509 standard without that extension.

I did try the DSV call with RCF-ANY and it returned the same error.

Sincerely,

Mark

Eric Rossman's profile image
Eric Rossman

I'm not sure I will use the exact correct terminology here, so bear with me.

My reading of RFC 5280 is that there is a CRL appended to the CA certificate (not directly as part of the certificate itself). However, I am NOT an expert in that RFC so I'm not sure.

Mark Vollmer's profile image
Mark Vollmer

Eric,

I found this information on the internet.  How accurate it is I do not know...

Based on RFC 5280, here are the required certificate extensions for CA certificates when they are used to validate digital signatures on certificates or CRLs:

Required Extensions

1. Key Usage (2.5.29.15) - Section 4.2.1.3

Requirement: MUST be included

Critical: SHOULD mark as critical

Required bits:

  • keyCertSign (bit 5) - MUST be set if validating signatures on certificates
  • cRLSign (bit 6) - MUST be set if validating signatures on CRLs

From RFC 5280:

"Conforming CAs MUST include this extension in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs."

KeyUsage ::= BIT STRING {

    digitalSignature  (0),

    nonRepudiation    (1),

    keyEncipherment   (2),

    dataEncipherment  (3),

    keyAgreement      (4),

    keyCertSign       (5),    -- MUST be set for CA certs

    cRLSign           (6),    -- MUST be set if signing CRLs

    encipherOnly      (7),

    decipherOnly      (8)

}

2. Basic Constraints (2.5.29.19) - Section 4.2.1.9

Requirement: MUST be included

Critical: MUST mark as critical

Required values:

  • cA boolean - MUST be TRUE
  • pathLenConstraint - Optional, but if keyCertSign is set, this can specify max path depth

From RFC 5280:

"Conforming CAs MUST include this extension in all CA certificates that contain public keys used to validate digital signatures on certificates and MUST mark the extension as critical in such certificates."

BasicConstraints ::= SEQUENCE {

    cA                BOOLEAN DEFAULT FALSE,  -- MUST be TRUE for CAs

    pathLenConstraint INTEGER (0..MAX) OPTIONAL

}

3. Subject Key Identifier (2.5.29.14) - Section 4.2.1.2

Requirement: MUST appear in all conforming CA certificates

Critical: MUST mark as non-critical

Purpose: Identifies the CA's public key; used in the Authority Key Identifier of issued certificates

From RFC 5280:

"To facilitate certification path construction, this extension MUST appear in all conforming CA certificates, that is, all certificates including the basic constraints extension where the value of cA is TRUE."

SubjectKeyIdentifier ::= KeyIdentifier

KeyIdentifier ::= OCTET STRING

4. Authority Key Identifier (2.5.29.35) - Section 4.2.1.1

Requirement: MUST be included (except for self-signed root CAs where it MAY be omitted)

Critical: MUST mark as non-critical

Purpose: Identifies the public key of the issuer that signed this CA certificate

From RFC 5280:

"The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction."

AuthorityKeyIdentifier ::= SEQUENCE {

    keyIdentifier             [0] KeyIdentifier           OPTIONAL,

    authorityCertIssuer       [1] GeneralNames            OPTIONAL,

    authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL

}

Summary Table

Extension

OID

Required?

Critical?

Purpose

Key Usage

2.5.29.15

MUST

SHOULD

Indicates cert/CRL signing capability

Basic Constraints

2.5.29.19

MUST

MUST

Identifies as CA certificate

Subject Key Identifier

2.5.29.14

MUST

MUST NOT

Identifies this CA's public key

Authority Key Identifier

2.5.29.35

MUST*

MUST NOT

Identifies issuer's public key

*Exception: MAY be omitted in self-signed root CA certificates

Important Relationships

Key Usage and Basic Constraints must be consistent:

"If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension MUST also be asserted."

Why these extensions matter for signature validation:

  1. Basic Constraints - Verifier checks: "Is this a CA certificate?" (cA=TRUE)
  2. Key Usage - Verifier checks: "Is this key authorized to sign certificates?" (keyCertSign bit set)
  3. Subject Key Identifier - Helps chain certificates together
  4. Authority Key Identifier - Helps find the issuer's certificate in the chain

Additional Recommended Extension

While not strictly required by RFC 5280, Certificate Policies (2.5.29.32) is also important:

From RFC 5280:

"Conforming CAs MUST support... certificate policies extensions."

This helps relying parties understand the policies under which the CA operates.

Practical Example

A typical CA certificate for signature validation would have:

Extensions:

    X509v3 Basic Constraints: critical

        CA:TRUE, pathlen:0

    X509v3 Key Usage: critical

        Certificate Sign, CRL Sign

    X509v3 Subject Key Identifier:

        AB:CD:EF:12:34:56:78:90...

    X509v3 Authority Key Identifier:

        keyid:12:34:56:78:90:AB:CD:EF...

Without these required extensions properly set, certificate path validation will fail according to RFC 5280 requirements.

I will be following up with the certificate vendor on these extensions.

Sincerely,

Mark

Mark Vollmer's profile image
Mark Vollmer

Eric,

If I cannot get the vendor to build a proper RFC-5280 constructed x.509 certificate for use in DSV,  What to you think of the idea of extracting the public RSA key out of the certificate and building an internal RSA token (probably not encrypted) and using it instead of the actual certificate in the DSV call?   Does this sound like something that would work?

Sincerely,

Mark

Mark Vollmer's profile image
Mark Vollmer

Eric,

For what it's worth, I tried to use RFC-ANY and it still gave me the same error.

Sincerely,

Mark

Eric Rossman's profile image
Eric Rossman

Since your vendor doesn't include the extensions the CCA service requires and RSA public keys are in the clear anyway, creating an RSA public key token from the material in the certificate sounds like the best option.

Mark Vollmer's profile image
Mark Vollmer

Eric,

Is there a way we can identify the exact minimum of the potentially required RFC-5280 x.509 extensions?   The APG manual does not tell me.  I have vendors with 3 of them but no one provides all 4 at this time.

Sincerely,

Mark

Mark Vollmer's profile image
Mark Vollmer

Eric,

At this point, I believe RFC 5280 requires the for extensions mentioned above.  I guess I need to know if the DSV call requires a CA certificate to have all 4 of those extensions as well.

Sincerely,

Mark

Eric Rossman's profile image
Eric Rossman

I only specifically saw the two extensions I mentioned listed in the code.

Mark Vollmer's profile image
Mark Vollmer

The IBM team has responded to the question regarding what DSV requires from RFC-5280 documented extensions, and their response is that DSV does not have any requirements.   They tell us that it is the hardware card that has the requirement.  And the suggestion is that not all cards have the same requirements. 

I would have appreciated a quick list of hardware cards and their required list of RFC-5280 extensions.  Had they done that, it would have been easy for us to follow through and check the hardware.

Eric  -  This seems to contradict your findings that the DSV code has two of the RFC-5280 requirements.

Management is not keen on going with the RSA key extract option yet.  I think they want to push for fully valid certificates.   This will take a while to sort out.

Sincerely,

Mark Vollmer

Eric Rossman's profile image
Eric Rossman
The IBM team has responded to the question regarding what DSV requires from RFC-5280 documented extensions, and their response is that DSV does not have any requirements.   They tell us that it is the hardware card that has the requirement.  And the suggestion is that not all cards have the same requirements. 
 
I read the case you are referring to. The answer wasn't phrased well. I think they meant that ICSF (CSNDDSV) doesn't enforce the requirements but the card (CCA) does the enforcement.
 
I would have appreciated a quick list of hardware cards and their required list of RFC-5280 extensions.  Had they done that, it would have been easy for us to follow through and check the hardware.
 
Eric  -  This seems to contradict your findings that the DSV code has two of the RFC-5280 requirements.
 
All the CEX cards that support certificates (CEX6C and up) have the same requirements. I only listed the two requirements that I was able to find. I'm not ruling out the others. Did you verify that the extensions I listed are present?
Mark Vollmer's profile image
Mark Vollmer

Eric,

One of my certificates has basicConstraints, cRLDistributionPoints, keyUsage, subjectKeyIdentifier and that appears to be it.  My other certificate does not have any of 2.5.29.x extensions.

I'll find out whether the first one will work after I've managed to get it extracted from a PKCS#7 wrapper and properly present it to the DSV interface.

Sincerely,
Mark Vollmer