RE: Registry Security Spec Version 003

[Krishna Sankar <ksankar@cisco.com>]

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