OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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]