RE: Magic Signatures

Based on a fairly brief analysis it seems to me that the claims made are misleading, if not actually overblown.

A brief summary of the scheme.

The data is represented as the URI and filename safe variant of base64. This is intended to make it safe to include it as text in XML, a string in JSON, a parameter in URLs, or as form data without using escape chars. The metadata (algorithm, encoding, etc.) can be represented as XML or JSON, although apparently there is not a lot of interest in the XML variant. The key is identified by a hash of the Public Key. The key can be discovered using LRDD. There are special considerations for use with Atom. In spite of the metadata machinery, only one encoding and one signature alg (RSA-SHA256) are supported.

The major virtue of this scheme is that the envelope can be used in pretty much any common protocol without breaking the signature. This is at a cost of a 1/3 increase in size.

The intro makes the following claims.

Compared to XML-DSig, Magic Signatures offers the following features: 
1. Can handle any data format; not tied to XML. 
2. Does not require any canonicalization beyond removal of whitespace, so it is much easier to verify messages correctly. 
3. Can survive message disassembly, storage into arbitrary systems, and re-constitution without invalidating the signature. 
4. Significantly smaller and simpler specification. 

My comments:

1. This is misleading, depending on what you think it means. XML-Dsig can sign arbitrary data, not just XML. On the other hand M-Sig can represent its metadata in JSON or XML. This would be trivial for XML-Dsig to allow a JSON representation.
2. There is no question that sig processing is simpler.
3. This is misleading as it cannot surive the most common XML usecase of being parsed and re-serialized. What apparently is meant by this is that the encoding will not be broken by various protocols as noted above. It is hard to see how this approach allows the data to be dissasembled and reassembled in any application-aware way which could be guaranteed not to break. if the protocol provides both encoded and unencoded forms, the verifier would have to determine that they are equivalent.
4. True, but the functionality is also greatly reduced.

Hal

  -----Original Message-----
  From: Martin, Cynthia E. [mailto:cemartin@mitre.org]
  Sent: Thursday, July 15, 2010 2:41 PM
  To: XMLSec WG Public List
  Subject: Magic Signatures


  Members,



  Is anyone familar with Magic Signatures?



  http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html



  According to the document, Magic Signatures is a lightweight, robust mechanism for digitally signing nearly arbitrary messages, along with a basic public key infrastructure for discovering the signing keys.

  The primary goal of Magic Signatures is to enable lightweight and robust public key signing for messages that may be transformed, converted, stored, and reconstituted in arbitrary ways. In order to make this mechanism useful, it also defines a public key discovery protocol that enables recipients to reliably map between pseudonyms for authors and their corresponding public keys. 

  This mechanism is an alternative to XML-DSig. In the field, XML-DSig has proven to be problematic in applications such as syndication of feeds. Compared to XML-DSig, Magic Signatures offers the following features: 

  - Can handle any data format; not tied to XML. 

  - Does not require any canonicalization beyond removal of whitespace, so it is much easier to verify messages correctly. 

  - Can survive message disassembly, storage into arbitrary systems, and re-constitution without invalidating the signature. 

  - Significantly smaller and simpler specification. 

  Magic Signatures does not attempt to address every XML-DSig use case, so it is best described as a lightweight, robust, and minimal form of digital signatures that can be used and deployed where XML-DSig cannot be relied on. Note that for XML, it is possible to combine both mechanisms.



  Any information on the claims would be very helpful.


  Regards,

  Cynthia

Received on Tuesday, 10 August 2010 14:05:00 UTC