RE: Registry Security Spec Version 003

[Martin W Sachs <mwsachs@us.ibm.com>]

David,

I think that we are in agreement with "API" question but  just to be sure:

We cannot enforce that implementers provide a rich API but we can certainly
encourage it by completing and publishing the service interface
specification even if it is (and probably should be) non-normative.  The
more non-normative discussion of possibilities there is in a specification,
the more likely that implementers will take the hint.

This isn't only a question of implementer business decisions.  In many
cases, I suspect that the problem is that the people doing the design and
coding simply don't have a sufficiently broad and deep understanding of the
issues.  Lots of non-normative discussion can do a lot of educating.

I recently tried to buy a desk lamp from a web service.  I searched their
catalog for lamps and got a couple of hundred hits on clipboards and paper
clips which obscured my lamp.  The reason turned out to be that the catalog
was giving me clamps in addition to lamps.  In that catalogue, "clamp" is a
category code which includes paperclips and clipboards. That's a case of
someone not knowing the difference between searching on text strings and
searching on words.  The more discussion we include, the more we can help
to avoid such errors.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



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