<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="docml.xsl"?>
<docml:document id="xmldoc_xsigncml" title="Chemical Markup, XML and the World-Wide Web. Part III: Towards a  Signed  Semantic Chemical Web of Trust." xmlns="http://www.w3.org/1999/xhtml" xmlns:chimeral="x-schema:http://www.xml-cml.org/spectrum_schema_ie_01.xml" xmlns:docml="x-schema:http://www.xml-cml.org/docml_schema_02.xml" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">

<!-- ************************** -->
<!-- ** enveloped signature *** -->
<!-- ************************** -->
<dsig:Signature>
	<dsig:SignedInfo>
		<dsig:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20001011"/>
		<dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
		<dsig:Reference URI="">
			<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
			<dsig:DigestValue>P8D/IjPgmPMC5A3rtgaN22dvw2U=</dsig:DigestValue>
		</dsig:Reference>
	</dsig:SignedInfo>
	<dsig:SignatureValue>
    iOCu+eMmhcWorNl014LOT94duywUY6/iRhXQXoEhqCPEzvn6Kd2M3HyQuJ//sJiGg7KpF7TI
    Q3NocPyV8lgsWuZwxopARiHSffNHxN8PrB/cMBJkASExcllBk9sKGcDjvYoQ1FCVtaFVOpV7
    0LINBhAm09zVx9TxxqRPWEBE9lY=
  </dsig:SignatureValue>
  <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    <KeyValue>
      <RSAKeyValue>
        <Modulus>
          y/gFMIdUnK4/WTFlAPjtQbOBGEFrwhpB9R10KrxAiAsteuQ70hG++ReLedY6hE3Tru
          yRLACVqe1vZPNM2G3ySyGkm2ZTjDEryk/QjqikHXko41WtJmhtrIxnnnjlLcM24Yre
          WO3wt3lI19Te5WINZiaojvzAAdEcXjIy+IeU6Gs=
        </Modulus>
        <Exponent>AQAB</Exponent>
      </RSAKeyValue>
    </KeyValue>
    <X509Data>
      <X509SubjectName>CN=XML-CML, OU=http://www.xml-cml.org/, O=n/a, L=London, ST=n/a, C=UK</X509SubjectName>
      <X509Certificate>
MIICTjCCAbcCBDo0y2cwDQYJKoZIhvcNAQEEBQAwbjELMAkGA1UEBhMCVUsxDDAKBgNVBAgTA24v
YTEPMA0GA1UEBxMGTG9uZG9uMQwwCgYDVQQKEwNuL2ExIDAeBgNVBAsTF2h0dHA6Ly93d3cueG1s
LWNtbC5vcmcvMRAwDgYDVQQDEwdYTUwtQ01MMB4XDTAwMTIxMTEyNDExMVoXDTAxMDMxMTEyNDEx
MVowbjELMAkGA1UEBhMCVUsxDDAKBgNVBAgTA24vYTEPMA0GA1UEBxMGTG9uZG9uMQwwCgYDVQQK
EwNuL2ExIDAeBgNVBAsTF2h0dHA6Ly93d3cueG1sLWNtbC5vcmcvMRAwDgYDVQQDEwdYTUwtQ01M
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDL+AUwh1Scrj9ZMWUA+O1Bs4EYQWvCGkH1HXQq
vECICy165DvSEb75F4t51jqETdOu7JEsAJWp7W9k80zYbfJLIaSbZlOMMSvKT9COqKQdeSjjVa0m
aG2sjGeeeOUtwzbhit5Y7fC3eUjX1N7lYg1mJqiO/MAB0RxeMjL4h5ToawIDAQABMA0GCSqGSIb3
DQEBBAUAA4GBABYyetfClkvB4CL214PSnoti+sdQK2cgPAb0UQeNkd9MQ4vUcr5JKyAUgbL9skOB
JuyenInmqQU7HUhyIgmDEnMi7DYx2Psc82RaRZlyaeRF7BqQB9mMtAWL/5H935GE48Pf6g9b9Z3q
9qh9rwwM2spqL6MCHjEEBJZYjPJ2MERv
      </X509Certificate>
    </X509Data>
  </KeyInfo>
</dsig:Signature>

<!-- ******************************************************** -->
<!-- *********************** metadata *********************** -->
<!-- ******************************************************** -->
<docml:metadata>
<docml:date type="creation">
<docml:day>29</docml:day><docml:month>11</docml:month><docml:year>2000</docml:year></docml:date>
<docml:list type="authors">
	<docml:author email="g.gkoutos@ic.ac.uk" id="author_gg" idref="insti_ic"><docml:name type="first">Georgios V.</docml:name><docml:name type="family">Gkoutos</docml:name></docml:author>
	<docml:author email="Peter.Murray-rust@nottingham.ac.uk" id="author_pmr" idref="insti_not"><docml:name type="first">Peter</docml:name><docml:name type="family">Murray-Rust</docml:name></docml:author>
	<docml:author email="h.rzepa@ic.ac.uk" href="http://www.ch.ic.ac.uk/rzepa/" id="author_hr" idref="insti_ic"><docml:name type="first">Henry S.</docml:name><docml:name type="family">Rzepa</docml:name></docml:author>
	<docml:author email="karne@innocent.com" href="http://www.ch.ic.ac.uk/chimeral" id="author_mw" idref="insti_ic"><docml:name type="first">Michael</docml:name><docml:name type="family">Wright</docml:name></docml:author>
</docml:list>
<docml:list type="institution">
	<docml:institution href="http://www.ch.ic.ac.uk" id="insti_ic">Department of Chemistry, Imperial College of Science, Technology and Medicine, UK</docml:institution>
	<docml:institution id="insti_not">School of Pharmaceutical Sciences, University of Nottingham, UK</docml:institution>
</docml:list>
<docml:list type="keyWords">
	<docml:keyword>ChiMeraL</docml:keyword>
	<docml:keyword>XML</docml:keyword>
	<docml:keyword>CML</docml:keyword>
	<docml:keyword>Signature</docml:keyword>
	<docml:keyword>digital</docml:keyword>
	<docml:keyword>X.509</docml:keyword>
	<docml:keyword>chemical</docml:keyword>
	<docml:keyword>markup</docml:keyword>
	<docml:keyword>language</docml:keyword>
	<docml:keyword>applet</docml:keyword>
	<docml:keyword>SVG</docml:keyword>
	<docml:keyword>FOP</docml:keyword>
	<docml:keyword>chemistry</docml:keyword>
</docml:list>
</docml:metadata>

