problems to solve
Brian Eaton
It was great to meet you all and chat about public key discovery. I'm
writing up some notes about the problems I'd like to solve:
Today, lots of applications need to authenticate to gain access to
backend systems. For example, they have a username and password for a
SQL database, or an HMAC key that they use to sign requests to Amazon
S3. These secrets are the keys to the kingdom: they grant access to
lots of data, and they need correspondingly good security.
On the other hand, it's hard to provide good security for these keys.
They are easy to copy around, by accident or on purpose. And it's
hard to know whether a developer copied the key onto a post-it note,
or left source code with a copy of the secret on a USB stick.
The normal way to deal with this problem is to periodically rotate the
keys so that even if they have leaked you can recover automatically.
But that's hard to implement without taking down your application
while you coordinate the key change on the frontend and the backend.
It also is insufficient to provide really good security: a leaked key
can do a lot of damage before it gets changed.
I think this is a serious problem, and I'd like to build software to
automate the key management and rotation problem for AppEngine
applications. But it's not enough for AppEngine to provide an
automatic system for using and changing keys. I also need the systems
that appengine communicates with to automatically discover the
corresponding public keys.
With those goals in mind, here is a rough draft of a solution:
1) Application hosting platforms provide trusted security modules that
hold private keys. Application code can use the private keys, but
they can't export them.
2) Applications publish their public keys at a well-known location,
such as http://<hostname>/.well-known/oauth
3) Receiving systems look up the public keys at
http://<hostname>/.well-known/oauth, and use those keys to validate
requests.
Mike Fleming has written up a proposal for the format of
.well-known/oauth. I just uploaded his proposal here:
http://groups.google.com/group/oauth-key-discovery/web/oauth-key-rotation-2009-11-04.html
Cheers,
Brian
John Panzer
as is being discussed on the XRI thread, I think you can handle both
public keys for a host and public keys for resources on the host.
E.g., inside host-meta, as I understand things today:
1. Link Rel = "oauth-consumer" would point at or embed the keys for
that host acting as a consumer.
2. Link Rel = "describedby" Ref = "http://example.com/describedby?
{uri}" points at an individual XRD
2.1 Individual XRD Link Rel = "signature-keys" could point at or embed
the keys for that individual resource to use for signing stuff.
So then Webfinger discovery on j...@example.com for "signature-keys"
can retrieve the signing public key for Joe.
>
> Cheers,
> Brian