RE: Magic Signatures

I agree with Hal's assessment. However, the way I would put it wrt the
topic of Magic Signature's handling of XML is that it does not allow
signing of plaintext XML that might be intentionally and legitimately
altered during business processing. XML Signature specifically supports
the ability to selectively sign XML parts (allowing applications to
legitimately manipulate non-signed parts of an XML instance) whereas
Magic Signature's do not. In addition, XML Signature makes it easy to
add signatures into XML instances (using the enveloped signature
approach) allowing the XML instance to maintain its XML nature, but this
would not be possible with Magic Signatures.

Also, fyi, James Clark's 2010 blog entries discusses Magic Signatures
(and XML Namespaces):

http://blog.jclark.com/

There are definitely things I like about Magic Signatures (e.g. an
attempt to provide a JSON-native signature format) but some of its
depictions of XML Signature definitely need addressing.

Corrections about my assessments above are welcome.

Ed


On Tue, 2010-08-10 at 07:03 -0700, Hal Lockhart wrote:
> 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
>         
>         

-- 
========================================
Ed Simon, XMLsec Inc.
613-726-9645
edsimon@xmlsec.com

Received on Tuesday, 10 August 2010 16:20:49 UTC