RE: Very Rough Draft of Header Specification

["Dick Brooks (D)" <dick@8760.com>]

David, regarding,

<DB>
IMHO, I think section 6 will define the nature of the problem. The detail of
how to solve it should be in a separate spec (i.e the ebXML Security and
Signature Specification) as not everyone will need to use signatures. We
specified how to define and use signatues in IOTP and I'm sure there are
other specs out there that we can leverage. I agree it's not easy but I do
think it's doable.
</DB>

<DICK>
EDIINT AS1 and AS2 contain specifications for signing/encrypting payloads
(including XML)
using S/MIME or PGP. Perhaps we can leverage this functionality for ebXML
header and payload bodyparts.
</DICK>

Dick Brooks
http://www.8760.com/


-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of David
Burdett
Sent: Monday, March 20, 2000 7:29 PM
To: 'Prasad Yendluri'
Cc: ebXML Transport (E-mail)
Subject: RE: Very Rough Draft of Header Specification


Prasad

See responses below.

David

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Monday, March 20, 2000 4:53 PM
To: David Burdett
Cc: ebXML Transport (E-mail)
Subject: Re: Very Rough Draft of Header Specification


David,

Please see couple of follow ups below in <PY></PY> brackets.

David Burdett wrote:

> Prasad
>
> Please see comments below. Let me know if you have any more queries.
>
> David
> PS i'm behind on my ebXML emails. Aim to catch up on the rest tomorrow.
>
> -----Original Message-----
> From: Prasad Yendluri [mailto:pyendluri@vitria.com]
> Sent: Thursday, March 16, 2000 4:53 PM
> To: David Burdett; ebXML Transport (E-mail)
> Subject: Re: Very Rough Draft of Header Specification
>
> If  "Message Routing Info" is something that is (potentially)
> extended as each time the message passes through a new hop, shouldn't it
> really be disjoint from the rest of the Message Header (that has headers
> that are closely coupled with the business exchange)? That would also help
> the case of a "relay" or a "hub" not having to look at the real business
> message to be able to route.
>
> ## Agreed. That's why the Message Routing Info is a separate part of the
> Message Envelope (see section 2) ##

<PY> True. But it really depends on what form the Header Envelope takes.
Section
6.1 "Header Envelope" does not specify this yet.
<PY>
<DB>
Agreed. Dick Brooks and co are working on the form of the Header Envelope.
Current thoughts are either MIME or possible XML.
</DB

> 1.      Shouldn't the  "Signatures" be really part of the message Body
> rather than Header?  ##There is no reason why you can't put signatures in
> the body if you want to. However if signatures are put in a specific place
> where the header can recognize them, then it means that it should be
> possible for middleware software to check the signatures in some standard
> way that would reduce the burden on the application programmer - as long
as
> the application programmer trusts the software ...## Or may be a separate
> entity by itself (neither header nor Body)  ##This is a perfectly valid
> option, since you could have, for example, Header Envelope; Signature(s);
> Message Body. In that sequence. I think it's always a good idea to put
> signatures neare the start. Thinking about it though, if we point to the
> signatures from the Message Manifest, I'm not really sure it matters much
> where you put the signature piece.##  It os not clear to me, how the
> association between a signature and the part(s) of the message it signs
> would be established?   ## In S/MIME it's done by physical association (I
> think !) in XMLDSIG, you can point to the thing that is being singed using
a
> URI.##  I am thinking we need to have a structure that permits signing the
> routing headers (potentially multiple times, as they get changed),
> individual parts (on a per part basis) and the whole message (again
multiple
> times if needed).   ##I've always thought that you could have multiple
> signatures (see the "s" on signatures in section 2). What we need to do is
> work out an approach where the individual signatures and their purpose can
> be quickly and easily determined.##

<PY> This is a tricky and complex aspect to nail IMHO. Is this specification
going to address this (again in section 6) or is there a specification that
is
slated for these aspects?
</PY>
<DB>
IMHO, I think section 6 will define the nature of the problem. The detail of
how to solve it should be in a separate spec (i.e the ebXML Security and
Signature Specification) as not everyone will need to use signatures. We
specified how to define and use signatues in IOTP and I'm sure there are
other specs out there that we can leverage. I agree it's not easy but I do
think it's doable.
</DB>

Thanks, Prasad