Re: dual-use digital signature [EMAIL PROTECTED]
At 02:00 PM 7/26/2004, Richard Levitte - VMS Whacker wrote: That's all and well, but I can't see why that would be interesting to a generic, third-party CA. If you're talking about a CA within the same corporation, then I can understand, since they usually (as far as I can guess) work from a different standpoint and with different priorities. What you describe feels to me like encryption is ill understood and placed in the hands of random individuals. If you want safety and recoverability, there's nothing like one or several backups, maybe protected with different means (different encryption, different storage media (including vaults), different keys, and so on). I believe there was at least one large institutional effort where keys were generated, escrowed and loaded into hardware tokens and distributed. the persons were expected to use the hardware tokens for both authentication and encryption. if the hardware token failed (like if the battery died), they could get a new hardware token issued with the same keys. the obviously needed the original keys if they had used the hardware token for encryption (of data that turned out to be laying around someplace). however, it wasn't necessary to have escrowed keys for authentication, simply issuing a new hardware tokens with new (authentication) keys would have been sufficient (and reregistering the new public key). here is an issue where, if they're using hardware tokens for key protection ... they really need to distinguish between encryption keys and authentication keys either a single hardware token with two different sets of keys ... and the token knows how to consistently differentiate their use between encryption and authentication ... or two different hardware tokens ... consistently used for the different (business) purposes. there is a side issue with institutional delivered hardware tokens ... and if they were to replace existing shared-secret pins/passwords ... where a person might have a hundred unique shared-secrets for their various electronic relationships and potentially be issued at least one hardware token to be used in lieu of every pin/password ... and potentially a second hardware token for encryption only purposes (say in dongle form ... a key chain with 100-120 or dongles ... in need of medium sized ruck sack just to lug them around). -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: dual-use digital signature [EMAIL PROTECTED]
In message <[EMAIL PROTECTED]> on Sun, 25 Jul 2004 13:41:56 -0600, Anne & Lynn Wheeler <[EMAIL PROTECTED]> said: lynn> At 07:07 PM 7/24/2004, Peter Gutmann wrote: lynn> >A depressing number of CAs generate the private key themselves lynn> >and mail out to the client. This is another type of PoP, the lynn> >CA knows the client has the private key because they've lynn> >generated it for them. Peter, are you talking about generic CAs or in-corporation ones? I can definitely see different needs between those. lynn> one could claim that there might be two possible useage lynn> scenarios, involving two different thread models: encryption and lynn> authentication. lynn> lynn> from a business standpoint the encryption of corporate data lynn> (especially data at rest which might include some of the lynn> corporate jewels) can represent single point of failures ... if lynn> private key is required for the recovery of corporate jewels and lynn> the private key isn't reliably replicated (to avoid single lynn> points of failure); then there is a serious, corporate, lynn> overriding availability threat. That's all and well, but I can't see why that would be interesting to a generic, third-party CA. If you're talking about a CA within the same corporation, then I can understand, since they usually (as far as I can guess) work from a different standpoint and with different priorities. What you describe feels to me like encryption is ill understood and placed in the hands of random individuals. If you want safety and recoverability, there's nothing like one or several backups, maybe protected with different means (different encryption, different storage media (including vaults), different keys, and so on). - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsvägen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ - A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: dual-use digital signature [EMAIL PROTECTED]
At 07:07 PM 7/24/2004, Peter Gutmann wrote: A depressing number of CAs generate the private key themselves and mail out to the client. This is another type of PoP, the CA knows the client has the private key because they've generated it for them. one could claim that there might be two possible useage scenarios, involving two different thread models: encryption and authentication. from a business standpoint the encryption of corporate data (especially data at rest which might include some of the corporate jewels) can represent single point of failures ... if private key is required for the recovery of corporate jewels and the private key isn't reliably replicated (to avoid single points of failure); then there is a serious, corporate, overriding availability threat. the claim can be made that the trade-off for authentication and digital signature would result in no escrow or replication of private key since the overriding threat model is a) impersonation and/or b) not being able to reliably attribute certain actions to specific people. the assertion here is possible threat model confusion when the same exact technology is used for two significantly different business purposes. in general, no key escrow or no key replication is frequently bad in the encryption business process scenario ... while no key escrow or no key replication is good in the authentication/digital signature business process scenario. a problem arises when the business purpose uses of the public/private key pair isn't sufficiently described ... leading to confusion (and/or the same public/private key pair are used for different business processes with possibly conflicting threat models). -- Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
