index.html 49.4 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
<html lang="en" dir="ltr">
<head>
    <title>XML Signature Properties</title>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8">

<!--      <script src='../../../dap-dev/ReSpec.js/js/respec.js' -->
<!--              class='remove'></script> -->


  <style type="text/css">
/*****************************************************************
 * ReSpec CSS
 * Robin Berjon (robin at berjon dot com)
 * v0.05 - 2009-07-31
 *****************************************************************/


/* --- INLINES --- */
em.rfc2119 {
    text-transform:     lowercase;
    font-variant:       small-caps;
    font-style:         normal;
    color:              #900;
}

h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
    border: none;
}

dfn {
    font-weight:    bold;
}

a.internalDFN {
    color:  inherit;
    border-bottom:  medium solid #99c;
    text-decoration:    none;
}

a.externalDFN {
    color:  inherit;
    border-bottom:  medium dotted #ccc;
    text-decoration:    none;
}

a.bibref {
    text-decoration:    none;
}

code {
    color:  #ff4500;
}


/* --- WEB IDL --- */
pre.idl {
    border-top: 1px solid #90b8de;
    border-bottom: 1px solid #90b8de;
    padding:    1em;
    line-height:    120%;
}

pre.idl::before {
    content:    "WebIDL";
    display:    block;
    width:      150px;
    background: #90b8de;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

.idlType {
    color:  #ff4500;
    font-weight:    bold;
    text-decoration:    none;
}

/*.idlModule*/
/*.idlModuleID*/
/*.idlInterface*/
.idlInterfaceID {
    font-weight:    bold;
    color:  #005a9c;
}

.idlSuperclass {
    font-style: italic;
    color:  #005a9c;
}

/*.idlAttribute*/
.idlAttrType, .idlFieldType {
    color:  #005a9c;
}
.idlAttrName, .idlFieldName {
    color:  #ff4500;
}
.idlAttrName a, .idlFieldName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlMethod*/
.idlMethType {
    color:  #005a9c;
}
.idlMethName {
    color:  #ff4500;
}
.idlMethName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlParam*/
.idlParamType {
    color:  #005a9c;
}
.idlParamName {
    font-style: italic;
}

.extAttr {
    color:  #666;
}

/*.idlConst*/
.idlConstType {
    color:  #005a9c;
}
.idlConstName {
    color:  #ff4500;
}
.idlConstName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlException*/
.idlExceptionID {
    font-weight:    bold;
    color:  #c00;
}

.idlTypedefID, .idlTypedefType {
    color:  #005a9c;
}

.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
    color:  #c00;
    font-weight:    normal;
}

.excName a {
    font-family:    monospace;
}

.idlRaises a.idlType, .excName a.idlType {
    border-bottom:  1px dotted #c00;
}

