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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-requirements message

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


Subject: Re: ebXML Requirements


You raise a very good point.  It may be appropriate for us to list this "static"
requirement in the Requirements Specification, but note that it will be
satisfied by something outside of the ebXML recommendations.

Dwight Arthur wrote:

> 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>

--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/




[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