Subject: [KEYPROV] Key Usage Policy

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Feb 2009 14:55:49 +0200

Hi all, 

the current PSKC document allows to put constraint usage on a key. The
<Usage> element has the following restrictions defined:

------------------

   <KeyUsage>:  The <KeyUsage> element puts constraints on the intended
      usage of the key.  The recipient of the PSKC document MUST enforce
      the key usage.  Currently, the following tokens are registered by
      this document:

      OTP:  The key MUST only be used for OTP generation.

      CR:  The key MUST only be used for Challenge/Response purposes.

      Encrypt:  The key MUST only be used for data encryption purposes.

      Integrity:  The key MUST only be used to generate a keyed message
         digest for data integrity or authentication purposes.

      Unlock:  The key MUST only be used for an inverse challenge
         response in the case a user has locked the device by entering a
         wrong PIN too many times (for devices with PIN-input
         capability).

      Decrypt:  The key MUST only be used for data decryption purposes.

      KeyWrap:  The key MUST only be used for key wrap purposes.

      The element MAY also be repeated to allow several key usages to be
      expressed.  When this element is absent then no key usage
      constraint is assumed, i.e., the key MAY be utilized for every
      usage.

--------------

Philip suggested to reference [1] and to extend the above list by the
following values from Table 5 of [1]: 

- Private signature key
- Public signature verification key
- Symmetric authentication key
- Private authentication key
- Public authentication key
- Symmetric data encryption/decryption key
- Symmetric and asymmetric RNG keys
- Symmetric key wrapping key 
- Symmetric master key
- Private key transport key
- Public key transport key
- Symmetric key agreement key
- Private static key agreement key
- Public static key agreement key
- Private ephemeral key agreement key
- Public ephemeral key agreement key
- Symmetric authorization keys
- Private authorization key
- Public authorization key

I think that this is a reasonable proposal. 

Philip, did I understood your proposal correctly?

Ciao
Hannes

[1]:
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Ma
r08-2007.pdf