Digital signature and non-repudiation key usage bits

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.)

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.

(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.)

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?"

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.)

(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.

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.

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

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!

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.
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.

DS by itself is OK.

DS plus data encryption is forbidden.

Does this make sense?

Bob




Robert R. Jueneman
Novell, Inc.
122 E. 1700 South
Provo, UT 84606
bjueneman@xxxxxxxxxx
1-801-861-7387