I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

I'm not very familiar with certificate credentials, but according to ICSF's Application Programmer's Guide,  it's the KRD credential and the CRL that's in common.

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

Anna,

Is this the text in the manual you are referring to?

The certificate revocation list (CRL) from the certificate authority the is in common with the KRD for the requested service.  

Sincerely,

I'm not very familiar with certificate credentials, but according to ICSF's Application Programmer's Guide,  it's the KRD credential and the CRL that's in common.

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

Yes, that's the part

Anna,

Is this the text in the manual you are referring to?

The certificate revocation list (CRL) from the certificate authority the is in common with the KRD for the requested service.  

Sincerely,

I'm not very familiar with certificate credentials, but according to ICSF's Application Programmer's Guide,  it's the KRD credential and the CRL that's in common.

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

If this is the case, then I'm going to need specifics on just what exactly needs to match.  I get to contact my vendor and tell them that the certificate and the CRL are mismatched.   They will want to know what I found wrong.  Is there any way we can nail down the specific field(s) that must match so I can tell my vendor...

Dear vendor, the provided certificate and related CRL have a mismatched such-n-such field(s) that needs to be corrected before I can use them together.

Otherwise I'm pretty darn sure they will respond with "what exactly did you find wrong with our certificates?" and I still won't know what to tell them.

Does the CRL AIK field need to match the certificate SKI field?  Or is it that both AIK fields must match?  Or something else entirely?

Sincerely,

Yes, that's the part

Anna,

Is this the text in the manual you are referring to?

The certificate revocation list (CRL) from the certificate authority the is in common with the KRD for the requested service.  

Sincerely,

I'm not very familiar with certificate credentials, but according to ICSF's Application Programmer's Guide,  it's the KRD credential and the CRL that's in common.

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

Perhaps it is not the extension fields at all but the signature on the CRL that is being asked to validate with a CA certificate that is not present?  Though I would have thought that using the PKI-NONE rule would have asked the system not to validate signatures.  Perhaps PKI-NONE applies to certificates only and not to CRL objects?

Sincerely,

If this is the case, then I'm going to need specifics on just what exactly needs to match.  I get to contact my vendor and tell them that the certificate and the CRL are mismatched.   They will want to know what I found wrong.  Is there any way we can nail down the specific field(s) that must match so I can tell my vendor...

Dear vendor, the provided certificate and related CRL have a mismatched such-n-such field(s) that needs to be corrected before I can use them together.

Otherwise I'm pretty darn sure they will respond with "what exactly did you find wrong with our certificates?" and I still won't know what to tell them.

Does the CRL AIK field need to match the certificate SKI field?  Or is it that both AIK fields must match?  Or something else entirely?

Sincerely,

Yes, that's the part

Anna,

Is this the text in the manual you are referring to?

The certificate revocation list (CRL) from the certificate authority the is in common with the KRD for the requested service.  

Sincerely,

I'm not very familiar with certificate credentials, but according to ICSF's Application Programmer's Guide,  it's the KRD credential and the CRL that's in common.

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

Hi Mark.

The CRL and the KDH cert must have the same issuer. That check is not disabled by 'PKI-NONE'. The issuer is a required field in the CRL. Here is a sample printout of the beginning of a CRL:

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = IBM Crypto Dev Unit Test, CN = TR34 3K Sub UT CA

Perhaps it is not the extension fields at all but the signature on the CRL that is being asked to validate with a CA certificate that is not present?  Though I would have thought that using the PKI-NONE rule would have asked the system not to validate signatures.  Perhaps PKI-NONE applies to certificates only and not to CRL objects?

Sincerely,

If this is the case, then I'm going to need specifics on just what exactly needs to match.  I get to contact my vendor and tell them that the certificate and the CRL are mismatched.   They will want to know what I found wrong.  Is there any way we can nail down the specific field(s) that must match so I can tell my vendor...

Dear vendor, the provided certificate and related CRL have a mismatched such-n-such field(s) that needs to be corrected before I can use them together.

Otherwise I'm pretty darn sure they will respond with "what exactly did you find wrong with our certificates?" and I still won't know what to tell them.

Does the CRL AIK field need to match the certificate SKI field?  Or is it that both AIK fields must match?  Or something else entirely?

Sincerely,

Yes, that's the part

Anna,

Is this the text in the manual you are referring to?

The certificate revocation list (CRL) from the certificate authority the is in common with the KRD for the requested service.  

