Re: [xacml] canonicalization for XACML instances being signed

[Anne Anderson <Anne.Anderson@Sun.com>]

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.  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.

Anne

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.

-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692