Introduce a Signature Extensibility mechanism

[GoogleCodeExporter]

It is good that the draft limits itself to defining only how to verify a 
signature and not what a signature means. The only exception to this is the 
business related to signing Atom messages, where there is to be a link 
between the "authors" of the entry and the signatures.

While the current simplicity of Magic Signatures will be broadly 
appreciated, it is inevitable that as time passes people will want to 
introduce additional complexity and that they will have "good" reasons for 
doing so. However, there exists no mechanism to allow extension of the core 
Magic Signatures method in a way that would be backwards/forward 
compatible. Thus, future extensions are likely to be implemented in a non-
optimal fashion.

Some things that folk might want to add:
* Date/Time when signature was created (as distinct from dates related to 
payload)
* "start time" or "end time" for validity of signature.
* Application or context-specific statements about the "purpose" of the 
signature. Does it imply ownership?, Agreement with statements in the 
payload? or simply that the signer "saw" entry in its current form?
* A WebFinger Id of the signer in cases where the payload can't be modified 
to include such an identifier.

Any method used to provide extensibility should be 1) Simple and 2) Baked 
into the core specification today in order to ensure backwards 
compatibility. So, I propose:

To the <me:sig/> element, allow a <data/> element which is encoded in much 
the same way as the payload. Then, modify the signing rules in "8. Signing 
Messages" to include the signature data as a fifth element of the data to 
be signed. This means that a signature might look like:
  <me:sig keyhash="4k8ikoyC2Xh...">
    EvGSD2vi8qYcveHnb-rrlok...
    <me:data type='application/xml'>Tm90IHJlYWxseS...
    </me:data>
  </me:sig>

Then, the signature would be over the five elements (rather than the four 
currently defined):
  <payload_data>.<data_type>.<encoding>.<alg>.<sig_data>
If there was no signature_data, the signed data would end with a "."

This would then allow me to create a signature that included some signature 
metadata which if un-encoded might look something like the following:

  <signed_on>2010-08-18T21:10:54-5:00</signed_on>
  <assert_authorship>no</assert_authorship>
  <webfinger>acct:bob@example.com</webfinger>

However, even though only some applications might actually understand the 
meaning of the stuff that I included in the signature metadata, all 
applications would be able to do Magic Signature verification to determine 
that the signature was actually related to the payload. In this way, we 
provide a means to support extensible signature metadata without 
compromising backwards compatibility or significantly increasing the 
complexity of the core specification.

Original issue reported on code.google.com by bobwyman on 21 Apr 2010 at 8:21

[GoogleCodeExporter]

Not sure if adding an additional metadata field is the best approach -- though 
it may be.  Are there other 
specific use cases?  Why couldn't you add this metadata inside the existing 
data blob (as the signer has to 
be able to parse/modify the content there in any case, and it usually contains 
all kinds of metadata today, 
like "generator" for activities?)

Original comment by jpanzer@google.com on 20 May 2010 at 7:42

[GoogleCodeExporter]

A different approach might be to specify a format for "wrapping" data before 
putting 
it in an envelope, with the wrapper format being safely extensible.

<me:env>
  <me:data type='application/me-signed-data+xml'>
[[encoded]]
    <me:signed-data>
      <me:data type='text/plain'>Original Document</me:data>
      <me:signer>acct:hjfreyer@google.com</me:signer>
      <me:date>20100101</me:date>
    </me:signed-data>
[[/encoded]]
  </me:data>
  <me:sig/>
</me:env>

Then you're wrapping things twice which is kind of annoying, but you're keeping 
a 
clear distinction between the signed and unsigned data, and theoretically 
clients can 
then check to see if the data type is "me-signed-data" and then do the 
unwrapping for 
the end user automatically.

Original comment by hjfre...@google.com on 20 May 2010 at 8:47

[GoogleCodeExporter]

Another possible approach that doesn't impact the current spec (but which 
requires a new extension spec) is to define a different signing algorithm, 
e.g., MULTI-RSA-SHA256, which specifically allows for additional metadata on 
the signatures, but is only understood by libraries implementing the extension. 

Original comment by jpanzer@google.com on 28 Jun 2010 at 8:22

• Changed state: Accepted

[GoogleCodeExporter]

After some offline discussion (recapped in the comments here), research, and 
sitting around and thinking, I think that this is a valid and worthwhile use 
case, but one that can get complex quite quickly, and that there are reasonable 
paths forward that use the current spec as a base even if it doesn't address 
these concerns up front.  In other words, I don't think this falls into the 
"80% rule" for Magic Signatures, and we're not ruling anything out by leaving 
this out of version 1.  Does that make sense?

Original comment by jpanzer@google.com on 28 Jun 2010 at 8:26

[GoogleCodeExporter]

The current spec [Sec 3.2. The XML Serialization] says: 
"Additional elements not defined by this specification MAY appear as children 
of the me:env or me:provenance elements, but MUST NOT appear as children of any 
other element." 

Thus, if a future extension were to provide for me:data being included as a 
child of me:sig, the result would violate the current language rather than 
simply producing a signature that won't verify properly without understanding 
the extension. Would it be possible to remove the restriction against adding 
child elements in me:sig and thus clear the road for future extensions?

Original comment by bobwyman on 28 Jun 2010 at 9:27

[GoogleCodeExporter]

IIRC, the primary complaint againt OpenPGP by Salmon people has been "the spec 
is long".  If you start adding these kind of extensions, you will eventually be 
feature-complete compared to OpenPGP... and thus will have an equally long spec.

This is similar to how the OpenID community started out wanting simple, and is 
now on the road to creating something even more complicated than SAML, just 
using different serializations.

Original comment by singpol...@gmail.com on 3 Jul 2010 at 5:15

[GoogleCodeExporter]

Singpolyma: The changes I have proposed are explicitly intended to ensure that 
the inevitable future suggestions for modifications to the core Magic Signature 
specification are unnecessary. In a system such as this, any of the inevitable 
requests for extensions must fall into a limited number of areas:

* Metadata describing the signed data
* Metadata describing the signature

Currently, the spec supports extensions to metadata describing the signed data, 
but does not support any extensions related to the signature other than those 
that can be accomplished by defining new encodings or algorithms. As a result, 
if anyone wants to add signature metadata, they will have to argue for 
modifications to the core specification. This is not good.

My proposal makes core Magic Signature safe against amendment and ensures that 
it can remain simple over time -- even though non-core extensions would be 
capable of handling requirements that equal or exceed the complexity of SAML. 
By rejecting this proposal, you risk either inevitable future extensions to the 
core or simply establish the requirement for yet-another-format that can, in 
fact, support additional signature metadata.

Original comment by bobwyman on 3 Jul 2010 at 5:45