Re: proposed key usaged text -- the final round

[Stefan Santesson <stefan@xxxxxxxxxxx>]

Russ and Tim,

Well done!!!!!

I can certainly live with this.

/Stefan

At 15:43 1999-11-24 -0500, Russ Housley wrote:
>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.