XML Digital Signature profile of XACML v2.0

OASIS Standard, 1 February 2005

Document identifier:

access_control-xacml-2.0-dsig-profile-spec-os

Location:

http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-dsig-profile-spec-os.pdf

Editor:

Anne Anderson, Sun Microsystems <anne.anderson@sun.com>

Abstract:

This specification profiles use of the W3C XML-Signature Syntax and Processing Standard in providing authentication and integrity protection for XACML schema instances.

Status:

This version of the specification is an approved OASIS Standard.

Access Control TC members should send comments on this specification to the xacml@lists.oasis-open.org list. Others should use the comment form at http://oasis-open.org/committees/comments/form.php?wg_abbrev=xacml.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Access Control TC web page (http://www.oasis-open.org/committees/xacml/ipr.php).

For any errata document for this specification, please refer to the Access Control TC web page (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml).

Copyright © OASIS Open 2004-2005 All Rights Reserved.

Table of Contents

1 Introduction (non-normative)	3

1.1 Terminology	3

2 XML Digital Signature profile of XACML	4

2.1 Use of SAML	4

2.2 Canonicalization	4

2.3 Signing schemas	5

3 References .	6

Appendix A. Acknowledgments	7

Appendix B. Notices	8

Introduction (non-normative)

This document provides a profile for use of the W3C XML-Signature Syntax and Processing Standard in providing authentication and integrity protection for OASIS eXtensible Access Control Markup Language [XACML] schema instances. Sections 9.2.1 Authentication and 9.2.4 Policy integrity in [XACML] describe requirements and considerations for such authentication and integrity protection.

A digital signature is useful for authentication and integrity protection only if the signed information includes a specification of the identity of the signer and a specification of the period during which the signed data object is to be considered valid. XACML itself does not define the format for such information, as XACML is intended to use other standards for functions other than the actual specification and evaluation of access control policies, requests, and responses.

One appropriate format that has been defined elsewhere is [SAML].. A profile for the use of SAML with XACML schema instances is available in [XACML-SAML]. This profile therefore RECOMMENDS use of XACML schema instances in SAML Assertions, Requests, and Responses, which MAY then be digitally signed as specified in the SAML specification.

This profile also notes various canonicalization issues that must be resolved in order for signed documents to be verified by a relying party.

This profile specification assumes that the reader is familiar with the concept of a digital signature, with the W3C XML-Signature Syntax and Processing Standard, and with XACML.

Terminology

(This section is not normative.)

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this profile are to be interpreted as described in [RFC2119].

data object – used in this profile to refer to a digital object that is being signed. A data object could be an XACML PolicySet, Policy, Request context, Response context, or any associated schemas. A data object is referenced inside an [XMLDSIG] <Reference> element using a URI as defined by [RFC2396].

XML Digital Signature profile of XACML

Use of SAML

(This section is normative)

This Profile RECOMMENDS use of XACML schema instances embedded in SAML Assertions, Requests, and Responses as described in [XACML-SAML]. Such SAML objects SHALL be digitally signed as described in Section 5: SAML and XML Signature Syntax and Processing of [SAML].

Canonicalization

In order for a digital signature to be verified by a relying party, the byte stream that was signed MUST be identical to the byte stream that is verified. To ensure this, the XML document being signed MUST be canonicalized. Section 5: SAML and XML Signature Syntax and Processing of [SAML] specifies use of Exclusive Canonicalization [ExclC14N].

2.2.1 Namespace elements in XACML data objects

Any XACML data object that is to be signed MUST specify all namespace elements used in the data object. If this is not done, then the data object will attract namespace definitions from ancestors of the data object that may differ from one envelope to another.

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

2.2.2 Additional canonicalization considerations

Additional transformations on the XACML data object must usually be performed in order to ensure that the data object signed will match the data object that is verified. Some of these transformations are listed here, but this Profile does not attempt to specify algorithms for performing these.

If an XACML data object includes data elements that may be represented in more than one form (such as (TRUE, FALSE), (1,0), (true,false)), then a Transform method MUST be defined and specified for normalizing those data elements.

This Profile RECOMMENDS applying the following canonicalizations to values of the corresponding datatypes, whether occurring in XML attribute values or in XACML Attributes.

Where a canonical representation for an XACML-defined datatype is defined in http://www.w3.org/2001/XMLSchema, then the value of the datatype MUST be put into the canonical form specified in http://www.w3.org/2001/XMLSchema. This includes boolean {“true”, “false”}, double, dateTime, time, date, and hexBinary (upper-case).

http://www.w3.org/2001/XMLSchema#anyURI - use the canonical form defined in [RFC2396]

