RE: [security-services-comment] Public Comment on DEFLATE

["Scott Cantor" <cantor.2@osu.edu>]

> [13:54:41] sampo.kellomaki My "issue" with deflate is two 
> fold: 1. the SAML2 spec is easy to misread in this regard. 2. 

What's really easy to misread are the javadocs. I think it's as much a Sun
issue as a SAML issue. Terminology there is misleading.

> I am not completely sure about the wisdom of using raw 
> deflate without supplying integrity mechanism like checksum. 
> zlib authors clearly state that raw deflate is intended for 
> cases where such protections are provided by some mechanism 
> other than zlib header or gzip header, but advise against 
> using raw deflate if no such mechanisms are available.

Could you elaborate on the threat? Integrity in a real sense, of course,
requires signing. I'm not sure what the concern is since this is transitory
data, not long-term archiving, etc. Not saying you're wrong, but I'm not
sure what the actual benefit is.

> [13:55:24] . SAML2 does not specify any such mechanism.

See above. We specify signing, which is expected to be commonly used with
this binding.

> [13:57:52] sampo.kellomaki Yes 1951 is clearly stated, but a 
> foot note calling out that "i.e. no zlib header is used" 
> would avoid the common confusion.

I think there's supposed to be errata on that but mainly it was intended to
be in a non-existent implementation guidelines document.

> [13:58:29] sampo.kellomaki My second comment says that 
> rfc1950 probably should have been specified in the first place.

Not sure I agree, but in retrospect, what we really did was choose DEFLATE
over gzip (1952) which is clearly not appropriate. Nobody mentioned 1950 as
a possible choice at the time.

I don't see that it's worth adding a new 1950-based binding now unless
there's a clear benefit to the specification, but YMMV. If what's there can
be implemented easily and is not "broken", I see no major problem with it.
The real step forward would be a more compact binary XML representation.

-- Scott