Magic Signatures: Signature should cover algorithm, MIME type, encoding parameters

[GoogleCodeExporter]

Per Ben Laurie: The signature should cover the algorithm, content MIME type, 
and encoding parameters as well as the data.  This requires having an 
algorithm for adding these to the bytes to be signed.  Also interacts with 
the question about signing prior to base64url encoding of course.

Even though the algorithm and encoding are fixed constants right now, the 
MIME type is not, and presumably if we can sign one we can sign all three 
just as easily.

Original issue reported on code.google.com by jpanzer@google.com on 26 Feb 2010 at 11:09

[GoogleCodeExporter]

I'm planning on appending these to the base64_url encoded signature base string:

base64url(data) + . + base64url(mimetype) + . + algorithm + . + encoding

where + indicates concatenation, . means an ASCII period, and names indicate 
the ASCII strings referenced.

The mimetype is base64url encoded because it can be arbitrary and will always 
include a / character and 
could contain . characters.  We control the algorithm and encoding parameters 
so we always pick a subset 
of base64url characters for those.

Please yell by EOW if you see a problem with this.  Note that this will change 
the signatures and therefore 
break the 3 existing implementations,.  I'll post code deltas when available as 
well.

Original comment by jpanzer@google.com on 6 Apr 2010 at 10:32

• Changed state: Accepted

[GoogleCodeExporter]

I prefer the Nigori formulation: 32 big-endian length followed by raw data.

Original comment by benl@google.com on 9 Apr 2010 at 5:54

[GoogleCodeExporter]

Having a side discussion w/Ben, but I've got the following text using the 
pure-concatenation 
method:
---
M is produced by concatenating the following substrings together, separated by 
periods 
(ASCII 0x2E):

o The armored string for "data" produced by Section 7.1
o The Base64url encoding of the "data_type" parameter
o The Base64url encoding of the "encoding" parameter
o The Base64url encoding of the "alg" parameter

For example, if the armored data is "Tm90IHJlYWxseSBBdG9t" with MIME type 
application/atom+xml, then M would be the string: 
"Tm90IHJlYWxseSBBdG9t.YXBwbGljYXRpb24vYXRvbSt4bWw=.YmFzZTY0dXJs.UlNBLVNIQTI1Ng==
"

Original comment by jpanzer@google.com on 13 Apr 2010 at 11:38

• Changed state: Started

[GoogleCodeExporter]

So much extra work just to make your new message format start to get close to 
parity
with existing formats that you could just use!

Original comment by singpol...@gmail.com on 14 Apr 2010 at 4:11

[GoogleCodeExporter]

Fixed in revision 104.

Original comment by jpanzer@google.com on 19 Jun 2010 at 7:39

[GoogleCodeExporter]

Original comment by jpanzer@google.com on 19 Jun 2010 at 7:39

• Changed state: Done