Sincerely,

I'm not very familiar with certificate credentials, but according to ICSF's Application Programmer's Guide,  it's the KRD credential and the CRL that's in common.

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

Roan,

Thanks for helping me out here.   Follow up question...

Are we talking binary exact match?  My issuers have different CN values.

Sincerely,

Hi Mark.

The CRL and the KDH cert must have the same issuer. That check is not disabled by 'PKI-NONE'. The issuer is a required field in the CRL. Here is a sample printout of the beginning of a CRL:

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = IBM Crypto Dev Unit Test, CN = TR34 3K Sub UT CA

Perhaps it is not the extension fields at all but the signature on the CRL that is being asked to validate with a CA certificate that is not present?  Though I would have thought that using the PKI-NONE rule would have asked the system not to validate signatures.  Perhaps PKI-NONE applies to certificates only and not to CRL objects?

Sincerely,

If this is the case, then I'm going to need specifics on just what exactly needs to match.  I get to contact my vendor and tell them that the certificate and the CRL are mismatched.   They will want to know what I found wrong.  Is there any way we can nail down the specific field(s) that must match so I can tell my vendor...

Dear vendor, the provided certificate and related CRL have a mismatched such-n-such field(s) that needs to be corrected before I can use them together.

Otherwise I'm pretty darn sure they will respond with "what exactly did you find wrong with our certificates?" and I still won't know what to tell them.

Does the CRL AIK field need to match the certificate SKI field?  Or is it that both AIK fields must match?  Or something else entirely?

Sincerely,

Yes, that's the part

Anna,

Is this the text in the manual you are referring to?

The certificate revocation list (CRL) from the certificate authority the is in common with the KRD for the requested service.  

Sincerely,

I'm not very familiar with certificate credentials, but according to ICSF's Application Programmer's Guide,  it's the KRD credential and the CRL that's in common.

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

This is X.509 so there is never a straight-forward answer.

The components of the issuer name are called RDNs.

The 2 names being compared must have the same number of RDN components , and each is then compared separately starting with the lowest level.

Each RDN component has attributes. All attributes must be the same.

Even the name string itself can have different types.

If both types are 'PrintableString', then the strings are stripped of leading and trailing whitespace, made into upper case and then compared character by character.

Otherwise, it is a binary comparison.

So with different CN values I'd expect failure. 

With that said, the simplest path forward is to make them a binary match if possible.

Roan,

Thanks for helping me out here.   Follow up question...

Are we talking binary exact match?  My issuers have different CN values.

Sincerely,

Hi Mark.

The CRL and the KDH cert must have the same issuer. That check is not disabled by 'PKI-NONE'. The issuer is a required field in the CRL. Here is a sample printout of the beginning of a CRL:

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = IBM Crypto Dev Unit Test, CN = TR34 3K Sub UT CA

Perhaps it is not the extension fields at all but the signature on the CRL that is being asked to validate with a CA certificate that is not present?  Though I would have thought that using the PKI-NONE rule would have asked the system not to validate signatures.  Perhaps PKI-NONE applies to certificates only and not to CRL objects?

Sincerely,

If this is the case, then I'm going to need specifics on just what exactly needs to match.  I get to contact my vendor and tell them that the certificate and the CRL are mismatched.   They will want to know what I found wrong.  Is there any way we can nail down the specific field(s) that must match so I can tell my vendor...

Dear vendor, the provided certificate and related CRL have a mismatched such-n-such field(s) that needs to be corrected before I can use them together.

Otherwise I'm pretty darn sure they will respond with "what exactly did you find wrong with our certificates?" and I still won't know what to tell them.

Does the CRL AIK field need to match the certificate SKI field?  Or is it that both AIK fields must match?  Or something else entirely?

Sincerely,

Yes, that's the part

Anna,

Is this the text in the manual you are referring to?

The certificate revocation list (CRL) from the certificate authority the is in common with the KRD for the requested service.  

Sincerely,

I'm not very familiar with certificate credentials, but according to ICSF's Application Programmer's Guide,  it's the KRD credential and the CRL that's in common.

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

This is X.509 so there is never a straight-forward answer.

The components of the issuer name are called RDNs.

The 2 names being compared must have the same number of RDN components , and each is then compared separately starting with the lowest level.

Each RDN component has attributes. All attributes must be the same.

Even the name string itself can have different types.

