Like the commentator, I'm also a little guy. In my case, I'm a retired guy
who got his intro to this stuff from Entrust. I got convinced that their
two (or more) -certificate solution was right, based upon the following:
If you are an employee in an organization, it is valid for the organization
to have access to your DATA but not your IDENTITY should you get run over
by a bus or tsunami. Two certificates, where the ENCRYPTION certificate's
private key is kept by the organization is thus a valid idea. This is
sometimes called Key Escrow, Key Recovery, etc. However, the organization
never has a legitimate reason to sign on your behalf. Two certificates
with different keys allow for this distinction. It also allows you, the
employee, to reclaim old encrypted material when you lose the key.
Furthermore, when the police knock down your door (as is increasingly
possible in the US) and demand your encryption key so they can scan your
computer, you can still keep your identity-proving key private, because one
assumes they would have no reason to manufacture new data signed by you.
Please note that having two certificates doesn't imply key escrow, it just
allows for it to happen when appropriate. Yet, it allows for a separation
of confidentiality and identity proof.
Well, actually, key escrow was designed in the system from the beginning.
For a shameless plug, this scheme is designed by myself. I'm giving
a brief description here, so you guys can help to see if that makes
sense.
User's keys are escrowed in a central database, completely separated
from the application system (physically and logically, on a remote site).
The escrow database is encrypted with two keys (double encryption,
one on top of another). The two keys are kept in USB tokens, separately,
then they are kept in a safe at a trusted third-party (e.g. a bank). The
2 tokens are kept at two totally different banks. The policy is that
no single person should have access to both tokens at the same time. It
requires
at least two dedicated officers to get both tokens.
There is an option too: In order to get both keys, both officers must
have a dedicated third-party witness (e.g. a well-known law firm). But
we are still evaluating if this option is really needed. This seems to be
more of policy management issue than technical issue.
The password to the token is kept with the token, in the safe at
the trusted third-party.
The issue seems to be with re-encryption of the escrow database.
For example, if the algo is found to be broken, or if the key length
is not enough anymore, then we would need to create new keys
and re-encrypt the thing. This is left as open for now.
That's it.
Yeah, I know, you have not seen the implementation, so not fair
to say if that's ok or not. This project is for a government agency,
which handles very sensitive data.
Sorry, this is getting into some non-sense unrelated to openssl.
I'll stop here :)
coco
_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
