Grouper Developers Forum

[David Langenberg <>]

On Wed, Jan 23, 2013 at 2:50 PM, Jim Fox <> wrote:

Chris,

Couple of comments.

We deal with the out-of-order problem a different way.  Since our
present applications use messaging to update the state of group
resources we can simply toss out any updates that arrive after
a more recent update to the same resource has been processed.
This does require maintaining a floating cache of recent resource
update times.  Looking through course enrollment updates for today,
of about 5000 membership updates only two were received out of order.


On the encryption page:

The shared secret is not so hard to revoke or change.  One easy way
to do this is store the shared secrets on a web site, protected by
client passwords.  As each client starts it accesses that page to
get the currently in use secrets.

Public key methods are convenient for signatures, as the sender can
easily distribute its public key (I tend to use MAC instead, though).
However, they are awkward for encryption.  The sender would have to encrypt a message specifically target at each client, encrypted with that client's public key.  Not an attractive situation.

Under PGP you can also encrypt a message to multiple targets.  What's really happening in that scenario is a unique message key is generated & used to encrypt the message.  Then the message key is encrypted once for each target using the target's public key.  Of course, if your objection was to message-size (as each new copy of the message key does increase the message length by a little bit) then yes you do need to weigh the tradeoffs as the number of targets for a message gets large.

Dave

--
David Langenberg

Identity & Access Management

The University of Chicago