http://www.w3.org/2001/XMLSchema#base64Binary - remove all line breaks and white space. Remove all characters following the first sequence of “=” characters. The Base64 Transform (identifier: http://www.w3.org/TR/xmldsig-core/#sec-Base-64 ) MAY be useful in performing this canonicalization.

urn:oasis:names:tc:xacml:1.0:data-type:x500Name - first normalize according to [RFC2253]. If any RDN contains multiple attributeTypeAndValue pairs, re-order the AttributeValuePairs in that RDN in ascending order when compared as octet strings (described in Section 11.6 “Set-of components” of [X.690]).

urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name - normalize the domain-part of the name to lower case.

XPath expression – apply [XPath2Filt] to put the XPath expression into canonical form.

Schema Centric XML Canonicalization Version 1.0 [ScC14N] describes many canonicalization issues for XML documents that should be addressed.

Signing schemas

The parsing of any XACML data object depends on having an accurate copy of all schemas on which the XACML data object depends. Note that the inclusion of a schema URI in the XACML schema instance attributes does not guarantee that an accurate copy of the schema will be used: an attacker may substitute a bogus schema that contains the correct identifier. Signatures can help protect against substitution or modification of the schemas on which an XACML data object depends. Use of signatures for this purpose are described in this section.

In most cases, a data object signer SHOULD include a <Reference> element for each schema on which the XACML data object depends in the <SignedInfo> element that contains the <Reference> to or including the XACML data object itself.

In some cases, the data object signer knows that all PDPs that will evaluate a given XACML data object will have accurate copies of certain schemas needed to parse the data object, and does not want to force the PDP to verify the message digest for such schemas. In these cases the data object signer MAY omit <Reference> elements for any schema whose verification is not needed.

References	.

[ExclC14N]	J. Boyer et al., Exclusive Canonicalization Version 1.0, 18 January 2002, World Wide Web Consortium, http://www.w3.org/TR/xml-exc-c14n/.

[RFC2119]	S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997, http://www.ietf.org/rfc/rfc2119.txt.

[RFC2253]	M. Wahl, et al., Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names, IETF RFC 2253, September 1997, http://www.ietf.org/rfc/rfc2253.txt.

[RFC2396]	T. Berners-Lee, et al., Uniform Resource Identifiers (URI): Generic Syntax, August 1998, http://ftp://ftp.isi.edu/in-notes/rfc2396.txt.

[SAML]	S. Cantor, et al., eds., Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML} V2.0, http://www.oasis-open.org/committees/documents.php?wg_abbrev=security.

[ScC14N]	S. Aissi, M. Hondo, eds., Schema Centric XML Canonicalization, Version 1.0, 20 May 2003, http://uddi.org/pubs/SchemaCentricCanonicalization.htm.

[XACML]	T. Moses, ed., OASIS eXtensible Access Control Markup Language (XACML) Version 2.0, OASIS Standard, 1 February 2005, http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf.

[XACML-SAML]	A. Anderson, H. Lockhart, eds., SAML 2.0 profile of XACML v2.0, OASIS Standard, 1 February 2005, http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-saml-profile-spec-os.pdf.

[XMLDSIG]	D. Eastlake, et al., W3C XML-Signature Syntax and Processing, W3C Recommendation, 12 February 2002, http://www.w3.org/TR/xmldsig-core.

[XPath2Filt]	J. Boyer, M. Hughes, J. Reagle, editors, XML-Signature XPath Filter 2.0, 8 November 2002 http://www.w3.org/TR/xmldsig-filter2/.

[X.690]	ITU-T Recommendation X.690 Information Technology – Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: General procedures, 1992.

Acknowledgments

The following individuals contributed to the development of the specification:

Anne Anderson

Anthony Nadalin

Bill Parducci

Daniel Engovatov

Don Flinn

Ed Coyne

Ernesto Damiani

Frank Siebenlist

Gerald Brose

Hal Lockhart

Haruyuki Kawabe

James MacLean

John Merrells

Ken Yagen

Konstantin Beznosov

Michiharu Kudo

Michael McIntosh

Pierangela Samarati

Pirasenna Velandai Thiyagarajan

Polar Humenn

Rebekah Metz

Ron Jacobson

Satoshi Hada

Sekhar Vajjhala

Seth Proctor

Simon Godik

Steve Anderson

Steve Crocker

Suresh Damodaran

Tim Moses

Von Welch

Notices

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

Copyright © OASIS Open 2004-2005. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

access_control-xacml-2.0-dsig-profile-spec-os	1 February 2005

Copyright © OASIS Open 2004-2005. All Rights Reserved.	Page 7 of 8

Eve L. Maler

2002-08-16T15:04:00

Anne Anderson