Re: allen's mail on manifests

[christopher ferris <chris.ferris@east.sun.com>]

David,

Responses inline below.

Cheers,

Chris

"Burdett, David" wrote:
<snip/>
> >
> > Secondly, some people have suggested that the Manifest should contain a
> > digest of what is the manifest entry points to. This doesn't make sense to
> > me since you would have to canonicalize the data before digesting it and
> > this is now getting very similar to signatures.
> 
> Please read the XML Signature spec as it relates to Manifest. I think that
> you'll find that the Manifest/Reference elements are the same as those
> in the SignedInfo element of a Signature. They contain the DigestValue
> and are processed the same as SignedInfo/Reference elements...
> <DB>I have read the spec and I know that they are similar. However the TRP
> Manifest, unlke the Dsig Manifes, does not contain the Transform and Digest
> elements so they are not the same.</DB>

I'm well aware of this. My comment related to the sameness of the
ds:Manifest/ds:Reference and ds:SignedInfo/ds:Reference. They are infact
the
same, just used in separate contexts. It was my hope that the same
Manifest *could* be leveraged for both the ebXML packaging AND digital
signing, but the XMLSignature schema is not extensible.

> >
> > For these reasons I have always thought that the message and signature
> > manifests should be kept separate. Does this make sense?
> 
> Actually, I very much favor the idea that a message be signed through
> use of a Manifest.
> <DB>So do I. The issue is can you have one manifest.</DB>
> It would be *very* useful as there needn't be redundant
> Reference elements if a message is multiply signed.
> <DB>This assumes that the same data is signed each time. This is not likely
> to be always true since when you add another signature you will frequently
> add additional information therefore the manifests can't be the same.</DB>

Yes, this is true if you aren't specific about what you are signing.
I think that if an intermediary process changes a message, that
it is in fact a DIFFERENT message and the intermediary is
obviously not a passive passthrough but an active participant in
a process. In this case, I am of the opinion that the intermediary
is in fact NOT an intermediary but a Party in a multi-party
collaboration. The messages it receives are not retransmitted,
they are consumed and a new message is produced by an application
that is directed to another party which MAY have very similar,
if not identical content, but it is in fact a VERY different
message. In this case the Signature is used to guard the payload
not the Message. 
 
> In regards
> to your suggestion that not all referenced content be signed, I would
> like to see it possible to have a Manifest that could be partially
> digested (e.g. remove constraint that all ds:Reference elements
> MUST have a ds:DigestMethod/ds:DigestValue) so that selected
> references (such as large images, or unimportant content) need
> not have to be digested.
> <DB>I agree, but I don't think the current XML Signature spec supports this
> and therefore we can't use it. Hence the need for us to be keep the
> signature and TRP manifests separate. Even though they have similar
> structure, they are used in different contexts for different reasons and
> therefore they can't necessarily be the same.</DB>

David, I am well aware that the current spec doesn't support it,
I am suggesting to the audience in general (some of whom may be
on the XML Signature WG or know someone who is) that this functionality
would be potentially useful, could use some exploration. I am 
making a suggestion that may never be acted upon. 

The whole point of Allen's email was to point out that a *single*
Manifest that were useful in all (or at the very least many)
contexts would be "a good thing" (tm). I tend to strongly
agree with his point.

Cheers,

Chris

> >
> > Regards
> >
> > David
> >
> > -----Original Message-----
> > From: Maryann Hondo [mailto:mhondo@us.ibm.com]
> > Sent: Wednesday, February 28, 2001 2:42 PM
> > To: ebxml-ta-security@lists.ebxml.org
> > Subject: allen's mail on manifests
> >
> > From: "Allen Brown" <allenbr@microsoft.com>
> > To: "Maryann Hondo" <mhondo@us.ibm.com>
> > Cc: <ebxml-ta-security@lists.ebxml.org>,      <mscherling@xcert.com>,
> > <aboseman@atpco.net>,    <gcrough@cyclonecommerce.com>,
> > <pbussey@cyclonecommerce.com>,     <jturpin@cyclonecommerce.com>,
> > <erick@softshare.com>
> >
> > EBXML's adoption of SOAP 1.1 and its attendant attachments specification
> > leads to two, or possibly three, distinct notions of manifest:
> >
> > * the EBXML native one
> > * the one in the SOAP attachments spec
> > * the one in the XML digital signature (and eventually encryption)
> >
> > One presumes that EBXML will also adopt the eventual SOAP signing and
> > encryption specifications based on the XML signing and encryption
> > specifications.
> >
> > An effective security environment will require signing and encryption to
> > interact smoothly with manifests. Thus far I can find no specification
> > work that would make a priori commensurate the various notions of
> > manifest mentioned above. Nor can I find any specifications that would
> > enforce alignment of these manifests even on an ad hoc basis. Perhaps I
> > have overlooked something?
> >
> > Independent of problems potentially arising from multiple notions of
> > manifest, there is also the fact that XML digital signatures (and
> > encryption) apply to well-formed XML. That being the case, it is not
> > entirely clear to me how XML encryption and signing would be applied to
> > arbitrary MIME-based attachments. If this is implicit in the
> > specification work done thus far (and I have missed it), I suggest that
> > it needs to be made _explicit_.
> >
> > Allen
> >
> > Allen Brown
> > Microsoft Corporation
> > +1 425 705-3290 (voice)
> > +1 425 936-7329 (fax)
> > allenbr@microsoft.com <mailto:allenbr@microsoft.com>
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-ta-security-request@lists.ebxml.org
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-ta-security-request@lists.ebxml.org
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-ta-security-request@lists.ebxml.org
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard