From RDFaWiki

WARNING: Experimental wiki page. This page outlines concepts that are purely experimental in nature.
WARNING: The work described below is in no way endorsed by the RDFa Task Force, SWDWG or the W3C.
WARNING: The existence of this page does not imply nor express a statement that the concepts here will become a part of RDFa now or in the future.

Contents 1 Introduction 2 Subject-signing 2.1 Example 2.2 Pseudo-code 2.3 Benefits 2.4 Issues 3 Signature attributes 3.1 Example 3.2 Pseudo-code 3.3 Benefits 3.4 Issues

Introduction

Ensuring secure, trusted and verified communication is an ongoing issue on the Web. The RDFa community along with the larger semantic web and general web community must continue to address issues such as trust, spam, phishing, and verified semantic web statements. This page is a starting point for various security and trust related initiatives that the RDFa community is undertaking. Please feel free to add semantic web security and trust initiatives onto this page.

Note that this page, much like most experimental sections of this website, is in no way driven by the RDF in XHTML Task Force since work on security related activities surrounding RDFa is completely outside of its charter.

Subject-signing

Subject signing is the act of in-order-serialization and digitally signing triples by subject.

Example

<div xmlns:dcterms="http://purl.org/dc/terms/"
     xmlns:media="http://purl.org/media#"
     xmlns:video="http://purl.org/media/video#"
     xmlns:trust="http://purl.org/trust#"
     about="#why-so-serious" typeof="video:Movie">
   <p>
   <a rel="media:depiction" href="http://images.rottentomatoes.com/images/movie/custom/51/1184851.jpg">
      <span about="#why-so-serious" property="dcterms:title">The Dark Knight</span>
   </a> directed by 
   <span property="dcterms:creator">Christopher Nolan</span>. 
   The 
   <span property="trust:algorithm">RSA/SHA-384</span>
   signature for this data is 
   <span property="trust:signature">9FA750B193A8570C398E457F90A</span>. 
   The public key is available
   <a rel="trust:publicKey" href="http://example.org/bob.pub">here</a>.
   </p>
</div>

Pseudo-code

Triple serialization order is important with this approach.

To generate the signature:

1. Keep a per-subject serialization going while generating the page.
2. When a signature is needed, hash and sign the per-subject serialization to that point.
3. Dump the signature method, signature and public key location to the HTML as either hidden or displayed content.

To verify the integrity of the data:

1. Read until a trust:signature predicate is detected for a given subject.
2. Serialize the triples in a well-defined way (N-triples, specific bnode naming convention, etc.).
3. Retrieve the public key and check the signature.

Benefits

• Reduces the amount of data needed to express the digital signature on large numbers of triples.

Issues

• If somebody inserts a triple into the stream of triples on the page (via a comment or wiki edit, the signature will fail for all data from the last signature to the last triple associated with the subject).
• Will probably not work well on publicly edited sites (comments, wikis, etc. that allow RDFa statements to be made in the comments).

Signature attributes

Signature attributes could be an extension to RDFa that would introduce a new attribute to associate a digital signature with each triple generated.

Example

<div xmlns:dcterms="http://purl.org/dc/terms/"
     xmlns:media="http://purl.org/media#"
     xmlns:video="http://purl.org/media/video#"
     xmlns:trust="http://purl.org/trust#"
     about="#why-so-serious" typeof="video:Movie">
   <p>
   <a rel="media:depiction" href="http://images.rottentomatoes.com/images/movie/custom/51/1184851.jpg"
      signature="#key-details 393A80C9FA750B195457F90A8E7">
      <span about="#why-so-serious" property="dcterms:title" 
            signature="#key-details 9FA750B193A8570C398E457F90A">The Dark Knight</span>
   </a> directed by 
   <span property="dcterms:creator"
         signature="#key-details 70C393A85457F90A8E9FA750B19">Christopher Nolan</span>.

   <div about="#key-details">
      The 
      <span property="trust:algorithm">RSA/SHA-384</span>
      signature for this data is 
      <a rel="trust:publicKey" href="http://example.org/bob.pub">here</a>.
   </div>
   </p>
</div>

Pseudo-code

Triple serialization order is not important to this approach.

To generate the signature:

1. Insert the key details into the document, preferably as the first set of triples that are generated.
2. Detect whenever a triple is generated in the markup.
3. Serialize the triple in a well-defined way (N-triples, specific bnode naming convention, etc.).
4. Sign the triple and insert a signature attribute containing a pointer to the key/signature information as well as the signature.

To verify the integrity of the data:

1. Detect whenever a triple is generated in the markup and see if it has an associated signature attribute.
2. Pull the key details subject and signature from the signature attribute.
3. Extract the associated key details from the triple store.
4. Retrieve the public key.
5. Verify the signature against the public key.

Benefits

• Not vulnerable to triple insertion attacks.

Issues

• Much more verbose for large numbers of triples than the subject-signing approach.
• If two predicates are stated on a single element, the signature only applies to the first triple generated.