Subject: proposed key usaged text -- the final round

From: Russ Housley <[email-masked]>
Date: Wed, 24 Nov 1999 15:43:37 -0500

To people who still care about NR:

In a last ditch hope of settling the key usage debate Tim Polk and I have 
made minor adjustments to the key usage text.  We hope that this is text 
that everyone can live with (but we know that there are some people who 
will feel compelled to argue on and on and on and on and on and on ...).

We believe that the PKIX Working Group Chairmen will have to determine 
whether or not we have reached rough consensus or not.

Thanks,
   Tim Polk and Russ Housley

----Proposed text for 4.2.1.3 Key Usage

4.2.1.3  Key Usage

    The key usage extension defines the purpose (e.g., encipherment, sig-
    nature, certificate signing) of the key contained in the certificate.
    The usage restriction might be employed when a key that could be used
    for more than one operation is to be restricted.  For example, when
    an RSA key should be used only for signing, the digitalSignature
    and/or nonRepudiation bits would be asserted. Likewise, when an RSA
    key should be used only for key management, the keyEncipherment bit
    would be asserted. When used, this extension SHOULD be marked criti-
    cal.

       id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }

       KeyUsage ::= BIT STRING {
            digitalSignature        (0),
            nonRepudiation          (1),
            keyEncipherment         (2),
            dataEncipherment        (3),
            keyAgreement            (4),
            keyCertSign             (5),
            cRLSign                 (6),
            encipherOnly            (7),
            decipherOnly            (8) }

    Bits in the KeyUsage type are used as follows:

       The digitalSignature bit is asserted when the subject public key
       is used with a digital signature mechanism to support security
       services other than non-repudiation (bit 1), certificate signing
       (bit 5), or revocation information signing (bit 6). Digital signa-
       ture mechanisms are often used for entity authentication and data
       origin authentication with integrity.

       The nonRepudiation bit is asserted when the subject public key is
       used to verify digital signatures used to provide a non-repudiation
       service.  This service protects against the certificate subject
       falsely denying signing the data, excluding certificate or CRL
       signing. In the case of later conflict, a reliable third party may
       determine the authenticity of the signed data.

       Further distinctions between the digitalSignature and nonRepudiation
       bits may be provided in specific certificate policies.  The values
       of the digitalSignature and nonRepudiation bits is insufficient to
       determine the intentions of the certificate subject.  The context
       in which the data was signed MUST also be considered.  A signature
       policy identifier embedded in the signed data MAY be used to
       explicitly provide context.

       The keyEncipherment bit is asserted when the subject public key is
       used for key transport.  For example, when an RSA key is to be
       used for key management, then this bit shall asserted.

       The dataEncipherment bit is asserted when the subject public key
       is used for enciphering user data, other than cryptographic keys.

       The keyAgreement bit is asserted when the subject public key is
       used for key agreement.  For example, when a Diffie-Hellman key is
       to be used for key management, then this bit shall asserted.

       The keyCertSign bit is asserted when the subject public key is
       used for verifying a signature on certificates.  This bit may only
       be asserted in CA certificates.  If the keyCertSign bit is
       asserted, then the cA bit in the basic constraints extension (see
       4.2.1.10) MUST also be asserted. If the keyCertSign bit is not
       asserted, then the cA bit in the basic constraints extension MUST
       NOT be asserted.

       The cRLSign bit is asserted when the subject public key is used
       for verifying a signature on revocation information (e.g., a CRL).

       The meaning of the encipherOnly bit is undefined in the absence of
       the keyAgreement bit.  When the encipherOnly bit is asserted and
       the keyAgreement bit is also set, the subject public key may be
       used only for enciphering data while performing key agreement.

       The meaning of the decipherOnly bit is undefined in the absence of
       the keyAgreement bit.  When the decipherOnly bit is asserted and
       the keyAgreement bit is also set, the subject public key may be
       used only for deciphering data while performing key agreement.

    This profile does not restrict the combinations of bits that may be
    set in an instantiation of the keyUsage extension.  However,
    appropriate values for keyUsage extensions for particular algorithms
    are specified in section 7.3.

---

From: Ed Gerck <[email-masked]>
Date: Wed, 24 Nov 1999 14:39:36 -0800

> will feel compelled to argue on and on and on and on and on and on ...).

