Subject: Re: proposed key usage text

From: "Aram Perez" <[email-masked]>
Date: Wed, 17 Nov 1999 10:32:22 -0800

Hi Tim and Russ,

This is a good first step to clarifying the key usage bits. I do have some
comments below...

>
> Folks,
>
> In hopes of settling the key usage debate (insert laughter here) Russ
> Housley and I are proposing some minor additions in the key usage text.  We
> recognize that complete consensus regarding the nonRepudiation bit does not
> (and may never) exist.  However, this text represents a  compromise
> position that should make everyopne equally unhapppy.
>
> Please review this text and decide if you can *live with it*.
>
> 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 which protects against the signing entity
>       falsely denying some action, excluding certificate or CRL  signing.
>       In the case of later conflict, a reliable third party may deter-
>       mine the authenticity of the signed data.
>
>       Further distinctions between the digitalSignature and nonRepudia-
>       tion bits may be provided in specific certificate policies.

What is happens when both the digitalSignature and nonRepudiation bits are
set? Does one of them take precendence?

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

Does section 4.2.1.10 state that "If the cA bit is asserted, then the
keyCertSign bit in the key usage extension (see 4.2.1.3) MUST also be
asserted. If the cA bit is not asserted, then the keyCertSign bit in the key
usage extension MUST NOT be asserted."?

If there is such a tight relation, why do you need both indicators? What
should happen if one bit is asserted and not the other.

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

Shouldn't this bit have a similar relation to the basic constraint extension
as the keyCertSign bit?

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

I think this is a mistake and causes confusion. In an extreme example, since
there is no restrictions, I could have a certificate that has all the bits
set. This means that I can do the following with my asymmetric key pair:

1) sign for entity authentication and data origin authentication with
integrity,
2) sign with a non-repudiation service,
3) encrypt keys for transport using RSA like algorithms,
4) encrypt data,
5) exchange keys using D-H like algorithms,
6) sign certificates,
7) sign CRLs,
8) encrypt data using D-H like algorithms, and
9) decrypt data using D-H like algorithms.

At a minimum, the profile should list the combination of bits which are not
allowed. A few examples:

1) If keyCertSign is asserted, then the only other bit that can be asserted
is the cRLSign bit.
2) If cRLSign is asserted, then the only other bit that can be asserted is
the keyCertSign bit.
3) If keyEncipherment is asserted, then keyAgreement MUST NOT be asserted.

Regards,
Aram Perez

---

From: Ed Gerck <[email-masked]>
Date: Wed, 17 Nov 1999 11:22:40 -0800

Aram Perez wrote:

> ....
> >       services other than non-repudiation (bit 1),

RFC 2459, Section 4.2.1.3 states:

 "This profile does not restrict the combinations of bits that may
 be set in an instantiation of the keyUsage extension."

IMO, changing this (as you propose) would have two detrimental
effects: (i) impose an uniform and artificial constraint on all
applications; and (ii) change the focus from "bit usage" to
"word usage".

Then, we would need to consider all 64K combinations of  eight bits
and provide rules for their usage or exclusion -- after all, we can't just
stop at prohibiting (DS=1, NR=1) and would need to move on as

> 3) If keyEncipherment is asserted, then keyAgreement MUST NOT be asserted.

etc.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Wed, 17 Nov 1999 12:12:26 -0800

> Aram has tried to motivate (provoke?):

Obvious slip, but just so that I don't overstate my case ;-)

" we would need to consider all 256 combinations of  eight bits"

Cheers,

Ed Gerck