[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] canonicalization for XACML instances being signed
My model for X.509 AC delegation has been that there would be a separate X.509 AC for each credential that can be delegated. I don't see any reason why they all have to be in one, except where a group of credentials will all be delegated at once. Anne On 29 August, D.W.Chadwick writes: Re: [xacml] canonicalization for XACML instances being signed > From: "D.W.Chadwick" <D.W.Chadwick@salford.ac.uk> > To: "Frank Siebenlist" <franks@mcs.anl.gov> > Subject: Re: [xacml] canonicalization for XACML instances being signed > Date: 29 Aug 2003 21:48:56 +0100 > > 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 > > -- > ********************************************************* > > Leaders of the world's richest nations meet in Cancun on September 10th > 2003. Oxfam is presenting them with a petition to make trade fair. Be > sure your voice is heard. Sign the 'Big Noise' petition to make trade > fair at: > > http://www.maketradefair.com/go/join/?p=omf1 > > > ***************************************************************** > > David W. Chadwick, BSc PhD > Professor of Information Systems Security > IS Institute, University of Salford, Salford M5 4WT > Tel: +44 161 295 5351 Fax +44 01484 532930 > Mobile: +44 77 96 44 7184 > Email: D.W.Chadwick@salford.ac.uk > Home Page: http://www.salford.ac.uk/its024/chadwick.htm > Research Web site: http://sec.isi.salford.ac.uk > Seminars: http://www.salford.ac.uk/its024/seminars.htm > Entrust key validation string: MLJ9-DU5T-HV8J > PGP Key ID is 0xBC238DE5 > > *****************************************************************begin:vcard > n:Chadwick;David > tel;cell:+44 77 96 44 7184 > tel;fax:+44 1484 532930 > tel;home:+44 1484 352238 > tel;work:+44 161 295 5351 > x-mozilla-html:FALSE > url:http://www.salford.ac.uk/its024/chadwick.htm > org:University of Salford;IS Institute > version:2.1 > email;internet:d.w.chadwick@salford.ac.uk > title:Professor of Information Security > adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England > note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5 > x-mozilla-cpt:;-4856 > fn:David Chadwick > end:vcard -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]