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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-tp message

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


Subject: Re: nonrepudiation (signing messages)


Hima,

Himagiri Mukkamala wrote:
> 
> I'd agree with Chris.
<snip/>
> What's also missing is the canonicalization method!
> I used a hardcoded canonicalization method for
> the POC.

That too is prescribed in the ebXML MS spec, but
you are correct that to be truely flexible and valuable
in other domains, we should provide for this.

> 
> About using a "Reference" DSIG element in the CPA,
> that would have to omit the "URI" element too
> cause that's something runtime would create
> for the business document which packaging it.

This is true, which suggests that a specific binding
on a per-message basis may be what is needed, not just
a per-channel basis as currently provided.

> 
> -hima
> 
> christopher ferris wrote:
> 
> > Marty,
> >
> > My take on this is that this element could take the form
> > of a Signature "template" which effectively provided
> > all of the requisite binding information including
> > reference URI(s) with only the Digest and actual
> > signature omitted. The IBM Alphaworks XSS4J DSig
> > implementation provides for use of a template
> > to drive the signing behavior, which is a nice
> > feature of the tool (IMHO).
> >
> > I have successfully used the SignatureAlgorithm, HashFunction
> > and Protocol. I haven't used Certificate yet mostly
> > for implementation reasons.
> >
> > Presently, the ebXML MS specification prescribes the
> > Transform algorithm(s) that MUST be used, as well as
> > the Reference URIs necessary for the header, but not the
> > payload item(s) since that would depend upon the Content-ID
> > or Content-Location URI which might vary from message to
> > message even of the same type. Thus, presently this is
> > not an issue. However, to make this more flexible, it might
> > be useful to have the ability to fully describe the Transform
> > as well.
> >
> > Another approach would be to leverage the Reference element
> > from the DSig specification, omitting the DigestValue (like the
> > Signature "template" but without describing the full Signature.
> >
> > Cheers,
> >
> > Chris
> >
> > Martin W Sachs wrote:
> > >
> > > The NonRepudiation element specifies signing of the messages using XMLDSIG.
> > > Its child elements are Protocol, HashFunction,  SignatureAlgorithm, and
> > > Certificate.  I have recently been asked whether NonRepudiation also has to
> > > have a Transform(s) element. If XMLDSIG provides a choice of Transform,
> > > then the choice should probably be expressed under NonRepudiation.
> > > Alternatively, we might prescribe a particular answer in the text and not
> > > need an element.
> > >
> > > If something about transforms is needed in the specification, let's put it
> > > on the list for the maintenance release.
> > >
> > > 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
> > > *************************************************************************************
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:;;One Network Drive;Burlington;Ma;01803-0903;USA
version:2.1
email;internet:chris.ferris@east.sun.com
title:Senior Staff Engineer
fn:Christopher Ferris
end:vcard


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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC