Re: Digital signature and non-repudiation key usage bits

Hi Bob,

See my personal opinions and comments below:

>I'm sorry that I wasn't able to attend the IETF meeting where we might 
>have been able to resolve some of these items, but the slow pace of 
>e-mail at least allowed me to review the thread and form some conclusions.
>
>I believe that we can agree on at least two things:
>
>1.  The Digital Signature key usage is an important indicator in those 
>environments where key strength may be limited and/or key escrow
>required, _except_ for keys whose usage can be proven to be restricted
>to benign applications, e.g., digital signatures.  (Actually proving that
>to the satisfaction of the export/import/use authorities isn't all that easy,
>especially in a general-purpose API environment, but the PKIX group
>doesn't need to concern themselves with those kinds of details.)

I do not think that key usage should be tied to any key strength and/or key
escrow requirements. There are many valid *security* reasons to limit how a key
is used.

>
>2.  There is a strong desire to have the Non-Repudiation bit serve as
>an indication of a conscious, volitional act that may have significant 
>legal consequences.

Does this mean that unless there is *always* "a conscious, volitional act"
Non-Repudiation can never occur?

>
>(Although there might be some benefit to having defining an "authentication 
>service" that would be distinct from the nonrepudiation service, there wasn't 
>much support for that, especially if it would mean trying to push a defect 
>report through X.509.  So I've given up on that thrust.)

I'd be glad to support pushing a defect report. They never should have
overloaded the key usage extension. They have overloaded the extension with 1)
usage of the key, 2) services the key may provide, and 3) limiting what the key
may signed.

>
>So let's think about what the implications of the NR bit ought to be.
>
>For one thing, as some people on the legal side of the house have argued,
>in order to forestall the "Grandma hits the wrong button and loses her house"
>argument against PKI and digital signatures in general, we need to require
>a "gravity charge" be provided in the software in this case.  It should say something 
>like: "Warning. You are about to sign something using a Non-Repudiation 
>key, which may give rise to legal consequences for which you may be 
>held personally and uniquely liable or responsible. Do you want to continue?"

As someone else already pointed out, this assumes that the application can parse
the certificate. Also, it assumes the the underlying crypto API takes the
certificate to do the sign operation and not the private key.

>
>In addition to the gravity charge, it would certainly be desirable to have 
>an additional level of password or even biometric controls that are applied in 
>order to unlock the NR key.  This not only underscores the serious, ceremonial 
>aspect of a legally binding signature, it helps to assure that that user and that user 
>only has access to that key.
>
>(I'm using the term "NR key" to avoid the awkward phrase, "the private 
>key that is logically associated with the public key which is included in a 
>certificate which has a Non Repudiation keyUsage parameter specified."  
>Besides, although some applications and/or APIs may not associate 
>the corresponding public key attributes with the private key, I 
>believe that most applications will in fact do so.)
>
>Since the absolute quintessence of non-repudiation in the technical sense is that
>only the authorized holder of the corresponding private key could have possibly
>signed the document which is validated by the NR certificate, it is essential that 
>access to that key be uniquely restricted to that user.
>
>At the risk of being obvious, that means that:
>
>1.  It must be computationally infeasible in the strictest sense for any other person 
>than the authorized user to computer or rederive the private key. that includes the 
>software vendor, the user's MIS department, the various export/import authorities,
>etc.
>
>2.  Likewise, it means that all possible precautions must be taken against 
>the possibility
>that even the authorized user could, accidentally or deliberately, disclose 
>or give away 
>knowledge of or access to so much as a single bit of the private key, or of 
>the entropy 
>from which it was derived.
>
>3. And again, it must not be possible for even the user's supervisor or MIS department 
>to replace the user's private key with another private key that matches a certificate 
>containing the user's identity information or rights access.  (The CA may 
>be able to issue
>a certificate corresponding to a bogus private key, but the network 
>administrator, directory
>administrator, etc., must not be able to do so, or to cause it to happen.)

Don't these 3 items apply to digital signatures when used for authentication?
While digital signatures provide integrity, you usually want more than integrity
(otherwise why use digital signatures?). Thus, if my supervisor can replace my
private key, then he can impersonate me.

>
>(It is one thing to say that "such and such cannot happen," and it is quite 
>something else to say so both qualitatively and quantitatively, in other words to 
>express a degree of confidence that is based on scientific evidence that has been
>independently and objectively weighed by accredited evaluation authority. But that 
>begins to go down the path that Stefan is talking about in his "Qualified certificate"
>profile, and includes measures of the operating system security, the 
>cryptographic security,
>etc.  I believe that those measures are very important and worthwhile, but I'd like to
>stick to just the keyUsage definitions for the moment.)
>
>In a sense, the NR bit goes further than my definition of the DS bit, in 
>that the DS bit 
>implies that the private key is not subject to governmental escrow as a 
>condition of its 
>export, import, or use, while the NR bit implies that the private key is 
>not subject to 
>ANY form of externally imposed escrow, key recovery, or key sharing.

I strongly disagree! Don't confuse the issue by bringing in key escrow, key
strength, key recovery, etc. into the picture. If I can coin a new phrase (and
I'm not trying to insult you, I highly respect your opinions): KISS - Keep It
Secure Stupid!

>
>So what does this imply about various combinations of key usage bits?
>
>Clearly, the use of the DS bit and either key exchange or data encryption is not 
>valid, as they are diametrically opposed concepts.

YES!!

>
>Equally clearly, the use of both the DS and the NR bit _is_ allowed.

YES!! If I could, I would require the DS bit to be set anytime the NR was set.

>
>But surprisingly, as I just realized while driving in to work this morning, the use 
>of the NR bit in combination with key encryption or data encryption is NOT prohibited,
>and in fact can be used as a form of back-handed specification of a key that can be 
>used for encryption and is not subject to escrow or sharing!

NO!! Do not mix key usage. To provide Non-Repudiation, you have to sign
something and hence that key should not be used for encryption.

>
>Using the same key for both encryption and for a digital signature is subject to a 
>number of potentially serious security problems, but it is not in and of 
>itself a security flaw.

What would be a security flaw?

>That is the assumed or default case, where none of the key usage bits are specified.
>
>Using a key that is marked for both NR and key or data encryption does NOT mean that 
>it is being used for digital signature, however -- at least with the above 
>definition. But it 
>does mean that that key is uniquely and exclusively associated with that user, which
>in many cases is a very desirable condition.
>
>So KR by itself or KR plus data encryption is OK.
>
>KR plus DS is OK.

I would prefer NOT OK.

>
>DS by itself is OK.
>
>DS plus data encryption is forbidden.

YES!!

>
>Does this make sense?

In general yes, but where does this leave a question I previously posted: "What
happens when there is more than one certificate for a key?" Who ensures that
there are no conflicting key usage in the different certificates?

Regards,
Aram Perez
Apple Computer, Inc.