[
Lists Home |
Date Index |
Thread Index
]
At 8:51 PM -0500 1/6/04, Rich Salz wrote:
>That's wrong. Anything signed or encrypted will be at least as big as
>the RSA key size, which will be at least 1Kbits. Throw in base 64 and
>you're talking at least 170 bytes.
My comparison was with the actual document itself, which is normally
quite a bit bigger than 170 bytes. Can you put some time numbers on
this, which would be more relevant. How long does it take on typical
desktop hardware to do a public key encryption or decryption of a
password of 8-20 bytes?
>For example, let's say my identity is a SAML document/assertion.
>If I push that out to the client, rather than use a cookie to refer
>to identity cached in the server, than that SAML document must either
>be signed or encrypted. Adding multiple kilobytes (say 2k up to
>maybe 10k) of data to every request is not scalable. Requiring the
>server to re-validate that data on every request is not scalable.
Why would your identity be a SAML document or assertion? In the cases
we're actually talking about, your identity is likely to be an
unencrypted user name in conjunction with an encrypted password.
Does any real world browser actually support SAML?
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