Russ and Tim:

Fine. The changes are IMO enough to capture the main points that I saw
worthwhile to discuss on and on and on ;-)  The inclusion of "falsely"
is now also in IMO fine, because it is clearly seen from the relying-party
viewpoint.   I have just one minor comment that is most probably just a
text glitch that can easily be corrected:

The text:

should be:

 The dataEncipherment bit is asserted when the subject public key
 is used for enciphering data other than cryptographic keys.

[i.e., deleted "user" and the comma]

Thank you both for the fine job!

Have a Great Thanksgiving.

Cheers,

Ed Gerck

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 Nov 1999 11:52:00 +0100

Tim and Russ,

> To people who still care about NR:

I care.

> will feel compelled to argue on and on and on and on and on and on ...).

I am not going to die with the proposed text :-) ... However, there
are two sentences that are rather obscure or not helpul and I would
like to take advantage of some earlier E-mail exchanges to
canibalize these exchanges in order to improve the text. The two
last sentences of the section explaining the NR bit could be deleted
without loosing much:

        [The nonRepudiation bit is asserted when the subject public
key is
        used to verify digital signatures used to provide a
non-repudiation
        service].  This service protects against the certificate
subject
        falsely denying signing the data, excluding certificate or
CRL
        signing. In the case of later conflict, a reliable third
party may
        determine the authenticity of the signed data.

Then we could take advantage of a letter sent on November the 18 th
by David P. Kemp proposing to turn back the clock to April 29, in
order to follow a proposal from Bob Jueneman. 

" > Date: Fri, 30 Apr 1999 13:37:05 -0600
  > From: "Bob Jueneman" <[email-masked]>
  > 
  > Recently, we have been having some discussion regarding 
  > Nonrepudiation on the cert-talk list, and I have been taking the 
  > position that the Nonrepudiation key usage bit should be
reserved
  > for those key pairs that are used exclusively to indicate the
user's
  > conscious and willing intent to be legally bound by what is
being 
  > signed.

  I agree with Stefan and Peter that we should turn back the clock
to
  April 29, and use the bit to specify exclusively concrete usage of 
  the key by applications."

There was no text proposal at that time. Using this input, (and
replacing "legally bound" by the notion of "endorsement" that
contains less legal sensitivity) I propose to keep the first
sentence unchanged and have the following global replacement for the
three sentences:

" The nonRepudiation bit is asserted when the subject public key is
used to verify digital signatures used to provide a non-repudiation
service. When present, the nonRepudiation bit indicates that the
private key corresponding to the subject public key present in that
certificate may be used to indicate the user's conscious and willing
intent to endorse what is being signed." 

I would also propose to add a note that explains the case of a
certificate having both the DS and the NR bits set and to place this
addition at the end of the whole section 4.2.1.3:

" Note: A certificate with the nonRepudiation bit set should only be
used when it is possible to get full confidence of the environments
where the private key will be used. If a certificate has both the
digitalSignature and the nonRepudiation bit set, the entity owning
the private key should have full confidence of all the various
environments and applications where the private key will being used.
For the cases where that condidence cannot be obtained, two
different certificates, one with one public public key and the
digitalSignature bit set and another one with a different public key
and the nonRepudiation bit set, should be used." 

Denis

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 25 Nov 1999 06:32:59 -0500

Russ and Tim,

Well done!!!!!

I can certainly live with this.

/Stefan

---

From: Ed Gerck <[email-masked]>
Date: Thu, 25 Nov 1999 10:01:02 -0800

Denis Pinkas wrote:

> I am not going to die with the proposed text :-) ...

But, perhaps we could all live with it ;-) and move on ....

> However, there are two sentences that are rather obscure or
> not helpul and I would like to take advantage of some earlier
> E-mail exchanges to canibalize these exchanges in order to
> improve the text. The two last sentences of the section
> explaining the NR bit could be deleted without loosing
> much:
>
>   [The nonRepudiation bit is asserted when the subject
>   public key is used to verify digital signatures used to
>   provide a non-repudiation  service].  This service protects
>   against the certificate subject falsely denying signing the
>   data, excluding certificate or CRL signing. In the case of
>    later conflict, a reliable third party may determine the
>    authenticity of the signed data.

