[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: signature producing problem



Vlad:

There was a small change to the logic that checks the signing login to
be sure it has proper KeyUsage extension settings (or a missing
KeyUsage).  The old sm_free3 CTIL logic would allow you to sign with a
login that was set to RSA encrypt only.

Be sure that the UseThis and IsApplicable flags are properly set for the
appropriate logins that you intend to sign/decrypt with.

My test execution with auto_hi test scripts properly creates SignedData
and EnvelopedData messages, so I do not understand your reference to
auto_hi failures.  If this issue has to do with your logins, the same
failure would occur here as well.

The verify operation will return success if there are no SignerInfos
present to verify.  You must navigate the SignerInfo list to check the
verified flag.  Actual verification failures will throw an exception,
but if the SFL library cannot locate a valid CTIL with proper
algorithm(s), you will not get an exception, but the SignerInfo will
indicate that it was not verified.  In your case, it would seem that you
have no SignerInfos present, which will return a successful verify.  You
should always check for a positive indication of verification success in
the individual SignerInfo(s) before believing that a message has been
successfully verified, NOT RELY ON THE VERIFY RETURN CODE.  This is
demonstrated in CSM_MsgSignerInfos::ReportMsgData(...)

<<<<< in ./SMIME/libsrc/lolevel/sm_MsgSignerInfo.cpp
...
        for (SetCurrToFirst(), tmpSI = Curr(); tmpSI; tmpSI = GoNext())
        {
            if (tmpSI->IsVerified())
            {
                os << "\nNumber "
                    << ++lCount
                    << " signer info WAS VERIFIED.\n";
            }
            else
            {
                os << "Did not verify number "
                    <<  ++lCount << " signer info.\n";
            }
...

except you would reference CSM_MsgToVerify::m_pSignerInfos->Curr, etc.
This does not help you current issue, but will better indicate the
failure you see in future tests (you would see that the SignerInfo list
is missing).


Bob Colestock


-----Original Message-----
From: Vlad Vetiul [mailto:Vlad.Vetiul@xxxxxxx] 
Sent: Monday, September 16, 2002 8:33 AM
To: imc-sfl@xxxxxxx
Subject: signature producing problem


Hi All!

I've worked with SFL 2.0.1 and a big part of it was working almost fine.
Then, I downloaded the new version and a trouble has arisen:
signing/encryption goes as usual, but results doesn't look like they
supposed to be. Like, signed message contains only the original message
and a portion of data (about 50 bytes, inserted in the begining of
file). So, the signed message doesn't contain any signature at all. The
similar problem with encrypted message. asn1parse shows it contains some
data, but it seems that some fields are missing.
verify/decrypt operation doesn't work.

Here the result of execution of "openssl asn1parse" on the encrypted
message:

    0:d=0  hl=4 l=1133 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim:  INTEGER           :00
    7:d=1  hl=3 l= 214 cons:  SET
   10:d=2  hl=3 l= 211 cons:   SEQUENCE
   13:d=3  hl=2 l=   1 prim:    INTEGER           :00
   16:d=3  hl=2 l=  60 cons:    SEQUENCE
   18:d=4  hl=2 l=  55 cons:     SEQUENCE
   20:d=5  hl=2 l=  11 cons:      SET
   22:d=6  hl=2 l=   9 cons:       SEQUENCE
   24:d=7  hl=2 l=   3 prim:        OBJECT            :countryName
   29:d=7  hl=2 l=   2 prim:        PRINTABLESTRING   :MD
   33:d=5  hl=2 l=  12 cons:      SET
   35:d=6  hl=2 l=  10 cons:       SEQUENCE
   37:d=7  hl=2 l=   3 prim:        OBJECT            :organizationName
   42:d=7  hl=2 l=   3 prim:        PRINTABLESTRING   :BNM
   47:d=5  hl=2 l=  26 cons:      SET
   49:d=6  hl=2 l=  24 cons:       SEQUENCE
   51:d=7  hl=2 l=   9 prim:        OBJECT            :emailAddress
   62:d=7  hl=2 l=  11 prim:        IA5STRING         :ca@xxxxxxxx
   75:d=4  hl=2 l=   1 prim:     INTEGER           :15
   78:d=3  hl=2 l=  13 cons:    SEQUENCE
   80:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
   91:d=4  hl=2 l=   0 prim:     NULL
   93:d=3  hl=3 l= 128 prim:    OCTET STRING
  224:d=1  hl=4 l= 909 cons:  SEQUENCE
  228:d=2  hl=2 l=   9 prim:   OBJECT            :pkcs7-data
  239:d=2  hl=2 l=  20 cons:   SEQUENCE
  241:d=3  hl=2 l=   8 prim:    OBJECT            :des-ede3-cbc
  251:d=3  hl=2 l=   8 prim:    OCTET STRING
  261:d=2  hl=4 l= 872 prim:   cont [ 0 ]


I tried Free3 and Pkcs11 CTILs.
auto_hi behaves in a similar manner.

Does anyone knows what is wrong? Or maybe somebody had experienced the
same trouble?


Thanks.

-- 
DISCLAIMER:
Any e-mail messages from the National Bank of Moldova are sent in good
faith, but shall not be binding nor construed as constituting any
obligation on the part of the Bank.
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. If you received this in error, please contact the sender and
delete the material from any computer.