[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Fwd: SAML Conformance SSL/TLS requirements
On 8/15/05 7:55 PM, "Scott Cantor" <cantor.2@osu.edu> wrote: >> Well, you are not "recommending", you are REQUIRING, which is my main point. >> I believe the language in this section should be relaxed to say these cipher >> suites are RECOMMENDED, rather than MTI. >> > The point of conformance is to ensure points of commonality. If they aren't > REQUIRED, then there is no guarantee that any two SAML components will share > any cipher suites. The fact that this is unlikely to be an issue in practice > doesn't change the goal. 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. Not to mention the cipher suites that may or may not be configured in the browser. > >> It isn't part of the SAML specification, it's purely a >> transport layer issue that (imho) is out of scope for these specs. > > It is important to ensure that the implementations of that transport layer > by requesters and responders support a common set. The fact that some of may > (or may not) choose to use existing off the shelf libraries to implement > that transport is immaterial. This just forces implementers to pick good > ones. > > Why is this different than making specific XML Sig algorithms MTI? Of course > maybe you disagree with that too, as that would be consistent. 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. 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. ET > > -- Scott > -- ____________________________________________________ Eric Tiffany | eric@projectliberty.org Interop Tech Lead | +1 413-458-3743 Liberty Alliance | +1 413-627-1778 mobile
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]