[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] comments on (most of) core-25
Phill, Of those you picked, only the "line 705" issue is really of major importance (the others aren't entirely nits though). I've moved the 705 issue to the top to make it more likely that folks read about it. Stephen. > 705: It is a URI, therefore no syntactical possibility of a wildcard I know this was debated some time ago and assume that "no wildcard resources" (e.g. no "http://foo.com/images/*.gif") reflects the consensus (with which I'd disagree mind you, but ignore that for now:-). In any case, the spec doesn't say anything at all about this and in fact even fixing that still leaves open the interpretation of, at least, directory name URLs (i.e. ending in "/"). Put it this way: If the spec isn't clear on how a PEP should interpret an AuthorizationDecisionStatement of "allow http://foo.com/images/" then its broken in the simplest possible (and most unbelievable!) way and I'd rather you remove my name from the the document. Now, I'd much rather that the spec were clear and included me in the acks of course, but *only* if the above is properly clarified. (btw: if the "Contributors" section is only supposed to list people who are voting members, then I should be removed anyway.) To be clear: I'm not asking that the spec say that "allow http://foo.com/images/" be interpreted in my favourite way - just that one of the reasonable intrepretations be chosen and that that be clearly documented. I can think of three intrepretations (none of which is fully developed here) for the statement "allow http://foo.com/images/", namely: - statement implies nothing about "http://foo.com/images/image1.gif" and the PEP has to ask the PDP each and every time, however, the spec still needs to say this & how the (web server specific) equivalent of "http://foo.com/images/index.html" is to be handled by PEPs (presumably the web server or PEP should have expanded the URL and not asked the PDP about "http://foo.com/images/") - statement implies to PEP that "allow http://foo.com/images/image1.gif" is also true i.e. any URL beginning-with "http://foo.com/images/" - this would be a rule probably specific to http URLs and so PEP has to ask again about "http://foo.com/imagesThatShouldBePrivate" (and we need tp define handling of "http://foo.com/images/public/../../private/" and similar) - statement implies that "images/images1.gif" is ok but that PEP must ask about "images/private/image1.gif", i.e. rule specific to http URLs and where directories are handled specially and not just as the start of URLs (still need specical rule for "images/.." but in this case not for "images/../../") Also, since i18n has been used as an exploit and SAML mustn't re-create such vunlerabilities, we must make sure that the chosen rule doesn't do so (and ideally, explain that to the reader somewhere). And even though case sensitivity will be addressed elsewhere, since its such a PITA for URLs, how that's handled should be described/referenced here too. I'm sure that there're more than the three options above too. Just pick & *clearly* document one. There's definitely enough experience in this group to get this right and no excuse for getting it wrong. > 200: Actually to be really pedantic it should be Internet DNS domain since > there are actually non-Internet DNS domains. Fine. > 215: Which paragraph? "SAML authorities...of assertions." All line numbers in my comments are from the pdf. > 237: The #rwed debate, deferred Pity. But ok for now. > 295: Wording was carefully chosen to avoid the birthday paradox. Shame it didn't then:-) (unless you want that IDType values MUST be 256 bits and SHOULD be 320 bits?) Birthday p/dox implies that given a population of 2^64 random strings of length 128 bits you've a 50% probabality of a collision in the set (I hope:-). I interpret the current text as implying (not saying) that I need to use at least 256 bit strings so that even in a large (2^64) population, the probability of a collision is still "cryptographically" small. I think the wording I suggested avoids the issue, is simpler and clearer. However, I won't insist on you using that, but please do explicitly say that you want IDtype values to be at least 128 bits long since with the current text that only follows depending on your interpretation of how the birthday paradox affects this text (in particular what you think "randomly chosen" means:-). Having said that, this is really a nit (since the effect of misreading the spec is positive given that no-one will have a problem with longer-than- expected IDtype values). So fix/not as you like. > 603: It is an attribute, not an element so does not need to be declared > optional. Fair 'nuff. However , now I see and agree with the significance of Eve's comments on NameIdentifier being broken. > 664: IPv6 addresses eeek! 'Fraid so. At least state that you're only allowing IPv4 and how they should be written (dot sep is it? what about network byte order? what if some gobsh*&$e puts in 257.258.259.999). That I can live with. However, IMO its a bit late in the day for a new standard to claim that IPv6 is a weird unknown thing that we can safely ignore - do we want SAML bounced by the 3G folks for this reason? Not saying that'd happen, but no reason to chance it, is there? > 779: Can directly reference LDAP values via the LDAP URI. I don't think we > should limit ourselves to LDAP though, I think we should accept the > probability that LDAP will eventually be replaced with an XML form. Like DSML? That's what I'd like. I can live with this being addressed later, but there was some support for at least demonstrating how LDAP attributes could be mapped to SAML attributes. I think that this was also agreed to be an interoperability issue (was it?), in that we don't want there to be 9 different SAML versions of the equivalent attribute set to inetOrgPerson in particular. > 825: Moot/fixed with the anyType ok. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC