RE: 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, [email protected] 
Getronics Government Solutions, LLC 
=========================================== 

-----Original Message-----
From: William Adams [mailto:[email protected]]
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: [email protected] [mailto:[email protected]]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, [email protected] 
Getronics Government Solutions, LLC 
=========================================== 



-----Original Message----- 
From: William Adams [ mailto:[email protected]
<mailto:[email protected]> ] 
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>