<!-- ******************************************************** -->
<!-- *********************** abstract *********************** -->
<!-- ******************************************************** -->
<docml:abstract>We describe how a collection of  documents expressed in XML-conforming languages such as  CML and XHTML can be authenticated against digital signatures which make use established X.509 certificate technology. These can be associated either with specific nodes in the XML document or with the entire document. We illustrate this with two examples. An entire journal article expressed in XML has its individual components signed by separate authors, and the collection is placed in an envelope and again signed. The second example involves using a software robot agent to acquire a collection of documents from a specified URL, to perform various operations and transformations on the content, including expressing molecules in CML, to automatically sign the various components and deposit the result in repository. We argue that these operations can be used to build what we term a authenticated and semantic chemical web of trust.</docml:abstract>

<!-- ******************************************************** -->
<!-- *********************** chapter ************************-->
<!-- ******************************************************** -->
<docml:chapter id="chap_introduction" title="Introduction">
<p>A prominent characteristic of modern chemistry is the increasing automation of processes such as synthetic combinatorial chemistry, or of data capture by instruments associated with high-throughput screening. These developments presage the era of intelligent robotic chemistry where components of the system are programmed to make decisions from structured information and to issue instructions to other components using structured messages. An example of this might be a robotic chemical synthesiser  automatically identifying and scanning a newly published journal article for interesting molecules reported there, and either ordering them for testing or deciding to synthesise them from existing starting materials.<docml:link idref="ref_henrybook" type="ref"/></p>

<p>Part of this vision stems from that of the &quot;Semantic Web&quot; proposed by Berners-Lee,<docml:link idref="ref_semanticweb" type="ref"/> where he conceives of simple robots or agents which can accurately gather and act upon high-quality data found on the Web or other networks. Web-based resources (&quot;URLs&quot;) would contain &quot;metadata&quot; describing the resource, e.g.  the  authorship, ownership and access rights of the resource.<docml:link idref="ref_rdf ref_dublincore" type="ref"/> Metadata can also be used to make assertions about other forms of metadata such as <i>&quot;resource X conforms to protocol Y&quot;</i>, or <i>&quot;I confirm that resource Z was authored by organisation Q&quot;</i>. Part of the necessary process to define and identify what we mean by the term &quot;high-quality&quot; data is to establish a so-called &quot;web of trust&quot;, which would be based on certifiable metadata and information objects. In other words,  can we, or the agents that act on our behalf, trust the authorship and content of metadata statements?</p>

<p>Chemistry as a discipline is well suited to this sort of reasoning. Chemical entities are well understood and described by nomenclature that is in the public domain. It is meaningful to make a series of related assertions including, but not limited to, the following;</p>

<ol>
	<li>&quot;Agent H identifies material K from an article in a journal authored by F and published by  G&quot;</li>
	<li>&quot;Agent H works/acts for organisation E&quot;</li>
	<li>&quot;Agent H decides that material K, which corresponds to a molecular connection table X, will be required&quot;</li>
	<li>&quot;To be useful, K must have <docml:lt/> 1% impurity&quot;</li>
	<li>&quot;Acetylsalicylic acid matches connection table X&quot;</li>
	<li>&quot;Authority M states that aspirin is a common name for acetylsalicylic acid&quot;</li>
	<li>&quot;Aspirin is entry A-312 in the catalogue from supplier J&quot;</li>
	<li>&quot;Supplier  J asserts that compound A-312 is <docml:gt/> 99% pure&quot;</li>
	<li>&quot;Y represents the NMR spectrum of compound A-312 in chloroform as solvent&quot;</li>
	<li>&quot;Computer program Z analyses Y as having <docml:lt/> 1% impurity&quot;</li>
	<li>&quot;Program Z was written by organisation Q&quot;</li>
	<li>&quot;Q is on E&apos;s list of approved NMR software suppliers&quot;</li>
	<li>&quot;J is on E&apos;s list of approved compound suppliers&quot;</li>
	<li>&quot;M is on E&apos;s list of approved chemical metadata suppliers&quot;</li>
	<li>&quot;G is on E&apos;s list of approved chemical publishers&quot;</li>
	<li>&quot;F is on H&apos;s list of known/trusted authors&quot;</li>
</ol>

<p>From this, a semantic chain can be constructed which automatically leads to Agent H proposing  an order of compound A-312 from supplier J. Whilst  in most chemical organisations Agent H is currently likely to be a research scientist, delegation of such purchasing decisions to a robot agent is already happening in other sectors of business-to-business (B2B) electronic commerce. We argue that such a &quot;chemical web of trust&quot; is a realistic vision, but is mainly dependent on the ability of suppliers to use  a uniform web-based approach to data and metadata. In this context, we recently proposed <docml:link idref="ref_chemcomm00" type="ref"/> one such universal approach to  Web-based Chemistry using XML (eXtensible Markup Language), and a specific implementation of XML termed CML (Chemical Markup Language).<docml:link idref="ref_JCICS99" type="ref"/> <docml:link idref="ref_JCICS01" type="ref"/> Here we describe a mechanism for the certification of chemical data and metadata which could be used to implement this vision.  </p>
</docml:chapter>

<!-- ******************************************************** -->
<!-- *********************** chapter ************************-->
<!-- ******************************************************** -->
<docml:chapter id="chap_auth" title="Authentication of  Chemical  Information">

<p>We require the following components to authenticate information:</p>

<ol type="a">
	<li><b>A list of authorities whom we are prepared to accept as making assertions we can act upon.</b> These assertions may be about &quot;facts&quot; or may authenticate assertions made by authorities that we do not as yet accept. For example if we assert <i>&quot;The absolute conformation of (-)-labetalol is (R,R)&quot;</i> the reader should not accept this without confirmation. However  much greater confidence is generated by accepting it from the assertions:
		<ol>
			<li>In <i>Acta Cryst</i> (1984), <b>C40</b>, 825, the authors state that the absolute configuration of (-)-labetalol hydrochloride is  (R,R). </li>
			<li>The International Union of Crystallography requires that the reporting of absolute configurations by X-ray crystallography in <i>Acta Cryst</i> conforms to its guidelines.</li>
			<li>The editorial office of <i>Acta Cryst</i> use algorithms to check the data consistency of every published structure.</li>
			<li>The editorial office of <i>Acta Cryst</i> have the power to reject publications of absolute configuration which do not meet its guidelines</li>
		</ol>
The reader may now feel able to accept the assertion with a high degree of confidence (e.g. <docml:gt/> 95%).</li>
	<li><b>The ability for each authority to certify their assertions.</b> The assertions made above cannot be automatically validated without referring back to (printed) material, which itself provides the authentication. When assertions are made in electronic form it is essential that their <b>origin</b> is verifiable and that their <b>content</b> is shown to be uncorrupted. </li>
</ol>

<p>Thus we see authors and publishers making authenticable assertions about the validity of their facts and assertions. It is important to distinguish between these concepts:</p>

