Glenn, There are a few parts of this I am confused on.
>In the cert is a private key. If the system were required to contact a >"backend" server first, passing it perhaps a cipher containing its >serial number encrypted with its private key and its identity, the When you say pass a 'cipher' do you mean pass a message? And if you mean pass a message then a public/private crypto system would encrypt this message using the backend servers public key, not its own private key. Or perhaps I have misread your posting. >server could send back a (hopefully unique to that cert) decryption key >that would decrypt the private key, allowing its use; the code at the PC >would need to erase the cleartext private key when done. The server Sending of any keys over the air like this is dangerous, thats what makes public/private crypto systems good. The only drawback is you need a good PKI to support those users and be the CA. The CA is the only authority the system should 'trust' when it comes to certificate validation and revocation. Which means a second 'backend' server may not fit well into this picture. >could check the serial number matched the "identity" (it would have the >public key) to prevent a simple search of the server for these >encrypting keys. I am not sure I understand this last part, please elaborate. ---------------------------------------- Chris Key ID: 7E8DE44E [EMAIL PROTECTED] ---------------------------------------- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/