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


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]