<ul>
	<li><b>Authenticity</b> is the ability to verify that a document/assertion has been created by the authority to whom it is attributed and that it is uncorrupted after its creation.</li>
	<li><b>Validity</b> is the ability to show that a specified validation process has been correctly carried out.</li>
	<li><b>Certification</b> is the association of a specified validation or authentication procedure with an identified authority (normally a named person or organisation) or an automated process certified by a specific authority. Certification is accomplished by incorporating a digital signature into the document (signing).</li>
</ul>

<p>In general, &quot;facts&quot; (primary data) are not validatable other than verifying their authenticity from an authority. However secondary data derived from primary data by a process (often algorithmic), can be validated. Thus <i>&quot;I mounted crystal X on an X-ray diffractometer and collected diffraction data Y&quot;</i> is not normally validatable electronically. However <i>&quot;From diffraction data Y,  I used program Z to determine the crystal structure of A as B&quot;</i> is validatable.  It is possible to support or refute this claim by running the same or equivalent computation.</p>

<p>We indicate below some of the electronic components that will need authentication and/or validation:</p>

<ol type="a">
<li><b>Chemical structures</b>, with both two and three dimensional co-ordinates. Validation includes the following hierarchy:

<ol>
<li><b>Syntactic conformance</b>. We have described earlier how Markup Languages can be used to ensure syntactic validity (i.e. that the components of a chemical structure obey a given CML DTD or Schema). <docml:link idref="ref_JCICS99 ref_njc00" type="ref"/> Schemas have greater power than DTDs and we shall describe later how they enhance validation of CML document instances. </li>
<li><b>Self-consistency</b>. CML-based representations of molecules contain some required internal self-consistency (e.g. that the <code>atomRef</code>s in bonds must reference valid atoms).</li> 
<li><b>Regularisation, normalisation and canonicalisation</b>. We assume algorithms to  determine &quot;chemical consistency&quot; such as valence checking, aromaticity and tautomerisation. There is no single approach to this and a variety of protocols will exist.</li> 
</ol>

These all involve agorithmic &quot;checking of validity&quot; through certified procedures. For example, XML-based validation requires an authentic schema and authenticated output from a validating XML parser. We assume that the appropriate DTD or Schema is authenticated before use and that the output includes this authentication. If the output itself is authenticated, it represents a trustable object for use in the semantic chemical web.
</li>
<li><b>Validation of computations.</b> Much chemical information now originates in the output of algorithmic-based modelling procedures, which may themselves include access to databases. Such programs will need to be authenticatable  and their output certified. </li>
<li><b>Instrumentation.</b> As with modelling programs, the parameters defining instrumental procedures need to be declared and the output authenticated.</li>
</ol>

</docml:chapter>

<!-- ******************************************************** -->
<!-- *********************** chapter ************************-->
<!-- ******************************************************** -->
<docml:chapter id="chap_markup" title="Markup of  Chemical  Information">

<p>For information to be easily authenticable and certifiable, it must be structured into precisely defined information components or objects, and these definitions must be openly declared and accessible. One such approach has been developed, called <b>XML</b> (eXtensible Markup Language).  Documents marked-up according to XML specifications have several characteristic features. They comprise data contained within tags known as <b>elements</b>, which may themselves be hierarchical. For example in the  CML (Chemical Markup Language) specification, <docml:link idref="ref_JCICS99" type="ref"/> a <code><docml:lt/>molecule<docml:gt/></code> element may contain many <code><docml:lt/>atom<docml:gt/></code> sub-elements or children. Elements can have associated attributes and attribute values and such documents are said to be &apos;well-formed&apos; if the syntax for expressing the elements, their attributes and their values all follow generic XML specifications.</p>

<p>A precise specification can be created of the allowed elements, their characteristics and the boundaries of the attribute values. This is referred to as a <b>Document Type Description</b> (DTD), and it can itself be expressed as an XML-conforming document called a <b>schema</b>. Any XML document conforming precisely to a given schema is said to be &quot;valid&quot;. Because the structure of the document is precisely specified, this allows transformations of the data contained within it, using  eXtensible Style Sheets (XSL) or other tools.  An illustration of this process as applied to chemistry is the ChiMeraL Project,<docml:link idref="ref_njc00" type="ref"/> where CML based documents are used to express molecules and their properties, and where the data can be visualised using conventional Web browsers and appropriate XSL transformations.</p>

<p>As noted above, XML-based validation will require an authentic schema. For example, CML version 1.0 is defined by a published DTD<docml:link idref="ref_JCICS99" type="ref"/> and only validation against this can certify that documents or components of documents contain authentic CML 1.0</p>

<p>We propose here that authenticity can be ensured by a procedure known as XML signing,<docml:link idref="ref_W3Cxsign" type="ref"/> which is based on the generation and use of key-pairs contained in so-called X.509 certificates. A description of  X.509 certificates  and their use for establishing the authenticity of Java applets has been previously described by us in some detail.<docml:link idref="ref_JCICS992" type="ref"/> In the next section,  we describe how X.509 certificates can be used to create authenticated XML documents or document components, and how such procedures can in turn be used to create certified documents and components contained within them. 
</p>
</docml:chapter>

<!-- ******************************************************** -->
<!-- *********************** chapter ************************-->
<!-- ******************************************************** -->
<docml:chapter id="chap_results" title="Signed Documents and  Document Components">

<p>Recent legislation in the UK and elsewhere has granted digital documents similar legal status to printed ones. It is self evident that someone receiving such documents must be able to establish that they are uncorrupted or unaltered since they were created by their originator (i.e. they are authentic), and that their source is itself authentic and verifiable. The first  document format to become accepted in this context is  Adobe Acrobat PDF (Portable Document Format). For example, virtually all electronic journals now offer articles in this format, and other important applications of PDF include patent submissions and compound safety sheets. An Acrobat PDF file can be digitally signed using X.509 certificates which can serve to ensure that the documents, like the Java applets noted above, are authentic. However, an important limitation of the Acrobat 4.0 format is that the digital signature can only be applied to the entire PDF document. Although the Acrobat 5.0 specification allows such documents to be further annotated by others, it is not possible in general to associate specific components of the documents with multiple and/or different certificates.</p>

<p>We propose that these and other limitations of Acrobat-format files can be overcome by using XML documents containing XML signatures. As examples we will use two sources of information. The first is an article describing the ChiMeraL project<docml:link idref="ref_njc00" type="ref"/> and available in XML form as supplemental information associated with the journal. This article contains not merely components authored by different people, but has well defined data components originating from different sources, and which we therefore use as a model for thechemical publication of the future. The trust associated with such an article originates at least in part from the original authors. In this example this is individually signed by the authors, and hence is not an automated procedure. The second example derives from the use of an  Web-based agent or robot which has been programmed to automatically traverse  a collection of documents from a remote site and on the basis of pre-defined procedures and associated algorithms, to express the documnets in valid XML form and to create specific metadata for the collection. The procedures include automatically validating any specific occurrences of e.g. an MDL Molfile and converting these files to valid CML. These components are then automatically signed by the robot agent as certifying that the metadata and  converted CML files were produced by this procedure and no other. The authors of the robot and the procedures it implements have in effect granted the robot a proxy to use their certificates. </p>
 
