[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: ebXML Requirements
Mike Rawlins wrote: My comments, MCR2 >Duane Nickull wrote<snipped>: > > >From Duane Nickull: > > > > Mike Rawlins wrote: > > > > > > > > > * In X12/EDIFACT, the facilities for signing/encrypting documents are > > > > quite extensive (e.g., signature over signature), whereas existing work with > > > > XML/EDI has only supported communication layer signatures/encryption. From > > > > a business/legal viewpoint, what are the security/privacy requirements? > > > > The expedient thing to do would be to accept the > > > > communications level solution for now, but is it adequate for now? > > > > > > MCR: That's a very good point. I think it appropriate for us to list as > > > non-functional requirements all of the classic aspects of security such as > > > non-repudiation in various flavors, confidentiality, authentication, etc. both > > > in regard to communications as well as static documents where appropriate. > > > > <DUANE> The industry standard RSA encryption techniques that are > > available to http bound messages should be good enough to satisfy for > > now. Can you please explain where you envision static documents fitting > > into the architecture that need to be encrypted? > > </DUANE> > > MCR2: This goes back to your group's (Bob Miller's) requirement for something beyond > just communications layer security. Others have described this needs for both > communications session encryption/authentication/etc., and > encryption/authentication/etc. that could be applied to a stand alone (what I call > static) document. <dwight> There was a similar discussion in the transport list. I do not understand this requirement. Many types of application will require many types of attribution and authentication of static documents that are to be incorporated into (attached to?) (carried through?) ebXML messages. EbXML imho needs to be able to attribute and authenticate its own envelopes, and must not interfere with the schemes used by applications to authenticate and attribute any objects placed into the ebXML envelope. However, I do not think it feasible for ebXML to incorporate a comprehensive specification for signing objects, combinations of objects, or ranges within objects with both transitory and persistent signatures. I believe that this should happen at a layer that's higher than the scope of ebXML.</dwight>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC