Re: German Key Usage

["Aram Perez" <aram@xxxxxxxxx>]

[Stand on soap box]

Security 101: Any key (whether symmetric or asymmetric) should have one and only
one use/purpose. Typically the uses are: 1) Key Exchange (or key encrypting), 2)
Data encryption, and 3) Signature (or binding).

[Step down from soap box]

Just because you can do something technically does not mean that you should do
it. There are plenty of security reasons why you should not use one key for more
than one purpose.

Non-repudiation is more of a "business/legal" concept than a technical one.
Asymmetric signatures can provide the property of non-repudiation only if you
are 100% assured that the signer is the only entity that has access to the
private key. I'm anxiously waiting for the first lawsuit related to the
"non-repudiation" of a business transaction (performed with a private key stored
on a file).

My two cents,
Aram Perez
Apple Computer, Inc.

>     All,
>     
>     I agree. What's wrong with one key/cert for 
>     keyExchange/Encipherment *and* digitalSignature and a second for 
>     nonRepudiation? 
>     
>     Still two keys/certs: The first is used for privileges/access to 
>     resources either encrypted or protected by some AC mechanism 
>     requiring remote I&A. The second is used for consciously created 
>     signatures that may have to stand up in court. 
>     
>     This would appear to be the most fundamental distinction of 
>     services from the user's or replying party's perspective.
>     
>     keyUsage is an assertion by the CA, so this split makes sense from 
>     the PKI's perspective, as well: The primary functional difference 
>     from the CA's point of view is the promise to support 
>     non-repudiation by archiving certs/CRLs beyond all statutes of 
>     limitations and that it has not archived a copy of the associated 
>     private key. 
>     
>     What I hope disappears is any possibility of interpreting 
>     nonRepudiation "service" as applying to notaries and timestamps! 
>     These are applications which require nonRepudiation keyUsage like 
>     anybody else.
>     
>     Paul 
>     
>      
>
>
>______________________________ Reply Separator
>_________________________________
>Subject: RE: German Key Usage
>Author:  lars.gu.johansson@posten.se [SMTP:lars.gu.johansson@posten.se]  at 
>DISAHUB
>Date:    8/13/98 10:14 AM
>
>
>Key users,
>     
>Seems to me that everyone agrees that it is essential
>to separate the two security services authentication and 
>non-repudiation by using different keys. That's why I've 
>previously supported the idea of never mix these key 
>usages (DS and NR) in the same certificate.
>     
>However, if the intepretation of the bits, as some of you 
>point out, should be that digitalSignature (DS) indicates a 
>MECHANISM wheras nonRepudiation (NR) is a SERVICE,
>then indeed can there be a good reason for having both 
>bits set.
>     
>In order to still achieve the separation of the authantication 
>and non-repudiation service, I would propose the addition
>of yet another key usage bit, namely the authentication (A) 
>SERVICE bit!
>     
>That could make sense: either the keyUsage field of the 
>certificate has DS+A set, indicating an authentication 
>service based on a digital signature mechanism. Or the 
>certificate would have the keyUsage field set to DS+NR, 
>indicating a non-repudiation service based on a digital 
>signature mechanism.
>     
>(Thinking of it: Wouldn't it also be possible to implement an 
>authentication service based on an data-encipherment 
>mechanism? If so, then the keyUsage would be DE+A)
>     
>The drawback of this aproach is that it adds further complexity 
>to an already quite complex concept. My only concern is that
>we can agree on ONE solution that everyone interpret the same 
>way. Perhaps it's better to stick to the original idea of never 
>combining the DS and NR bits? Opinions?
>     
>/Lars Johansson
>
>+-------------------------------------------------------------+
>+ For information about the cert-talk mailing list, including +
>+ archives and how to subscribe and unsubscribe, visit:       +
>+          http://mail.structuredarts.com/cert-talk           +
>+-------------------------------------------------------------+