Magic Signatures: Key rotation and revocation

[GoogleCodeExporter]

A serious key discovery specification should have mechanisms for key 
rotation and especially revocation.  The problems:  If a private key is 
compromised, you want to be able to at least publish the fact that a key 
should not be valid after timestamp t.  You also would like to be able to 
warn people ahead of time what the planned lifetime for a key is, and (for 
retired keys) their valid time period.  So with every key you want a time 
period, possibly open ended on the upper bound.

Some initial thoughts on this were written up at 
http://code.google.com/p/salmon-protocol/wiki/SalmonPublicKeys.  A couple 
of proposals:

1. Rely on XRD Properties associated with the link from user XRD to key.  
<Property type="http://salmon-protocol.org/ns/valid-between">934340980-
93434999</Property>.  Value is a range of epoch timestamps, with a missing 
upper bound meaning "unbounded".  
2. Add the same information to the key serialization, in other words, embed 
the validity time period in the public key published info.  This would be 
two additional integers on top of the two existing integers (modulus and 
timestamp).  This would obviously be affected by the outcome of 
http://code.google.com/p/salmon-protocol/issues/detail?id=11.

In either case, discovering retired or revoked keys would need discovery 
rel values.  I think it would be sufficient to have one "this key used to 
be valid but is no longer valid, don't use it as described in the Wiki 
page.  So then you could publish up to N keys, one of which was the current 
valid one, the rest of which are retired keys.  Anyone who only cares about 
accepting currently valid keys isn't affected by this.  Anyone who wants to 
check old data or check to see if their previously accepted Salmon were 
actually counterfeit can look for the old keys.

Original issue reported on code.google.com by jpanzer@google.com on 2 Mar 2010 at 10:07

[GoogleCodeExporter]

For item 1, wouldn't it be easier to parse the timestamps
if each timestamp was referenced in its own Property element?
For example provide properties for "not-valid-before" and/or
"not-valid-after" timestamps.  A missing property would
then be treated as unbound.

Having to parse out multiple timestamps from a range of
values seems more difficult than just reading the value of
the property and verifying it's in the correct format for
a timestamp.

Original comment by mail.ton...@gmail.com on 2 Mar 2010 at 11:07

[GoogleCodeExporter]

How do you handle the case of multiple signers in
a Magic Envelope, specifically the use-case identified
in item 1 of [1]?

What affect does this have on the mechanism used to
publish multiple keys (in the case of key rotation) or
revocation lists?

Will it be necessary to include a unique identifier on
public key data?  Will it be possible to identify
one and only one public key given a resource and a
valid timestamp or timestamp range?  If not, will the
verification process need to check all valid keys
identified such that at least one matches (or all match
if required by the trust profile)?

[1] http://code.google.com/p/salmon-protocol/issues/detail?id=10

Original comment by mail.ton...@gmail.com on 2 Mar 2010 at 11:14

[GoogleCodeExporter]

The multiple signers, and multiple keys, are being addressed in issue #10.

I believe that the discovery mechanism (XRD in this case) should be the place 
where you discover different 
types of data, like which key(s) are currently valid and which have been 
revoked or retired.

So this means I'm on the hook for specifying a definite syntax for this.  I am 
not going to get to that this week 
but I will try to make whatever it is backwards-compatible with current code 
(e.g., if you don't want to look 
up retired/revoked keys, you won't be affected by this issue.)

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

[GoogleCodeExporter]

Proposal:

<Link rel="historical-magic-public-key" type="application/magic-public-key" 
href="...">
  <Property type="http://salmon-protocol.org/ns/issued">2010-04-15T12:58:43+07:00</Property>
  <Property type="http://salmon-protocol.org/ns/retired">2010-04-15T12:59:43+07:00</Property>
</Link>

Both properties are optional, and specify the valid lifetime of the key: 
[issued, retired).  Thus the key is 
valid to sign things timestamped on or after the issued timestamp, up to but 
not including the retired 
timestamp.  A missing issued timestamp is the same as negative infinity, a 
missing retired timestamp is 
the same as positive infinity.   Setting the timestamps equal means the key is 
explicitly never valid for any 
timestamp.

...and links with rel="magic-public-key" can also have these properties, with 
the caveat that the key has 
to be 'live' when it's retrieved (issued must be in the past and retired must 
be in the future).

This uses the same timestamp syntax as Atom (RFC3339, essentially) as a 
compromise between ease of 
parsing and ease of view-source-ing.

This makes no distinction between a key which has merely been retired and one 
which is actively revoked 
due to compromise, except that you can change the "retired" timestamp to be the 
date of compromise (or 
to be conservative, the issued date).  This does not force anyone to go back 
and undo prior verifications 
of course.

In all cases, currently "live" keys MUST be identified with 
rel="magic-public-key", so processors that don't 
care about key rotation can ignore it.

It is possible for a given key to be valid for on identifier but not for 
another.  This would be the case if for 
example the key were ported from one id to another.

If you attempt to verify a Salmon whose keyhash doesn't match the currently 
valid magic-public-key, you 
MAY check historical-magic-public-keys for a match & verification.  The 
timestamp to use in this case is 
the (signed) timestamp of the thing being verified.  If the key in question was 
live as of the entity's 
timestamp, then it verifies.  If the key was not live -- e.g., was not yet 
issued or was retired -- then 
verification fails.  Salmon receivers are not required to do this additional 
step (it's really only useful if 
there may be significant delays between generation of the signature and 
verification).

Original comment by jpanzer@google.com on 15 Apr 2010 at 8:16

[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:42

• Changed state: Started