Re: [xacml] canonicalization for XACML instances being signed

[Frank Siebenlist <franks@mcs.anl.gov>]

Hi Anne,

Anne Anderson wrote:

> XACML does not currently define semantics for delegation
> operations.  For example, it is possible to express the following
> two policies:
> 
>    Policy 1: entity A says entity B can assign rights Y and Z
>    Policy 2: entity B says entity C can have right Y
> 
> But there are no semantics defined for verifying that the linkage
> is correct.  

right, and I understood that for the delegation of rights as in an authorization 
  rule or decision,  but until David's email I didn't make the link to the 
delegation of attribute assertions... which is similar but may require a 
somewhat different processing (?).

> This is one of the big differences between a digital
> rights management language (which must use simple conditions in
> order to be able to define semantics for all linkages) and an
> access control language such as XACML (which can express complex
> conditions over multiple subjects and resources).
> 
> It would be easy to define an evaluation semantics for simple
> delegation such as that above, however.  We just haven't done it
> yet.


Easy is good ;-)

Regards, Frank.


> On 29 August, Frank Siebenlist writes: Re: [xacml] canonicalization for XACML instances being signed
>  > From: Frank Siebenlist <franks@mcs.anl.gov>
>  > To: "D.W.Chadwick" <D.W.Chadwick@salford.ac.uk>
>  > Subject: Re: [xacml] canonicalization for XACML instances being signed
>  > Date: Fri, 29 Aug 2003 17:22:01 -0700
>  > 
>  > 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 ?
>  > 
>  > 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
>  > 
>  > 
>  > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
> 

-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory