[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]
Powered by eList eXpress LLC