W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2003

Re: Draft XACML Profile for use of XMLDSig

From: Joseph Reagle <reagle@w3.org>
Date: Mon, 31 Mar 2003 19:24:10 -0500
To: Anne.Anderson@Sun.com, w3c-ietf-xmldsig@w3.org
Cc: XACML TC <xacml@lists.oasis-open.org>
Message-Id: <200303311924.10618.reagle@w3.org>

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
Received on Monday, 31 March 2003 19:24:14 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:16 GMT