If both types are 'PrintableString', then the strings are stripped of leading and trailing whitespace, made into upper case and then compared character by character.

Otherwise, it is a binary comparison.

So with different CN values I'd expect failure. 

With that said, the simplest path forward is to make them a binary match if possible.

Roan,

Thanks for helping me out here.   Follow up question...

Are we talking binary exact match?  My issuers have different CN values.

Sincerely,

Hi Mark.

The CRL and the KDH cert must have the same issuer. That check is not disabled by 'PKI-NONE'. The issuer is a required field in the CRL. Here is a sample printout of the beginning of a CRL:

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = IBM Crypto Dev Unit Test, CN = TR34 3K Sub UT CA

Perhaps it is not the extension fields at all but the signature on the CRL that is being asked to validate with a CA certificate that is not present?  Though I would have thought that using the PKI-NONE rule would have asked the system not to validate signatures.  Perhaps PKI-NONE applies to certificates only and not to CRL objects?

Sincerely,

If this is the case, then I'm going to need specifics on just what exactly needs to match.  I get to contact my vendor and tell them that the certificate and the CRL are mismatched.   They will want to know what I found wrong.  Is there any way we can nail down the specific field(s) that must match so I can tell my vendor...

Dear vendor, the provided certificate and related CRL have a mismatched such-n-such field(s) that needs to be corrected before I can use them together.

Otherwise I'm pretty darn sure they will respond with "what exactly did you find wrong with our certificates?" and I still won't know what to tell them.

Does the CRL AIK field need to match the certificate SKI field?  Or is it that both AIK fields must match?  Or something else entirely?

Sincerely,

Yes, that's the part

Anna,

Is this the text in the manual you are referring to?

The certificate revocation list (CRL) from the certificate authority the is in common with the KRD for the requested service.  

Sincerely,

I'm not very familiar with certificate credentials, but according to ICSF's Application Programmer's Guide,  it's the KRD credential and the CRL that's in common.

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

Since I could not get the issuer fields to match.   I opted to omit the CRL.   I believe it is optional.

The first test returned 8 / 11000 - The digital signature verify ICSF callable service completed successfully, but the supplied digital signature
failed verification.

Thinking that it needed the CA certificates, I added them to the PKDS file.   And I ran the test again.

I still get the 8 / 11000,

What digital signature is it testing and where should it find the CA certificates/

Sincerely,

This is X.509 so there is never a straight-forward answer.

The components of the issuer name are called RDNs.

The 2 names being compared must have the same number of RDN components , and each is then compared separately starting with the lowest level.

Each RDN component has attributes. All attributes must be the same.

Even the name string itself can have different types.

If both types are 'PrintableString', then the strings are stripped of leading and trailing whitespace, made into upper case and then compared character by character.

Otherwise, it is a binary comparison.

So with different CN values I'd expect failure. 

With that said, the simplest path forward is to make them a binary match if possible.

Roan,

Thanks for helping me out here.   Follow up question...

Are we talking binary exact match?  My issuers have different CN values.

Sincerely,

Hi Mark.

The CRL and the KDH cert must have the same issuer. That check is not disabled by 'PKI-NONE'. The issuer is a required field in the CRL. Here is a sample printout of the beginning of a CRL:

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = IBM Crypto Dev Unit Test, CN = TR34 3K Sub UT CA

Perhaps it is not the extension fields at all but the signature on the CRL that is being asked to validate with a CA certificate that is not present?  Though I would have thought that using the PKI-NONE rule would have asked the system not to validate signatures.  Perhaps PKI-NONE applies to certificates only and not to CRL objects?

Sincerely,

If this is the case, then I'm going to need specifics on just what exactly needs to match.  I get to contact my vendor and tell them that the certificate and the CRL are mismatched.   They will want to know what I found wrong.  Is there any way we can nail down the specific field(s) that must match so I can tell my vendor...

Dear vendor, the provided certificate and related CRL have a mismatched such-n-such field(s) that needs to be corrected before I can use them together.

Otherwise I'm pretty darn sure they will respond with "what exactly did you find wrong with our certificates?" and I still won't know what to tell them.

Does the CRL AIK field need to match the certificate SKI field?  Or is it that both AIK fields must match?  Or something else entirely?

Sincerely,

Yes, that's the part

Anna,

Is this the text in the manual you are referring to?

The certificate revocation list (CRL) from the certificate authority the is in common with the KRD for the requested service.  

