Magic Signatures: Multiple signatures

[GoogleCodeExporter]

Right now there's no way to add multiple signatures to a magic envelope 
without having envelopes-inside-envelopes.  It would be useful to be able to 
add multiple signatures in at least 2 cases:
1) Robustness during key rotation, where an author generates a new public 
key, but has an overlapping period during which both old and new public keys 
are active (requires a way to identify old and new public keys via 
discovery).
2) Handling the multiple author case.  This is an edge case but the 
specification allows it.  A concrete example might be a "friend" activity 
where there are two authors jointly attesting to the friend relationship.

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

[GoogleCodeExporter]

Can you allow multiple <me:sig> elements in the <me:env>
element, provided:

- They MUST use the same algorithm and encoding parameters
as recorded in the envelope.

- They provide the actual public key data (e.g. as a data: URI)
or an identifier that maps to one and only one public key.

- When multiple signers are present, they SHOULD include a
signer attribute whose value is an URI that identifies the
signer.

For provenance in Salmon, the signer attribute should match one
of the authors identified in the salmon encoded in the
<me:data> element.

Original comment by mail.ton...@gmail.com on 2 Mar 2010 at 10:54

[GoogleCodeExporter]

While I support most of what Tony Evans suggests, I really think that we should
discourage or even forbid embedding of key data in Salmon.

Much of the goodness of Salmon's signature strategy is that it links objects to 
the
identifiers of those who create the signatures. Doing this allows us to support
revocation of keys and all sorts of other related functions without increasing 
the
complexity of messages themselves. If we permit the keys to be published with 
the
Salmon, I think it will only be a question of time before people start trying to
extend the specification to provide all sorts of PKI services for those 
embedded keys.

If the community insists on permitting key data to be embedded, I think it is
reasonable that we require that identifiers MUST also be provided and that any
embedded key data should be considered invalid if resolving the identifier does 
not
result in discovering equivalent data.

Original comment by bobwyman on 5 Mar 2010 at 5:58

[GoogleCodeExporter]

For key identifiers, I'm thinking that something like the key hash adopted by 
KeyCzar 
(http://code.google.com/p/keyczar/wiki/KeyHash) would be a good choice.  It's a 
SHA-1 hash 
of a public key's bytestream representation, truncated to the first 4 bytes of 
the hash 
output.  So it's a number between 0 and 4B, and hopefully will uniquely 
identify each key 
used within each message, but you still have to retrieve the actual keys and 
the hash just 
serves to accelerate selection of the right key(s).

As an aside, the KeyCzar key format uses a simple JSON structure and I may 
propose switching 
to it (http://code.google.com/p/keyczar/wiki/RsaPublicKey) for Salmon.  It's 
nearly 1:1 with 
Salmon's quick and dirty format.  It'd be fine for me to do this but it would 
require anyone 
doing key parsing to either have a JSON interpreter or a one-off parser that 
can slurp up a 
simple JSON object with string and integer fields.

Original comment by jpanzer@google.com on 5 Mar 2010 at 6:41

[GoogleCodeExporter]

Why use a truncated hash? If we assume 2 random keys per message, then with a 4 
byte 
truncated hash we'd expect a collision every 65k messages. Which ain't so hot.

Hashes are fine as key IDs, but why choose a hash that is likely to collide?

Original comment by benl@google.com on 6 Mar 2010 at 10:33

[GoogleCodeExporter]

PROPOSED:

1. Relax requirements to allow multiple me:sig elements, all of which share the 
same algorithm, and change 
the JSON sig to be "sigs" and make it a list of objects.
2. Each signature gets a keyid, a string which is a hash (see #3) of the key 
used for signing.  This also 
identifies the signing author.
3. Keys are identified by hashes of their content.  Exact algorithm TBD.

Ben:  You should ask the keyczar folks why they're using hashes that can 
collide :).  In practice I don't think 
there's a huge problem either way -- the code would either just fail fast if 
the first key found by hashval 
doesn't validate, or it would fail slowly after trying all keys found by the 
hashval.  In practice the probability 
of a collision is vanishingly small so I don't think it would slow anything 
down, and truncating the hashes 
keeps the size small.  But if the hashes aren't too big anyway we might as well 
just use the full hash.

Please yell if you see a problem with this proposal.  Again, this would be a 
breaking change and I hope to 
make it by EOW.

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

• Changed state: Accepted

[GoogleCodeExporter]

I don't need to ask Keyczar, because it was my design. The short hashes are 
there for a 
bunch of reasons, but they're short to conserve space. Salmon does not need to 
conserve 
space and so should, IMO, use full-length hashes as key IDs.

If you don't, then every time you want to talk about a key, you'll have to 
either show 
the key, or sign something with it. And, OK, I said Salmon didn't need to 
conserve 
space, but doing this every time you mention a key seems excessive.

Original comment by benl@google.com on 9 Apr 2010 at 6:00

[GoogleCodeExporter]

SHA256 hashes would look like 'axeZ5Sfn3LzV6EyQuEK+AwYt92r9qw4mU/R9dplHAPg=' 
which I think is 
okay as a key ID.  If no one yells I'll just do that.  

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

[GoogleCodeExporter]

Proposed change in detail:

(1) "sig" can be repeated multiple times, each with an additional attribute 
"keyhash".
(2) "keyhash" is the base64url encoding of the sha256 hash of the public key's 
serialized 
format from the Simple Public Key Infrastructure section.
(3) All signatures share the same alg/encoding/etc. per Tony's remarks.

Examples follow.

XML:
<me:sig keyhash="4k8ikoyC2Xh+8BiIeQ+ob7Hcd2J7/Vj3uM61dy9iRMI=">
EvGSD2vi8qYcveHnb-rrlok07qnCXjn8YSeCDDXlbhILSabgv
NsPpbe76up8w63i2fWHvLKJzeGLKfyHg8ZomQ
</me:sig>

JSON:
"sigs": [
  {
     "value": "EvGSD2vi8qYcveHnb-rrlok07qnCXjn8YSeCDDXlbhILSabgv
NsPpbe76up8w63i2fWHvLKJzeGLKfyHg8ZomQ",
     "keyhash": "4k8ikoyC2Xh+8BiIeQ+ob7Hcd2J7/Vj3uM61dy9iRMI="
  }
]

So you always have an array in JSON, even for the standard case of one 
signature.

The keyhash identifies the signing key used and therefore the signatory author. 
 It's legal 
for only one of N claimed authors to sign -- the semantics of this are up to 
the receiving 
application (it's the signatory author asserting a claim that other people also 
contributed).

The keyhash does not require any modification to the magicsig key format.

The keyhash is also useful to select keys if there are multiple potential keys 
for a given 
author.

Original comment by jpanzer@google.com on 14 Apr 2010 at 11:24

• Changed state: Started

[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