OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] Fwd: SAML Conformance SSL/TLS requirements


> Well it really doesn't guarantee anything anyway, because if you deploy a
> conformant SAML implementation (which implements the protocols, messages,
> processing, etc) on top of (e.g.) Tomcat (which implements the SSL/TLS
> cipher suites), the actual cipher suites in use become a deployment
decision
> outside of the control of the implementer.

They're always under the deployer's control. The implementer's only job is
to ensure that the minimal subset are there. If Tomcat supports them, then
you can ship your SAML product using it and be conformant. If not, you
can't, and you'd better pick something else....

> Not to mention the cipher sites that may or may not be configured in the
> browser.

The browser has nothing to do with this, these are SAML binding issues
between SAML-aware entities. Browsers are not.

> No, I think this is different. The implementer has direct control over
which
> XML Sig algorithm is used, unlike the cipher suite his customer may chose
to
> deploy on his web server.

But SAML authorities and requesters are not web servers. Authorities might
decide to implement themselves using a web server (we do, certainly), but
that's not allowed if your server of choice doesn't support the required
ciphers.

If you let deployers run your product on non-conformant SSL stacks, that's
your business of course, but if that's all you support, then we have a
problem.

> In any case, this isn't that big a deal.  But I think it is important to
> recognize the real-world limitations of what can reasonably be normatively
> specified versus what are deployment decisions that cannot.

I don't see what deployment ever has to do with conformance. They are
separate issues. We may depend on lots of functionality all up and down the
stack, but that doesn't let us off the hook if those functions are poorly
implemented. I can't be given carte blanche to say "sorry, we use Joe's SSL
lib" if it doesn't support the required features.

-- Scott



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]