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 <>
To: , 
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: 
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311
Tel: 781/442-0928
Burlington, MA 01803-0902 USA
Fax: 781/442-1692