Subject: [KEYPROV] Adding status of a key to PSKC

From: "Philip Hoyer" <[email-masked]>
Date: Thu, 19 Feb 2009 15:52:30 +0100

Ladies and Gentlemen,

Whilst reviewing the NIST document and as a appendix to my analysis of
the PSKC key policy vs the SKSML permissions I came across the ability
of SKSML to transfer the status of a key.

I wanted to split this discussion from the other email thread so that we
can reach a conclusion separately.

So to summarise:

Currently PSKC does not allow transmission of a status of a key in an
explicit form.

SKSML allows transmission of the status of a key and possible values
are: 

1. The Active value indicates that the element that makes up the
document-root is currently active in the

SKMS and conforming SKCL implementations may use it within applications.

2. The Default value indicates that the element that makes up the
document root is the default element in

the SKMS, is also active, and conforming SKCL implementations may use it
within applications.

3. The Inactive value indicates that the element that makes up the
document root is not active in the

SKMS, and conforming SKCL implementations may NOT use it within
applications.

4. The Other value indicates that the element that makes up the document
root has a meaning that is

application-specific. However, conforming SKCL implementations may NOT
use it within applications.

Also according to NIST SP800-57 part1 keys have a status as described in
the following table (Section 7 of the NIST document):

7.1 Key States

A key is used differently depending upon its state in the life cycle.
Key states are defined from a

system point of view, as opposed to a single cryptomodule point of view.

1. Pre-activation state: The key has been generated, but is not yet
authorized for use. In

this state the key may only be used to perform proof of possession or
key confirmation

(see Section 8.1.5.1.1.2 and Section 4.2.5.5). Other than for proof of
possession (Section

8.1.5.1.1.2) or key confirmation (Section 4.2.5.5) purposes, a key is
not used to apply

cryptographic protection to information (e.g., encrypt or sign
information to be

transmitted or stored) while in this state. Other than for proof of
possession or key

confirmation purposes, the key is not used to process cryptographically
protected

information (e.g., decrypt ciphertext or verify a digital signature)
while in this state.

2. Active state: The key may be used to cryptographically protect
information or to

cryptographically process previously protected information (e.g.,
decrypt ciphertext or

verify a digital signature) or both. When a key is active, it may be
designated to protect

only, process only, or both protect and process. Private signature
generation keys are

implicitly designated as protect only; public signature verification
keys are designated as

process only. A symmetric data encryption key may be used for a
predetermined period

of time to both encrypt and decrypt information. When that period
expires, the key may

transition to process only (See Section 5.3.4.2) within the active
state.

3. Deactivated state: A key whose cryptoperiod has expired but is still
needed to perform

cryptographic processing is deactivated until it is destroyed. A
deactivated key is not used

to apply cryptographic protection to information, but in some cases it
may be used to

process cryptographically protected information. When a key in the
deactivated state is

no longer required for processing cryptographically protected
information, the key is

destroyed (see Section 8.3.4).

4. Destroyed state: The key is destroyed as specified in Section 8.3.4.
Even though the key

no longer exists in this state, certain key attributes (e.g., key name,
type, and

cryptoperiod) may be retained (see Section 8.4).

5. Compromised state: Generally, keys are compromised when they are
released to or

determined by an unauthorized entity. If the integrity or secrecy of the
key is suspect, the

compromised key is revoked (see Section 9.3.4). This state may be
entered from all states

except the destroyed and destroyed compromised states. A compromised key
is not used

to apply cryptographic protection to information. In some cases, a
compromised key may

be used to process cryptographically protected information, even though
the

confidentiality, integrity, non-repudiation or associations of the
information may be

suspect. For example, a signature may be validated if it can be shown
that the signed data

with its signature has been physically protected since a time before the
compromise

occurred. This processing is done only under very highly controlled
conditions where the

users of the information are fully aware of the possible consequences.

6. Destroyed Compromised state: The key is destroyed after a compromise,
or the key is

destroyed and a compromise is later discovered. Key attributes (e.g.,
key name, type, and

cryptoperiod) may be retained. This state differs from the destroyed
state in that keys in

this state are known, or suspected, to have been compromised (see
Section 8.4).

Now the question here is should we allow status to be sent with a key in
PSKC and if we do what states do we allow?

My suggestion is to add it to the container and align with NIST as the
following allowed states:

*	Pre-active -  The key MAY be used to perform proof of possession
('otp', 'cr',) or key confirmation and MUST  NOT be used for integrity,
verify, encrypt, decrypt
*	Active - The key CAN be used for all purposes as defined under
<KeyPolicy>
*	Deactivated - The key MUST not be used for algorithmic usages
other than Generate and Derive (key rollover)
*	Destroyed - The key MUST NOT be used

Thoughts?

Philip

________________________________

Philip Hoyer 

Senior Architect - Office of CTO

ActivIdentity (UK)

117 Waterloo Road

London SE1 8UL

Telephone: +44 (0) 20 7960 0220

Fax: +44 (0) 20 7902 1985

Private and confidential: This message and any attachments may contain

privileged / confidential information. If you are not an intended
recipient,

you must not copy, distribute, discuss or take any action in reliance on
it.

If you have received this communication in error, please notify the
sender

and delete this message immediately.