RE: Registry Security Spec Version 003

[Krishna Sankar <ksankar@cisco.com>]

Hi,

	From what I understand, SSL is a blackbox as far as the applications are
concerned. That is why we cannot use SSL for non-repudiation. Agreed,
theoretically, there could be an SSL implementation which does a few corner
cases. But we should always look at the most common implementations and what
they provide.

cheers and thanks for the discussions.

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