[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Consensus Text for key usage?
Folks,
With Aram and Denis back in the fray, I think we can finish this one off.
I have incorporated all the changes, and think we may be nearing consensus!
There are two pieces of proposed text; text for the key usage extension
and text for the security considerations section.
Please read it carefully. In general, the changes were all introduced on
the list in the "porposed" thread, but I have tweaked a couple of other
paragraphs. The only real suprise is that I capitulated and deleted the
word "user" under dataEncipherment. I thought keeping it would be less
controversial, but that wasn't true! I don't think it added anything, so
let's delete it.
Thanks,
Tim Polk
parties.---- 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. In the case of later conflict, a reliable
third party may determine the authenticity of the signed data.
The values of the digitalSignature and nonRepudiation bits are not
considered when validating the signature on certificates or certificate
status information. 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 be asserted.
The dataEncipherment bit is asserted when the subject public key
is used for enciphering 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 be 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).
Note: Unlike the keyCertSign bit, there is no relationship
between the value of cRLSign and the basic constraints extension.
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,
valid combinations of bits are specified for particular algorithms
in section 7.3.
--- proposed new paragraphs for Security Considerations section
A CA may include the key usage extension and assert the
nonRepudiation bit when issuing a certificate. 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.
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. 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.