digitalsignature-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
mNo edit summary
m (Reverted edits by MonelAltrt (Talk) to last version by HenrichPoehls)
 
(3 intermediate revisions by 3 users not shown)
Line 1: Line 1:
I would like to start discussing the posibility to digitally sign Microformatted content.  
<h1>Digital Signatures Brainstorming</h1>
 
== Henrich Poehls ==
 
I would like to start discussing the possibility of digitally signing Microformatted content.  


A Microformat carrying a digital signature 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.
A Microformat carrying a digital signature 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.
Line 5: Line 9:
This is part of ongoing research aiming to protect content, especially content that has been made machine-readable through the use of semantic annotations. I have plenty of ideas and further use cases.
This is part of ongoing research aiming to protect content, especially content that has been made machine-readable through the use of semantic annotations. I have plenty of ideas and further use cases.


* Why a new Microformat?
I think signing a "Microformat" (aka Microformatted Content) shall be possible within "Microformats" (so itself a microformat). Such as XML can be signed and the Signature stored in XML as well.


===An hSig Microformat "proposal" ===
* Why signing Microformatted content?
 
Microformats facilitate reuse of semantically annotated content. It allows services and applications to cut&paste, convert, re-publish, link-to, cite Microformatted content. In any of these cases it might be interesting to see who the original author was. Additionally viewers want to verify authorship. Digital Signatures offer just this, Origin-Authentication.
 
The structure and names are chosen in the style of the W3C Recommendation for XML-Signature Syntax and Processing [http://www.w3.org/TR/xmldsig-core/], the existing XML structure for digital signatures.
 
<pre><nowiki>
....
<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>
...
</nowiki></pre>
     
hsig: Microformat for Digital Signatures with example values
 
There are several differences compared to the original XML Signature structure:
* Most notably the proposed Microformat is less nested. For example instead of putting digestmethod and digestvalue into a sub-container called reference we flattened the structure.  
* 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.
 
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.  
 


===Enveloping signature===
* Why use digital signatures and not some [http://microformats.org/discuss/mail/microformats-discuss/2007-January/thread.html#8265 "Trace-Back-Mechanism"] 
Trace-back allows to find a "bigger", more complete version of Microformatted content. Trace-back only verifies that the pointer used for trace-back is now "self referencing". Trace-back will then verify the content's source based on a URI/URL.


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 ).
IMHO this is a weaker "form of authenticity" than that achieved by a digital signatures.  
===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.
<pre>
<nowiki>
<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>
</nowiki>
</pre>


Signed micro content using an enveloped hsig Microformat
Also digital signatures are more versatile:
* Digital signatures add authenticity without the need to trace links back to some URL, so reduces the overhead if the content at view is "authoritative enough".
* Digital signatures allow to add authority to content that is placed on foreign URLs (e.g. Signing your whole Comment you left on a foreing Blog).




===Manifest and signature generation details===
== Discussion participants ==
* Henrich C. Pöhls, [http://www.informatik.uni-hamburg.de/SVS/personnel/henrich/index.php University of Hamburg]
* Add your name if you feel you have made significant additions to the page.


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.
== Proposal/ overview ==
This page is a companion to '''[[digital-signatures]]'''. Please read that page first, and then return here to discuss and post ideas/ examples.

Latest revision as of 22:34, 5 January 2009

Digital Signatures Brainstorming

Henrich Poehls

I would like to start discussing the possibility of digitally signing Microformatted content.

A Microformat carrying a digital signature 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.

This is part of ongoing research aiming to protect content, especially content that has been made machine-readable through the use of semantic annotations. I have plenty of ideas and further use cases.

  • Why a new Microformat?

I think signing a "Microformat" (aka Microformatted Content) shall be possible within "Microformats" (so itself a microformat). Such as XML can be signed and the Signature stored in XML as well.

  • Why signing Microformatted content?

Microformats facilitate reuse of semantically annotated content. It allows services and applications to cut&paste, convert, re-publish, link-to, cite Microformatted content. In any of these cases it might be interesting to see who the original author was. Additionally viewers want to verify authorship. Digital Signatures offer just this, Origin-Authentication.

Trace-back allows to find a "bigger", more complete version of Microformatted content. Trace-back only verifies that the pointer used for trace-back is now "self referencing". Trace-back will then verify the content's source based on a URI/URL.

IMHO this is a weaker "form of authenticity" than that achieved by a digital signatures.

Also digital signatures are more versatile:

  • Digital signatures add authenticity without the need to trace links back to some URL, so reduces the overhead if the content at view is "authoritative enough".
  • Digital signatures allow to add authority to content that is placed on foreign URLs (e.g. Signing your whole Comment you left on a foreing Blog).


Discussion participants

  • Henrich C. Pöhls, University of Hamburg
  • Add your name if you feel you have made significant additions to the page.

Proposal/ overview

This page is a companion to digital-signatures. Please read that page first, and then return here to discuss and post ideas/ examples.

Retrieved from "http://microformats.org/wiki/index.php?title=digitalsignature-brainstorming&oldid=37313"