<!-- ******************************************* -->
<!-- **************** subsection *************** -->
<!-- ******************************************* -->
<docml:subsection id="sub_xsign1" title="Internal XML Signature">

<p>We note firstly that the procedures described here make use of experimental tools and standards which have not yet completed full ratification, and so should be regarded as being only illustrative of the concepts involved rather than as a definitive formula for its implementation.</p>

<p>The procedure starts by generating key pairs for three agents (in this case, each author of the article). Each key-pair is password protected (and known only to each author) and saved within a keystore. Each pair consists of a private key (which remains locked in the keystore) and a public key, both being required to sign a document. The keys are used to produce an X.509 certificate, which might be uniquely associated with either an individual or an organisation.  By embedding this certificate within an object known as a signature, the receiver is able to verify that the signature and any object or objects the signature contains is unaltered since the time it was signed. To achieve the greatest degree of trust, X.509 certificates, like other legal document such as e.g. driving licenses or passports, should carry a stamp of approval from a trusted agency.  The certificate generated using the process above is known as a &apos;self-signed&apos; type, and as such would  rely upon any  receiver trusting (or being able to verify) the signing agent is who or what they claim to be. To achieve a higher degree of trust,  the X.509 certificate can be submitted to a so-called  certification agency (CA) along with proof of identity, which may indeed be a passport or driving license. The CA will add its own certificate to that of the applicant (known as a root certificate) and return the compound certificate. A CA can operate globally  (such as Verisign or  GlobalSign) or it may be purely organisational. Such certificates therefore allow a &quot;chain of trust&quot; to be established, a chain which any recipient of a certificate can follow themselves if they wish to do so. </p>

<p>The ChiMeraL XML document contains several overall components, each of which can individually validated against a different XML Schema. We have chosen to illustrate the signing process by selecting four components of the original document.</p>

<ol>
<li>a molecule expressed using standard CML,</li>
<li>a spectrum using an extended CML schema,</li>
<li>a reaction expressed using an extended CML schema,</li>
<li>the document abstract expressed as XHTML. </li>
</ol>

<p>Each component can in principle be signed by a different agent. For example, the spectrum could be produced directly from an instrument capable of expressing its output as XML and carrying an internal X.509 certificate, whilst the molecule co-ordinates might be generated from a database search or a molecular modelling calculation, again each containing implicit  X.509 certificates. In our case, since no such instrumental, database or program certificate infra-structure exists yet, we have emulated the process by installing our own &quot;self-generated&quot; certificates. We note that  by retaining these signatures throughout its lifetime, the  document could contain an audit trail for each of its components.</p>

<p>In the next stage, the generated keys are used to sign the individual document components and the resulting signatures are stored as XML nodes using a proposed XML signature language.<docml:link idref="ref_JCICS992" type="ref"/> These signatures can either contain, or be contained by, the components they are signing. In either case, each signature must contain links to the component it is presumed to be authenticating (normally expressed as a URI), as illustrated in <docml:link idref="label_1" type="label"/>.</p>

<docml:box cols="1" rows="1" type="coloured">
<docml:label id="label_1" index="1" type="figure">This enveloping signature contains the component it is signing (shown in bold) within a <code>dsig:Object</code> element. </docml:label>
<docml:link idref="code_sig1" type="code"/>
</docml:box>

