[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] canonicalization for XACML instances being signed
Hi David, David Chadwick wrote: > > Frank Siebenlist wrote: > >>Hi David, >> >>Please let us help you to get rid of these flaky X.509 ACs with a combination of >>xacml attribute and policy assertions ;-) >> >>.. but you bring up an interesting point: how can I express the delegation of an >>attribute assertion? >> >>For example, if I want to assert you the right to use my "GoldMembership" for >>certain operation, how would I go about that within the xacml framework ? > > > Frank > > this is not the real problem I was addressing. Those good ol' flaky > X.509 ACs can already do that. Sorry, my email was not clear enough: I wasn't questioning the ability of a "good ol' flaky" x509 ac to do this, but was wondering how we could do that within the xacml framework... > Its relatively easy. The real problem is > how can I delegate to you GoldMembership but say that you can only > delegate SilverMembership to your friend (assuming hierarchical RBAC > here). > Or I delegate to you RWE, but only want you to delegate R to someone > else. It looks like a new data construct is required to do it properly > > (I can think of a cumbersome work around, using multiple delegations, > viz: I delegate one set to you, saying that you are not allowed to > delegate it further e.g. GoldMembership, and I delegate another set to > you saying that you can delegate it further e.g. SilverMembership). which brings up yet another interesting use case for xacml 2.0. I vaguely remember trying to map clearance levels onto x509 ac attributes, but there wasn't direct support for enumerated values, like platinum/gold/silver/bronze/tin, so all was pushed to the interpretation in the application. Maybe the richer xml schema could provide more syntactic support here. It might be an interesting exercise, like the one for RBAC, to see how well xacml could address the requirements of MAC-style access control, for clearance levels, data labels, CMW... Regards, Frank. >>D.W.Chadwick wrote: >> >> >>>Frank >>> >>>X.509 ACs (partly) support this mechanism in one of the extension fields >>>(in much the same way the PKC trust chains are built up). So you can >>>calculate that a delegated credential is trusted, and that it is a >>>subset of the authorising credential, but without defining another >>>extension there is currently no way of signaling which part of a >>>credential can be delegated (its all or nothing) >>> >>>regards >>> >>>David >>> >>> >>>Frank Siebenlist wrote: >>> >>> >>>>If I would delegate you some of my rights with the right to further delegate >>>>those onwards, like reading one of my files on a machine, and you would delegate >>>>those rights on to a third party, then in your authorization assertion for that >>>>third party, you will have to reference my original assertion somehow, either by >>>>complete inclusion of my original assertion or at least by inclusion of the >>>>digest value that I signed. >>>> >>>>My understanding of canonicalization is not good enough to state the >>>>implications of this... >>>> >>>>-Frank. >>>> >>>>Anne Anderson wrote: >>>> >>>> >>>> >>>>>I am trying to wrap up the next revision of the XACML DSig >>>>>Profile. To bring everyone up to date, our profile says "follow >>>>>the SAML DSig guidelines" >>>>>(http://www.oasis-open.org/committees/security/docs/draft-sstc-xmlsig-guidelines-03.pdf), >>>>>and then adds only instructions specific to the XACML payload, >>>>>such as how to handle <PolicyIdReference> and >>>>><PolicySetIdReference>. >>>>> >>>>>The hard part is dealing with canonicalization. SAML's DSig >>>>>Profile seems underspecified here, and not just for use with >>>>>XACML. The Exclusive Canonicalization it recommends does not >>>>>create canonical forms of XML Schema primitive datatypes (such as >>>>>"...#boolean" becoming either "true/false" or "1/0") and does not >>>>>deal with things like schema-specified default values. >>>>> >>>>>Joe Reagle suggested I look at Schema Centric XML >>>>>Canonicalization >>>>>(http://uddi.org/pubs/SchemaCentricCanonicalization.htm). This >>>>>seems to handle all sorts of issues such as this, but I don't >>>>>feel qualified to evaluate it. Does anyone have expertise in >>>>>this area? Does anyone know how widely it has been implemented? >>>>> >>>>>Related question: do we actually need to deal with canonicalized >>>>>XACML schema instances? If the instances are always signed and >>>>>signature-verified in their unparsed text/octetstring form, then >>>>>there is no need for canonicalization. Canonicalization would >>>>>come into play if people will be taking parsed XACML schema >>>>>instances out of the SAML envelope and re-encoding them for >>>>>repackaging in some other envelope, while retaining the original >>>>>signature. Will this be happening? For example, will an XACML >>>>>Response be removed from its SAML DecisionStatement or SAML >>>>>Assertion and put into some other envelope for retransmission? >>>>> >>>>>Anne >>>> >>>>-- >>>>Frank Siebenlist franks@mcs.anl.gov >>>>The Globus Project - Argonne National Laboratory >>> >>> >>-- >>Frank Siebenlist franks@mcs.anl.gov >>The Globus Project - Argonne National Laboratory > > -- Frank Siebenlist franks@mcs.anl.gov The Globus Project - Argonne National Laboratory
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]