[openssl.org #1011] PKCS7 verifier fails to recognize sha1WithRSAEncryption digestAlgorithm
[derek@ihtfp.com - Fri Feb 18 09:28:03 2005]:
[color=blue]
> Hi,
>
> [ originally written by Scott J. Tamosunas,
> [url]http://www.mail-archive.com/openssl-dev@openssl.org/msg05433.html[/url] ]
>
> I am trying to verify the signature of a PKCS7 object created by
> another PKI
> that used SHA1 as the method of digest and RSA Encryption as the
> method of
> private key encryption. However, if I parse the DER, the following
> shows
> that the sha1withRSAEncryption was used as the
> digestAlgorthimIdentifier:
>
> 0 30 1855: SEQUENCE {
> 4 06 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
> 15 A0 1840: [0] {
> 19 30 1836: SEQUENCE {
> 23 02 1: INTEGER 1
> 26 31 13: SET {
> 28 30 11: SEQUENCE {
> 30 06 9: OBJECT IDENTIFIER
> : sha1withRSAEncryption (1 2 840 113549 1 1 5)[/color]
there are 2 published standard versions: 1.5 and 1.6
[url]http://www.rsasecurity.com/rsalabs/node.asp?id=2129[/url]
The "1" shows version 1.5 rules apply
[url]ftp://ftp.rsasecurity.com/pub/pkcs/ps/pkcs-7.ps.gz[/url]
SET of objects here should be DigestAlgorithmIdentifier
with DigestAlgorithms "include MD2 and MD5" (clause 6.3).
For S/MIME (draft-ietf-smime-rfc2633bis-08.txt),
DigestAlgorithmIdentifier "MUST support SHA-1" (clause 2.1).
See also draft-ietf-smime-rfc3369bis-02.txt clause 10.1.1.
For a project implementing SET, I was using SHA-1 here
[url]http://www.unity.net/~vf/naina_r1.tgz[/url]
and that was specified in SET books.
For the message attached, SignedData start at offset 63
and objectID in question at offset 74.
I'd suggest to double-check exactly what specifications
the other PKI (creating PKCS7 in question) follows
[color=blue]
> : }
> : }
> 41 30 11: SEQUENCE {
> 43 06 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
>
> it would seem to me, first of all that seeing this is supposed to be a
> digestAlgorithmIdentifier, this should just be SHA1 as
> sha1withRSAEncrytion
> implies a signature algorithm, not a message digest.
>
>
> Therefore, when I try to verify the signature in the PKCS7 object, in
> the
> function PKCS7_dataInit():
> if (md_sk != NULL)
> {
> for (i=0; i<sk_X509_ALGOR_num(md_sk); i++)
> {
> xa=sk_X509_ALGOR_value(md_sk,i);
> if ((btmp=BIO_new(BIO_f_md())) == NULL)
> {
>[/color]
PKCS7err(PKCS7_F_PKCS7_DATAINIT,ERR_R_BIO_LIB);[color=blue]
> goto err;
> }
>
> j=OBJ_obj2nid(xa->algorithm);
> evp_md=EVP_get_digestbyname(OBJ_nid2sn(j));
>
> j = 65
> evp_md = RSA-SHA1
>
> This gets set into the output bio struct.
>
> Later in the PKCS7_signatureVerify() function in the location:
>
> md_type=OBJ_obj2nid(si->digest_alg->algorithm);
>
> btmp=bio;
> for (;;)
> {
> if ((btmp == NULL) ||
> ((btmp=BIO_find_type(btmp,BIO_TYPE_MD)) ==
> NULL))
> {
> PKCS7err(PKCS7_F_PKCS7_SIGNATUREVERIFY,
>[/color]
PKCS7_R_UNABLE_TO_FIND_MESSAGE_DIGEST);[color=blue]
> goto err;
> }
> BIO_get_md_ctx(btmp,&mdc);
> if (mdc == NULL)
> {
> PKCS7err(PKCS7_F_PKCS7_SIGNATUREVERIFY,
>[/color]
PKCS7_R_INTERNAL_ERROR);[color=blue]
> goto err;
> }
> if (EVP_MD_CTX_type(mdc) == md_type)
> break;
> btmp=btmp->next_bio;
> }
>
> The error PKCS7err(PKCS7_F_PKCS7_SIGNATUREVERIFY,
> PKCS7_R_UNABLE_TO_FIND_MESSAGE_DIGEST) is set because md_type = 65 and
> mdc->digest.type = 64. 64 is SHA1 so the comparisons to the message
> digests
> fail, when really they should not.
>
> My question is:
> Is this the intended behavior? Shouldn't this situation be handled?
> From the
> PKCS7 and X509 specs, I don't see any provision for what is a digest
> algorithm and what is not. Clearly, SHA1 has been used to create the
> digest.
> Or, is the PKI that created the PKCS7 object in the wrong?
>
> In either case, OpenSSL should probably accept the message with the
> sha1WithRSAEncryption instead of sha1 message digest.
>
> Thanks,
>
> -derek, plagiarizing Scott[/color]
______________________________________________________________________
OpenSSL Project [url]http://www.openssl.org[/url]
Development Mailing List [email]openssl-dev@openssl.org[/email]
Automated List Manager [email]majordomo@openssl.org[/email]