hSig & SMAC: Verifying digitally signed Microformatted content

Microformats offer a way to semantically annotate data contained in HTML web pages. You will find more information about Microformats on their webpage and in their WiKi. On this page we will show an approach to digitally sign Microformatted data by presenting a new Microformat that allows to "hold" (semantically annotate) the information needed to "machine-understandable" (automatically parse and verify) the digital signature.

As part of a diploma thesis, Henrik Niklaus implemented a Firefox extension called SMAC (signature for microformat annotated content), that allows to verify digitally signed Microformatted content. The prototype (version 0.9.1) has been released to allow public testing. We will release some testcases soon. For feedback and questions please send an email to Henrich C. Pöhls.

This is part of ongoing research aiming to protect content, especially content that has been made machine-readable through the use of semantic annotations.

Fig.1: Screenshot of the SMAC Firefox Extension

An hSig Microformat proposal

The structure and names are chosen in the style of the W3C Recommendation for XML-Signature Syntax and Processing, the existing XML structure for digital signatures. Figure 1 shows the proposed structure. To better understand Microformats in general: Any HTML structure allows the class attribute to have one or more values. As such class can be used to store also annotations, so below is just one way of representing the values needed for the cryptographic information by using the HTML elements div, a, span and abbr. The latter is parsed according to Microformats in such a way that the value is taken from the abbr's title-value.

[...]
<div>
 <a
     href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">
 </a>
   Signed using <span>RSA</span>.
   Hashed using <span>SHA1</span>.
   <abbr title="vcard:fn,vcard:email">
       Name and eMail signed.
   </abbr>
   <abbr title="57c8105e6d944[...]a14c4cea7f53">
       The Hash.
   </abbr>
   <abbr title="7m6NS6ANCa[...]Kl42Rr+Pfw==">
       The signature.
   </abbr>
   <abbr title="X509">
       I have an X509 certified key.
   </abbr>
   <abbr title="-----BEGIN CERTIFICATE----- E693c4[...]
         [...]MIICIzCCAc2gAgANB-----END CERTIFICATE-----" >
       My X509 certificate containing my public-key.
   </abbr>.
 </div>
 [...]

Fig. 2:   hsig: Microformat for Digital Signatures with example values

There are several differences compared to the original XML Signature structure. Most notably the proposed Microformat takes a less nested approach. For example instead of putting digestmethod and digestvalue into a sub-container called reference we flattened the structure. Also we added fields that would allow more room for capturing different signature formats. For example additionally to flattening keyinfo we added keyvalue , which allows to store information about the key.

Using the already existing approach to semantically markup content using Microformats, we propose a new Microformat to specify the information related to digital signatures. We implemented a prototype using Microformats as micro content format. We have chosen Microformats, because it allows easy addition of semantic information to existing HTML-based structured content. Several content creation tools already allow to generate Microformatted content.
Thus, we believe the signature generation and verification can also be build into the same tools, allowing to add additional value by signing the content.

This Microformat could be used in conjunction with other already defined Microformats like hcard, hcalendar or hreview. As our proposed Microformat for digital signatures is content agnostic it can be used to build compound signed Microformats from all existing and future Microformats.

To bind the signature to an existing Microformatted micro content we foresee three possibilities, that are again conforming to the use of XML Signatures: Enveloping, enveloped and detached signatures. We will shortly describe the three cases.

Enveloping signature

For an enveloping signature the hsig container contains the Microformatted micro content that is signed. The micro content's sub-properties are referenced in the manifest using the Microformat's name followed by the sub-property, separated by a colon (e.g. vcard:fn ).

Enveloped signature

In the case of an enveloped signature the hsig container is contained within the Microformatted micro content that is signed. Again the micro content's sub-properties are referenced in the manifest using the Microformat's name followed by the sub-property, separated by a colon (e.g. vcard:fn ). Figure 2 shows this case.

Detached signature

This case is needed when a signature shall cover more than one micro content from that page. The micro contents that are part of the signature are then referenced using an <object> or <a> HTML element inside the hsig -section. In this case the micro content needs an id, which is then used for reference instead of the Microformat's name. This case is the most complex one and is not further elaborated for brevity.

<div>
   <h1>SVS - Office</h1>
   <a href="mailto:svs-office@informatik.uni-hamburg.de">Email us.</a><br/>
           Tel.: <span>+49 40 42883 - 2510</span><br/>
           Fax: +49 40 42883 - 2086 <br/>
           Room: F-631 <br>
   <div>
      <abbr title="vcard:fn, vcard:tel, vcard:email">
             This
      </abbr>
      <abbr title="57c8105e6dd944[...]a14c4cea7f53">
             content
      </abbr>
      <abbr7m6NS6NCa[...]Kl42Rr+Pfw==">
             is signed.
      </abbr>
      <abbr title="SHA1">It was hashed using SHA1.</abbr>
      <abbr title="RSA">And signed using RSA.</abbr>
      <abbr title="-----BEGIN CERTIFICATE----- [....]
                     [...] CIzCCAc2gAgA-----END CERTIFICATE-----" >
             My <span>X509</span> public-key certificate.
      </abbr>.
   </div>
< /div>

Fig. 3:   Signed micro content using an enveloped hsig Microformat

Manifest and signature generation details

In our prototype the manifest is stored under the class name manifest (see fig. 2). The manifest is also embedded into the signature this aids security. The manifest first identifies for which Microformat structure the signature has been generated. After the Microformat identifier the sub-properties are expressed using their class names (e.g. vcard:fn). Hashes are computed over each sub-property in the manifest and the manifest itself. The hahses are then concatenated in the order they appear in the manifest with the manifest's hash first . This concatenation of hashes is hashed again and stored in digestvalue. Finally it is digitally signed using a digital signature algorithm (specified in signaturemethod) and the value is stored in signaturevalue. To allow for an easier verification of the signature and to aid authentication of the signer, the key can be added to hSig as keyvalue. The key could be anything ranging from a PGP Key to an X509 Certificate from a ca. Exactly what key information is appended should be specified in keyinfo even if it might be deductable from the values of the key itself or the signing method used.