Re: [security-services] Bug in the bindings doc; wrong RFC

[Greg Whitehead <grw@trustgenix.com>]

Hi,

It was great working with all of you at the Oasis SAML2.0 Interop Lab.

I just wanted to remind everyone that, now that the RSA show is safely 
behind us, we all need to correct our respective implementations of the 
DEFLATE encoding to remove the ZLIB header. If anyone is interested in 
doing some online testing after applying this fix, let me know.

BTW - This whole thread (beyond what is captured here) is available 
from the SSTC archives.

-Greg

On Feb 7, 2005, at 1:08 PM, Ari Kermaier wrote:

> It seems to me, from Scott Cantor's responses, that we are all wrong 
> w.r.t. the SAML spec, and that we will need to fix our 
> implementations/products to comply. However, I suggest we do this 
> *after* 2/17/05, or we court disaster at the RSA IOP demo.
>
> Ari Kermaier
>
> -----Original Message-----
> From: Rich Salz [mailto:rsalz@datapower.com]
> Sent: Monday, February 07, 2005 1:21 PM
> To: Scott Cantor
> Cc: 'SSTC WG'; 'Ken Ballou'
> Subject: Re: [security-services] Bug in the bindings doc; wrong RFC
>
>
>> It may be that use with most libraries would require 1950/zlib and 
>> that
>> referencing DEFLATE isn't sufficient to specify the wire format.
>
> Either it's DEFLATE (RFC 1951) or its ZLIB (RFC 1950).  ZLIB is a
> wrapper (header and trailer) around compressed data, and is currently
> only defined for DEFLATE.  There are probably libraries that can
> transparently consume either format, but I can't imagine how to
> implement one that magically knows which one to generate. :)
>
>> The point
>> was to avoid formats like gzip that presumed a lot of metadata about 
>> the
>> stream that was N/A to this use case.
>
> That makes complete sense.  (I didn't mention RFC 1952, and I don't see
> anyone else doing so either.)
>
>> If the DEFLATE scheme is itself enough to be "descriptive", then the 
>> spec,
>> IMHO, is correct. It may be that using zlib instead is preferable, 
>> and an
>> alternate encoding could be developed for that.
>
> If DEFLATE/RFC1951 is what was intended, and what is still desired, 
> then
> the specification is correct, although it is missing a bibliography
> entry for the actual RFC.
>
> I will point out, however, that everyone seems to have implemented it
> wrong.  Let me emphasize that:  everyone. Certainly, some of this is 
> the
> fault of errors in the Java documentation.  But it also has to make you
> wonder if the spec itself doesn't, somehow, need improvement.
>
> It is unfortunate that the evil triumvirate (RFC 195[012]) didn't
> include any test vectors.
> 	/r$
>
> -- 
> Rich Salz, Chief Security Architect
> DataPower Technology                           http://www.datapower.com
> XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html
> XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> security-services-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: 
> security-services-help@lists.oasis-open.org
>
>