RE: Registry Security Spec Version 003

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

If the conformance document says that all ebXML conforming
apps will, among other things, support XMLDsig over
the header and the payload, then there will always
be a default interoperability mode for application
layer signature. If the application also supports
other security modes, tnen the CPP and CPA based
agreement could specify operation in that other
mode, provided both sides were capable of operating
in that mode and preferred it. Isn't that one of
the distinct advantages 
of adding CPP/CPA functionality 
to ebXML? 

In this way we permit
local, bilaterally agreed upon
security solutions to exist
where possible and desired,
but otherwise always have a fallback
security mode of operation.
Excluding other security options would
be pointless and would certainly detract
from the attractivenss of the ebXML
framework to those organizations large
enough to have a security policy and
preferences concerning implementation. 

The interoperability
concern from Sid, in so far as
it is not being used as a club,
is completely satisfied by the conformance
requirement; the CPP/CPA extensibility
mechanisms allow other solutions
to interoperate and provide a flexible
framework for setting them up,
thus enhancing the overall appeal
of the ebXML framework.

> -----Original Message-----
> From: Maryann Hondo [mailto:mhondo@us.ibm.com]
> Sent: Thursday, December 28, 2000 9:29 AM
> To: Burdett, David
> Cc: 'Krishna Sankar'; ebxml-regrep@lists.ebxml.org; Ebxml Transport;
> Ebxml-Ta-Security
> Subject: RE: Registry Security Spec Version 003
> 
> 
> Just to let you know,
> 
> Sid from Netfish raised the concern of whether or not we 
> should actually
> require a minimum security profile for interoperability
> on the last TRP call.  He feels it is imperative for TRP to chose one
> profile.  I have suggested to him and to
> Anders and the Technical  Architecture team that this be 
> considered as part
> of the
> "conformance" section of the technical architecture document 
> (new version
> just released).
> 
> Have you all looked at the architecture doc?
> Do you believe this will work?
> 
> I believe this issue will need to come to a vote soon.
> 
> Maryann
> 
> "Burdett, David" <david.burdett@commerceone.com> on 
> 12/27/2000 03:40:26 PM
> 
> To:   "'Krishna Sankar'" <ksankar@cisco.com>, 
> ebxml-regrep@lists.ebxml.org,
>       Ebxml Transport <ebxml-transport@lists.ebxml.org>, 
> Ebxml-Ta-Security
>       <ebxml-ta-security@lists.ebxml.org>
> cc:
> Subject:  RE: Registry Security Spec Version 003
> 
> 
> 
> >>>if there is only an anemic MAY, then all applications 
> which use the TRP
> would have to specify alternate ways (for signature and encryption) as
> well.<<<
> 
> I disagree. If the specification provides for a wire format 
> that meets all
> the signature and encryption requirements of an application then there
> should be no reason why an application should not be able to 
> use it, if
> they
> want to. If the software that an implementer has chosen 
> doesn't allow it
> then it is the implementers problem for choosing the wrong software.
> 
> IMO, I think we need to encourage the availability of software that
> provides
> a rich inteface to high level applications so that they can 
> examine and
> process any data in an ebXML message **without requiring all solutions
> provide it**. For one thing you can't make software 
> developers implement a
> rich API if they don't want to.
> 
> However you can let software developers create solutions that meet
> customers
> needs. So if customers need access to the inner details of an 
> ebXML message
> then they will demand, and solution providers will presumably develop,
> solutions that meet that need. Similarly, if there is a 
> demand, solutions
> that hide all the lower level details from the application will be
> developed.
> 
> Once we do get the infamous Service Interface Specification 
> developed then
> software vendors will be able to claim compliance with it and 
> therefore
> provide the richer functionality you seek.
> 
> Either way I honestly don't see how the specification can 
> mandate the use
> of
> an API for the software, you just need to make sure that the 
> specification
> encourages it but doesn't prevent it.
> 
> Cheers !!
> 
> David
> 
> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: Wednesday, December 27, 2000 11:46 AM
> To: Burdett, David; ebxml-regrep@lists.ebxml.org; Ebxml Transport;
> Ebxml-Ta-Security
> Subject: RE: Registry Security Spec Version 003
> 
> 
> David,
> 
>      Sorry David, if there is only an anemic MAY, then all 
> applications
> which
> use the TRP would have to specify alternate ways (for signature and
> encryption) as well. Which is fine, so long as this is what 
> the TRP specs
> says. But I would rather see a crisp specification which 
> deals with what
> things would be done rather than possibilities.
> 
>      Remember, we are talking about what and not how and when.
> 
>      cheers
> 
> > -----Original Message-----
> > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > Sent: Wednesday, December 27, 2000 11:30 AM
> > To: 'Krishna Sankar'; ebxml-regrep@lists.ebxml.org; Ebxml Transport;
> > Ebxml-Ta-Security
> > Subject: RE: Registry Security Spec Version 003
> >
> >
> > I really think we are debating specification vs implementation.
> > You say that
> > SSL stips of the signature so that you can't see it. I 
> haven't used SSL
> > myself, but I guess what you are actually saying is that SSL
> > implementations
> > strip of the signature and do not pass it to a higher level app.
> > Or does the
> > SSL **spec** require that signatures are stripped. I could 
> imagine that a
> > particular SSL implementation could make the signature available
> > if this was
> > important.
> >
> > What I think you are looking for in the ebXML TRP specs is
> > wording along the
> > following lines ...
> >
> > "Any or all of the data contained in the data communication 
> protocol,
> MIME
> > envelopes and the ebXML Header Document, MAY be made 
> available by the
> > Message Service Handler to an application or other process that is
> > processing the message. How this is done is implementation dependent
> > although ebXML Service Interface specification (to be developed)
> > provides a
> > non-normative design for how this may be done."
> >
> > David
> >
> > -----Original Message-----
> > From: Krishna Sankar [mailto:ksankar@cisco.com]
> > Sent: Wednesday, December 27, 2000 10:21 AM
> > To: Burdett, David; ebxml-regrep@lists.ebxml.org; Ebxml Transport;
> > Ebxml-Ta-Security
> > Subject: RE: Registry Security Spec Version 003
> >
> >
> > David,
> >
> >    Thanks for the e-mail. My comments are embedded.
> >
> > cheers
> >
> > > -----Original Message-----
> > > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > <snip ../>
> > >
> > > The answer to this question depends on whether you are defining:
> > > a) a wire specification with a description of the behavior of
> > the software
> > > at each end, or
> > > b) a software solution that implements the specification 
> defined in a)
> > >
> >
> > Yep, we are doing a wire specification. No problems here.
> >
> > > I think we are doing the former - the wire specification. More
> > > specifically
> > > we are saying the following:
> > > 1) You can have a XML Dsig compliant signature in the ebXML
> > > header which can
> > > potentially sign anything, and
> > > 2) The MIME part that is the payload may be digitally signed
> > > using, S/MIME,
> > > PGP/MIME or XML Dsig.
> > >
> > > However whether or not software that supports the ebXML 
> specification
> is
> > > able to sign a payload really is an implementation decision of
> > > the software
> > > designer.
> > >
> >
> > David, you are addressing specification Vs implementation. 
> I am not even
> > talking about implementation. If the software does not 
> implement security
> > stuff, then that particular installation will not have the 
> capability.
> >
> > The question is whether the *specification* says the TRP is 
> a black box
> or
> > not. It is a question of visibility to the upper layers - an
> > architectural/specification issue. Pl read on.
> >
> > > So to answer your question ... "Is the TRP going to be a 
> black box with
> > > regard to applications or will it "communicate" with the layers
> > > above ?" The
> > > real answer is it depends on how you build your solution or the
> > > features of
> > > the ebXML solution you buy.
> >
> > I disagree. If the specification leaves the architecture 
> issues to the
> > implementer then we are asking for trouble ! For the lack 
> of better words
> > "communicate with the layers above" is *not* an 
> implementation issue.
> >
> > Remember my question is not whether it is *available* or 
> not, but whether
> > there is an interface from the TRP layer to the upper 
> application layer.
> > This need not be APIs or services, could be just elements 
> in the XML -
> for
> > example if the signature is OK, the TRP puts an element
> > <SignatureVerified>Yes</SignatureVerified> in the header for the
> > application
> > to read - This is just an example.
> >
> > The visibility example can be best amplified by SSL. Even 
> though SSL does
> > encryption et al, the application cannot get to the 
> signatures or the
> > encrypted payload. So even if the transport layer (actually 
> the message
> > layer to be politically correct) uses SSL, the application 
> still has to
> > specify how to sign a payload, how to encrypt it etc.
> >
> > Again, as there are well known standards, the specification 
> has to do
> only
> > the semantics and syntax not the algorithms.
> >
> > >
> > > So for your spec, I would focus on describing the requirement
> > rather than
> > > the solution to the requirement. For example if you wanted allow
> > > the payload
> > > resulting from a reg-rep query to be digitally signed, 
> then I would use
> > > words along the lines of:
> > >
> > > >>>"The Payload of the Reg-Rep query MAY be signed using a XML
> Signature
> > > within the ebXML Header Document, etc...<<<
> >
> > This approach I like. We can specify the requirements. But 
> by saying that
> > the header MAY be signed, we are saying that the semantics and
> > syntax of the
> > operation is described somewhere, hopefully in the TRP 
> specification.
> >
> > Again my question is, if the TRP specifies how to sign a header
> > separately,
> > then I can do what you say. But then the header - with the 
> signature -
> > should be available at the application layer. In other words, if the
> > application can "see" the signature, then we can leverage the TRP
> > specs. But
> > if the TRP strips off the signature, we need to have some 
> other scheme.
> >
> > Same is true with the payload signature. If the TRP 
> verifies the payload
> > signature and strips it, then the application not only has 
> to specify
> what
> > is required, but it needs to specify the XML elements as well.
> >
> > It is this interaction that I was abstracting as the black-box
> > behavior. May
> > be the idea all along was to pass on the header signature 
> and payload
> > signature/encryption to the application layer. I have a 
> related question
> -
> > have you folks discussed using SSL at the TRP layer ? If 
> so, how will it
> > play ? Will an SSL implementation satisfy the TRP security 
> requirements ?
> >
> > Hopefully, I have made the points more clearer.
> >
> > cheers
> >
> >
> > >
> > > David
> > >
> > > -----Original Message-----
> > > From: Krishna Sankar [mailto:ksankar@cisco.com]
> > > Sent: Tuesday, December 26, 2000 11:55 AM
> > > To: ebxml-regrep@lists.ebxml.org; Ebxml Transport; 
> Ebxml-Ta-Security
> > > Subject: RE: Registry Security Spec Version 003
> > >
> > >
> > > Chris,
> > >
> > >  Comments embedded.
> > > cheers
> > >
> > > > -----Original Message-----
> > > > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > > > Sent: Tuesday, December 26, 2000 7:24 AM
> > > > To: Krishna Sankar
> > > > Cc: ebxml-regrep@lists.ebxml.org; Ebxml Transport; 
> Ebxml-Ta-Security
> > > > Subject: Re: Registry Security Spec Version 003
> > > >
> > > >
> > > > Krishna,
> > > >
> > > > Some comments on your proposal.
> > <snip ../>
> >
> 
>