RE: Registry Security Spec Version 003

["Burdett, David" <david.burdett@commerceone.com>]

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