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.
This Working Draft 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, XML-Signature XPath Filter 2.0, and XML Security Generic Hybrid Ciphers. The normative description of the respective data formats are included in the Recommendation-track specifications.
These schemas are drafts and subject to further revisions. This is a work in progress. This document is intended to evolve to include additional RELAX NG schemas.
This version of this specification is significantly different from the previous version.
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".
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.
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 emtpy sequence of child
elements.
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.
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.
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.
Strict schemas provide stirct 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
Algorithm
attribute and an optional HMACOutputLength element is allowed,Algorithm
attribute and no child elements are allowed, or 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 defintion is NOT overshaddowed.
The value "http://www.w3.org/2000/09/xmldsig#sha1" continues
to be allowed for the Algorithm attribute.
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*
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 defintion of ds_DigestMethodType cotanins "- 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"
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.
This subsection provides a list of driver schemas and also provides a list of included schemas for each driver schema.