<p>Two forms are possible, an enveloping signature (<docml:link idref="label_1" type="label"/>) and an enveloped signature (<docml:link idref="label_2" type="label"/>). For the former, the reference URI refers to an object with an <code>dsig:Id</code> attribute that matches it, and the element to be signed is contained by the enveloping signature element. This produces a &quot;human-readable&quot; document where the signed component is readily identifiable. In contrast, the enveloped signature uses a URI to define the component being signed, and hence can reside anywhere in the document, for example at the end. Although less readable, it is easier to automate the insertion of such signatures. An example is the signed version of the CML schema (<a href="http://www.xml-cml.org/cml_schema_ie_02_signed.xml" target="new" title="Signed CML Schema">http://www.xml-cml.org/cml_schema_ie_02_signed.xml</a>).</p>

<docml:box cols="1" rows="1" type="coloured">
<docml:label id="label_2" index="2" type="figure">This enveloped signature has an empty URI attribute and hence signs the rest of the document (shown in bold). </docml:label>
<docml:link idref="code_sig2" type="code"/>
</docml:box>

<p>The procedure shown for creating such signatures is illustrated schematically in  <docml:link idref="label_3" type="label"/>, and the results can be seen as part of the supplemental information. The signing procedure authenticates two different aspects of the document: </p>
<ol type="a">

<li>Firstly, the structure of the document itself is authenticated. This includes the element signed, and any sub-elements it contains, along with all attributes of these elements and their values. This procedure ignores the order of any element attributes, and any &quot;white space&quot; or line-breaks in the specifications of the elements and their attributes, which is normalised using the built-in XML parser of the signing/authenticating tool. White space is however considered significant in the values of each attribute. </li>

<li>Next, the content itself  of each element is signed. The specific tools that we used to do this include significant  white space and also the  platform-specific line breaks. In general, line breaks often carry semantics, particularly  when &quot;pre-formatting&quot; is used in the document and so must be retained.  A more problematic issue is whether white space is normalised to a single character, or left un-normalised. Typically, an XML-aware editor might normalise white space, whereas the  signing tool will assume it is un-normalised. </li>
</ol>

<docml:box cols="1" rows="2" type="white">
<docml:label id="label_3" index="3" type="figure">Signing procedure for the ChiMeraL document: (1)  Four document components are prepared as separate XML files. (2) Each component is individually signed, using the authors&apos; certificates and enveloping signatures. (3) The components are concatenated and combined with the remaining text. (4) The completed document is over-signed using an external signature. <a href="images/xsign.svg" target="new" title="Click to open SVG version (requires Adobe SVg plugin)">(SVG version of this figure)</a></docml:label>
<docml:link alt="Signing procedure for the ChiMeraL document" display="image" height="696" href="images/xsign.gif" type="external" width="712"/>
</docml:box>

<p>A recipient receiving a signed XML document has several possible actions.  A simple tree-view display of the XML in a browser such as Internet Explorer 5 will reveal the location and number of signed components. If the XML document uses (for example) an XSL stylesheet transformation of the document to achive an on-screen display, then current versions of browsers need not in general show the presence of any signatures. One might expect that future versions of browsers would automatically detect signatures in XML documents and allow the reader an option to view the associated  X.509 certificate and their verification if required.  Current generations of browsers do indeed support this feature if present in  Java applets and email. An interim solution might be to separately process the document using the authentication tools provided as part of the IBM signing suite, prior to viewing the document within a browser. It is also possible to pre-process the document using a stylesheet such that any certificate present is displayed in the browser window. An illustration of this particular process can be viewed in the supplemental information associated with this article.</p>

</docml:subsection>

<!-- ******************************************* -->
<!-- **************** subsection *************** -->
<!-- ******************************************* -->
<docml:subsection id="sub_xsign2" title="External XML Signatures">

<p>Internal signatures are best suited for documents that have been completed and are unlikely to change. Adding further signatures may alter the content of pre-existing signatures. If a document is under development by multiple authors, then internal signatures are less appropriate, since each would have to be removed, recalculated and replaced each time its component is changed. An alternative approach is to use external signatures, which makes use of separate XML files linked to their signed components by a URI. One can envisage a database holding XML documents along with their collection of external signatures. Retaining superseded signatures and documents automatically supplies an audit trail. Because authentication using this procedure must be initiated from the signature document, there is currently no implicit way to tell if a document or document component has been externally signed.</p>

<docml:box cols="1" rows="1" type="coloured">
<docml:label id="label_4" index="4" type="figure">A detached signature is contained within a seperate XML file. A URI attribute (shown in bold) links this file to the document or document component it is signing.</docml:label>
<docml:link idref="code_sig3" type="code"/>
</docml:box>

</docml:subsection>

<!-- ******************************************* -->
<!-- **************** subsection *************** -->
<!-- ******************************************* -->
<docml:subsection id="sub_pass" title="Document Encryption">
<p>The act of signing a document only serves to authenticate it. If a greater degree of protection is required, the document or its components can also be encrypted. This can be done using two mechanisms. The simplest, and oldest technique is using a password devised by the encrypter, and which itself needs be sent to any person wishing to view the document. This password must therefore be deemed potentially insecure, since it might be intercepted on its way to whoever needs to read the document.  An example of an  XML component encrypted in this manner  is seen in <docml:link idref="label_5" type="label"/>. </p>

<docml:box cols="1" rows="1" type="coloured">
<docml:label id="label_5" index="5" type="figure">Encrypted XML element</docml:label>
<docml:link idref="code_encrypt" type="code"/>
</docml:box>

<p> A more secure method of encryption would be to make use of an X.509 certificate sent to the encrypter by the intended recipient of the document. This certificate contains a public key which is used to encrypt the document instead of a password. The safety of the document is ensured because only the original owner of the  certificate has the corresponding private key, which is the only mechanism which can be used to decrypt the document fragment. Because this process does not involve  password transmission it is far more secure, but by its very nature it is less well suited if many recipients would need to read the document.
</p>

</docml:subsection>

<!-- ******************************************* -->
<!-- **************** subsection *************** -->
<!-- ******************************************* -->
<docml:subsection id="sub_ac" title="Access Controls">

<p>Both methods described previously would be cumbersome in a large organisation where multiple documents and their components would need to be read by many people.  We note, but do not illustrate, an interesting intermediate solution which can be implemented for XML documents. XACL (XML Access Control Language)<docml:link idref="ref_access_control-language" type="ref"/> aims at providing XML documents with a sophisticated access control model and access control specification language. With this technology, access control policies control how an XML document appears to the end reader. This system defines who is able to read, change, add or delete nodes in an XML document and can be set to log all requests and changes. It is based around the following XML files</p>

<ul>
<li>Target.  This is the &apos;source&apos; document, containing appropriately marked up information. This should be stored in a server-based database and should be accessible only through the XACL protocol.</li>
<li>Policy. This contains a set of access rules declaring what privileges each user or group of users has over each node on the target document. It should be stored with the target document.</li>
<li>Request. This is a document sent to the XACL engine by a user wishing to access the target document. It declares who the user is, which node they wish to access and what they wish to do. On receiving the request, the XACL engine will look up the access rules in the policy file and return the following.</li>
<li>Decision_list. This declares whether or not each request has been passed. These decisions are also logged</li>
<li>View. This is the subset of the target document that the user has been allowed to access, and is dynamically generated from the document database and sent to the requester&apos;s browser. The rest of the document remains hidden.</li>
</ul>

</docml:subsection>
</docml:chapter>

<!-- ******************************************************** -->
<!-- *********************** chapter ************************-->
<!-- ******************************************************** -->
<docml:chapter id="chap_applications" title="Agent-based Signing Procedures">

<p>The signing procedures above were applied manually to a single document and its components by the authors of that document. An alternative approach is to delegate the signing process to an agent. This agent can perform a task pre-programmed by its author/creator. In our case, we illustrate this by using the  <b>ChemDig</b>, <b>JChemTidy</b> and <b>JChemMeta</b> agents described previously.<docml:link idref="ref_george1 ref_george2" type="ref"/> This involves using a tree traversing robot (ChemDig) to retrieve the HTML content of a remote site and to perform three operations on each document located in the tree:</p>

<ol>
<li>Each HTML document is normalised to conform to XHTML syntax (JChemTidy), producing a well formed and valid XML document.</li>
<li>Any chemical data files transcluded into the original  HTML document are then parsed, and key chemical meta-information (JChemMeta) is either extracted from the original file or derived using suitable software (e.g. a canonical  SMILES string is produced using a specified algorithm). This meta-information can then be expressed into the XHTML document via an appropriately defined schema.</li>
<li>Finally, selected types of transcluded chemical files such as the MDL Molfile are converted to a CML representation according to published Molfile specifications  using a conversion tool written by us.</li>
</ol>

<p>The next stage involves establishing a level of trust that the conversions and transformations of the chemical data indeed involve authentic processes as described by us. To achieve this, we have now added two further steps in the sequence indicated above:</p>

<ol>
<li>The derived meta-information as contained in the two elements <code><docml:lt/>meta<docml:gt/>...<docml:lt/>/meta<docml:gt/></code> and  <code><docml:lt/>link<docml:gt/>...<docml:lt/>/link<docml:gt/></code> and the converted XHTML is signed as described in <docml:link idref="label_2" type="label"/>.</li>
<li>Each of the XML/CML files converted from a Molfile is similarly signed, resulting in a collection of  XHTML and XML documents each of which can be authenticated against a formal digital signature. This authentication signifies that a specific Molfile to CML conversion process has been conducted, and that meta-information has been added according to our specifications. These components, if added to a larger database of chemical information would automatically carry their provenance and authenticity.</li>
</ol>

<p>To illustrate the complete process, we have taken
another recently published article<docml:link idref="ref_mobius" type="ref"/>. The supplemental information for this article contains a collection of  HTML documents, together with  13 MDL Molfiles which have been linked (transcluded) to the main document. We have now charged our ChemDig agent/robot to produce from this a  well formed and  valid XHTML document from each original  HTML file, to add specific chemical metadata to the XHTML, and to transform the  13 original Molfiles to valid CML form. This process creates in effect a set of assertions about the operations conducted on the original information. It does of course, not validate the original chemical claims made. The resulting collection of documents is deposited as supplemental information with the present article.<docml:link idref="ref_supplemental" type="ref"/>.</p>


</docml:chapter>

<!-- ******************************************************** -->
<!-- *********************** chapter ************************-->
<!-- ******************************************************** -->
<docml:chapter id="chap_conclusion" title="Conclusion">

<p>The techniques described in this article will allow an entire document expressed in XML, or individual components of such a document, or both,  to be authenticated against a unique digital signature encapsulated in what is referred to as an X.509 certificate. This represents a considerable advance over the use of  Acrobat PDF files for producing authenticatable documents. The various ways of implementing signatures allow for a diverse set of applications of this technology. Most importantly, the  signature can be used to authenticate the specific schema and hence XML language used to encapsulate the information in the document, in the form of a signature attached to the document schema itself. In this manner, the recipient can be assured that the structure of the document is valid.</p>

<p>Chemical information and data could be assembled from a variety of sources, including instruments, computational procedures, databases, e-journals and e-books, and the authenticity of each source individually signed as being authentic. Because each signature is individually a well formed and valid component of the overall XML document, it can be retained as an audit trail of the source of the information it refers to. As such, the signature might authenticate that component, or it may indicate that the information has been deliberately or otherwise either altered or superseded. Signatures can be also regarded as envelopes. Thus small components of a CML document which contain one or more molecules and associated properties can be wrapped in a large envelope containing in effect a database of such molecules. At the other extreme, individual properties such as e.g a melting point could be signed as authentic if deemed necessary.</p>

<p>The signatures can be included within the document itself if the nature of the document is such that it is not intended to be further edited. This would represent an archive of the information. Such documents are extensively used in areas such as patent submissions and drug submissions.  If the document is intended to be extensively revised, then the signatures can be deposited in an external database, with  URI links to the components they refer to. This approach might be useful for establishing a clear audit trail of the various information components in an organisation, or of the process representing the eventual publication of a journal article. The signing procedures could be extended to two other areas, namely access control lists for individual document components, and encryption of these components to ensure that only the intended recipient can make use of them.</p>

<p>The preceding discussions makes it apparent that a context or role must be placed on the signature, which  would include certifying the authenticity of a document, its XML/CML syntactic validity and conformance  and most challengingly its chemical validity. Similar roles can in fact be declared when an Acrobat PDF file is signed, but only in the context of the entire document and not its components. Declaration of signature roles in XML is currently less well developed, and we have not applied it here. The chemical community faces a major challenge in making available  communally agreed procedures for  evaluating chemical validity, an example of which might be validating a declaration that one compound is a tautomer of another. We hope that in the future, globally available resources for establishing chemical validity will become available.  </p>

<p>We suggest that the concept of information component authentication and delivery to intended recipients  represents a radical departure from current methods of document transmission and processing. We anticipate the techniques describe here will have widespread importance in the industrial chemical and publishing industries, and could  ultimately serve as an infra-structure on which to base the creation of a  chemical and semantic web of trust associated with on-line information.</p>
</docml:chapter>

<docml:chapter id="chap_ack" title="Acknowledgement">
<p> One of us (GVG) thanks  Merck Sharpe and  Dohm and the EPSRC for the award of a studentship.
</p>
</docml:chapter>


<!-- ********************************************************* -->
<!-- *********************** bibliography ******************** -->
<!-- ********************************************************* -->
<docml:bibliography id="bibend" title="References">
<p>This article expressed as XML, along with a number of examples are available via the supplemental information 
pages at <A href="http://www.ch.ic.ac.uk/chimeral/documents/xsign/" title="This article expresses as XML">http://www.ch.ic.ac.uk/chimeral/documents/xsign/</A> </p>
<docml:ref id="ref_henrybook">
	<docml:index>1</docml:index>
	A similar process was described by H. S. Rzepa, in &quot;The Internet: A Guide for Chemists&quot;,
	<docml:title>&quot;The Internet: A Guide for Chemists&quot;</docml:title>
	<docml:list type="authors">
		<docml:author><docml:name type="first">Ed. S.</docml:name><docml:name type="family">Bachrach</docml:name></docml:author>
	</docml:list>
	<docml:publication>American Chemical Society</docml:publication>
	<docml:date>1995</docml:date>
	<docml:volume>Chapter 11</docml:volume>
</docml:ref>

<docml:ref href="http://www.w3.org/2000/01/sw/" id="ref_semanticweb">
	<docml:index>2</docml:index>
		&quot;Weaving the Web : The Original Design and Ultimate Destiny of the World Wide Web by its Inventor&quot;,
		<docml:list type="authors">
		<docml:author><docml:name type="first">T.</docml:name><docml:name type="family">Berners-Lee</docml:name></docml:author>
		<docml:author><docml:name type="first">M.</docml:name><docml:name type="family">Fischetti</docml:name></docml:author>		<docml:author>
<docml:name type="first">M.</docml:name><docml:name type="family">Dertouzos</docml:name></docml:author>
	</docml:list>
	<docml:title>Weaving the Web : The Original Design and Ultimate Destiny of the World Wide Web by its Inventor</docml:title>
	<docml:publication>Harper, San Francisco</docml:publication>
	<docml:date>1999</docml:date>
</docml:ref>

<docml:ref href="http://www.w3.org/RDF/" id="ref_rdf">
	<docml:index>3</docml:index>
	<docml:title>Resource Description Framework (W3C)</docml:title>
</docml:ref>

<docml:ref href="http://purl.org/DC/" id="ref_dublincore">
	<docml:index>4</docml:index>
	<docml:title>Dublin Core Metadata Initiative</docml:title>
</docml:ref>

<docml:ref id="ref_chemcomm00">
	<docml:index>5</docml:index>
	<docml:list type="authors">
		<docml:author><docml:name type="first">P.</docml:name><docml:name type="family">Murray-Rust</docml:name></docml:author>
		<docml:author><docml:name type="first">H. S.</docml:name><docml:name type="family">Rzepa</docml:name></docml:author>
		<docml:author><docml:name type="first">M.</docml:name><docml:name type="family">Wright</docml:name></docml:author>
		<docml:author><docml:name type="first">S.</docml:name><docml:name type="family">Zara</docml:name></docml:author>
	</docml:list>
	<docml:publication>Chem. Commun.</docml:publication>
	<docml:date>2000</docml:date>
	<docml:page type="first">1471</docml:page>
	<docml:page type="last">1472</docml:page>
</docml:ref>

<docml:ref href="http://www.xml-cml.org" id="ref_JCICS99">
	For a formal description of CML version 1.0, see
	<docml:index>6</docml:index>
	<docml:list type="authors">
		<docml:author><docml:name type="first">P.</docml:name><docml:name type="family">Murray-Rust</docml:name></docml:author>
		<docml:author><docml:name type="first">H. S.</docml:name><docml:name type="family">Rzepa</docml:name></docml:author>
	</docml:list>
	<docml:publication>J. Chem. Inf. Comp. Sci.</docml:publication>
	<docml:date>1999</docml:date>
	<docml:volume>39</docml:volume>
	<docml:page type="first">928</docml:page>
</docml:ref>

<docml:ref href="http://www.xml-cml.org" id="ref_JCICS01">
	For part 2 of this series, see;
	<docml:index>7</docml:index>
	<docml:list type="authors">
		<docml:author><docml:name type="first">P.</docml:name><docml:name type="family">Murray-Rust</docml:name></docml:author>
		<docml:author><docml:name type="first">H. S.</docml:name><docml:name type="family">Rzepa</docml:name></docml:author>
	</docml:list>
	<docml:publication>J. Chem. Inf. Comp. Sci.</docml:publication>
	<docml:date>2001</docml:date>
	<docml:volume>41</docml:volume>
	<docml:page type="first">xxx</docml:page>
</docml:ref>

<docml:ref id="ref_njc00">
	<docml:index>8</docml:index>
	<docml:title/>
	<docml:list type="authors">
		<docml:author><docml:name type="first">P.</docml:name><docml:name type="family">Murray-Rust</docml:name></docml:author>
		<docml:author><docml:name type="first">H. S.</docml:name><docml:name type="family">Rzepa</docml:name></docml:author>
		<docml:author><docml:name type="first">M.</docml:name><docml:name type="family">Wright</docml:name></docml:author>
	</docml:list>
	<docml:publication>N. J. Chem.</docml:publication>
	<docml:date>2000</docml:date>
	<docml:volume>in press</docml:volume>
</docml:ref>

<docml:ref href="http://www.w3.org/TR/xmldsig-core/" id="ref_W3Cxsign">
	<docml:index>9</docml:index>
	<docml:title>W3C Working draft - &quot;XML-Signature Syntax and Processing&quot;</docml:title>
</docml:ref>

<docml:ref href="http://www.ch.ic.ac.uk/chimeral/" id="ref_chimeral">
	<docml:index>10</docml:index>
	<docml:title>ChiMeraL - CML Development</docml:title>
</docml:ref>

<docml:ref id="ref_JCICS992">
	<docml:index>11</docml:index>
	<docml:title/>
	<docml:list type="authors">
		<docml:author><docml:name type="first">A. P.</docml:name><docml:name type="family">Tonge</docml:name></docml:author>
		<docml:author><docml:name type="first">H. S.</docml:name><docml:name type="family">Rzepa</docml:name></docml:author>
		<docml:author><docml:name type="first">Hiroshi</docml:name><docml:name type="family">Yoshida</docml:name></docml:author>
	</docml:list>
	<docml:publication>J. Chem. Inf. Comp. Sci.</docml:publication>
	<docml:date>1999</docml:date>
	<docml:volume>39</docml:volume>
	<docml:page type="first">483</docml:page>
	<docml:page type="last">490</docml:page>
</docml:ref>

<docml:ref href="http://www.trl.ibm.co.jp/projects/xml/xacl/index.htm" id="ref_access_control-language">
	<docml:index>12</docml:index>
	<docml:title>IBM - XML Access Control</docml:title>
</docml:ref>

<docml:ref id="ref_george1">
	<docml:index>13</docml:index>
	<docml:list type="authors">
		<docml:author><docml:name type="first">G.</docml:name><docml:name type="family">Gkoutos</docml:name></docml:author>
		<docml:author><docml:name type="first">P.</docml:name><docml:name type="family">Kenway</docml:name></docml:author>
		<docml:author><docml:name type="first">H. S.</docml:name><docml:name type="family">Rzepa</docml:name></docml:author>
	</docml:list>
	<docml:publication>J. Chem. Inf. Comp. Sci.</docml:publication>
	<docml:date>2000</docml:date>
	<docml:volume>in press</docml:volume>
</docml:ref>

<docml:ref id="ref_george2">
	<docml:index>14</docml:index>
	<docml:list type="authors">
		<docml:author><docml:name type="first">G.</docml:name><docml:name type="family">Gkoutos</docml:name></docml:author>
		<docml:author><docml:name type="first">P.</docml:name><docml:name type="family">Kenway</docml:name></docml:author>
		<docml:author><docml:name type="first">H. S.</docml:name><docml:name type="family">Rzepa</docml:name></docml:author>
	</docml:list>
	<docml:publication>N. J. Chem.</docml:publication>
	<docml:date>2000</docml:date>
	<docml:volume>submitted</docml:volume>
</docml:ref>

<docml:ref id="ref_mobius">
	<docml:index>15</docml:index>
	<docml:list type="authors">
		<docml:author><docml:name type="first">S.</docml:name><docml:name type="family">Martin-Santamaria</docml:name></docml:author>
		<docml:author><docml:name type="first">H. S.</docml:name><docml:name type="family">Rzepa</docml:name></docml:author>
	</docml:list>
	<docml:publication>J. Chem. Soc. Per. Trans. 2</docml:publication>
	<docml:date>2000</docml:date>
	<docml:page type="first">2378</docml:page>
</docml:ref>
</docml:bibliography>

<!-- ********************************************************** -->
<!-- ********************* Code Block ************************* -->
<!-- ********************************************************** -->
<docml:code display="hide" id="code_sig1" xml:space="preserve">
<docml:lt/>dsig:Signature<docml:gt/>
  <docml:lt/>dsig:SignedInfo<docml:gt/>
    <docml:lt/>dsig:CanonicalizationMethod Algorithm=&quot;http://www.w3.org/TR/2000/WD-xml-c14n-20001011&quot;/<docml:gt/>
    <docml:lt/>dsig:SignatureMethod Algorithm=&quot;http://www.w3.org/2000/09/xmldsig#dsa-sha1&quot;/<docml:gt/>
    <docml:lt/>dsig:Reference <i>URI=&quot;#sign_molecule&quot;</i><docml:gt/>
      <docml:lt/>dsig:DigestMethod Algorithm=&quot;http://www.w3.org/2000/09/xmldsig#sha1&quot;/<docml:gt/>
      <docml:lt/>dsig:DigestValue<docml:gt/>kYI/aeHODcfdAVwfd5D+iifwamo=<docml:lt/>/dsig:DigestValue<docml:gt/>
    <docml:lt/>/dsig:Reference<docml:gt/>
  <docml:lt/>/dsig:SignedInfo<docml:gt/>
  <docml:lt/>dsig:SignatureValue<docml:gt/>
    DNRqWAjLILQnoPxiWvXfhZlTApoH2CxEfPW4BxLGuUm4oU7loJ9Tdg==
  <docml:lt/>/dsig:SignatureValue<docml:gt/>
  <docml:lt/>KeyInfo xmlns=&quot;http://www.w3.org/2000/09/xmldsig#&quot;<docml:gt/>
    <docml:lt/>DSAKeyValue<docml:gt/>
      <docml:lt/>P<docml:gt/>
        /X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y+r/F9bow9s
        ubVWzXgTuAHTRv8mZgt2u<font class="strong">...</font>
  <docml:lt/>/KeyInfo<docml:gt/>
  <docml:lt/>dsig:Object <i>Id=&quot;sign_molecule&quot;</i><docml:gt/>
    <font class="em"><docml:lt/>molecule title=&quot;tetrahydrofuran&quot;<docml:gt/><font class="strong">...</font><docml:lt/>/molecule<docml:gt/></font>
  <docml:lt/>/dsig:Object<docml:gt/>
<docml:lt/>/dsig:Signature<docml:gt/>
</docml:code>

<docml:code display="hide" id="code_sig2" xml:space="preserve">
<font class="em"><docml:lt/>molecule title=&quot;tetrahydrofuran&quot;<docml:gt/>
  <docml:lt/>formula<docml:gt/>C4 H8 O<docml:lt/>/formula<docml:gt/>
  <docml:lt/>string title=&quot;CAS&quot;<docml:gt/>109-99-9<docml:lt/>/string<docml:gt/>
  <font class="strong">...</font></font>
  <docml:lt/>dsig:Signature<docml:gt/>
    <docml:lt/>dsig:SignedInfo<docml:gt/>
      <docml:lt/>dsig:CanonicalizationMethod Algorithm=&quot;http://www.w3.org/TR/2000/WD-xml-c14n-20001011&quot;/<docml:gt/>
      <docml:lt/>dsig:SignatureMethod Algorithm=&quot;http://www.w3.org/2000/09/xmldsig#dsa-sha1&quot;/<docml:gt/>
      <docml:lt/>dsig:Reference <i>URI=&quot;&quot;</i><docml:gt/>
        <docml:lt/>dsig:DigestMethod Algorithm=&quot;http://www.w3.org/2000/09/xmldsig#sha1&quot;/<docml:gt/>
        <docml:lt/>dsig:DigestValue<docml:gt/>qqEOUky3GP1WCzwjlp0xAwzsHUg=<docml:lt/>/dsig:DigestValue<docml:gt/>
      <docml:lt/>/dsig:Reference<docml:gt/>
    <docml:lt/>/dsig:SignedInfo<docml:gt/>
    <docml:lt/>dsig:SignatureValue<docml:gt/>
      iIFvJvG9epMKZ1zTPvmBgy5XE5hyq+vL6kfp9SSuWEaxchy61Ychfg==
    <docml:lt/>/dsig:SignatureValue<docml:gt/>
    <docml:lt/>KeyInfo xmlns=&quot;http://www.w3.org/2000/09/xmldsig#&quot;<docml:gt/>
    <docml:lt/>DSAKeyValue<docml:gt/>
      <docml:lt/>P<docml:gt/>
        /X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y+r/F9bow9s
        ubVWzXgTuAHTRv8mZgt2u<font class="strong">...</font>
  <docml:lt/>/KeyInfo<docml:gt/>
  <docml:lt/>/dsig:Signature<docml:gt/>
<font class="em"><docml:lt/>/molecule<docml:gt/></font>
</docml:code>

<docml:code display="hide" id="code_sig3" xml:space="preserve">
<docml:lt/>dsig:Signature<docml:gt/>
  <docml:lt/>dsig:SignedInfo<docml:gt/>
    <docml:lt/>dsig:CanonicalizationMethod Algorithm=&quot;http://www.w3.org/TR/2000/WD-xml-c14n-20001011&quot;/<docml:gt/>
    <docml:lt/>dsig:SignatureMethod Algorithm=&quot;http://www.w3.org/2000/09/xmldsig#rsa-sha1&quot;/<docml:gt/>
    <docml:lt/>dsig:Reference <font class="em">URI=&quot;http://www.ch.ic.ac.uk/chimeral/xsign/article.xml&quot;</font><docml:gt/>
        <docml:lt/>dsig:DigestMethod Algorithm=&quot;http://www.w3.org/2000/09/xmldsig#sha1&quot;/<docml:gt/>
        <docml:lt/>dsig:DigestValue<docml:gt/>QLfOmhf0CVTJeGRi0RGlqrJ7phQ=<docml:lt/>/dsig:DigestValue<docml:gt/>
      <docml:lt/>/dsig:Reference<docml:gt/>
  <docml:lt/>/dsig:SignedInfo<docml:gt/>
  <docml:lt/>dsig:SignatureValue<docml:gt/>
    IzYvVLmiUtXeJzFZJMFni1w1CqePQyrALpvxhZD/Y2R4D7XR3Xcchg==
  <docml:lt/>/dsig:SignatureValue<docml:gt/>
  <docml:lt/>KeyInfo xmlns=&quot;http://www.w3.org/2000/09/xmldsig#&quot;<docml:gt/>
      <docml:lt/>DSAKeyValue<docml:gt/>
        <docml:lt/>P<docml:gt/>
          /X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAiUftZPY1Y+r/F9bow9s
          ubVWzXgTuAHTRv8mZgt2u<font class="strong">...</font>
    <docml:lt/>/KeyInfo<docml:gt/>
<docml:lt/>/dsig:Signature<docml:gt/>
</docml:code>

<docml:code display="hide" id="code_encrypt" xml:space="preserve">
<docml:lt/>docml:document<docml:gt/>
  <docml:lt/>EncryptedElement algorithm=&quot;DES/CBC/PKCS5Padding&quot; 
  	contentType=&quot;text/xml&quot; encoding=&quot;base64&quot; iv=&quot;/w8IHCxetvQ=&quot;<docml:gt/>
    PFXFr/Cr7UTcJTQXEg3KiCqRyLkHzi3IF+KtJJY7eTs61lUgw54LKokxW4WLOwSrUwLZQ0sf0K5/
    St9mmu7cHxNhP2WLQ0xBj6QZ8kONMawGNeAqpR/EUpcjsxxhDjc5JoU9IhVGIVJHJr0/98AWtkS8
    4oTCl9M0CBRBFMzbqG6HB+afVUYCaZTDb9XYqUduOP/sbOiSnJarNPg0Z9Lv8XbxVZEp24CmuoOE
    6vpPYOAyKAcFiNY7oUQtmv4QoEwB+YsxBOrpAHfgAdokK6unr415atyzxP0OAt90topPRFBHXLAA
    <font class="strong">...</font>
  <docml:lt/>/EncryptedElement<docml:gt/>
<docml:lt/>/docml:document<docml:gt/>
</docml:code>

</docml:document>