Re: dual-use digital signature [EMAIL PROTECTED]

2004-07-26 Thread Anne Lynn Wheeler
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]


Re: dual-use digital signature [EMAIL PROTECTED]

2004-07-26 Thread Richard Levitte - VMS Whacker
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]

2004-07-26 Thread Anne Lynn Wheeler
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]