[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Draft XACML Profile for use of XMLDSig. Forwarded message from Joseph Reagle.
Comments from Joseph Reagle on the XACML XML DSig Profile 0.2. I've sent him an e-mail thanking him for these - very helpful! -Anne ------- start of forwarded message ------- From: Joseph Reagle <reagle@w3.org> To: Anne.Anderson@sun.com, w3c-ietf-xmldsig@w3.org Subject: Re: Draft XACML Profile for use of XMLDSig Date: Mon, 31 Mar 2003 19:24:10 -0500 On Friday 28 March 2003 10:08, Anne Anderson wrote: >A copy of the draft profile is > attached. Hi Ann, comments on: http://lists.oasis-open.org/archives/xacml/200303/msg00063.html """verify - the process of checking the signature on a data object to verify that the signature and the data object are consistent.""" I'm not sure what this "verify" is speaking to. If it's XML Signature, then the approriate term is "validate" according to its definitions and RFC2828 ($ validate vs. verify) because XML Signatures have no semantics of the accuracy, truth, or trustworthiness of what it signs, only validaty, integrity and (sometimes) non-repudiation. http://www.ietf.org/rfc/rfc2828.txt http://www.w3.org/TR/xmldsig-core/#def-ValidationCore If your profile is adding semantics beyond xmldsig core validity, it's best to make this clear, or to even represent it explicitly. For example: http://www.w3.org/TR/xmldsig-p3p-profile/#sec-Semantics """If a Message Authentication Code (MAC) is being used, then first the canonicalization algorithm specified in the <CanonicalizationMethod>""" "then the first" is confusing because in the context of <CanonicalizationMethod> there is only *one*. """Since <Signature> elements are usually embedded in some protocol envelope, any <Signature> element MUST specify all namespace elements used in the <Signature> itself. If this is not done, then the <Signature> will attract namespace definitions from ancestors of the <Signature> that may differ from one envelope to another.""" I'm not sure what is meant by this. A local/nearby namaespace declaration will always trump a further remove declaration. If you want exclusive canonicalization, then use that algorithm, if you don't, then don't. I don't understand why this constraint is present and it may be difficult to implement. """When [ExclC14N] is used as the canonicalization or transform method, then the namespace of XACML schemas used by elements in an XACML data object MUST be bound to prefixes and included in the InclusiveNamespacesPrefixList parameter to [ExclC14N].""" I'm not sure I undestand this either, an example would probably help me. """Signatures for XACML data objects MUST use Exclusive Canonicalization Version 1.0 [ExclC14N] (identifiers: http://www.w3.org/2001/10/xml-exc- c14n# and http://www.w3.org/2001/10/xml-exc-c14n#WithComments) as the final canonicalization algorithm if possible. If this canonicalization algorithm can not be used, then Canonical XML Version 1.0 [InclC14N] (identifiers: http://www.w3.org/TR/2001/REC-xml-c14n-20010315 or http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments) MUST be used." The use of "MUST" in this section and elsewhere is confusing. If exc-C14N is a MUST, then there is no "can not be used", right? """[The XACML TC should specify a transform that puts all XACML-defined datatypes into their canonical form. This transform should include something like the following:""" Are you familiar with Schema Centric Canonicalization? That might provide some of the features you are looking for. http://www.uddi.org/pubs/SchemaCentricCanonicalization-20020710.htm ------- end of forwarded message ------- -- 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]