RE: Encoding of INTEGER fields in PKIX certs

Title: FW: Encoding of INTEGER fields in PKIX certs

William,

Thanks again for your feedback and detailed analysis. After further investigation, we agree that the problem is not with the P parameter that was issued by the Entrust CA. We have identified a bug in the CML v1.9.2 in which the DSA parameters aren't being properly re-encoded in the CM_encode.cpp source file. This cause the CTIL code to return the error that you originally reported. We are working to develop a solution to this problem. We will let the SFL and CML mail lists know when the solution is available.

Thanks again,

===========================================
John Pawling, John.Pawling@xxxxxxxxxxxxxxxx
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: William Adams [mailto:William.Adams@xxxxxxxxxxx]
Sent: Monday, August 13, 2001 5:40 AM
To: 'Pawling, John'; 'SFL List (E-mail)'
Subject: RE: Encoding of INTEGER fields in PKIX certs

John,

We have looked into this problem a bit deeper and we feel that the problem is not with the P parameter that was issued by the entrust CA. I stepped through some of the process of verifying a DSA signature. To start with I dumped the asn encoded certificate, that contained the DSA parameters, during the function "checkTrustedCertSig" in "CM_cache.c". The dumped ASN.1 is attached in the file cert.asn1 and the encoded result is included in cert.txt. As you can see the parameters all have a single octet prepended, in which every bit is set to 0. So I stepped through the decoding of the DSA parameters to observe where this octet went. It happens in the file "X_DecodeCert.c" in the function

"short copyHugeIntToExistingBytes(Bytes_struct *cm_bytes, AsnOcts *octs, long zPad)".

At the start of this function it has the following section of code:

/* look at the first byte */
if (count > 1)
{
  if(data[0] == 0)
  {
   data++; /* skip that leading zero */
   count--; /* remove leading zero, indicating positive numeric value */
  }
}

Obviously this means that our parameters now no longer have the zeroed octet on the front and so will fail the test in void "CSM_BigIntegerStr::Get(CSM_Buffer &bigIntBuf, const size_t octets)". According to the message you forwarded it looks like

"short copyHugeIntToExistingBytes(Bytes_struct *cm_bytes, AsnOcts *octs, long zPad)"

is performing the right steps since it says if every bit of the most significant octet is set to zero then it should be deleted. It looks like the check performed, which our parameters fail, does not take into account that the prepending octet might have already been removed and so checks the value of the MSB to late.

Could you please look at this to verify where the problem lies.

Regards

William Adams
Software Engineer
Nexor.
================
Tel: +44 115 9535536
Fax: +44 115 9520519

-----Original Message-----
From: owner-imc-sfl@xxxxxxxxxxxx [mailto:owner-imc-sfl@xxxxxxxxxxxx]On Behalf Of Pawling, John
Sent: 10 August 2001 19:15
To: 'William.Adams'; SFL List (E-mail)
Subject: FW: Encoding of INTEGER fields in PKIX certs

William,

The Entrust CA has generated an invalid P parameter. The SFL correctly reported the error. Please see the attached message, subject: Re: Encoding of INTEGER fields in PKIX certs, for further details.

===========================================
John Pawling, John.Pawling@xxxxxxxxxxxxxxxx
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: William Adams [mailto:William.Adams@xxxxxxxxxxx]
Sent: Thursday, August 09, 2001 11:00 AM
To: SFL List (E-mail)
Subject: Invalid DSA Parameters?

I am trying to validate a certificate that has been issued by a Entrust V6
CA. The certificate was signed using DSA. When I try to verify the
certificate the SFL returns the error "MSB is 1.". Stepping through this I
found that the error occurred when trying to Get the parameters in the
function

SM_RET_VAL CSM_DSAParams::Decode(CSM_Buffer *pParams)

This function calls

void CSM_BigIntegerStr::Get(CSM_Buffer    &bigIntBuf, const size_t   octets)

which performs several checks to see if the parameters are valid. One of
these checks is

if (bigIntData[0] >> 7 == 1)
{
     SME_THROW(BIGINT_DECODE_ERROR, "MSB is 1.", NULL);
}

According to the comment surrounding the code this check is:

/* Make sure value is not negative. This rule only applies here
   because the octets variable is only used when decoding
   r,s,p,g,q, or y values; which MUST be positive. */

However are parameters all fail this check. If we comment out this line
check then the certificate is verified. To verify there was nothing wrong
with the certificate I imported it into the CAPI Certificate Store and this
managed to verify the certificate. The P parameter that fails is shown here:

b68b0f942b9acea5
25c6f2edfcfb9532
ac011233b9e01cad
909bbc48549ef394
773c2c713555e6fe
4f22cbd5d83e8993
334dfcbd4f41643e
a29870ec31b450de
ebf198280ac93e44
b3fd22979683d018
a3e3bd355bffeea3
21726a7b96dab93f
1e5a90af24d620f0
0d21a7d402b91afc
ac21fb9e949e4b42
459e6ab24863fe43

this was observed both during debugging and also when viewing the
certificate through the CA. Is there a fault with this parameter or is the
check wrong?

Regards

William Adams
Software Engineer
Nexor.
================
Tel: +44 115 9535536
Fax: +44 115 9520519

<snip>