.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
    width:  45px;
    text-align: center;
}
.excGetSetTrue, .prmNullTrue, .prmOptTrue { color:  #0c0; }
.excGetSetFalse, .prmNullFalse, .prmOptFalse { color:  #c00; }

.idlImplements a {
    font-weight:    bold;
}

dl.attributes, dl.methods, dl.constants, dl.fields {
    margin-left:    2em;
}

.attributes dt, .methods dt, .constants dt, .fields dt {
    font-weight:    normal;
}

.attributes dt code, .methods dt code, .constants dt code, .fields dt code {
    font-weight:    bold;
    color:  #000;
    font-family:    monospace;
}

.attributes dt code, .fields dt code {
    background:  #ffffd2;
}

.attributes dt .idlAttrType code, .fields dt .idlFieldType code {
    color:  #005a9c;
    background:  transparent;
    font-family:    inherit;
    font-weight:    normal;
    font-style: italic;
}

.methods dt code {
    background:  #d9e6f8;
}

.constants dt code {
    background:  #ddffd2;
}

.attributes dd, .methods dd, .constants dd, .fields dd {
    margin-bottom:  1em;
}

table.parameters, table.exceptions {
    border-spacing: 0;
    border-collapse:    collapse;
    margin: 0.5em 0;
    width:  100%;
}
table.parameters { border-bottom:  1px solid #90b8de; }
table.exceptions { border-bottom:  1px solid #deb890; }

.parameters th, .exceptions th {
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
    font-family:    initial;
    font-weight:    normal;
    text-shadow:    #666 1px 1px 0;
}
.parameters th { background: #90b8de; }
.exceptions th { background: #deb890; }

.parameters td, .exceptions td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
    vertical-align: top;
}

.parameters tr:first-child td, .exceptions tr:first-child td {
    border-top: none;
}

.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
    width:  100px;
}

.parameters td.prmType {
    width:  120px;
}

table.exceptions table {
    border-spacing: 0;
    border-collapse:    collapse;
    width:  100%;
}

/* --- TOC --- */
.toc a {
    text-decoration:    none;
}

a .secno {
    color:  #000;
}

/* --- TABLE --- */
table.simple {
    border-spacing: 0;
    border-collapse:    collapse;
    border-bottom:  3px solid #005a9c;
}

.simple th {
    background: #005a9c;
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
}

.simple th[scope="row"] {
    background: inherit;
    color:  inherit;
    border-top: 1px solid #ddd;
}

.simple td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
}

.simple tr:nth-child(even) {
    background: #f0f6ff;
}

/* --- DL --- */
.section dd > p:first-child {
    margin-top: 0;
}

.section dd > p:last-child {
    margin-bottom: 0;
}

.section dd {
    margin-bottom:  1em;
}

.section dl.attrs dd, .section dl.eldef dd {
    margin-bottom:  0;
}

/* --- EXAMPLES --- */
pre.example {
    border-top: 1px solid #ff4500;
    border-bottom: 1px solid #ff4500;
    padding:    1em;
    margin-top: 1em;
}

pre.example::before {
    content:    "Example";
    display:    block;
    width:      150px;
    background: #ff4500;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

/* --- EDITORIAL NOTES --- */
.issue {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #ffc;
}

.issue::before {
    content:    "Issue";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}

.note {
    margin: 1em 0em 0em;
    padding:    1em;
    border: 2px solid #cff6d9;
    background: #e2fff0;
}

.note::before {
    content:    "Note";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #cff6d9;
    background: #fff;
    padding:    3px 1em;
}

/* --- Best Practices --- */
div.practice {
    border: solid #bebebe 1px;
    margin: 2em 1em 1em 2em;
}

span.practicelab {
    margin: 1.5em 0.5em 1em 1em;
    font-weight: bold;
    font-style: italic;
}

span.practicelab   { background: #dfffff; }

span.practicelab {
    position: relative;
    padding: 0 0.5em;
    top: -1.5em;
}

p.practicedesc {
    margin: 1.5em 0.5em 1em 1em;
}

@media screen {
    p.practicedesc {
        position: relative;
        top: -2em;
        padding: 0;
        margin: 1.5em 0.5em -1em 1em;
}

/* --- SYNTAX HIGHLIGHTING --- */
pre.sh_sourceCode {
  background-color: white;
  color: black;
  font-style: normal;
  font-weight: normal;
}

pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; }           /* language keywords */
pre.sh_sourceCode .sh_type { color: #666; }                            /* basic types */
pre.sh_sourceCode .sh_usertype { color: teal; }                             /* user defined types */
pre.sh_sourceCode .sh_string { color: red; font-family: monospace; }        /* strings and chars */
pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; }     /* regular expressions */
pre.sh_sourceCode .sh_specialchar { color: 	#ffc0cb; font-family: monospace; }  /* e.g., \n, \t, \\ */
pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; }         /* comments */
pre.sh_sourceCode .sh_number { color: purple; }                             /* literal numbers */
pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; }       /* e.g., #include, import */
pre.sh_sourceCode .sh_symbol { color: blue; }                            /* e.g., *, + */
pre.sh_sourceCode .sh_function { color: black; font-weight: bold; }         /* function calls and declarations */
pre.sh_sourceCode .sh_cbracket { color: red; }                              /* block brackets (e.g., {, }) */
pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; }   /* TODO and FIXME */

/* Predefined variables and functions (for instance glsl) */
pre.sh_sourceCode .sh_predef_var { color: #00008B; }
pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }

/* for OOP */
pre.sh_sourceCode .sh_classname { color: teal; }

/* line numbers (not yet implemented) */
pre.sh_sourceCode .sh_linenum { display: none; }

/* Internet related */
pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }

/* for ChangeLog and Log files */
pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }

/* for Prolog, Perl... */
pre.sh_sourceCode .sh_variable { color: #006400; }

/* for LaTeX */
pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
pre.sh_sourceCode .sh_argument { color: #006400; }
pre.sh_sourceCode .sh_optionalargument { color: purple; }
pre.sh_sourceCode .sh_math { color: orange; }
pre.sh_sourceCode .sh_bibtex { color: blue; }

/* for diffs */
pre.sh_sourceCode .sh_oldfile { color: orange; }
pre.sh_sourceCode .sh_newfile { color: #006400; }
pre.sh_sourceCode .sh_difflines { color: blue; }

/* for css */
pre.sh_sourceCode .sh_selector { color: purple; }
pre.sh_sourceCode .sh_property { color: blue; }
pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }

/* other */
pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
pre.sh_sourceCode .sh_paren { color: red; }
pre.sh_sourceCode .sh_attribute { color: #006400; }

</style><link href="http://www.w3.org/StyleSheets/TR/W3C-CR" rel="stylesheet" type="text/css" charset="utf-8"></head><body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">XML Signature Properties</h1><h2 id="w3c-candidate-recommendation-03-march-2011">W3C Candidate Recommendation 03 March 2011</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2011/CR-xmldsig-properties-20110303/">http://www.w3.org/TR/2011/CR-xmldsig-properties-20110303/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/xmldsig-properties/">http://www.w3.org/TR/xmldsig-properties/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/">http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/</a></dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2010/WD-xmldsig-properties-20100204/">http://www.w3.org/TR/2010/WD-xmldsig-properties-20100204/</a></dd><dt>Editor:</dt><dd><span>Frederick Hirsch</span></dd>
</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
    <div id="abstract" class="introductory section"><h2>Abstract</h2>
      <p>This document outlines proposed standard XML Signature
      Properties syntax and processing rules and an associated
      namespace for these properties. The intent is these can be
      composed with any version of XML Signature using the XML
      SignatureProperties element. These properties are intended to
      meet code signing requirements.
      </p>
    </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
      <p>
  </p><p>There is no previous W3C Recommendation of XML Signature Properties.
  Please review <a href="Overview_diff.html">differences between the previous
  Working Draft
  and this Candidate Recommendation</a>.
  </p>
  <p> Changes since the previous Last Call include updated
  References, addition of a clarification for related work in response
  to a Last Call comment, a minor editorial wording correction and
  update to  example formatting.
</p>
  <p>The XML Security WG <a href="http://lists.w3.org/Archives/Public/public-xmlsec/2011Jan/att-0066/minutes-2011-01-18.html#item04">agreed
  at the 18 January 2011 teleconference</a> that the
  <code>Created</code>, <code>Expires</code>, and
  <code>ReplayProtect</code> properties are "at risk"  according to
  the W3C process.
This means that if two interoperable implementations are not available
  when the Working Group agrees to exit CR these features may be
  dropped from the specification without requiring an additional Last Call
  review.
      </p>
    <p>This document was published by the <a href="http://www.w3.org/2008/xmlsec/">XML Security Working Group</a> as a Candidate Recommendation. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to <a href="mailto:public-xmlsec@w3.org">public-xmlsec@w3.org</a> (<a href="mailto:public-xmlsec-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-xmlsec/">archives</a>). W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 01 June 2011. All feedback is welcome.</p><p>Publication as a Candidate Recommendation 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.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/42458/status" rel="disclosure">public list of any patent disclosures</a> 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 <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#sec-Introduction" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#sec-Editorial" class="tocxref"><span class="secno">2. </span>Editorial and Conformance Conventions</a></li><li class="tocline"><a href="#namespaces" class="tocxref"><span class="secno">3. </span>Versions, Namespaces and Identifiers</a></li><li class="tocline"><a href="#general" class="tocxref"><span class="secno">4. </span>Normative Material and Compliance</a><ul class="toc"><li class="tocline"><a href="#normative" class="tocxref"><span class="secno">4.1 </span>Normative Material</a></li><li class="tocline"><a href="#compliance" class="tocxref"><span class="secno">4.2 </span>Compliance</a></li></ul></li><li class="tocline"><a href="#scenarios" class="tocxref"><span class="secno">5. </span>Usage scenarios and Requirements</a><ul class="toc"><li class="tocline"><a href="#code-signing-scenarios" class="tocxref"><span class="secno">5.1 </span>Mobile Code Signing Scenario</a></li><li class="tocline"><a href="#code-signing-requirements" class="tocxref"><span class="secno">5.2 </span>Mobile Code Signing Requirements</a></li></ul></li><li class="tocline"><a href="#placement" class="tocxref"><span class="secno">6. </span>Signature Properties Placement</a></li><li class="tocline"><a href="#design" class="tocxref"><span class="secno">7. </span>Signature Properties</a><ul class="toc"><li class="tocline"><a href="#profile-property" class="tocxref"><span class="secno">7.1 </span>Profile Property</a><ul class="toc"><li class="tocline"><a href="#profile-property-generation" class="tocxref"><span class="secno">7.1.1 </span>Generation</a></li><li class="tocline"><a href="#profile-property-validation" class="tocxref"><span class="secno">7.1.2 </span>Validation</a></li></ul></li><li class="tocline"><a href="#role-property" class="tocxref"><span class="secno">7.2 </span>Role Property</a><ul class="toc"><li class="tocline"><a href="#role-property-generation" class="tocxref"><span class="secno">7.2.1 </span>Generation</a></li><li class="tocline"><a href="#role-property-validation" class="tocxref"><span class="secno">7.2.2 </span>Validation</a></li></ul></li><li class="tocline"><a href="#identifier-property" class="tocxref"><span class="secno">7.3 </span>Identifier Property</a><ul class="toc"><li class="tocline"><a href="#identifier-property-generation" class="tocxref"><span class="secno">7.3.1 </span>Generation</a></li><li class="tocline"><a href="#identifier-property-validation" class="tocxref"><span class="secno">7.3.2 </span>Validation</a></li></ul></li><li class="tocline"><a href="#created-property" class="tocxref"><span class="secno">7.4 </span>Created Property</a><ul class="toc"><li class="tocline"><a href="#created-property-generation" class="tocxref"><span class="secno">7.4.1 </span>Generation</a></li><li class="tocline"><a href="#created-property-validation" class="tocxref"><span class="secno">7.4.2 </span>Validation</a></li></ul></li><li class="tocline"><a href="#expires-property" class="tocxref"><span class="secno">7.5 </span>Expires Property</a><ul class="toc"><li class="tocline"><a href="#expires-property-generation" class="tocxref"><span class="secno">7.5.1 </span>Generation</a></li><li class="tocline"><a href="#expires-property-validation" class="tocxref"><span class="secno">7.5.2 </span>Validation</a></li></ul></li><li class="tocline"><a href="#replay-nonce-property" class="tocxref"><span class="secno">7.6 </span>ReplayProtect Property</a><ul class="toc"><li class="tocline"><a href="#replay-nonce-property-generation" class="tocxref"><span class="secno">7.6.1 </span>Generation</a></li><li class="tocline"><a href="#replay-nonce-property-validation" class="tocxref"><span class="secno">7.6.2 </span>Validation</a></li></ul></li></ul></li><li class="tocline"><a href="#schema" class="tocxref"><span class="secno">8. </span>Schema</a><ul class="toc"><li class="tocline"><a href="#xsdschema" class="tocxref"><span class="secno">8.1 </span>XSD Schema and Valid Example</a></li><li class="tocline"><a href="#rngschema" class="tocxref"><span class="secno">8.2 </span>RNG Schema</a></li></ul></li><li class="tocline"><a href="#thanks" class="tocxref"><span class="secno">9. </span>Acknowledgments</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">A. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">A.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">A.2 </span>Informative references</a></li></ul></li></ul></div>

    <div id="sec-Introduction" class="section">
      <!--OddPage--><h2><span class="secno">1. </span>Introduction</h2>
      <p>
	The SignatureProperties element defined by XML Signature
    [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-CORE1">XMLDSIG-CORE1</a></cite>]
	offers a means to associate property values with an XML
    Signature. This document defines
	specific properties that may be used by various applications of
    XML Signature, without
	requiring those applications to define such properties on a per
    case basis. This document
	defines how these properties are to be specified and processed
    when used but does not
	require their use - specifications that reference this document
    may or may not require their
	use.
      </p>
      <p>
	The properties defined in this document are not a breaking
    change to XML Signature, but
	warrant a new namespace for the properties themselves so that they
    can be used in various
	versions of XML Signature.
      </p>
<p>
The XAdES specification defines signature property formats for
advanced electronic signatures that remain valid over long periods,
are compliant with the European Directive and incorporate additional
useful information in common uses cases [<cite><a class="bibref" rel="biblioentry" href="#bib-XADES">XADES</a></cite>].</p>
    </div>

    <div id="sec-Editorial" class="section">
      <!--OddPage--><h2><span class="secno">2. </span>Editorial and Conformance Conventions</h2>
  <p>This specification provides a normative XML Schema
  [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-1">XMLSCHEMA-1</a></cite>], [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>]. The full normative grammar is
  defined by the XSD schema and the normative text in this
  specification. The standalone XSD schema file is authoritative in
  case there is any disagreement between it and the XSD schema
  portions in this specification. </p>

  <p>The key words "<em class="rfc2119" title="must">must</em>", "<em class="rfc2119" title="must not">must not</em>", "<em class="rfc2119" title="required">required</em>", "<em class="rfc2119" title="shall">shall</em>", "<em class="rfc2119" title="shall not">shall not</em>",
  "<em class="rfc2119" title="should">should</em>", "<em class="rfc2119" title="should not">should not</em>", "<em class="rfc2119" title="recommended">recommended</em>", "<em class="rfc2119" title="may">may</em>", and "<em class="rfc2119" title="optional">optional</em>" in this
  specification are to be interpreted as described in [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">RFC2119</a></cite>].</p>

  <blockquote>
    <p>"They <em class="rfc2119" title="must">must</em> only be used where it is actually required for interoperation
        or to limit behavior which has potential for causing harm (e.g., limiting
        retransmissions)"</p>
  </blockquote>
      <p>
        Consequently, these capitalized keywords are used to unambiguously
        specify requirements over protocol and application features and
        behavior that affect the interoperability and security of
        implementations. These key words are not used (capitalized) to
        describe XML grammar; schema definitions unambiguously describe such
        requirements. For instance, an XML attribute might be described as
        being "optional."
      </p>
    </div>

    <div id="namespaces" class="section">
      <!--OddPage--><h2><span class="secno">3. </span>Versions, Namespaces and Identifiers</h2>
      <p>No provision is made for an explicit version number in this syntax. If a future version is
      needed, it will use a different namespace. The XML namespace
      [<cite><a class="bibref" rel="biblioentry" href="#bib-XML-NAMES">XML-NAMES</a></cite>] URI that <em class="rfc2119" title="must">must</em> be used by
      implementations of this (dated) specification is:</p>
<pre class="xml-example">xmlns dsp="http://www.w3.org/2009/xmldsig-properties"</pre>
      <p>
	This namespace is also used as the prefix for identifiers defined by this
	specification. While applications <em class="rfc2119" title="must">must</em> support XML and XML namespaces, the use of internal
	entities [<cite><a class="bibref" rel="biblioentry" href="#bib-XML10">XML10</a></cite>] or our <code>dsp</code> XML namespace prefix
    and defaulting/scoping
	conventions are <em class="rfc2119" title="optional">optional</em>; use these facilities to provide compact
    and readable examples.
      </p>
      <p>
	This specification uses Uniform Resource Identifiers [<cite><a class="bibref" rel="biblioentry" href="#bib-URI">URI</a></cite>] to identify resources,
	algorithms, and semantics. The URI in the namespace declaration
    above is also used as a
	prefix for URIs under the control of this specification.
      </p>
      <p>
	This document does not change the namespace URI associated with XML Signature itself.
      </p>
    </div>
    <div id="general" class="section">
      <!--OddPage--><h2><span class="secno">4. </span>Normative Material and Compliance</h2>
      <div id="normative" class="section">
	<h3><span class="secno">4.1 </span>Normative Material</h3>
	<p>
	  All material in this document is Normative except for examples and
	sections marked as non-normative.</p>
      </div>
      <div id="compliance" class="section">
	<h3><span class="secno">4.2 </span>Compliance</h3>
	<p>
	  Use of any or all of these Signature Properties in an XML Signature is
<em class="rfc2119" title="optional">optional</em> and nothing precludes the use of additional properties
	  defined elsewhere.
	</p>
	<p>
	  <dfn id="dfn-common-signature-properties">Common
	  Signature Properties</dfn> are properties defined in this
	  specification and identified by
	  the namespace defined in this document.
	  </p>
      <p>
        The full normative grammar is defined by the XSD schema and
        the normative text in this specification. The standalone XSD
        schema file is authoritative in case there is any disagreement
        between it and the XSD schema portions in this specification.
      </p>
      </div>
      </div>

    <div id="scenarios" class="informative section">
      <!--OddPage--><h2><span class="secno">5. </span>Usage scenarios and Requirements</h2><p><em>This section is non-normative.</em></p>
      <div id="code-signing-scenarios" class="section">
        <h3><span class="secno">5.1 </span>Mobile Code Signing Scenario</h3>
	<p>A developer (author) produces code that is delivered to users
    by a distributor (mobile
	operator). The code package contains an XML Signature and this
    should be validated upon code
	installation to provide integrity for the package. The signature
    delivered with the package
	from the distributor may change upon later installations for
    various reasons, such as the
	inclusion of more timely revocation information, so signatures
    should have an
	expiration. One goal is not to depend an X509 certificate
    expiration for this functionality,
	since that certificate may have a longer lifetime.
	</p>
	<p>This case can introduce requirements for an expiration of a
    signature as well as
	identifying the role of a signer (developer or distributor), as
    well as a possible profile
	of the general signature standard for that specific use case (such
    as restricting algorithms
	etc).
	</p>
      </div>
      <div id="code-signing-requirements" class="section">
	<h3><span class="secno">5.2 </span>Mobile Code Signing Requirements</h3>
	<p>
	  There are specific requirements associated with this use case:
	</p>
	<ol>
	  <li><p>Specify any additional constraints on the use of XML Signature, referencing an
	  appropriate profile by URI. This might limit algorithms, for example.</p></li>
	  <li><p>Define an expiration with a signature, enabling a validator to determine that the
	  signature should no longer validate after a given time.  </p></li>
	  <li><p>State the role of the signature creator, e.g. author, distributor etc.</p></li>
	</ol>
      </div>
      </div>
<div id="placement" class="section">
      <!--OddPage--><h2><span class="secno">6. </span>Signature Properties Placement</h2>
      <p>
The Signature Properties defined in this specification are intended to
be used with XML Signature [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLDSIG-CORE1">XMLDSIG-CORE1</a></cite>].
      </p><p>
  When a Signature Property element defined by this specification is
used within an XML Signature it <em class="rfc2119" title="must">must</em>
 be contained within a
<code>ds:SignatureProperty</code> element.
      </p><p>
  This <code>ds:SignatureProperty</code> element <em class="rfc2119" title="must">must</em> be contained within a
<code>ds:SignatureProperties</code> element.
      </p><p>
  The <code>ds:SignatureProperties</code> element <em class="rfc2119" title="must">must</em> be contained within a
<code>ds:Object</code> element within the <code>ds:Signature</code> element.
      </p>
    </div>
    <div id="design" class="section">
      <!--OddPage--><h2><span class="secno">7. </span>Signature Properties</h2>
      <p>
	This section includes schema definitions and processing
	rules for <a title="Common Signature Properties" href="#dfn-common-signature-properties" class="internalDFN"> Common Signature
	Properties</a>.
      </p>

      <p>
	This section defines a number of signature properties that are expected to be commonly used
	in profiles.  For each property, an intended processing model is suggested.  However, the
	details of processing each of these properties will depend upon
    individual application
	scenarios, and <em class="rfc2119" title="must">must</em> be specified in any profile that makes use of
    the properties defined in
	this document.
      </p>

    <div id="profile-property" class="section">
      <h3><span class="secno">7.1 </span>Profile Property</h3>
      <p>
	The Profile Property specifies a URI to be associated with the Signature instance to
	identify a Profile specification that details how the XML Signature is to be used. This
	profile may restrict the choice of algorithms, for example, as
    well as requiring certain
	<a title="Common Signature Properties" href="#dfn-common-signature-properties" class="internalDFN">Common Signature
	Properties</a> and/or other
	properties in the signature.
      </p>
      <p>The element has no content, but specifies a URI attribute that is
      required.</p>
<pre class="xml-example">&lt;element name="Profile" type="dsp:ProfileType"/&gt;
&lt;complexType name="ProfileType"&gt;
 &lt;attribute name="URI" type="anyURI"/&gt;
&lt;/complexType&gt;
</pre>
      <div id="profile-property-generation" class="section">
	<h4><span class="secno">7.1.1 </span>Generation</h4>
	<p>Upon Signature generation, if this property is used, the URI
    attribute value <em class="rfc2119" title="must">must</em>  be set
	to a value that can be understood by the relying party.
      </p>
      </div>

      <div id="profile-property-validation" class="section">
	<h4><span class="secno">7.1.2 </span>Validation</h4>
	<p>
	  Applications are expected to use this property to verify an assertion that a signature is
	  meant to fulfill a specific profile.  Validation behavior is application-specific.
	</p>
	<p>
	  Profiles <em class="rfc2119" title="must">must</em> specify what application behavior is expected in
      case an unknown profile URI
	  is encountered.
	</p>
	<p>
	  Profiles <em class="rfc2119" title="must">must</em> specify whether profile URIs defined by them can
      coexist with other
	  instances of the profile property element.
	</p>
      </div>
      </div>

    <div id="role-property" class="section">
      <h3><span class="secno">7.2 </span>Role Property</h3>
      <p>
	The Role Property allows a URI to be associated with the signature
    to specify an application
	specific role for the signature, implying application specific
    processing steps
    related to the signature.
      </p>
      <p>
	An example might be to indicate that the signer of code is the
    author or the distributor of that code.
      </p>
	<p>The element has no content, but specifies a URI attribute that
    is required.</p>
<pre class="xml-example">&lt;element name="Role" type="dsp:RoleType"/&gt;

&lt;complexType name="RoleType"&gt;
 &lt;attribute name="URI" type="anyURI"/&gt;
&lt;/complexType&gt;
</pre>

	<div id="role-property-generation" class="section">
	  <h4><span class="secno">7.2.1 </span>Generation</h4>
	  <p>
	    Upon Signature generation, if this property is used, the URI
        attribute value <em class="rfc2119" title="must">must</em> be
	    set to a value that can be understood by the relying party.
	  </p>
	</div>

	<div id="role-property-validation" class="section">
	  <h4><span class="secno">7.2.2 </span>Validation</h4>
	  <p>
	    Applications are expected to use this property to identify a
        specific role for a signature (e.g., author or distributor
        signed).  An unexpected role URI will
	    frequently be reason for applications to deem a signature
        invalid.
        Profiles <em class="rfc2119" title="must">must</em> specify what application behavior is
        expected in case an unknown
	    role URI is encountered, or when several role properties
        exist on a single signature.
	  </p>
	</div>
	</div>

<div id="identifier-property" class="section">
      <h3><span class="secno">7.3 </span>Identifier Property</h3>
      <p>
	The Identifier Property is intended to
	enable use cases where a unique identifier needs to be associated
    with the signature, such as to enable signature management.
      </p>
<pre class="xml-example">&lt;element name="Identifier" type="string"/&gt;
</pre>
      <p>
Identifier string values <em class="rfc2119" title="must">must</em> be unique for each signature from a
given signer and <em class="rfc2119" title="should">should</em>
be unique across all signers.
      </p>

      <div id="identifier-property-generation" class="section">
	<h4><span class="secno">7.3.1 </span>Generation</h4>
	<p>Upon Signature generation, if this property is used, the value
is set to a unique value to be associated with the signature for a
particular signer.
 </p>
      </div>

      <div id="identifier-property-validation" class="section">
	<h4><span class="secno">7.3.2 </span>Validation</h4>
	<p>
	  Applications are expected to use this property to identify the
      signature.
	</p>
	<p>
	  Profiles <em class="rfc2119" title="must">must</em> specify details of the identifier property value
      creation and interpretation.
	</p>
	<p>
      If multiple instances of this property are found on a
      single signature, then
	  applications <em class="rfc2119" title="must not">must not</em> deem any of these properties valid.
	</p>
      </div>
      </div>

    <div id="created-property" class="section">
      <h3><span class="secno">7.4 </span>Created Property</h3>
      <p>
	The Created Property is intended to
	enable use cases where the time of signature creation needs to be recorded.
      </p>
<pre class="xml-example">&lt;element name="Created" type="dateTime"/&gt;
</pre>
      <p>
	Creation times <em class="rfc2119" title="must">must</em> be given as <em>timezoned</em>
    values. (See <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime">section
	3.2.7</a> of [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>].)
    This property <em class="rfc2119" title="must not">must not</em>
	occur more than once for a given signature.
      </p>

      <div id="created-property-generation" class="section">
	<h4><span class="secno">7.4.1 </span>Generation</h4>
	<p>Upon Signature generation, if this property is used, the time
    value is set to a reference
	time, as defined by the application.  The value of the time does
    not need to be from a
	trusted timestamp authority. The time value needs only be accurate
    enough for comparison,
	as required by the application usage.  The time <em class="rfc2119" title="should">should</em> reflect the
    time that signature generation completes.
    </p>
      </div>

      <div id="created-property-validation" class="section">
	<h4><span class="secno">7.4.2 </span>Validation</h4>
	<p>
	  Applications are expected to use this property to identify the
      creation date of a signature.
	  Evaluation of this property is with respect to an application
      defined reference time
	  (possibly wall clock time, possibly a time that is determined
      otherwise).
	</p>
	<p>
	  Profiles <em class="rfc2119" title="must">must</em> specify what reference time should be used when
      interpreting this property.
	</p>
	<p>
	  A Created property with an <em>untimezoned</em> time value
      <em class="rfc2119" title="must not">must not</em> be considered
	  valid.  If multiple instances of this property are found on a
      single signature, then
	  applications <em class="rfc2119" title="must not">must not</em> deem any of these properties valid.
	</p>
      </div>
      </div>

    <div id="expires-property" class="section">
      <h3><span class="secno">7.5 </span>Expires Property</h3>
      <p>
	The Expires Property is intended to
	enable use cases where the signature is intended to expire.
      </p>
<pre class="xml-example">&lt;element name="Expires" type="dateTime"/&gt;
</pre>
      <p>
	Expiration times <em class="rfc2119" title="must">must</em> be given as <em>timezoned</em> values. (See <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dateTime">section
	3.2.7</a> of [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>].)
    This property <em class="rfc2119" title="must not">must not</em>
	occur more than once for a given signature.
      </p>

      <div id="expires-property-generation" class="section">
	<h4><span class="secno">7.5.1 </span>Generation</h4>
	<p>Upon Signature generation, if this property is used, the time
    value is set to a reference
	time, as defined by the application.  The value of the time does not need to be from a
	trusted timestamp authority. The time value needs only be accurate enough for comparison,
	as required by the application usage.  </p>
      </div>

      <div id="expires-property-validation" class="section">
	<h4><span class="secno">7.5.2 </span>Validation</h4>
	<p>
	  Applications are expected to use this property to identify the expiry date of a signature.
	  Evaluation of this property is with respect to an application defined reference time
	  (possibly wall clock time, possibly a time that is determined otherwise).  A property
	  value that is later than the reference time will typically be reason for applications to
	  deem a signature invalid with respect to the reference time.
	</p>
	<p>
	  Profiles <em class="rfc2119" title="must">must</em> specify what reference time should be used when
      interpreting this property.
	</p>
	<p>
	  An expiry property with an <em>untimezoned</em> time value <em class="rfc2119" title="must not">must not</em> be considered
	  valid.  If multiple instances of this property are found on a single signature, then
	  applications <em class="rfc2119" title="must not">must not</em> deem any of these properties valid.
	</p>
      </div>
      </div>

    <div id="replay-nonce-property" class="section">
      <h3><span class="secno">7.6 </span>ReplayProtect Property</h3>
      <p>
	To prevent against inappropriate reuse of the signature after its intended use, a replay
	nonce may be provided. This is a random value that should not be repeated, allowing the
	verifier to determine that the signature has already been seen. In order to avoid the need
	to retain nonce values indefinitely, a timestamp is included, indicating that all signatures
	before that time should be ignored.
      </p>
      <p>
	This property may be used in applications where the signature is used
	to secure a message or other applications where it should not be
	reused.
      </p>
<pre class="xml-example">&lt;element name="ReplayProtect" type="dsp:ReplayProtectType"/&gt;

&lt;complexType name="ReplayProtectType" &gt;
  &lt;sequence&gt;
    &lt;element name="timestamp" type="dateTime"/&gt;
    &lt;element name="nonce" type="dsp:NonceValueType"/&gt;
  &lt;/sequence&gt;
&lt;/complexType&gt;

&lt;complexType name="NonceValueType" &gt;
  &lt;extension base="string"&gt;
    &lt;attribute name="EncodingType" type="anyURI"/&gt;
  &lt;/extension&gt;
&lt;/complexType&gt;
</pre>

      <p>
	Timestamp values <em class="rfc2119" title="must">must</em> be timezoned.
      </p>

      <div id="replay-nonce-property-generation" class="section">
	<h4><span class="secno">7.6.1 </span>Generation</h4>

	<p>
	  Upon Signature generation, if this property is used, the nonce value <em class="rfc2119" title="must">must</em> be set to a
	  previously unused random value and the timestamp <em class="rfc2119" title="must">must</em> be set to a time before which the
	  signature is determined to no longer be valid (and for which nonces need not be
	  maintained).
	</p>
      </div>

      <div id="replay-nonce-property-validation" class="section">
	<h4><span class="secno">7.6.2 </span>Validation</h4>

	<p>
	  If timestamp values are untimezoned, validation fails.
	</p>
	<p>
	  Validation succeeds when the relying party is able to determine that the nonce in the
	  property has not been seen before and the current time is after the timestamp recorded in
	  the ReplayProtect property. Otherwise validation fails.
	</p>
	<p>
	  Behavior of applications when an invalid property is encountered is application-specific.
	</p>
      </div>
    </div>
    </div>
  <div id="schema" class="section">
    <!--OddPage--><h2><span class="secno">8. </span>Schema</h2>
  <div id="xsdschema" class="section">
      <h3><span class="secno">8.1 </span>XSD Schema and Valid Example</h3>
<dl>
<dt>Signature Properties XSD Schema Instance</dt>
<dd>
<a href="xmldsig-properties-schema.xsd">xmldsig-properties-schema.xsd</a>
<p>Valid XML Schema instance based on the XML Schema
[<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-1">XMLSCHEMA-1</a></cite>], [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSCHEMA-2">XMLSCHEMA-2</a></cite>].</p>
</dd>
<dt>Signature Properties 1.1 Schema Driver</dt>
<dd>
<a href="xmldsig1-properties-schema.xsd">xmldsig1-properties-schema.xsd</a>
<p>This schema instance binds together the XML Signature Core XML Schema
instance, the XML Signature 1.1 XML Schema instance and the XML Signature
Properties XML Schema instance.</p>
</dd>
          <dt>XML Security Signature Properties Example</dt>
          <dd>
            <a href="sp-example.xml">sp-example.xml</a>
            <p>A cryptographically fabricated XML Signature Properties
            example that validates
            under the schema.</p>
          </dd>
</dl>
  </div>
  <div id="rngschema" class="informative section">
    <h3><span class="secno">8.2 </span>RNG Schema</h3><p><em>This section is non-normative.</em></p>
Non-normative RELAX NG schema [<cite><a class="bibref" rel="biblioentry" href="#bib-RELAXNG-SCHEMA">RELAXNG-SCHEMA</a></cite>] information is
  available in a separate document [<cite><a class="bibref" rel="biblioentry" href="#bib-XMLSEC-RELAXNG">XMLSEC-RELAXNG</a></cite>].
</div>
  </div>
  <div id="thanks" class="section">
    <!--OddPage--><h2><span class="secno">9. </span>Acknowledgments</h2>
    <p>
The Working Group thanks Mark Priestley, Vodafone, and Marcos Caceres,
Opera Software, of
the W3C Web Applications Working Group for requirements discussions
related to widget signing, and thanks Makoto Murata for assistance with the
  RELAX NG schema.
    </p>
 <p> Contributions received from the members of the XML Security Working
      Group: Scott Cantor, Juan Carlos Cruellas, Pratik Datta, Gerald Edgar,
      Ken Graf, Phillip Hallam-Baker, Brad Hill, Frederick Hirsch, Brian LaMacchia, Konrad Lanz, Hal Lockhart, Cynthia Martin, Rob
      Miller, Sean Mullan, Shivaram Mysore, Magnus Nyström, Bruce Rich, Thomas
      Roessler, Ed Simon, Chris Solc, John Wray,
      Kelvin Yiu. </p>

  </div>


<div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">A. </span>References</h2><p>Dated references below are to the latest known or appropriate edition of the referenced work.  The referenced works may be subject to revision, and conformant implementations may follow, and are encouraged to investigate the appropriateness of following, some or all more recent editions or replacements of the works cited. It is in each case implementation-defined which  editions are supported.</p><div id="normative-references" class="section"><h3><span class="secno">A.1 </span>Normative references</h3><dl class="bibliography"><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119.  URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>
</dd><dt id="bib-URI">[URI]</dt><dd>T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifiers (URI): generic syntax.</cite></a> January 2005. Internet RFC 3986. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
</dd><dt id="bib-XML-NAMES">[XML-NAMES]</dt><dd>Richard Tobin; et al. <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/"><cite>Namespaces in XML 1.0 (Third Edition).</cite></a> 8 December 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-xml-names-20091208/">http://www.w3.org/TR/2009/REC-xml-names-20091208/</a>
</dd><dt id="bib-XMLDSIG-CORE1">[XMLDSIG-CORE1]</dt><dd>D. Eastlake, J. Reagle, D. Solo, F. Hirsch, T. Roessler, K. Yiu. <a href="http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/"><cite>XML Signature Syntax and Processing Version 1.1.</cite></a> 3 March 2011. W3C Candidate Recommendation. (Work in progress.) URL: <a href="http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/">http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/</a>
</dd><dt id="bib-XMLSCHEMA-1">[XMLSCHEMA-1]</dt><dd>Henry S. Thompson; et al. <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/"><cite>XML Schema Part 1: Structures Second Edition.</cite></a> 28 October 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/">http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/</a>
</dd><dt id="bib-XMLSCHEMA-2">[XMLSCHEMA-2]</dt><dd>Paul V. Biron; Ashok Malhotra. <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>XML Schema Part 2: Datatypes Second Edition.</cite></a> 28 October 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/">http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/</a>
</dd></dl></div><div id="informative-references" class="section"><h3><span class="secno">A.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-RELAXNG-SCHEMA">[RELAXNG-SCHEMA]</dt><dd><a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip"><cite>Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG</cite></a>. ISO/IEC 19757-2:2008. URI: <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip">http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip</a>
</dd><dt id="bib-XADES">[XADES]</dt><dd><a href="http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.01_60/ts_101903v010401p.pdf"><cite>XML Advanced Electronic Signatures (XAdES)</cite></a>.  ETSI TS 101 903 V1.4.1 (2009-06) URL: <a href="http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.01_60/ts_101903v010401p.pdf">http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.01_60/ts_101903v010401p.pdf</a>
</dd><dt id="bib-XML10">[XML10]</dt><dd>C. M. Sperberg-McQueen; et al. <a href="http://www.w3.org/TR/2008/REC-xml-20081126/"><cite>Extensible Markup Language (XML) 1.0 (Fifth Edition).</cite></a> 26 November 2008. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2008/REC-xml-20081126/">http://www.w3.org/TR/2008/REC-xml-20081126/</a>
</dd><dt id="bib-XMLSEC-RELAXNG">[XMLSEC-RELAXNG]</dt><dd>Makoto Murata, Frederick Hirsch. <a href="http://www.w3.org/TR/2011/WD-xmlsec-rngschema-20110303/"><cite>XML Security RELAX NG Schemas.</cite></a> 3 March 2011. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/2011/WD-xmlsec-rngschema-20110303/">http://www.w3.org/TR/2011/WD-xmlsec-rngschema-20110303/</a>
</dd></dl></div></div></body></html>