Re: SACRED Protocol (long!)

Magnus Nystrom <[email protected]> Fri, 7 Dec 2001 10:05:48 -0500 (Eastern Standard Time)
Newsgroups gmane.ietf.sacred
Message-ID <Pine.WNT.4.31.0112071000130.1180-100000@mnystrom-lap>
Marshall,

I agree with you that there certainly is a need to do mappings to
underlying transports. But we claim that with our proposal, this won't
be any more difficult than, e.g., the mapping of OCSP messages to http
(which is described in an Appendix to RFC 2560, less than one page
long) or XKMS messages to OCSP (which also is described in a simple
Appendix).

With the current draft, it was not clear how to do this, and hence if
someone would have liked to implement SACRED on top of http, they
would more or less had been forced to start all over again (since the
current proposal relied on BEEP's support of SASL, and http does not
have this support (yet)).

My suggestion is to define a mapping to SOAP. Since SOAP already maps
to BEEP (as I understand it) and also has a http binding this would
seem to take care of our immediate requirements.

BR,
-- Magnus

 On Thu, 6 Dec 2001, Marshall T. Rose wrote:

> > Actually Marshall, I think it is a good thing to run SACRED on top of
> > BEEP. However, I also do believe that it should be possible to run
> > SACRED on top of other protocols as well, including protocols that
> > does not have BEEP's support for SASL. By integrating SACRED's
> > security mechanism into SACRED itself we claim to achieve this.
>
> everything has a cost. by mandating
>
> > > > -allow SACRED protocol exchanges to run on top of any reliable
> > > >  transport, including SOAP, http, BEEP, and other protocols,
>
> you have increased the cost of entry for developers (which mappings do i do
> first) along with the switching cost for consumers (can't switch to vendor
> Y's product, because it doesn't support the mapping used by vendor X's
> product).
>
> very often having too many choices is far worse than having once choice.
>
> /mtr
>
> ps: of course, this all assumes that the wg can agree on N mappings in
> finite time, that the iesg goes along with it, etc., etc. in other words,
> the scope of effort just got a whole lot bigger...
>
>
>

-- Magnus
Magnus Nystrom
RSA Security