Hi
I finally found the problem and could verify the PKCS#7 SignedData. The
problem was in one bit:
Netscape DER encoded it's pkcs-9 15 object like this:
06 09
2A 86 48 86 F7 0D 01 09 0F
31 35
30 33 <-- SEQUENCE (Constructed, definite-length method)
30 0A ......
while SSLeay 0.6.4 encodes the pkcs-9 15 object like this:
06 09
2A 86 48 86 F7 0D 01 09 0F
31 35
10 33 <-- SEQUENCE (Primitive, definite-length method)
30 0A ......
Ok, I'm not an ASN.1 expert but I think the way Netscape did it is
certainly correct. I will study the code to find out how this problem has
to be solved. Assistance would be appreciated.
Markus
Markus Isler[SMTP:[EMAIL PROTECTED]] wrote:
> 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
>
>
--
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/ |
+-------------------------------------------------------------------------+
