Abstract
This document serves to publish RELAX NG schemas for XML
Security specifications, including XML Signature 1.0 and 1.1, XML Encryption 1.0 and 1.1, Exclusive Canonicalization, XML
Signature Properties, XML-Signature XPath Filter 2.0, and XML Security Generic Hybrid Ciphers.
Status of This Document
This section describes the status of this document at the time of its publication. Other
documents may supersede this document. A list of current W3C publications and the latest revision
of this technical report can be found in the W3C technical reports
index at http://www.w3.org/TR/.
This W3C Working Group Note collects non-normative RELAX NG Schemas for XML
Security specifications, including XML Signature 1.0 and 1.1, XML Encryption
1.0 and 1.1, Exclusive Canonicalization, XML
Signature Properties, and XML-Signature XPath Filter 2.0. The
normative description of the respective data formats are
included in the Recommendation-track specifications. It also
includes RELAX NG Schemas for the informative material in the
XML Security Generic Hybrid Ciphers Note.
This version of this specification differs from the
the
previous
Working Group Note as follows (redline):
- Updated the xmldsig-properties-schema.rnc and rng files
linked from the specification to remove the definitions of the 'Created', 'Expires' and 'ReplayProtect' properties
which have been removed from the XML Signature Properties
specification and associated XSD schema.
- Updated the xmldsig11-schema.rnc and rng files linked from the
specification to remove the 'OCSPResponse' element which has
been removed from the XML Signature 1.1 specification and associated
XSD schema.
- Updated the status section and references.
This document was published by the XML Security Working Group as a Working Group Note.
If you wish to make comments regarding this document, please send them to
public-xmlsec@w3.org
(subscribe,
archives).
All comments are welcome.
Publication as a Working Group Note does not imply endorsement by the W3C Membership.
This is a draft document and may be updated, replaced or obsoleted by other documents at
any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the
5 February 2004 W3C Patent Policy.
W3C maintains a public list of any patent disclosures
made in connection with the deliverables of the group; that page also includes instructions for
disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains
Essential Claim(s) must disclose the
information in accordance with section
6 of the W3C Patent Policy.
1. Introduction
The XML Security specifications include normative XML
Schema [XMLSCHEMA-1], [XMLSCHEMA-2].
This note provides non-normative RELAX NG schemas in the compact syntax as well as the
XML syntax [RELAXNG-SCHEMA].
The biggest difference from the original XSD schemas is that these
RELAX NG schemas provide co-occurrence constraints between the
Algorithm attribute and child parameter elements. Thus, RELAX NG
validation can report an error when a DigestMethod element with
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" has an
HMACOutputLength element, which is allowed only when
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1".
2. Taxonomy of Schemas
2.1 Driver Schemas
Schemas in this group invoke other schemas, and further define the start
pattern and wildcard patterns. These driver schemas are written from
scratch.
A driver schema is required for each combination of strict,
lenient, and supplementary schemas (see below). This
note provides some driver schemas, but does not cover all possible
combinations. It is believed that driver schemas for other
combinations are easy to write.
Moreover, the driver schemas in this note allow signature or encryption elements anywhere
in the given XML document. When one wants to allow signature or encryption elements at a certain location only,
dedicated schemas are required.
2.2 Strict Schemas
Schemas in this group play the key role, and they are derived from the
original XSD schemas. Unlike the original XSD schemas, strict schemas
allow specific values of the Algorithm attribute and further specify
permissible child parameter elements for each of the values. For
example, a strict schema xmldsig-core-schema.rnc allows
"http://www.w3.org/2000/09/xmldsig#sha1" as the value of the Algorithm
attribute of the DigestMethod element and an empty sequence of child
elements.
2.3 Lenient Schemas
Schemas in this group complement strict schemas, and they are derived
mainly from xsd:any in the original XSD schemas. Lenient schemas are
expected to be used together with strict schemas.
Unlike strict schemas, lenient schemas allow any value for the
Algorithm attribute and allow any child parameter elements. For
example, xmldsig-allowAnyForeign.rnc allows any value for the
Algorithm attribute of the DigestMethod element and any child
parameter element. However, when the Algorithm attribute value is
explicitly specified in strict schemas, child parameter elements
continue to be tightly constrained.
2.4 Supplementary Schemas
Schemas in this group are derived from XSD schemas not constraining
the Algorithm attribute. These schemas are used together with strict
schemas. These schemas are intended to exactly capture the original
XSD schemas.
2.5 Common schemas
Schemas in this group define common patterns for RELAX NG. These
schemas are not derived from XSD schemas. There is one common schema,
namely security_any.rnc (security_any.rng). It defines
security_anyElement and security_anyAttribute, which allow any element
and attribute, respectively.
3. Schema Authoring Techniques
3.1 Strict Definitions
Strict schemas provide strict definitions of the Algorithm attribute
as well as permissible child elements. For example, a strict schema
xmldsig-core-schema.rnc has a definition shown below. It specifies
that "http://www.w3.org/2000/09/xmldsig#sha1" is allowed for the
Algorithm attribute and an empty sequence of child elements are
allowed. This definition is used for defining attributes and contents
of the DigestMethod element.
ds_DigestMethodType =
attribute Algorithm {
xsd:anyURI "http://www.w3.org/2000/09/xmldsig#sha1" }
Another definition (shown below) from the same schema specifies that either
- "http://www.w3.org/2000/09/xmldsig#hmac-sha1" is allowed for the
Algorithm
attribute and an optional HMACOutputLength element is allowed,
- "http://www.w3.org/2000/09/xmldsig#dsa-sha1" is allowed for the
Algorithm
attribute and no child elements are allowed, or
- "http://www.w3.org/2000/09/xmldsig#rsa-sha1" is allowed for the
Algorithm
attribute and no child elements are allowed.
Note that RELAX NG allow the use
of attribute definitions in the choice construct.
ds_SignatureMethodType =
(attribute Algorithm {
xsd:anyURI "http://www.w3.org/2000/09/xmldsig#hmac-sha1" },
element HMACOutputLength { ds_HMACOutputLengthType }?)
| attribute Algorithm {
xsd:anyURI "http://www.w3.org/2000/09/xmldsig#dsa-sha1" }
| attribute Algorithm {
xsd:anyURI "http://www.w3.org/2000/09/xmldsig#rsa-sha1" }
Furthermore, strict or supplementary schemas may extend definitions
provided by other strict schemas. This is done by the combine feature
of [RELAXNG-SCHEMA]. For example, another strict schema,
xmldsig11-schema.rnc, extends the definition ds_DigestMethodType in
xmldsig-core-schema.rnc.
ds_DigestMethodType |=
attribute Algorithm {
xsd:anyURI "http://www.w3.org/2001/04/xmlenc#sha256"
}
| attribute Algorithm {
xsd:anyURI "http://www.w3.org/2001/04/xmldsig-more#sha384"
}
| attribute Algorithm {
xsd:anyURI "http://www.w3.org/2001/04/xmlenc#sha512"
}
It specifies that "http://www.w3.org/2001/04/xmlenc#sha256",
"http://www.w3.org/2001/04/xmldsig-more#sha384", and
"http://www.w3.org/2001/04/xmlenc#sha512" are also allowed as
values of the Algorithm attribute.
Note that the original strict definition is NOT overshadowed.
The value "http://www.w3.org/2000/09/xmldsig#sha1" continues
to be allowed for the Algorithm attribute.
3.2 Lenient Definitions
Lenient schemas provide lenient definitions of the Algorithm attribute as well
as permissible child elements. For example,
xmldsig-allowAnyForeign.rnc has a definition shown below. It
specifies that any value except ds_DigestAlgorithms (see 3.1.3) is
allowed for the Algorithm attribute and a possibly-empty sequence of
foreign elements is allowed as the content. Again, note that
the combine feature of RELAX NG is used to combine strict
definitions and lenient definitions.
ds_DigestMethodType |=
attribute Algorithm { xsd:anyURI - ds_DigestAlgorithms },
ds_anyForeignElement*
3.3 Except Patterns
Lenient definitions do not allow any value except those explicitly allowed by strict
schemas. This is done by the except pattern of RELAX NG.
The above lenient definition of ds_DigestMethodType contains "-
ds_DigestAlgorithms". It is an except pattern, and allows any value
except those matching ds_DigestAlgorithms, which is defined by the
strict schema xmldsig-core-schema.rnc.
ds_DigestAlgorithms =
xsd:anyURI "http://www.w3.org/2000/09/xmldsig#sha1"
Since other strict schemas introduce other values for the Algorithm
attribute, they also extend such definitions for the except pattern.
For example, xmldsig11-schema.rnc, extends the above definition.
ds_DigestAlgorithms |=
xsd:anyURI "http://www.w3.org/2001/04/xmlenc#sha256"
| xsd:anyURI "http://www.w3.org/2001/04/xmldsig-more#sha384"
| xsd:anyURI "http://www.w3.org/2001/04/xmlenc#sha512"
3.4 Wildcard Patterns
Wildcard patterns, namely ds_anyForeignElement,
dsig11_anyForeignElement, xenc_anyForeignElement, and
xenc11_anyForeignElement, in driver schemas capture foreign elements. These wildcard
patterns are defined as elements not belonging to
any of the known namespaces.