Re: [xacml] canonicalization for XACML instances being signed

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

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