digital-signatures

Digital Signatures

This page documents a discussion about digitally signed Microformatted data.

Introduction

Defined Microformats such as hCard, hCalendar or hReview can be formatted to include a digital signature. This document is a definition of a proposed format for the digital signing of Microformatted data. As this format is content agnostic it can be used to build compound signed Microformats from all existing and future Microformats.

In a broad sense, this format (sometimes referred to as hSig) aims to protect the authenticity and authority of content that has been made machine-readable through the use of semantic annotations (e.g. Microformatted data).

Format

The structure and names are chosen in the style of the W3C Recommendation for XML-Signature Syntax and Processing [1], the existing XML structure for digital signatures.

// Proposed format with example values
....
<div class="hsig">
 <a class="canonicalizationmethod url"
     href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">
 </a>
   Signed using <span class="signaturemethod">RSA</span>.
   Hashed using <span class="digestmethod">SHA1</span>.
   <abbr class="manifest" title="vcard:fn,vcard:email">
       Name and eMail signed.
   </abbr>
   <abbr class="digestvalue" title="57c8105e6d944[...]a14c4cea7f53">
       The Hash.
   </abbr>
   <abbr class="signaturevalue" title="7m6NS6ANCa[...]Kl42Rr Pfw==">
       The signature.
   </abbr>
   <abbr class="keyinfo" title="X509">
       I have an X509 certified key.
   </abbr>
   <abbr class="keyvalue" title="-----BEGIN CERTIFICATE----- E693c4[...]
         [...]MIICIzCCAc2gAgANB-----END CERTIFICATE-----" >
       My X509 certificate containing my public-key.
   </abbr>.
 </div>
...

There are several differences between this format and the original XML Signature structure:

• Most notably, the proposed Microformat is less nested. For example, instead of placing digestmethod and digestvalue into a sub-container called reference, the structure was flattened.
• Fields were added which allow more room for capturing different signature formats. For example, in addition to flattening keyinfo keyvalue was added, which stores information about the key.

Integration of signature

To bind the signature to existing Microformatted content, there are three possibilities (again conforming to the use of XML Signatures).

Enveloping signature

For an enveloping signature the hsig container contains the Microformatted content that is signed. The 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.

// Signed content using an enveloped hsig

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

Manifest and sig generation details

In our prototype, the manifest is stored under the class name manifest (see above). 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.

References

Normative References

• hcard
• hCalendar

Informative References

• A Microformat for Digital Signatures

Related pages

• digitalsignature-brainstorming
• digitalsignature-examples