[Web-SIG] Secret keys (was: Session interface)

[Phillip J. Eby]

At 05:22 PM 8/16/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>Really the only "interesting" part of managing a hash-based signature is 
>>where to store the key such that all the server processes can access it, 
>>but it isn't part of your source code.  You can do that with a file on a 
>>single server, but for multiple servers it's back to the DB or else you 
>>need a way to push out configuration to the servers.  You also need key 
>>rotation such that your signatures indicate which key was used to sign 
>>them, so that people's keys don't suddenly stop working when you update 
>>your key.
>
>It would be nice if there was a standard way to get the "server's" secret 
>key (or key(s)).  Or, maybe more abstractly, to sign and confirm the 
>signature of an item, like:
>
>   signed_data = sign(data)
>   # Raises exception if there's a problem:
>   data = extract_signed_data(signed_data)

The extraction facility should probably accept an optional timeout, too, so 
that messages older than the timeout are considered invalid.


>At that level any key rotation can be hidden.  The mechanism is easy, the 
>key management is actually not "hard", but it depends on what your 
>definition of "server" is.  That would be a ripe place for 
>standardization; easy to define, useful, multiple implementations 
>expected.  But where do you stuff the functions?

In a WSGI service, as soon as we finish that spec.  :)


>   It almost seems best to have server environments create or monkey patch 
> some single module, since I can't really think of a reason that a single 
> process should have multiple keys (except maybe in Zope, which has 
> intraprocess security).

I'm not so much concerned about intraprocess security as I am with 
associating things with the right applications, and being able to use two 
independently-developed applications that depend on different key 
stores.  With WSGI, you can run discrete apps in the same server process, 
so it seems to make more sense to put that in the pipeline than a 
monkeypatched module.