Hi
I'm using SSLeay 0.6.4 and I'm trying to verify a PKCS#7 of type
SignedData. I generated a PKCS#7 SignedData using the crypto.signText
method with Netscape Navigator 4.04 . From my pint of view I have to
proceed the following steps:
1. Get the DER encoding of the authenticatedAttributes field:
iAttributeDataLen =
i2d_ASN1_SET(pAttributes,NULL,i2d_X509_ATTRIBUTE,V_ASN1_SET,V_ASN1_UNIVE
RSAL);
pchAttributeData = malloc(iAttributeDataLen);
M_CHECK_NULL_POINTER(pchAttributeData);
pchAttributeDataPtr = pchAttributeData;
i2d_ASN1_SET(pAttributes,&pchAttributeDataPtr,i2d_X509_ATTRIBUTE,V_ASN1
_SET,V_ASN1_UNIVERSAL);
2. Digest the DER encoded authenticatedAttributes:
EVP_DigestInit(&hCtx,pMessageDigestAlg);
EVP_DigestUpdate(&hCtx,pchAttributeData,iAttributeDataLen);
EVP_DigestFinal(&hCtx,pMessageDigest->data,&pMessageDigest->length);
3. Create a DigestInfo object and fill in the data:
pDigestInfo = PKCS7_DIGEST_INFO_new();
M_CHECK_NULL_POINTER(pDigestInfo);
M_FREE(ASN1_OCTET_STRING_free,pDigestInfo->digest);
pDigestInfo->digest = pMessageDigest;
SetAlgorithm(pDigestInfo->digest_alg,pMessageDigestAlg->type,piErr);
4. Get the DER encoding of the DigestInfo:
iDigestInfoDataLen = i2d_PKCS7_DIGEST_INFO(pDigestInfo,NULL);
pchDigestInfoData = malloc(iDigestInfoDataLen);
M_CHECK_NULL_POINTER(pchDigestInfoData);
pchDigestInfoDataPtr = pchDigestInfoData;
i2d_PKCS7_DIGEST_INFO(pDigestInfo,&pchDigestInfoDataPtr);
5. Public decrypt the encrypted message digest in the signer info:
RSA_public_decrypt(pEncMessageDigest->length,pEncMessageDigest->data,pc
hDigestInfoData2,pepKey->pkey.rsa);
6. Compare the data
if (!memcmp(pchDigestInfoData2,pchDigestInfoData,iDigestInfoDataLen))
iRet = 1;
Ok, so far so good. Everything works fine until I have to compare the data
:( . The first 15 Bytes in the pchDigestInfoData2 and pchDigestInfoData are
the same. This means that the DigestInfo structure was encoded correctly.
The data only differs in the digest field. This means that I must have
calculated the digest wrongly. I realized, that in the SSLeay 0.9.0 Eric
was building the DER encoding of the authenticatedAttributes field the same
way I do. He then does things completely different:
sk=si->auth_attr;
if ((sk != NULL) && (sk_num(sk) != 0))
{
i=i2d_ASN1_SET(sk,NULL,i2d_X509_ATTRIBUTE,
V_ASN1_SET,V_ASN1_UNIVERSAL);
pp=(unsigned char *)malloc(i);
p=pp;
i2d_ASN1_SET(sk,&p,i2d_X509_ATTRIBUTE,
V_ASN1_SET,V_ASN1_UNIVERSAL);
EVP_VerifyUpdate(&mdc_tmp,pp,i);
free(pp);
}
os=si->enc_digest;
i=EVP_VerifyFinal(&mdc_tmp,os->data,os->length,
X509_get_pubkey(x509));
It looks to me like he is signing directly the DER encoded
authenticatedAttributes. Did I miss something ? Anyway, that's not my
problem but a hint if you have a problem verifying a Netscape generated
SigningData.
My question is: what is the correct input for the message digest ?
Whit the asn1pars application I found out that Netscape is having a PKCS#9
object in the authenticatedAttributes that isn't recognized by SSLeay 0.6.4
nor by 9.0.0. The object is : 1 2 840 113549 1 9 15 == pkcs-9 15. This
object seems to trouble the reading or writing procedure
of a PKCS#7. The result is that the PKCS#7 read differs in the PKCS#7
written. If I read and write a PKCS#7 not having this object, the problem
doesn't exist. Ok, what has this to do with the PKCS#7 verifying problem
mentioned above. I believe that the function i2d_ASN1_SET produces a wrong
result if the pkcs-9 15 object is present. If it is so, what I still have
to find out, the input of the digesting process is wrong and the verifying
process never works for this kind of PKCS#7.
Has anybody made the same experience, or can anybody give me a hint ? Every
comment is highly appreciated. I will go on trying to proof my theory and
will let you know about my results.
I still don't know the pkcs-9 15 object (it's not in the PKCS#9 standard so
it must be defined somewhere else). What is it ? What is it's ASN.1
definition ?
Cheers
Markus
--
Markus Isler
P O Box 74028 Market Rd, Auckland 1130
Level 7, Eden House, 44 Khyber Pass Rd, Grafton, Auckland, NEW ZEALAND
Tel +64.9.366.1502 Fax +64.9.366.1554 Mobile +64.21.637.746
Internet: [EMAIL PROTECTED] http://www.hardcastle.co.nz
+-------------------------------------------------------------------------+
| Administrative requests should be sent to [EMAIL PROTECTED] |
| List service provided by Open Software Associates, http://www.osa.com/ |
+-------------------------------------------------------------------------+
