OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Security - question about nonrepudiation


Suresh,

1a) The ebXML Message Service specification [1] is the MS spec
referred to in the context of these lists.

1b) The Manifest I referred to is not the DSig manifest but
the ebXML Message Service manifest defined in [1]. The processing
semantics defined for signing an ebXML SOAP message are
orthogonal to those defined for manifest processing in the DSig
specification because they are different manifests.

It would please me to no end to see an alignment of the
two manifests, but alas, because the DSig manifest cannot
be extended, it wasn't possible to leverage it to our needs.

2) This is exactly the sort of thing that is relevant to the
discussion. Hence, the need to sign the message, not just
bits of it. If you simply sign the payload, all that can be said 
about it is that the payload hasn't been altered since it
was signed by the holder of the private key that was used to
generate the signature. This can be useful to a point, but it
doesn't necessarily provide much more than integrity.

3) yes, some elements of the envelope may be changed as the
message makes its way from sender to receiver (such as TraceHeader,
Via, etc.) Thus, the Message Service specification prescribes
a specific transform that is to be applied to the SOAP Envelope
before the digest is computed excluding those elements that
may be altered without sacrificing the repudiation characteristics
of the signature.

Cheers,

Chris

[1]  http://ebxml.org/specs/ebMS.pdf

"Damodaran, Suresh" wrote:
> 
> I have some questions/comments. Shoot me if I am completely off,
> because I haven't digested everything on this thread.
> [Feel free to post this message to the list if you think it will be of
> wider interest]
> 
> 1. Which is the MS spec being referred to? XMLDSIG spec
> allows for not signing all the payloads using "manifest"
> as I understand. Will this be relevant?
> 
> 2. Whether signature will be enough to authenticate the sender:
> Alice sends to Bob a note saying "I love you." The message was
> signed by Alice's private key and encrypted with Bob's public key. Bob
> decrypts, encrypts with Charlie's public key, and sends it to Charlie.
> How can Charlie say Alice didn't send it?
> Only if Alice signed the message and the intended receiver.
> Is this example of relevance to the discussion?
> 
> 3. Is there a need to sign only some elements of the envelope?
> 
> Regards,
> -Suresh
> 
> -----Original Message-----
> From: Collier, Timothy R [mailto:timothy.r.collier@intel.com]
> Sent: Tuesday, July 31, 2001 7:03 PM
> To: 'christopher ferris'; ebxml-cppa@lists.oasis-open.org
> Subject: RE: Security - question about nonrepudiation
> 
> Chris,
> 
>         Thanks.  Hum... I think the nonrepudiation element seems to need
> some work ;)  Ok, the authenticated element is a transport characteristic,
> makes sense. But still, the only method supported, right now, for
> nonrepudiation is digital signatures, which is already defined (in the
> docExchange).  Just seems like the nonrepudiation element is like pushing an
> elevator button that is already lit, it might make you feel good, but it
> doesn't really do anything.
> 
>         We should sync the MS signature methodology with the CPP/A
> definitions for the application of signatures.
> 
>         Regards,
> 
>         Tim
> 
> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Tuesday, July 31, 2001 4:24 PM
> To: Collier, Timothy R; ebxml-cppa@lists.oasis-open.org
> Subject: Re: Security - question about nonrepudiation
> 
> Tim,
> 
> The MS spec clearly defines how to sign a message (SOAP envelope
> and its contents plus any attachments listed in the Manifest).
> I will grant that this may be overkill in certain situations
> (e.g. if one of the attachments is an image that would require
> excessive overhead to sign and no benefit would be derived from having
> it signed).
> 
> As to authenticated, the mechanism used to authenticate the source
> of a message MAY be orthogonal to the mechanism used to provide
> non-repudiation. A message exchange that does not require NR might
> still require authentication at the transport level, which is what
> the Authentication element is intended to provide at that level
> (granted, it may need some work as well).
> 
> The fact is that there are many layers at play, each can add
> something to the next or not as the case may be. The "authentication"
> provided at the transport layer might not be bi-lateral. In fact,
> it may only be transient (to prevent m-i-m attack on a network
> connection) in which case the certificate that generates the keys
> to be used is not verified, it is just used to establish the keys
> to be used to encrypt/decrypt the packets sent on the wire.
> 
> The signature itself may not be the entity that is authenticated,
> but merely a mechanism that ensures that that entity (such as a
> SAML assertion) is authentic and hasn't been tampered with in-transit.
> 
> Great discussion!
> 
> Cheers,
> 
> Chris
> 
> "Collier, Timothy R" wrote:
> >
> > Marty,
> >
> > I was reading the risk assessment and that is what started this.  I do
> think
> > we need to address, in the CPP/A, how to indicate what the signature is
> > applied to - header, body, attachment, entire thing - but I don't see how
> > the nonrepudiation elements adds something new.
> >
> > What I was wondering is if we define the document exchange details, like
> > nonrepudiation (digital signature) and digital envelope (encryption) don't
> > they cover all of the requirements already?  Even the existing delivery
> > channel definition does not need the nonrepudiation element as it covers
> the
> > signature requirement via the authenticated element.  In the delivery
> > channel definition, IMHO, the authenticated and nonrepudiation elements
> are
> > redundant.
> >
> > I was mostly trying to get some discussion started on some of these areas
> > within security.
> >
> >         Tim
> >
> > -----Original Message-----
> > From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> > Sent: Tuesday, July 31, 2001 3:41 PM
> > To: Collier, Timothy R
> > Subject: Re: Security - question about nonrepudiation
> >
> > Tim,
> >
> > The attributes in the BPSS instance document don't say anything about how
> > to actually do nonrepudiation.  The CPP/CPA is precisely where the two
> > partners agree on what standard to use (actually XML DSIG is the only one
> > we support) and various details of XML DSIG such as certificates,
> signature
> > algorithm, transforms, etc.
> >
> > There are some questions as to whether what is in the CPP/CPA is correct
> > and whether it is comprehensive enough to, for example, cover the
> > application-level response, signing of payload vs signing of the entire
> > message,  and the signals that may need to be signed.  Some of these
> > questions are covered in my new.work document and the previous Changes
> > document.  Others may be called out in the ebXML Risk Assessment document.
> > It does need a thorough going over.
> >
> > Regards,
> > Marty
> >
> >
> ****************************************************************************
> > *********
> >
> > Martin W. Sachs
> > IBM T. J. Watson Research Center
> > P. O. B. 704
> > Yorktown Hts, NY 10598
> > 914-784-7287;  IBM tie line 863-7287
> > Notes address:  Martin W Sachs/Watson/IBM
> > Internet address:  mwsachs @ us.ibm.com
> >
> ****************************************************************************
> > *********
> >
> > "Collier, Timothy R" <timothy.r.collier@intel.com> on 07/31/2001 05:25:40
> > PM
> >
> > To:   ebxml-cppa@lists.oasis-open.org
> > cc:
> > Subject:  Security -  question about nonrepudiation
> >
> > All,
> >
> >      If two parties agree on complimentary roles within a process
> > specification, and agree on the document properties (in particular
> signing)
> > don't the nonrepudiation elements in the delivery channel characteristics
> > become superfluous?  After all, the parties have agreed on a process
> > specification that includes acknowledgement of receipt, and they have
> > agreed
> > on which documents have signatures attached (in the document exchange).
> To
> > me NRR sounds like a requirement on the BP, and NRO is a document
> > requirement for digital signature.
> >      I have heard that the delivery channel is an implementation
> > convenience, which is ok, but it seems even for that the authenticated tag
> > covers the digital signature requirement. And the implementation already
> is
> > monitoring the runtime process according to the BPSS.
> >      Do you think the nonrepudiation tags in the delivery channel express
> > unique requirements that are not already covered?
> >
> >      Tim
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC