[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed key usaged text -- the final round
Tim and Russ,
> To people who still care about NR:
I care.
> 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 ...).
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" <BJUENEMAN@novell.com>
>
> 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
> 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.