Re: Consensus Text for key usage?

[Ed Gerck <egerck@xxxxxxx>]

Tim Polk wrote:

>  There are two pieces of proposed text; text for the key usage extension
> and text for the security considerations section.
>
> 4.2.1.3  Key Usage
>

No comments.  The key usage text looks fine.

> --- proposed new paragraphs for Security Considerations section

Here, I have some comments.

>     A CA may include the key usage extension and assert the
>     nonRepudiation bit when issuing a certificate.

This part is fine.

> When such a
>     certificate is delivered, it implies that the owner of the
>     corresponding private key should be warned that, in the event of a
>     dispute, he may be held responsible of the data signed with this
>     key.

I am not in favor of this entire sentence.  It fixes a context for the
NR bit which *contradicts* the key usage section (for example: "A
signature policy identifier embedded in the signed data MAY be used to
explicitly provide context.") and it unduly imposes upon the owner
of the private key a duty which the signer herself (the CA, that elusive lady)
refrains from, for example: in the case of virus, fraud, etc,. These are valid
cases and if they would be reflected in the text, we would have a repeat of a
CA's CPS, I am afraid.

So, "when such a certificate is delivered, it implies that" is not a matter to
be solved here. Rather it MAY be solved in a signature policy identifier
embedded in the signed data, it MAY be solved in the CA's CPS, etc., all
as already predicated in PKIX.

Suggestion: delete the sentence.

>     If a certificate has both the digitalSignature and the
>     nonRepudiation bit set, the owner of the private key should make
>     sure that all the environments and applications where the
>     corresponding private key is being used do not allow a misuse of
>     that private key.

I am not in favor of this entire sequence.  It is not realistic that the
owner of the private key "should make sure that all the
environments and applications where the corresponding private key is
being used" is anything.  The most we can ask is a reasonable effort,
which may not be much in the case of virus, fraud, theft, etc.  To say
otherwise is to put on the certificate subject's a burden which not even
highly-qualified CAs want to shoulder.

Suggestion: A toned-down statement might be useful, such as:

    If a certificate has both the digitalSignature and the
    nonRepudiation bit set, the private key owner should take
    justified measures to prevent a misuse of that private key.

Of course, "justified measures" are commensurate to cost and risk,
which means that the above statement is even more effective than
the original to define what the keyholder's responsibilities are (for
example, a private key used to sign money transfer justifies a
need for more precautions than a private key used to sign email messages
in a mailing list) -- and avoids the trap of requiring the whole world
to be secure. An untainable goal, which could easily make the original
clause moot by excessive requirements (not even CAs can do this).

Note: I have, on purpose, avoided the terms "reasonable measures"
because reasonableness may be difficult to define in the technical
sense, while a justification can be a letter from the ISP on which
one relies upon without (usually) further checking.

>  If that confidence can only be obtained in some
>     environments, two different certificates, one with one public
>     key and the digitalSignature bit set and another one with a
>     different public key and the nonRepudiation bit set, should be used,
>     so that the private key corresponding to the certificate with the
>     nonRepudiation bit set is only used in secure environments.

I am not in favor of this addition, which seems obvious (do not set the
NR bit unless you want to set the NR bit), costly (two certificates) and
unnecessary -- since I can use only one certificate with the NR bit set
and deny NR directly in the signed data, case by case (NR opt out mode).
Or, I can use only one certificate with the NR bit off and grant NR directly
in the signed data, case by case (NR opt in mode).

If one thinks though that saying something is necessary, I suggest, in
agreement with the change proposed above:

 If the private key owner can only prevent misuse in some environments, 
 then it is possible to use a certificate with the nonRepudiation bit 
 set and deny non-repudiation in the signed data, case by case (NR opt
 out mode); or use a certificate with the nonRepudiation bit off and
 grant non-repudiation in the signed data, case by case (NR opt in
 mode); or use two different certificates, one with one public key and
 the digitalSignature bit set and another one with a different public
 key and the nonRepudiation bit set; or use another method that could
 be justified, so that the private key corresponding to the certificate
 with the nonRepudiation bit set is not used in environments that may 
 either not conform to a non-repudiation signature policy, or be unknown.


Cheers,

Ed Gerck