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

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 :)


On the road to retirement? Check out MSN Life Events for advice on how to get there!

OpenSSL Project                       
User Support Mailing List          
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to