RE: ebXML Proof of Concept Proposal v0.5

[Dale Moberg <Dale_Moberg@stercomm.com>]

>Previously, concerns have been raised that a "receiver" couldn't produce a
>"correct" message digest from ebXML messages sent using a MIME aware
>transport because the servlet API or CGI didn't provide direct access to the
>original MIME headers of the ebXML Message Envelope.

For SMTP, it would be a bad idea to try to define the boundaries of
the data to be hashed to include any transport headers, as these
are added to in transport and when gateways are involved, even
the original headers and values may be tampered with.

For HTTP, (RFC 2068 or 2616), the problem is not so much modification
as access for a given application using a given API (CGI, NSAPI, ISAPI etc)
I thought that at the f2f we agreed that for this purpose (and in the
absence of using S/MIME, OpenPGP, or some other well-defined
security protocol, we would in effect adopt the convention of using
the hash defined by the "Content-MD5" header which is specified
in section 14.16 of RFC 2068. In that section, they discuss the
appropriate "canonicalization" methods and it basically saves
us the effort of reinventing the wheel for this specific functionality.

I suppose someone will want SHA-1, but if they do, I think it is
best to suggest that they use a standard multipart/signed approach


> However, during the F2F
>on 7/11+12 the TR&P team agreed to define the "signature block" of an ebXML
>message, which excludes the ebXML Message envelope MIME headers. The latest
>version of the packaging spec discusses this in section 4.7.


I need to check 4.7 to see that it does it the same way as RFC 2068, section
14.16. If we don't, I propose that we consider following 14.16 unless
people find a problem with it. (The canonicalization works through
thorny issues involving the HTTP Transfer-Encoding (not to be
confused with Content-Transfer-Encoding of SMTP), the issue
of end-of-line canonicalization (basically here they say to not
to canonicalize back to CFLF, which is sensible for HTTP),
and so on. )

Dale Moberg