I disagree -- the first sentence explains what the NR bit is used
for (to verify digital signatures) in a specific context ( to provide
a non-repudiation service), in contrast to explaining what the service
is and why it would be useful to use it (protects against the
certificate subejct falsely denying signing).

If you believe that it could be deleted without loosing much, and
in fact something *is* lost, then it is IMO better to keep it and be clear
in a subject which has been unclear for far too long.  I would rather we
would not need to beat this horse dead an umpth-time.

> I propose to keep the first sentence unchanged and have the following
> global replacement for the three sentences:
>

I disagree -- is there anything more "rather obscure or not helpul"
than "the user's conscious and willing intent"?  So, the change IMO
is in contradiction with the purpose. Further, "to endorse" may have
different legal meanings in different jurisdictions ("endorsement
sans recourse" in the UK is one of the few that does not have legal
consequences, but it needs to have the "sans recourse" appended
to it and it is not valid in civil law regimes where almost anything that
you do flows back to the original agent -- you).

Finally, I would lint anything that predicates measuring, assessing,
controlling or even estimating "the user's conscious and willing
intent" in PKIX because if there is anything that no law, policy or
dictatorship has ever managed to do is to control people's "conscious
and willing intent" -- so, this is a slippery slope which was already
debated, spotted and marked as leading nowhere in an Internet
protocol; and debating this on and on and on and on will not change
it or make it valid by repetition.

Gosh, if we can't even say *who* the sender is, *what* path did that
message take, *if* the full communication of the sender with all its follow
up certified partial messages arrived or if there was a partial or total denial
en route which was blocked by an attacker, then how can we say what
that unknown person in an unknown place with an unknown communication
*intented* to say???

> and the nonRepudiation bit set, should be used."

I do not want to sound in opposition to your entire email, but I also
disagree. This is an "explanation mode" definition which is repetitive
("possible to get full confidence of the environments where the private
key will be used" and "should have full confidence of all the various
environments and applications where the private key will being used");
predicates an impossible condition (full confidence) in an overbroad
context (all  the various environments where the private key will be
used); indeterminate ("For the cases where that condidence cannot
be obtained"); ineffective ("two different certificates ..."); and
contradictory (why would two wrong certificates make a right one?)

Cheers,

Ed Gerck

---

From: Tim Polk <[email-masked]>
Date: Fri, 26 Nov 1999 16:22:33 -0500

Denis,

We thought you might.  :-)

I've cut and pasted a bit to asssist those reading along at home...  I
trust I haven't altered your intent.

non-repudiation

I prefer our text, since it sticks to the definition of the service.  The
certificate subject can use their private key for anything they'd like. 
The question for the key usage extension is, "Should I use this public
key to implement this service?".  I believe our text describes the
general case, yours an important specific case.

Russ and I worked very hard to remove the word "intent" in our latest
proposal.  Intent can only be indicated through context, such as the
signing policy that ETSI has proposed.  This specification cannot do a
thing to ensure that any particular signature was generated conciously
and willingly.

Since our text includes your case, and ETSI is already working on the
mechanisms to describe the signing context, I think our text is a good
middle ground.

I substituted "issued" for "used" in this paragraph.  I'm assuming you
are talking about how a CA determines *which* bits should be asserted. 
Is that right?  On that assumption, I think it is a policy issue or a
security consideration.  [Side note:  What do you mean by "full
confidence"?]  The next paragraph points to the policy for additional
information. 

The other possibility would be the security considerations section.  It
could build on the current text, which includes the folowing:

<bigger>

   The protection afforded private keys is a critical factor in main-

   taining security.  On a small scale, failure of users to protect

   their private keys will permit an attacker to masquerade as them, or

   decrypt their personal information. [stuff about CA keys deleted]

</bigger>

Adding the following paragraph might address your concern:

      A CA may include the key usage extension and assert the
nonRepudiation bit

      when issuing a certificate.  This implies that a reliable third
party will

      be able to determine the authenticity of signed data in the event
of a dispute.

      If the certificate subject uses the private key in an insecure
environment,

      it may be difficult to detect or prevent key compromise.  This
could prevent a 

      reliable third party from determining the authenticity of signed
data.  A CA

      should consider the environment of the private key before asserting
the

      nonRepudiation bit.

I know this text is very rough, but would this serve your purpose?

Thanks,

Tim