RFC 4130 checksum in SHA1 - Openssl

This is a discussion on RFC 4130 checksum in SHA1 - Openssl ; Can anyone help me with the procedure to calculate the message integrity check in this RFC? it's about calculating the sha1 checksum over a multipart message. This is the text in the RFC ( http://www.ietf.org/rfc/rfc4130.txt ), chapter 7.1, paragraph 8) ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: RFC 4130 checksum in SHA1

  1. RFC 4130 checksum in SHA1


    Can anyone help me with the procedure to calculate the message integrity
    check in this RFC?

    it's about calculating the sha1 checksum over a multipart message.

    This is the text in the RFC (http://www.ietf.org/rfc/rfc4130.txt), chapter
    7.1, paragraph 8)

    The EC Interchange and the RFC 1767 MIME EDI content header can
    actually be part of a multi-part MIME content-type. When the EDI
    Interchange is part of a multi-part MIME content-type, the MIC MUST
    be calculated across the entire multi-part content, including the
    MIME headers.


    My problem is that i think I understood, but another software gives me a
    different checksum for the same message.


    I canonicalize headers, no problem
    I process signature of message with openssl which provides a multipart file
    I calculate sha1 over exactly that output file


    Is there something done wrong in this procedure? Whant to try some
    examples?
    This file is a multipart output from openssl
    http://www.nabble.com/file/p18034577/mictest.txt mictest.txt

    Ok, not directly. Because openssl produces the base64 signature, which I
    detach to then transform to binary or "DER" and I attach it back, with the
    corresponding change in Content-enconding: binary.

    For this file I get IpWFspJ2hKwfja5CkOPnDW2ctT8=
    The other trading partner says: Uiaz1kOChhlSb/f3SJsmJ/O/8SI=

    Could this be a mere misunderstanding of the RFC?, I've seen way different
    "interpretations" on the net, which I have tried but don't work either.

    Well thanks for the help
    --
    View this message in context: http://www.nabble.com/RFC-4130-check...p18034577.html
    Sent from the OpenSSL - User mailing list archive at Nabble.com.


  2. Re: RFC 4130 checksum in SHA1


    If I understand your question correctly, you are asking how to calculate the
    MIC (SHA1 checksum) to put in an AS2 MDN.

    The MIC should be calculated over exactly that data that was signed in the
    original AS2 message. The data used to calculate the MIC should not include
    the actual signature. Thus, the MIC should be calculated over that data that
    appears between the first two boundary markers in the multipart/signed of
    the original AS2 message. Note that the first boundary marker includes the
    trailing CRLF and the second boundary marker includes the leading CRLF.
    Thus, those CRLF sequences should not be included in the MIC calculation.


    javierm wrote:
    >
    > Can anyone help me with the procedure to calculate the message integrity
    > check in this RFC?
    >
    > it's about calculating the sha1 checksum over a multipart message.
    >
    > This is the text in the RFC (http://www.ietf.org/rfc/rfc4130.txt), chapter
    > 7.1, paragraph 8)
    >
    >

    The EC Interchange and the RFC 1767 MIME EDI content header can
    > actually be part of a multi-part MIME content-type. When the EDI
    > Interchange is part of a multi-part MIME content-type, the MIC MUST
    > be calculated across the entire multi-part content, including the
    > MIME headers.
    >


    >
    > My problem is that i think I understood, but another software gives me a
    > different checksum for the same message.
    >
    >


    >

    I canonicalize headers, no problem
    >

    I process signature of message with openssl which provides a multipart file
    >

    I calculate sha1 over exactly that output file
    >


    >
    > Is there something done wrong in this procedure? Whant to try some
    > examples?
    > This file is a multipart output from openssl
    > http://www.nabble.com/file/p18034577/mictest.txt mictest.txt
    >
    > Ok, not directly. Because openssl produces the base64 signature, which I
    > detach to then transform to binary or "DER" and I attach it back, with the
    > corresponding change in Content-enconding: binary.
    >
    > For this file I get IpWFspJ2hKwfja5CkOPnDW2ctT8=
    > The other trading partner says: Uiaz1kOChhlSb/f3SJsmJ/O/8SI=
    >
    > Could this be a mere misunderstanding of the RFC?, I've seen way
    > different "interpretations" on the net, which I have tried but don't work
    > either.
    >
    > Well thanks for the help
    >


    --
    View this message in context: http://www.nabble.com/RFC-4130-check...p18039269.html
    Sent from the OpenSSL - User mailing list archive at Nabble.com.


  3. Re: RFC 4130 checksum in SHA1


    Hi jkoehring:

    Thanks a lot for the help, (ah just noticed another reply from you on this
    question placed in another way, thanks). I tried that part too but did not
    get the expected checksum. Not that I doubt what you say, but perhaps I'm
    mistaken at some point. When I do the verify, the openssl smime -verify
    outputs the original document and optionally the certificate. I was doing
    the checksum not after the verification, but instead, I was just processing
    the multipart/signed document, and extracting the first portion between the
    first and second boundary. I will do it again right now and be right back.

    On the other hand, don't you think the 7.1.8 paragraph of RFC4130 misleads
    one, by saying " MIC MUST
    be calculated across the entire multi-part content, including the
    MIME headers." It seems to me a trick to give clients to "somebody".

    Later,
    Javier


    jkoehring wrote:
    >
    > If I understand your question correctly, you are asking how to calculate
    > the MIC (SHA1 checksum) to put in an AS2 MDN.
    >


    > The MIC should be calculated over exactly that data that was signed in the
    > original AS2 message. The data used to calculate the MIC should not
    > include the actual signature. Thus, the MIC should be calculated over that
    > data that appears between the first two boundary markers in the
    > multipart/signed of the original AS2 message. Note that the first boundary
    > marker includes the trailing CRLF and the second boundary marker includes
    > the leading CRLF. Thus, those CRLF sequences should not be included in the
    > MIC calculation.
    >
    >
    > javierm wrote:
    >>
    >> Can anyone help me with the procedure to calculate the message integrity
    >> check in this RFC?
    >>
    >> it's about calculating the sha1 checksum over a multipart message.
    >>
    >> This is the text in the RFC (http://www.ietf.org/rfc/rfc4130.txt),
    >> chapter 7.1, paragraph 8)
    >>
    >>

    The EC Interchange and the RFC 1767 MIME EDI
    >> content header can
    >> actually be part of a multi-part MIME content-type. When the EDI
    >> Interchange is part of a multi-part MIME content-type, the MIC MUST
    >> be calculated across the entire multi-part content, including the
    >> MIME headers.
    >>

    >>
    >> My problem is that i think I understood, but another software gives me a
    >> different checksum for the same message.
    >>
    >>

      >>
    • I canonicalize headers, no problem

    • >>
    • I process signature of message with openssl which provides a
      >> multipart file

    • >>
    • I calculate sha1 over exactly that output file

    • >>

    >>
    >> Is there something done wrong in this procedure? Whant to try some
    >> examples?
    >> This file is a multipart output from openssl
    >> http://www.nabble.com/file/p18034577/mictest.txt mictest.txt
    >>
    >> Ok, not directly. Because openssl produces the base64 signature, which I
    >> detach to then transform to binary or "DER" and I attach it back, with
    >> the corresponding change in Content-enconding: binary.
    >>
    >> For this file I get IpWFspJ2hKwfja5CkOPnDW2ctT8=
    >> The other trading partner says: Uiaz1kOChhlSb/f3SJsmJ/O/8SI=
    >>
    >> Could this be a mere misunderstanding of the RFC?, I've seen way
    >> different "interpretations" on the net, which I have tried but don't work
    >> either.
    >>
    >> Well thanks for the help
    >>

    >
    >


    --
    View this message in context: http://www.nabble.com/RFC-4130-check...p18039358.html
    Sent from the OpenSSL - User mailing list archive at Nabble.com.

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  4. Re: RFC 4130 checksum in SHA1


    Hi and thanks again:

    Completely clear. I found some weird content in the original message which
    is only a XML in 2 lines. It's not a multipart (not a multipart inside
    another multipart, but only an XML in UTF-8, which is then signed and
    finally encrypted, then sent).

    The weird content to which I refer is that the original message is not
    exactly UTF-8. And also, when verifying, the just after the XML
    content -and before the boundary- is removed, because that's not part of
    original content. I will be testing with my trading partner what is exactly
    the original content but this time sent via email, because I suspect this
    parter has her UTF-8 file (the very original one), which produces the right
    MIC, but the encoder of her WebSphere saves it in ISO-8859-1, according the
    codes shown in certain word which is the name of the othe trading partner.
    (i.e. DISEÑOS is transformed to DISEÑOS if you see the UTF-8 as
    ISO-8859-1, but this time I'm reading the content as UTF-8 and I don't see
    DISEÑOS....)

    I think we are close to the end of this problem.
    Greetings


    jkoehring wrote:
    >
    > The mechanism for calculating the MIC for an AS2 message is exactly the
    > same as that for an AS1 message. The two protocols are practically
    > identical except that the outermost contents of AS1 messages are
    > frequently encoded (base64 , quoted-printable, etc) so that they may be
    > transported safely over SMTP. Otherwise, AS21 and AS2 messages are
    > "packaged" identically.
    >


    > The paragraph you are referring to in section 7.1 of RFC 4130 is referring
    > to the situation in which the data being transported in an AS2 message is
    > a multipart. That is, the first part of the multipart/signed is, itself,
    > another multipart. It is not saying that the MIC should be calculated over
    > the entire multipart/signed, just the first part of the multipart/signed.
    >


    > Another way to look at it is when the original AS2 message is signed, the
    > MIC for the MDN should be exactly the same as the hash used in the
    > calculation of the signature for the multipart/signed.
    >


    --
    View this message in context: http://www.nabble.com/RFC-4130-check...p18067119.html
    Sent from the OpenSSL - User mailing list archive at Nabble.com.

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  5. Re: RFC 4130 checksum in SHA1




    jkoehring wrote:
    >
    > I have to admit, I am not very familiar with the openssl commands. The one
    > question I have is exactly what are the contents of original.txt after
    > running the commands you list? Does it contain exactly the contents of the
    > first part of the multipart/signed?
    >
    > javierm wrote:
    >>
    >> Thanks for the wait:
    >>
    >> Well, these are the steps followed
    >>
    >>

      >>
    • Encrypted body with Mime headers.- body decrypted and
      >> multipart/signed message obtained

    • >>
    • Signature in binary, so processed with openssl pkcs7 to convert the
      >> binary signature to b64 (script in perl to extract the binary signature,
      >> process it with pkcs7 it and put it back in between the 2nd an 3rd
      >> boundary, Content-transfer-encoding changed from : binary to base64--->
      >> file produced: signed.txt

    • >>
    • openssl smime -verify -in signed.txt -nosigs -noverify -signer
      >> who.pem -out original.txt (successful, cert found inside used in
      >> signature written to who.pem-yes the signer is right)

    • >>
    • openssl sha1 -binary original.txt|openssl enc -a ,

    • >>
    • and... I don't get the signature that the signer claims I should
      >> get!!

    • >>

    >>
    >> What do you think?
    >> Thanks
    >>
    >>
    >> javierm wrote:
    >>>
    >>> Hi jkoehring:
    >>>
    >>>

    Thanks a lot for the help, (ah just noticed another reply from you on
    >>> this question placed in another way, thanks). I tried that part too but
    >>> did not get the expected checksum. Not that I doubt what you say, but
    >>> perhaps I'm mistaken at some point. When I do the verify, the openssl
    >>> smime -verify outputs the original document and optionally the
    >>> certificate. I was doing the checksum not after the verification, but
    >>> instead, I was just processing the multipart/signed document, and
    >>> extracting the first portion between the first and second boundary. I
    >>> will do it again right now and be right back.


    >>>
    >>>

    On the other hand, don't you think the 7.1.8 paragraph of RFC4130
    >>> misleads one, by saying

    MIC MUST
    >>> be calculated across the entire multi-part content, including the
    >>> MIME headers."
    It seems to me a trick to give clients to
    >>> "somebody".


    >>>
    >>>

    Thanks


    >>> Later,

    >>> Javier
    >>>
    >>>
    >>> jkoehring wrote:
    >>>>
    >>>> If I understand your question correctly, you are asking how to
    >>>> calculate the MIC (SHA1 checksum) to put in an AS2 MDN.
    >>>>


    >>>> The MIC should be calculated over exactly that data that was signed in
    >>>> the original AS2 message. The data used to calculate the MIC should not
    >>>> include the actual signature. Thus, the MIC should be calculated over
    >>>> that data that appears between the first two boundary markers in the
    >>>> multipart/signed of the original AS2 message. Note that the first
    >>>> boundary marker includes the trailing CRLF and the second boundary
    >>>> marker includes the leading CRLF. Thus, those CRLF sequences should not
    >>>> be included in the MIC calculation.
    >>>>
    >>>>
    >>>> javierm wrote:
    >>>>>
    >>>>> Can anyone help me with the procedure to calculate the message
    >>>>> integrity check in this RFC?
    >>>>>
    >>>>> it's about calculating the sha1 checksum over a multipart message.
    >>>>>
    >>>>> This is the text in the RFC (http://www.ietf.org/rfc/rfc4130.txt),
    >>>>> chapter 7.1, paragraph 8)
    >>>>>
    >>>>>

    The EC Interchange and the RFC
    >>>>> 1767 MIME EDI content header can
    >>>>> actually be part of a multi-part MIME content-type. When the EDI
    >>>>> Interchange is part of a multi-part MIME content-type, the MIC MUST
    >>>>> be calculated across the entire multi-part content, including the
    >>>>> MIME headers.
    >>>>>

    >>>>>
    >>>>> My problem is that i think I understood, but another software gives me
    >>>>> a different checksum for the same message.
    >>>>>
    >>>>>

      >>>>>
    • I canonicalize headers, no problem

    • >>>>>
    • I process signature of message with openssl which provides a
      >>>>> multipart file

    • >>>>>
    • I calculate sha1 over exactly that output file

    • >>>>>

    >>>>>
    >>>>> Is there something done wrong in this procedure? Whant to try some
    >>>>> examples?
    >>>>> This file is a multipart output from openssl
    >>>>> http://www.nabble.com/file/p18034577/mictest.txt mictest.txt
    >>>>>
    >>>>> Ok, not directly. Because openssl produces the base64 signature,
    >>>>> which I detach to then transform to binary or "DER" and I attach it
    >>>>> back, with the corresponding change in Content-enconding: binary.
    >>>>>
    >>>>> For this file I get IpWFspJ2hKwfja5CkOPnDW2ctT8=
    >>>>> The other trading partner says: Uiaz1kOChhlSb/f3SJsmJ/O/8SI=
    >>>>>
    >>>>> Could this be a mere misunderstanding of the RFC?, I've seen way
    >>>>> different "interpretations" on the net, which I have tried but don't
    >>>>> work either.
    >>>>>
    >>>>> Well thanks for the help
    >>>>>
    >>>>
    >>>>
    >>>
    >>>

    >>
    >>

    >
    >


    --
    View this message in context: http://www.nabble.com/RFC-4130-check...p18067148.html
    Sent from the OpenSSL - User mailing list archive at Nabble.com.

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  6. Re: RFC 4130 checksum in SHA1


    Ok following your quoted note, I got the asn1 structure to see what was
    inside there:

    Which value contains the hash you mention? Is it the messageDigest?


    Thanks




    jkoehring wrote:
    >
    >


    > Another way to look at it is when the original AS2 message is signed, the
    > MIC for the MDN should be exactly the same as the hash used in the
    > calculation of the signature for the multipart/signed.


    >





    $> openssl asn1parse -in SIGB64-pk7.txt

    0:d=0 hl=4 l=1101 cons: SEQUENCE
    4:d=1 hl=2 l= 9 prim: OBJECT kcs7-signedData
    15:d=1 hl=4 l=1086 cons: cont [ 0 ]
    19:d=2 hl=4 l=1082 cons: SEQUENCE
    23:d=3 hl=2 l= 1 prim: INTEGER :01
    26:d=3 hl=2 l= 11 cons: SET
    28:d=4 hl=2 l= 9 cons: SEQUENCE
    30:d=5 hl=2 l= 5 prim: OBJECT :sha1
    37:d=5 hl=2 l= 0 prim: NULL
    39:d=3 hl=2 l= 11 cons: SEQUENCE
    41:d=4 hl=2 l= 9 prim: OBJECT kcs7-data
    52:d=3 hl=4 l= 643 cons: cont [ 0 ]
    56:d=4 hl=4 l= 639 cons: SEQUENCE
    60:d=5 hl=4 l= 488 cons: SEQUENCE
    64:d=6 hl=2 l= 3 cons: cont [ 0 ]
    66:d=7 hl=2 l= 1 prim: INTEGER :02
    69:d=6 hl=2 l= 4 prim: INTEGER :468D29E6
    75:d=6 hl=2 l= 13 cons: SEQUENCE
    77:d=7 hl=2 l= 9 prim: OBJECT :md5WithRSAEncryption
    88:d=7 hl=2 l= 0 prim: NULL
    90:d=6 hl=3 l= 131 cons: SEQUENCE
    93:d=7 hl=2 l= 11 cons: SET
    95:d=8 hl=2 l= 9 cons: SEQUENCE
    97:d=9 hl=2 l= 3 prim: OBJECT :countryName
    102:d=9 hl=2 l= 2 prim: PRINTABLESTRING :MX
    106:d=7 hl=2 l= 14 cons: SET
    108:d=8 hl=2 l= 12 cons: SEQUENCE
    110:d=9 hl=2 l= 3 prim: OBJECT ostalCode
    115:d=9 hl=2 l= 5 prim: PRINTABLESTRING :66260
    122:d=7 hl=2 l= 11 cons: SET
    124:d=8 hl=2 l= 9 cons: SEQUENCE
    126:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
    131:d=9 hl=2 l= 2 prim: PRINTABLESTRING :NL
    135:d=7 hl=2 l= 18 cons: SET
    137:d=8 hl=2 l= 16 cons: SEQUENCE
    139:d=9 hl=2 l= 3 prim: OBJECT :localityName
    144:d=9 hl=2 l= 9 prim: PRINTABLESTRING :Monterrey
    155:d=7 hl=2 l= 26 cons: SET
    157:d=8 hl=2 l= 24 cons: SEQUENCE
    159:d=9 hl=2 l= 3 prim: OBJECT rganizationName
    164:d=9 hl=2 l= 17 prim: PRINTABLESTRING :removed
    183:d=7 hl=2 l= 12 cons: SET
    185:d=8 hl=2 l= 10 cons: SEQUENCE
    187:d=9 hl=2 l= 3 prim: OBJECT rganizationalUnitName
    192:d=9 hl=2 l= 3 prim: PRINTABLESTRING :ENG
    197:d=7 hl=2 l= 25 cons: SET
    199:d=8 hl=2 l= 23 cons: SEQUENCE
    201:d=9 hl=2 l= 3 prim: OBJECT :commonName
    206:d=9 hl=2 l= 16 prim: PRINTABLESTRING :removed
    224:d=6 hl=2 l= 30 cons: SEQUENCE
    226:d=7 hl=2 l= 13 prim: UTCTIME :070705172702Z
    241:d=7 hl=2 l= 13 prim: UTCTIME :080704172702Z
    256:d=6 hl=3 l= 131 cons: SEQUENCE
    259:d=7 hl=2 l= 11 cons: SET
    261:d=8 hl=2 l= 9 cons: SEQUENCE
    263:d=9 hl=2 l= 3 prim: OBJECT :countryName
    268:d=9 hl=2 l= 2 prim: PRINTABLESTRING :MX
    272:d=7 hl=2 l= 14 cons: SET
    274:d=8 hl=2 l= 12 cons: SEQUENCE
    276:d=9 hl=2 l= 3 prim: OBJECT ostalCode
    281:d=9 hl=2 l= 5 prim: PRINTABLESTRING :66260
    288:d=7 hl=2 l= 11 cons: SET
    290:d=8 hl=2 l= 9 cons: SEQUENCE
    292:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
    297:d=9 hl=2 l= 2 prim: PRINTABLESTRING :NL
    301:d=7 hl=2 l= 18 cons: SET
    303:d=8 hl=2 l= 16 cons: SEQUENCE
    305:d=9 hl=2 l= 3 prim: OBJECT :localityName
    310:d=9 hl=2 l= 9 prim: PRINTABLESTRING :Monterrey
    321:d=7 hl=2 l= 26 cons: SET
    323:d=8 hl=2 l= 24 cons: SEQUENCE
    325:d=9 hl=2 l= 3 prim: OBJECT rganizationName
    330:d=9 hl=2 l= 17 prim: PRINTABLESTRING :removed
    349:d=7 hl=2 l= 12 cons: SET
    351:d=8 hl=2 l= 10 cons: SEQUENCE
    353:d=9 hl=2 l= 3 prim: OBJECT rganizationalUnitName
    358:d=9 hl=2 l= 3 prim: PRINTABLESTRING :ENG
    363:d=7 hl=2 l= 25 cons: SET
    365:d=8 hl=2 l= 23 cons: SEQUENCE
    367:d=9 hl=2 l= 3 prim: OBJECT :commonName
    372:d=9 hl=2 l= 16 prim: PRINTABLESTRING :removed
    390:d=6 hl=3 l= 159 cons: SEQUENCE
    393:d=7 hl=2 l= 13 cons: SEQUENCE
    395:d=8 hl=2 l= 9 prim: OBJECT :rsaEncryption
    406:d=8 hl=2 l= 0 prim: NULL
    408:d=7 hl=3 l= 141 prim: BIT STRING
    552:d=5 hl=2 l= 13 cons: SEQUENCE
    554:d=6 hl=2 l= 9 prim: OBJECT :md5WithRSAEncryption
    565:d=6 hl=2 l= 0 prim: NULL
    567:d=5 hl=3 l= 129 prim: BIT STRING
    699:d=3 hl=4 l= 402 cons: SET
    703:d=4 hl=4 l= 398 cons: SEQUENCE
    707:d=5 hl=2 l= 1 prim: INTEGER :01
    710:d=5 hl=3 l= 140 cons: SEQUENCE
    713:d=6 hl=3 l= 131 cons: SEQUENCE
    716:d=7 hl=2 l= 11 cons: SET
    718:d=8 hl=2 l= 9 cons: SEQUENCE
    720:d=9 hl=2 l= 3 prim: OBJECT :countryName
    725:d=9 hl=2 l= 2 prim: PRINTABLESTRING :MX
    729:d=7 hl=2 l= 14 cons: SET
    731:d=8 hl=2 l= 12 cons: SEQUENCE
    733:d=9 hl=2 l= 3 prim: OBJECT ostalCode
    738:d=9 hl=2 l= 5 prim: PRINTABLESTRING :66260
    745:d=7 hl=2 l= 11 cons: SET
    747:d=8 hl=2 l= 9 cons: SEQUENCE
    749:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
    754:d=9 hl=2 l= 2 prim: PRINTABLESTRING :NL
    758:d=7 hl=2 l= 18 cons: SET
    760:d=8 hl=2 l= 16 cons: SEQUENCE
    762:d=9 hl=2 l= 3 prim: OBJECT :localityName
    767:d=9 hl=2 l= 9 prim: PRINTABLESTRING :Monterrey
    778:d=7 hl=2 l= 26 cons: SET
    780:d=8 hl=2 l= 24 cons: SEQUENCE
    782:d=9 hl=2 l= 3 prim: OBJECT rganizationName
    787:d=9 hl=2 l= 17 prim: PRINTABLESTRING :removed
    806:d=7 hl=2 l= 12 cons: SET
    808:d=8 hl=2 l= 10 cons: SEQUENCE
    810:d=9 hl=2 l= 3 prim: OBJECT rganizationalUnitName
    815:d=9 hl=2 l= 3 prim: PRINTABLESTRING :ENG
    820:d=7 hl=2 l= 25 cons: SET
    822:d=8 hl=2 l= 23 cons: SEQUENCE
    824:d=9 hl=2 l= 3 prim: OBJECT :commonName
    829:d=9 hl=2 l= 16 prim: PRINTABLESTRING :removed
    847:d=6 hl=2 l= 4 prim: INTEGER :468D29E6
    853:d=5 hl=2 l= 9 cons: SEQUENCE
    855:d=6 hl=2 l= 5 prim: OBJECT :sha1
    862:d=6 hl=2 l= 0 prim: NULL
    864:d=5 hl=2 l= 93 cons: cont [ 0 ]
    866:d=6 hl=2 l= 24 cons: SEQUENCE
    868:d=7 hl=2 l= 9 prim: OBJECT :contentType
    879:d=7 hl=2 l= 11 cons: SET
    881:d=8 hl=2 l= 9 prim: OBJECT kcs7-data
    892:d=6 hl=2 l= 28 cons: SEQUENCE
    894:d=7 hl=2 l= 9 prim: OBJECT :signingTime
    905:d=7 hl=2 l= 15 cons: SET
    907:d=8 hl=2 l= 13 prim: UTCTIME :080623140750Z
    922:d=6 hl=2 l= 35 cons: SEQUENCE
    924:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
    935:d=7 hl=2 l= 22 cons: SET
    937:d=8 hl=2 l= 20 prim: OCTET STRING [HEX
    DUMP]:F715D2B0C84D0D98ADD5823C3A186CADBE43DE43
    959:d=5 hl=2 l= 13 cons: SEQUENCE
    961:d=6 hl=2 l= 9 prim: OBJECT :rsaEncryption
    972:d=6 hl=2 l= 0 prim: NULL
    974:d=5 hl=3 l= 128 prim: OCTET STRING [HEX
    DUMP]:1F29519CBE7E44EC36DDDBD0C9ACC80D2E2003AC32BBEF8EA 5A56EE8C0CB26A4EB964EA2CBCDA6FC023F6953D9EB65C5642 EF6CA0D0C6060CEE605C7BE5BA2140D4350F579DFA3AC601F5 265C0D5F7458383D7E3A756FED95A42313EF323606B4EDCA22 7B14E5AD29458C76CBBDA5ACC0D18D9D573DB6FECDE3BD6DBF 3A58F87




    --
    View this message in context: http://www.nabble.com/RFC-4130-check...p18093533.html
    Sent from the OpenSSL - User mailing list archive at Nabble.com.


  7. Re: RFC 4130 checksum in SHA1


    Yes, I believe the messageDigest in the ASN.1 dump is, indeed, the hash of
    the data that was signed.

    javierm wrote:
    >
    >

    Ok following your quoted note, I got the asn1 structure to see what was
    inside there:

    > Which value contains the hash you mention? Is it the messageDigest?


    >
    >

    Thanks

    >
    >
    >
    > jkoehring wrote:
    >>
    >>


    >> Another way to look at it is when the original AS2 message is signed, the
    >> MIC for the MDN should be exactly the same as the hash used in the
    >> calculation of the signature for the multipart/signed.


    >>

    >
    >
    >


    >


    > $> openssl asn1parse -in SIGB64-pk7.txt
    >
    > 0:d=0 hl=4 l=1101 cons: SEQUENCE
    > 4:d=1 hl=2 l= 9 prim: OBJECT kcs7-signedData
    > 15:d=1 hl=4 l=1086 cons: cont [ 0 ]
    > 19:d=2 hl=4 l=1082 cons: SEQUENCE
    > 23:d=3 hl=2 l= 1 prim: INTEGER :01
    > 26:d=3 hl=2 l= 11 cons: SET
    > 28:d=4 hl=2 l= 9 cons: SEQUENCE
    > 30:d=5 hl=2 l= 5 prim: OBJECT :sha1
    > 37:d=5 hl=2 l= 0 prim: NULL
    > 39:d=3 hl=2 l= 11 cons: SEQUENCE
    > 41:d=4 hl=2 l= 9 prim: OBJECT kcs7-data
    > 52:d=3 hl=4 l= 643 cons: cont [ 0 ]
    > 56:d=4 hl=4 l= 639 cons: SEQUENCE
    > 60:d=5 hl=4 l= 488 cons: SEQUENCE
    > 64:d=6 hl=2 l= 3 cons: cont [ 0 ]
    > 66:d=7 hl=2 l= 1 prim: INTEGER :02
    > 69:d=6 hl=2 l= 4 prim: INTEGER :468D29E6
    > 75:d=6 hl=2 l= 13 cons: SEQUENCE
    > 77:d=7 hl=2 l= 9 prim: OBJECT :md5WithRSAEncryption
    > 88:d=7 hl=2 l= 0 prim: NULL
    > 90:d=6 hl=3 l= 131 cons: SEQUENCE
    > 93:d=7 hl=2 l= 11 cons: SET
    > 95:d=8 hl=2 l= 9 cons: SEQUENCE
    > 97:d=9 hl=2 l= 3 prim: OBJECT :countryName
    > 102:d=9 hl=2 l= 2 prim: PRINTABLESTRING :MX
    > 106:d=7 hl=2 l= 14 cons: SET
    > 108:d=8 hl=2 l= 12 cons: SEQUENCE
    > 110:d=9 hl=2 l= 3 prim: OBJECT ostalCode
    > 115:d=9 hl=2 l= 5 prim: PRINTABLESTRING :66260
    > 122:d=7 hl=2 l= 11 cons: SET
    > 124:d=8 hl=2 l= 9 cons: SEQUENCE
    > 126:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
    > 131:d=9 hl=2 l= 2 prim: PRINTABLESTRING :NL
    > 135:d=7 hl=2 l= 18 cons: SET
    > 137:d=8 hl=2 l= 16 cons: SEQUENCE
    > 139:d=9 hl=2 l= 3 prim: OBJECT :localityName
    > 144:d=9 hl=2 l= 9 prim: PRINTABLESTRING :Monterrey
    > 155:d=7 hl=2 l= 26 cons: SET
    > 157:d=8 hl=2 l= 24 cons: SEQUENCE
    > 159:d=9 hl=2 l= 3 prim: OBJECT rganizationName
    > 164:d=9 hl=2 l= 17 prim: PRINTABLESTRING :removed
    > 183:d=7 hl=2 l= 12 cons: SET
    > 185:d=8 hl=2 l= 10 cons: SEQUENCE
    > 187:d=9 hl=2 l= 3 prim: OBJECT rganizationalUnitName
    > 192:d=9 hl=2 l= 3 prim: PRINTABLESTRING :ENG
    > 197:d=7 hl=2 l= 25 cons: SET
    > 199:d=8 hl=2 l= 23 cons: SEQUENCE
    > 201:d=9 hl=2 l= 3 prim: OBJECT :commonName
    > 206:d=9 hl=2 l= 16 prim: PRINTABLESTRING :removed
    > 224:d=6 hl=2 l= 30 cons: SEQUENCE
    > 226:d=7 hl=2 l= 13 prim: UTCTIME :070705172702Z
    > 241:d=7 hl=2 l= 13 prim: UTCTIME :080704172702Z
    > 256:d=6 hl=3 l= 131 cons: SEQUENCE
    > 259:d=7 hl=2 l= 11 cons: SET
    > 261:d=8 hl=2 l= 9 cons: SEQUENCE
    > 263:d=9 hl=2 l= 3 prim: OBJECT :countryName
    > 268:d=9 hl=2 l= 2 prim: PRINTABLESTRING :MX
    > 272:d=7 hl=2 l= 14 cons: SET
    > 274:d=8 hl=2 l= 12 cons: SEQUENCE
    > 276:d=9 hl=2 l= 3 prim: OBJECT ostalCode
    > 281:d=9 hl=2 l= 5 prim: PRINTABLESTRING :66260
    > 288:d=7 hl=2 l= 11 cons: SET
    > 290:d=8 hl=2 l= 9 cons: SEQUENCE
    > 292:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
    > 297:d=9 hl=2 l= 2 prim: PRINTABLESTRING :NL
    > 301:d=7 hl=2 l= 18 cons: SET
    > 303:d=8 hl=2 l= 16 cons: SEQUENCE
    > 305:d=9 hl=2 l= 3 prim: OBJECT :localityName
    > 310:d=9 hl=2 l= 9 prim: PRINTABLESTRING :Monterrey
    > 321:d=7 hl=2 l= 26 cons: SET
    > 323:d=8 hl=2 l= 24 cons: SEQUENCE
    > 325:d=9 hl=2 l= 3 prim: OBJECT rganizationName
    > 330:d=9 hl=2 l= 17 prim: PRINTABLESTRING :removed
    > 349:d=7 hl=2 l= 12 cons: SET
    > 351:d=8 hl=2 l= 10 cons: SEQUENCE
    > 353:d=9 hl=2 l= 3 prim: OBJECT rganizationalUnitName
    > 358:d=9 hl=2 l= 3 prim: PRINTABLESTRING :ENG
    > 363:d=7 hl=2 l= 25 cons: SET
    > 365:d=8 hl=2 l= 23 cons: SEQUENCE
    > 367:d=9 hl=2 l= 3 prim: OBJECT :commonName
    > 372:d=9 hl=2 l= 16 prim: PRINTABLESTRING :removed
    > 390:d=6 hl=3 l= 159 cons: SEQUENCE
    > 393:d=7 hl=2 l= 13 cons: SEQUENCE
    > 395:d=8 hl=2 l= 9 prim: OBJECT :rsaEncryption
    > 406:d=8 hl=2 l= 0 prim: NULL
    > 408:d=7 hl=3 l= 141 prim: BIT STRING
    > 552:d=5 hl=2 l= 13 cons: SEQUENCE
    > 554:d=6 hl=2 l= 9 prim: OBJECT :md5WithRSAEncryption
    > 565:d=6 hl=2 l= 0 prim: NULL
    > 567:d=5 hl=3 l= 129 prim: BIT STRING
    > 699:d=3 hl=4 l= 402 cons: SET
    > 703:d=4 hl=4 l= 398 cons: SEQUENCE
    > 707:d=5 hl=2 l= 1 prim: INTEGER :01
    > 710:d=5 hl=3 l= 140 cons: SEQUENCE
    > 713:d=6 hl=3 l= 131 cons: SEQUENCE
    > 716:d=7 hl=2 l= 11 cons: SET
    > 718:d=8 hl=2 l= 9 cons: SEQUENCE
    > 720:d=9 hl=2 l= 3 prim: OBJECT :countryName
    > 725:d=9 hl=2 l= 2 prim: PRINTABLESTRING :MX
    > 729:d=7 hl=2 l= 14 cons: SET
    > 731:d=8 hl=2 l= 12 cons: SEQUENCE
    > 733:d=9 hl=2 l= 3 prim: OBJECT ostalCode
    > 738:d=9 hl=2 l= 5 prim: PRINTABLESTRING :66260
    > 745:d=7 hl=2 l= 11 cons: SET
    > 747:d=8 hl=2 l= 9 cons: SEQUENCE
    > 749:d=9 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
    > 754:d=9 hl=2 l= 2 prim: PRINTABLESTRING :NL
    > 758:d=7 hl=2 l= 18 cons: SET
    > 760:d=8 hl=2 l= 16 cons: SEQUENCE
    > 762:d=9 hl=2 l= 3 prim: OBJECT :localityName
    > 767:d=9 hl=2 l= 9 prim: PRINTABLESTRING :Monterrey
    > 778:d=7 hl=2 l= 26 cons: SET
    > 780:d=8 hl=2 l= 24 cons: SEQUENCE
    > 782:d=9 hl=2 l= 3 prim: OBJECT rganizationName
    > 787:d=9 hl=2 l= 17 prim: PRINTABLESTRING :removed
    > 806:d=7 hl=2 l= 12 cons: SET
    > 808:d=8 hl=2 l= 10 cons: SEQUENCE
    > 810:d=9 hl=2 l= 3 prim: OBJECT rganizationalUnitName
    > 815:d=9 hl=2 l= 3 prim: PRINTABLESTRING :ENG
    > 820:d=7 hl=2 l= 25 cons: SET
    > 822:d=8 hl=2 l= 23 cons: SEQUENCE
    > 824:d=9 hl=2 l= 3 prim: OBJECT :commonName
    > 829:d=9 hl=2 l= 16 prim: PRINTABLESTRING :removed
    > 847:d=6 hl=2 l= 4 prim: INTEGER :468D29E6
    > 853:d=5 hl=2 l= 9 cons: SEQUENCE
    > 855:d=6 hl=2 l= 5 prim: OBJECT :sha1
    > 862:d=6 hl=2 l= 0 prim: NULL
    > 864:d=5 hl=2 l= 93 cons: cont [ 0 ]
    > 866:d=6 hl=2 l= 24 cons: SEQUENCE
    > 868:d=7 hl=2 l= 9 prim: OBJECT :contentType
    > 879:d=7 hl=2 l= 11 cons: SET
    > 881:d=8 hl=2 l= 9 prim: OBJECT kcs7-data
    > 892:d=6 hl=2 l= 28 cons: SEQUENCE
    > 894:d=7 hl=2 l= 9 prim: OBJECT :signingTime
    > 905:d=7 hl=2 l= 15 cons: SET
    > 907:d=8 hl=2 l= 13 prim: UTCTIME :080623140750Z
    > 922:d=6 hl=2 l= 35 cons: SEQUENCE
    > 924:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
    > 935:d=7 hl=2 l= 22 cons: SET
    > 937:d=8 hl=2 l= 20 prim: OCTET STRING [HEX
    > DUMP]:F715D2B0C84D0D98ADD5823C3A186CADBE43DE43
    > 959:d=5 hl=2 l= 13 cons: SEQUENCE
    > 961:d=6 hl=2 l= 9 prim: OBJECT :rsaEncryption
    > 972:d=6 hl=2 l= 0 prim: NULL
    > 974:d=5 hl=3 l= 128 prim: OCTET STRING [HEX
    > DUMP]:1F29519CBE7E44EC36DDDBD0C9ACC80D2E2003AC32BBEF8EA 5A56EE8C0CB26A4EB964EA2CBCDA6FC023F6953D9EB65C5642 EF6CA0D0C6060CEE605C7BE5BA2140D4350F579DFA3AC601F5 265C0D5F7458383D7E3A756FED95A42313EF323606B4EDCA22 7B14E5AD29458C76CBBDA5ACC0D18D9D573DB6FECDE3BD6DBF 3A58F87
    >


    >


    >
    >
    >


    --
    View this message in context: http://www.nabble.com/RFC-4130-check...p18094840.html
    Sent from the OpenSSL - User mailing list archive at Nabble.com.


  8. Re: RFC 4130 checksum in SHA1


    Oh Boy!! Eureka,


    Yes the HEX number in "messageDigest" converted to base64 gives me the MIC
    that the trading partner expects, though, I can not figure out how this
    value is obtained based on the original content between the first and second
    boundary. I calculated the message digest for this "original content" in
    SHA1 obtaining a binary data which I then convert to base64 using openssl,
    but in all variations of end of line with mime without mime header (the rfc
    1767 header for EDI object), with end of line at the end of the EDI record,
    and I don't get the same value that comes out from the signature in the
    second part of the signed message. I also used an online tool for
    translating all sorts of numbers at http://www.paulschou.com/tools/xlate/
    and pasting my original content on first box of this translator, gives me a
    completely new SHA1 value. %-|.


    Linux has one straightforward "sha1sum" GNU command to do the same without
    openssl, and it gives the same result as the one obtained with openssl, so I
    don't think I'm using the tool in a wrong way because it only needs the name
    of the file...WHAT DO YOU THINK?


    The rfc 4130 mentions precisely what you said:





    a. The message integrity check (MIC or Message Digest), is
    decrypted using the sender's public key. (I use as1parse, and
    get the messageDigest record)

    b. A MIC on the signed contents (the MIME header and encoded
    EDI object, as per RFC 1767) in the message received is
    calculated using the same one-way hash function that the
    sending trading partner used.

    c. The MIC extracted from the message that was sent and the MIC
    calculated using the same one-way hash function that the
    sending trading partner used are compared for equality.




    jkoehring wrote:
    >
    > Yes, I believe the messageDigest in the ASN.1 dump is, indeed, the hash of
    > the data that was signed.
    >


    --
    View this message in context: http://www.nabble.com/RFC-4130-check...p18098049.html
    Sent from the OpenSSL - User mailing list archive at Nabble.com.


  9. Re: RFC 4130 checksum in SHA1

    Technically, the mime-type application/xml requires that ALL content
    be encoded in UTF-8. (This is an artifact of XML itself specifying
    that it is always UTF-8.)

    If it's not valid UTF-8, then it's not valid XML, which (depending on
    your environment) may not even need to be evaluated for its signature.

    -Kyle H

    On Tue, Jun 24, 2008 at 12:18 PM, javierm wrote:
    > Oh Boy!! Eureka,
    >
    > Yes the HEX number in "messageDigest" converted to base64 gives me the MIC
    > that the trading partner expects, though, I can not figure out how this
    > value is obtained based on the original content between the first and second
    > boundary. I calculated the message digest for this "original content" in
    > SHA1 obtaining a binary data which I then convert to base64 using openssl,
    > but in all variations of end of line with mime without mime header (the rfc
    > 1767 header for EDI object), with end of line at the end of the EDI record,
    > and I don't get the same value that comes out from the signature in the
    > second part of the signed message. I also used an online tool for
    > translating all sorts of numbers at http://www.paulschou.com/tools/xlate/
    > and pasting my original content on first box of this translator, gives me a
    > completely new SHA1 value. .
    >
    > Linux has one straightforward "sha1sum" GNU command to do the same without
    > openssl, and it gives the same result as the one obtained with openssl, so I
    > don't think I'm using the tool in a wrong way because it only needs the name
    > of the file...WHAT DO YOU THINK?
    >
    > The rfc 4130 mentions precisely what you said:
    >
    > a. The message integrity check (MIC or Message Digest), is
    > decrypted using the sender's public key. (I use as1parse, and
    > get the messageDigest record)
    >
    > b. A MIC on the signed contents (the MIME header and encoded
    > EDI object, as per RFC 1767) in the message received is
    > calculated using the same one-way hash function that the
    > sending trading partner used.
    >
    > c. The MIC extracted from the message that was sent and the MIC
    > calculated using the same one-way hash function that the
    > sending trading partner used are compared for equality.
    >
    > jkoehring wrote:
    > Yes, I believe the messageDigest in the ASN.1 dump is, indeed, the hash of
    > the data that was signed.
    >
    > ________________________________
    > View this message in context: Re: RFC 4130 checksum in SHA1
    > Sent from the OpenSSL - User mailing list archive at Nabble.com.
    >

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  10. Re: RFC 4130 checksum in SHA1


    Well, for the moment all succeeded in practical terms, by just parsing the
    ASN1 structure and getting what is read there as "messageDigest". That is
    what the trading partner expects to "see", but I'm not so happy not knowing
    how this message digest is obtained


    So I did another test that I would like you guys to do, to illustrate us
    mortals on what's going on.




    Take any text: "This is a test for checksums or messagedigests" included the
    quotes and no endofline or carriagereturn.
    It has the SHA1 = [b33490ef86874904c7fc38bb92122665540fd7ce] or
    [szSQ74aHSQTH/Di7khImZVQP184=] same SHA1 in base64

    Now put that quoted text in a textfile and sign it with your cert and
    private key
    Then you get a multipart smime output to a file say signedmsg.txt

    Get the PKCS#7 structure of the signature with


    openssl smime -in signedmsg.txt -pk7out -out p7struc.pem

    Now get the ASN1 structure out of p7struc.pem with


    openssl asn1parse -in p7struc.pem


    ....and there you go, check under the line identified as ":messageDigest".


    (your version of openssl should not be too old or this field will show
    empty, I use OpenSSL 0.9.8h 28 May 2008)

    Notice it's not the checksum we calculated first. Ok perhaps it should not
    be because this message digest shown in PKCS7 might include the values of
    the certificate involved.

    Does that value come perhaps from the message digest on the binary pkcs7
    structure?


    openssl pkcs7 -in p7struc.pem -outform der -out p7struc.der

    Try sha1 on p7struc.der and nothing....it doesn't match the digest from the
    ASN1 structure



    Any idea on what is the base data on which a SHA1 produces the messagedigest
    in the ASN1 structure?

    --
    View this message in context: http://www.nabble.com/RFC-4130-check...p18115897.html
    Sent from the OpenSSL - User mailing list archive at Nabble.com.


  11. Re: RFC 4130 checksum in SHA1

    On Wednesday August 6th 2008 at 20:42 javierm wrote:

    [ RFC 4130 calculating MIC, mostly offtopic for OpenSSL ]

    > Sorry about the lengthy post, but it's worth to seem or be redundant. I
    > give proofs


    I have read it all, but will comment on just a few points.

    > ...
    >
    > I found that commercial packages agree that THIS messageDigest is the VALID
    > MIC to return on the MDN


    There really is only one way to calculate the MIC (the message digest)
    so of course they should all agree!

    I know the RFC says to canonicalize the contents, but as far as I know
    this doesn't happen in practice.

    Canonicalizing the contents would be impossible to begin with, because
    you would have to know which is "text" (so has line endings) and which
    isn't. Strictly speaking you should have a "Content-type:" header in
    every RFC 4130 (AS2) message, but as far as I know no canonicalization
    of the contents takes place.

    The MIME headers might be a different story. A certified AS2 product
    that I have made _never_ canonicalizes received MIME headers and works
    fine. On sending we always generate MIME headers with "\r\n" (DOS line
    endings) but that is because RFC 2616 (HTTP) requires (or advises) this.
    There might be products that canonicalize "\n" MIME headers to "\r\n"
    before calculating the MIC; I don't know that, it will be safest to just
    generate the MIME headers (and MIME boundaries of course) with "\r\n".

    > If you make your message and you sign it, you will find this.


    I think there might be a problem with your signing which is the problem.

    > ...


    > Notice that ALL 3 signatures have the same MESSAGE DIGEST


    So there is a problem with your signing, it's as simple as that.
    Different byte sequences should always result in different message
    digests.

    At least separate the canonicalization (which I maintain isn't
    necessary) from the calculation of the MIC itself. This makes analysing
    what's going on much clearer.

    Calculating an MIC is basically just feeding a bunch of bytes to some
    OpenSSL routine, and always results in the exact same answer, which is
    also exactly the same as the value encoded in the PKCS7 encapsulation.

    > Notice that EVERY one of the MICs CALCULATED FIRST are different AMMONG
    > THEMSELVES, this is what you said, and I agree, because data is different
    >
    > But also notice that ONLY ONE OF THE MICs MATCH THE messageDigest inside all
    > signatures


    Yes, because your signing uses canonicalization, so the input to the
    message digest calculation is not three different messages but rather
    only one. And of course the only one that "matches" will be the one that
    happens to be the same before and after your canonicalization.

    > Which ONES MATCH?
    >
    >
    > Not the one from the text not canonicalized
    > Not the one from the text WITH ONLY MIME HEADERS canonicalized
    > BUT THE ONE from text WITH ***ALL CANONICALIZED***


    So your signing process uses full canonicalization. That's wrong and
    explains the failure with other products.

    > I have gone through another test about weird UTF-8 encoding but without
    > success. They send me UTF-8 data (containing a,e,i,o,u "acute" and n with
    > tilde in their UTF-8 encoding) and all that is further encoded again in
    > UTF-8. I've done the double decoding, again the things of the
    > canonicalization but still the MIC and messageDigest don't match.


    For calculating the MIC al this characterset encoding and possibly
    transfer encoding like "quoted-printable" (yes even this happens!) is
    completely irrelevant. Just take the bytes as an opaque structure,
    calculate the MIC and compare with the original.

    > These are just facts (not opinions) placed in words meaning "this happens"
    > if only MIME headers are canonicalized: THE BUSINESS PARTNER'S "certified
    > software" WILL REJECT your calculated MIC unless you watch the messageDigest
    > inside the signature and make it MATCH with the MIC calculated. (more
    > práctical if you forget about calculating MIC and simply fetch the
    > messageDigest inside the signature and send it back in the MDN's MIC.


    The wording of the RFC 4130 is sometimes a little vague and there are
    lots of details only determined in practice but calculating the MIC is
    possible. As with many RFC's, only see it as a common starting point and
    concentrate on the way it is used in practice, which often differs. And
    as they say don't attribute to malice which can be explained by sheer
    incompetence! ;-)

    So my advice: on sending use MIME headers and MIME boundaries (and HTTP
    headers, although not relevant for the MIC) with "\r\n" headers, and do
    not do any further canonicalization, either on sending or receiving. So
    in OpenSSL (finally something on topic!) always use the "PKCS7_BINARY"
    flag in the relevant function calls.
    --
    Marco Roeland
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  12. Re: RFC 4130 checksum in SHA1


    On Aug 07, 2008; 02:18am, Marco Roeland wrote:

    Marco Roeland wrote:
    >
    >
    > [ RFC 4130 calculating MIC, mostly offtopic for OpenSSL ]
    >
    >


    It is trivial that a checksum on same data produce the same result, that's
    by definition right with a very small probability to find two sets of data
    which give the same checksum. So that is not to discussion.

    Your answers on stating that RFC's are not followed or that not all is said
    on RFC's, confirm my first statement, that there are things done beyond the
    RFC. Tricks, Pre-Process, Procedure, Convention or anything done either
    due to Incompetence, Malice or "Tech Conventions", hey!, that *is* off
    topic, and it's not my point, but that just confirms the fact that there is
    a Pre-Process. Ok, not magic, not trick but something certainly *not* in
    RFC as you correctly acknowledge.

    This is graphically the signed document:

    Content-Type: multipart/signed; micalg=sha1;
    protocol="application/pkcs7-signature";
    boundary="----=_Part_271718_798961567.1217934040548"

    ------=_Part_271718_798961567.1217934040548
    original document
    ------=_Part_271718_798961567.1217934040548
    signature
    ------=_Part_271718_798961567.1217934040548--

    My point is that you (anyone interested in this RFC 4130) take the "original
    document" above and sign it.

    a) and if it is YOUR or MY document or any other document actually signed
    based on a -binary process, we get same signature and same messageDigest or
    MIC shown in "signature" above.

    1.- Yes sign it with -binary flag.
    2.- Using OpenSSL routines like shell openssl smime -sign -binary

    b) In case of an IBM solution I've worked with, you will have hard time
    kneading the "original document" to make it good to be signed and produce
    same MIC shown in the signature below. That kneading, -call it Tricks,
    professional secret, incompetence, malice- not found in the RFC is not just
    within the \r\n set of solutions. There are other pre-process procedures,
    so far not said, because they are in fact OFF TOPIC. Not important to be
    discused. But I have tested that signing -binary the "original document",
    doesn't produce the signature (in the example above).

    I just suggest within the OpenSSL topic, to use the asn1parse to find the
    messageDigest record and read that value.

    That's the MIC that all trading partners wish to receive in the MDN. I
    suggest to not get so much involved in the pre-process of the original data
    and if someone does it, just don't feel so bad if the MIC found doesn't
    match with the MIC in the signature. Just as Marco says and by definition
    of a checksum: "Calculating an MIC is basically just feeding a bunch of
    bytes to some OpenSSL routine, and always results in the exact same answer".
    By consequence if the answer is not the expected answer, then the original
    data is not the original data on which the MIC found in signature was
    calculated.

    What transformations are done from the original data seen on "original
    document" to the "thing actually signed", understood that's off topic. For
    that reason, and because they are not merely \r\n transformations, please
    just use OpenSSL asn1parse to find the messageDigest stored in signature.

    Greetings
    Javier

    --
    View this message in context: http://www.nabble.com/RFC-4130-check...p20060192.html
    Sent from the OpenSSL - User mailing list archive at Nabble.com.

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


+ Reply to Thread