Sincerely,

I'm not very familiar with certificate credentials, but according to ICSF's Application Programmer's Guide,  it's the KRD credential and the CRL that's in common.

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer

That return/reason code is because the CRL is required and you omitted it (provided an invalid length so received 8/11000). 

You looked at the description for 4/11000 instead of 8/11000.

Since I could not get the issuer fields to match.   I opted to omit the CRL.   I believe it is optional.

The first test returned 8 / 11000 - The digital signature verify ICSF callable service completed successfully, but the supplied digital signature
failed verification.

Thinking that it needed the CA certificates, I added them to the PKDS file.   And I ran the test again.

I still get the 8 / 11000,

What digital signature is it testing and where should it find the CA certificates/

Sincerely,

This is X.509 so there is never a straight-forward answer.

The components of the issuer name are called RDNs.

The 2 names being compared must have the same number of RDN components , and each is then compared separately starting with the lowest level.

Each RDN component has attributes. All attributes must be the same.

Even the name string itself can have different types.

If both types are 'PrintableString', then the strings are stripped of leading and trailing whitespace, made into upper case and then compared character by character.

Otherwise, it is a binary comparison.

So with different CN values I'd expect failure. 

With that said, the simplest path forward is to make them a binary match if possible.

Roan,

Thanks for helping me out here.   Follow up question...

Are we talking binary exact match?  My issuers have different CN values.

Sincerely,

Hi Mark.

The CRL and the KDH cert must have the same issuer. That check is not disabled by 'PKI-NONE'. The issuer is a required field in the CRL. Here is a sample printout of the beginning of a CRL:

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = IBM Crypto Dev Unit Test, CN = TR34 3K Sub UT CA

Perhaps it is not the extension fields at all but the signature on the CRL that is being asked to validate with a CA certificate that is not present?  Though I would have thought that using the PKI-NONE rule would have asked the system not to validate signatures.  Perhaps PKI-NONE applies to certificates only and not to CRL objects?

Sincerely,

If this is the case, then I'm going to need specifics on just what exactly needs to match.  I get to contact my vendor and tell them that the certificate and the CRL are mismatched.   They will want to know what I found wrong.  Is there any way we can nail down the specific field(s) that must match so I can tell my vendor...

Dear vendor, the provided certificate and related CRL have a mismatched such-n-such field(s) that needs to be corrected before I can use them together.

Otherwise I'm pretty darn sure they will respond with "what exactly did you find wrong with our certificates?" and I still won't know what to tell them.

Does the CRL AIK field need to match the certificate SKI field?  Or is it that both AIK fields must match?  Or something else entirely?

Sincerely,

Yes, that's the part

Anna,

Is this the text in the manual you are referring to?

The certificate revocation list (CRL) from the certificate authority the is in common with the KRD for the requested service.  

Sincerely,

I'm not very familiar with certificate credentials, but according to ICSF's Application Programmer's Guide,  it's the KRD credential and the CRL that's in common.

On the KDH Credential, I can see CRL Distribution Points & Authority Information Access.   On the CRL, I'm not seeing anything that would suggest it is tied to any particular issuer.

Maybe the Authority Key Identifier?

I'll freely admit that TR-34 is not my strongest suit. The first thought that comes to mind is that you are seeing the error because the CredKDH and CRL are not from the same issuer.

I'm finally back to working on TR-34 key blocks again.   All I'm trying to do is to get this call to complete with zeros, even if the key block I create is totally useless.  I've got this call setup as follows:

Rule Array:  2PASSCRE, PKI-NONE, SKEY-DES, VARDRV-B, T34-2019, KEK, ENC-ONLY, EXP-NONE

The  CRED KDH and CRED KRD are present in DER form.

The Priv RSA is my own internal RSA key pair.  This has nothing to do with either of the two aforementioned credentials.   All I want is for the system to use this PRIV key to generate a signature.

None of the CA certificates are in ICSF anywhere.  

I chose PKI-NONE because at this time, I do not want to mess with CA validations.   I'll get fix that later.

I'm getting 907 which says: Error in certificate processing. Issuer certificate not found.

What certificate are we trying to validate against the issuer?  And since there are no other spots available in the parameter list, where is the T34D call looking for that CA certificate?  I had been thinking PKI-NONE turned all this off.

I would certainly appreciate any helpful pointers to get me past this problem.

Sincerely,

Mark Vollmer