they listed several financial institutions as well as some gov. operations
http://www.sigaba.com/
random saml related references ....
http://www.garlic.com/~lynn/aadsm11.htm#19 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#6 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#58 Time to ID Identity-Theft Solutions
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aepay10.htm#57 SAML Just The Start For Web Services Security
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay11.htm#1 Sun releases Liberty-enabled software
At 09:38 AM 1/16/2003 +0100, Birger Toedtmann wrote:
Hi,--
can anyone pinpoint me to some papers on this - the Net did not show
up anything useful (and I hope it's not my lacking competence in using
Google).
I'd like to use a server to share documents between users. The users
are grouped, i.e. a user of group A should not be able to read the
docs of group B (if not a member of it). There are conceptually two
possible ways to design this:
* use an "out-band-process" (an operating system watching over
file permissions, a web service verifying user credentials etc.)
* use in-band crypto on the document itself, i.e. the "permissions"
are inherently tied to the bits it consists of
I wanted to use the latter with a critical constraint: ease of deploy-
ment (at least in a sense) which basically means that we don't want
to write a new client but use freely available ones. So my first
guess was to PGP-encrypt the files on the server using the public
keys of the group-members. The server obviously should not have the
secret keys of them. I further assume that (a) a member-no-more takes
his secret key with him and (b) the server may be hacked but the hacker
should not be able to read the documents (but may corrupt/delete them).
So far, so good. Now a user leaves a group. As the server is not
able to decrypt files and we don't want someone to decrypt 1000 files
of a group and re-encrypt them again with the members left, it would
be possible to just encrypt the already-crypted file again with the
"new" group of the remaining members (adding sort of a second armor).
Despite this being quite stressing for users if a file has some-20
armors, I did not come up with an idea for adding *new* members to a
group....
Well, maybe I'm already on the wrong track for this issue, so I
appreciate any suggestions or hints to sites/papers discussing these
problems.
Regards,
Birger T�dtmann
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Anne & Lynn Wheeler [EMAIL PROTECTED], http://www.garlic.com/~lynn/
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
