Re: SACRED Protocol (long!)

   >Honestly, I don't think that work will be too onerous. C.f. with 
other
   >security-related protocols that runs over http.
 
hi. i think we live in different realities because i can't think of 
any "security-related protocols that runs over http" that were done in 
the ietf or signed-off by the iesg. in my reality, anything involving 
any  "protocol that runs over http" gets to run the brickbat gauntlet 
in the ietf/iesg. and speaking from experience, it's not fun...


   >As I mentioned in an earlier posting, the concern we had about the
   >current draft stemmed from two facts:
   >
   >-it binds SACRED tightly to BEEP; and
   >-there are widely implemented protocols that do not support SASL 
(or
   > other security frameworks), and platforms that SACRED is expected 
to
   > serve support these protocols and not BEEP.

in terms of the 1st requirement, i think dave addressed "the usual 
issues".

i just have to question the wisdom of the 2nd requirement 
because...see my next response...


   >We therefore felt that making SACRED payloads security-aware would
   >alleviate these concerns. And yes, at least one mapping to some
   >existing transport is needed, and given the latter factor above I
   >suggest that the initial mapping shall be to SOAP.

with enough thrust even a truck can achieve orbit, but you have to ask 
if it's worth it by tossing sasl (and to much a lesser extent beep) 
and re-inventing them. in the ietf, i think it's a hard sell. sure, 
it's not as hard a sell as also re-inventing tcp, but there's a big 
cost... 

to make matters worse, it turns out that the ietf's confusion as to 
whether soap is a format or a protocol introduces a huge amount of 
uncertainty as to how high the bar will be for making  sacred/soap 
payloads  security-aware...

/mtr