Subject: problem - veryfing Cyclone signed message

From: Konrad Jasinski <[email-masked]>
Date: Wed, 17 Sep 2003 15:21:54 +0200 (CEST)

Hi,

can anyone help me with my problem?

I'm testing some self-made software to communicate with CycloneActivator
ver 4.2 by using AS2 protocol;

To do tests I'm using two Cyclons and my soft is analyzing backup data
I'm analyzing signed messages from Cyclone, but I have a problem with
verifing them.

In rfcs and drafts it's said that multipart/signed message should be
created
with two parts:
- in the first part: source data with some MIME Headers
- in the second part: signature computed over the first part

the first part sent by Cyclone is OK, but the second part is strange for
me
, it has much more that 64 bytes (Cyclone is using RSA(512 bits) with
SHA-1,
so the signature should be 64 bytes long)

after a while i realized that in second part is:
- something like certificate (several bytes are different, the public key
is the same I've imported from Cyclone earlier - .p7c and .cer format) - I
don't know
why Cyclone is sending it...
- after that some data,which loooks similar to some kind of certificate
- at the end, just before "----=_Part....": 64 bytes - I thaught that it
was
a signature, but when Cyclone sends the same data, these 64 bytes are
different
(however the first part is all the time the same)

I've computed hash(sha-1) over the first part and it's equal to the value
returned
by the second Cyclone in MDN

I can't find the proper 64 bytes to verify this message, and i don't know
how it's
possible since these 64 bytes at the end of the second part are changing

perhaps, these 64 bytes are computed over some more data
(maybe including current time or sth else)

i'm attaching backup files:
- 2 different files with the same data sent : a106test1in , a108test1in
(differences in time,----=_Part...,and those 64 bytes! )
- certificates created by sending Cyclone: cert.cer, certp7.p7c
- MDN for a104test1in, returned by the second Cyclone: mdn

Thanks!

best regards:
Konrad Jasinski

---

From: "Dale Moberg" <[email-masked]>
Date: Wed, 17 Sep 2003 09:42:34 -0700

Hi Konrad,

This list is primarily for discussions of the drafts from the EDIINT
IETF group.

Nevertheless, here is a suggestion that may help you. The "second part"
is really a PKCS7 detached signature, which is a structure originally
defined by the Public Key Cryptography Specifcation 7. Basically it
omits the "content data part" of the signature which is usually present
in a pkcs7. PKCS7 is defined using ASN.1, and encoded in BER (the
certificates or CRLS that may be included will be DER encoded). Use your
favorite search engine to find copies of these or just read the IETF CMS
specification instead (and postpone the extensive history of readings.)

I think following up on these references will eventually (and it will be
a while) lead to a solution to your difficulties!

Cordially,

Dale Moberg

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Konrad Jasinski
Sent: Wednesday, September 17, 2003 6:22 AM
To: [email-masked]
Subject: problem - veryfing Cyclone signed message
Importance: Low

Hi,

created with two parts:

the first part sent by Cyclone is OK, but the second part is strange for
me , it has much more that 64 bytes (Cyclone is using RSA(512 bits) with
SHA-1, so the signature should be 64 bytes long)

after a while i realized that in second part is:
- something like certificate (several bytes are different, the public
key is the same I've imported from Cyclone earlier - .p7c and .cer
format) - I don't know why Cyclone is sending it...
- after that some data,which loooks similar to some kind of certificate
- at the end, just before "----=_Part....": 64 bytes - I thaught that it
was a signature, but when Cyclone sends the same data, these 64 bytes
are different (however the first part is all the time the same)

I've computed hash(sha-1) over the first part and it's equal to the
value returned by the second Cyclone in MDN

I can't find the proper 64 bytes to verify this message, and i don't
know how it's possible since these 64 bytes at the end of the second
part are changing

Thanks!

best regards:
Konrad Jasinski