Subject: Re: [KEYPROV] New proposal od PSKC schema based on discussions at IETFand terminology alignment

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 4 May 2009 23:12:34 -0700

Attached is schema update about MACAlgorithm to MACMethod. See also the
example 3 with the syntax change. There needs some text change in the
draft about MAC generation and key choice. I will update it next with
comments from Andrew, and update example for corresponding values.
 
Please review. Thanks,
 
- Ming

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Philip Hoyer
Sent: Wednesday, April 08, 2009 8:04 AM
To: [email-masked]
Subject: [KEYPROV] New proposal od PSKC schema based on discussions at
IETFand terminology alignment

Ladies and Gentlemen,

Please find attached a proposal of the new PSKC schema based on the
discussions at IETF (captured by the email below).

In this first proposal I have tried to reduce the impact of changes to
the current PSKC. Hence there are points that warrant discussion.

Here are the main changes:

1.      Aligned to the concept of Keypackage containing at maximum 1 key

2.      Added the CryptomoduleInfo to Keypackage (introducing an
extensible CryptoModuleInfoType)

3.      Removed the User from the Keypackage and left the User under Key
(I believe having the User under Key is more logical in the sense that
it is the user to whom the key is bound) I thought that at the
Keypackage level it might get confused with the user of the device)

4.      Added a UserId to the DeviceINfo to be still able to convey the
User-> Device Binding 

5.      Renamed the Usage to AlgorithmParameters

6.      Added the missing value for KeyUsage (unwrap, verify, etc)

7.      Removed redundant ref to KeyProperties (in the KeyAttributes)

Since I have tried to minimize the impact on changes currently we have
the following mapping to the concepts discussed at IETF and described in
Pasi's email below:

Key -> PSKC:Key

Key Value -> PSKC:Key.Data(Secret)

Key Attributes -> this is split into more explicit modelled concepts

Example:

        The length of OTP value (for OTP algorithms that support

        variable length OTPs) -> PSKC:Key.AlgorithmParameters

        date after which the Key should not be used,

        how access to Key functionality should be controlled (e.g. local

        PIN code) -> PSKC:Key.Policy

Key Type: this is still split as currently used in PSKS

Determines how a Key works: for example, the allowed lengths

of the Key Value, -> currently determined by PSKC:Key(algorithm)

the cryptographic operations that can be performed

(e.g. OTP computation or challenge-response) -> PSKC.Key.Policy.Usage

Cryptographic Module: ->PSKC:CryptoGraphicModuleInfo

Device: -> PSKC:DeviceInfo

Key Package: -> PSKC:KeyPackage

I believe this is already quite satisfactory.

Now in terms of where in the structure some of these elements sit we can
discuss this further:

I left KeyPolicy under Key so it would be under

<KeyContainer>

        <KeyPackage>

                <Key>

                        <Policy>

                </Key>

We can argue if we want to have under the KeyPackage directly:

<KeyContainer>

        <KeyPackage>

                <Key/>

                <Policy/>

I left Issuer under the Key as I logically assume it is the issuer of
the key and not the Issuer of the Device or Cryptomodule.

I introduced CryptoModuleInfo just containing an ID and would like input
on what needs to be added as sub elements.

<<pskc_080409.xsd>> <<PSKC_Spec_IETF_PSKC_DRAFT07_Example2.pskc>>
<<PSKC_Spec_IETF_PSKC_DRAFT03_Example1.pskc>>
<<PSKC_Spec_IETF_PSKC_DRAFT03_Example3.pskc>>
<<PSKC_Spec_IETF_PSKC_DRAFT03_Example5.pskc>> 

Please review and comment,

Philip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Philip Hoyer
Sent: Wednesday, March 25, 2009 9:36 AM
To: [email-masked]; [email-masked]
Subject: Re: [KEYPROV] My notes from today

Pasi,

I think we are getting to some consensus.

I was wondering if Key, KeyAttributes and KeyType need a bit more

analysis.

I believe that we should explicitly model KeyPolicy e.g. the Policy

governing the use of the key, hence this would be:

- Usage (encryption, decription, OTP, etc)

- permitted dates the key can be used

- permitted number of transactions

- PINPoliicy

- etc

Then we have the key and its algorithm

There is the concept of static parameters for a specific algorithm for

example

 - IV 

 - OTP length

 - format produced

And then for some algorithm types we have the concept of dynamic

values/meta_data, tied to a key for example:

 - OTP event counter

 - time drift

Now I am not sure if we need to split them out but currently in PSKC we

have modeled them separately

- dynamic value are under Key.Data (e.g. Key.Data.Counter)

- static values are under Key.Usage (e.g. Key.Usage.ResponseFormat)

The other point I wanted to make is that the User binding currently can

be on a device level AND on a Key level and the Users could be different

so maybe we should leave the user under the respective sub elements:

<KeyContainer>

<KeyPackage>

...info about Key

                        Algorithm (under here we could put the current

Key.Usage and rename them as algorithm.parameters)

                        Data (dynamic data)

                        Policy

                        ...info about User

                        ...info about Issuer

...info about Cryptographic Module

...info about Device

                        SerialNo

                        Manufacturer

                        ...info about User

                        etc

</KeyPackage>

<KeyPackage>

....

</KeyPackage>

<KeyPackage>

....

</KeyPackage>

</KeyContainer>

Philip

-----Original Message-----

From: [email-masked] [mailto:[email-masked]] On

Behalf Of [email-masked]

Sent: Wednesday, March 25, 2009 1:46 AM

To: [email-masked]

Subject: [KEYPROV] My notes from today

Writing these down before the social event... 

Key: A logical component that performs symmetric key operations using

a Key Value, Key Attributes, and other state. 

Key Value: The secret value used by a Key.  (DSKPP and PSKC treat this

as a single key, although there could be some internal structure.)

Key Attributes: Set of information that influence how the Key Value

will be used, and how the Key can be used.

   Example: The length of OTP value (for OTP algorithms that support

   variable length OTPs), date after which the Key should not be used,

   how access to Key functionality should be controlled (e.g. local

   PIN code).

Key Type: Determines how a Key works: for example, the allowed lengths

of the Key Value, the cryptographic operations that can be performed

(e.g. OTP computation or challenge-response) and their inputs,

outputs, and algorithms; and what Key Attributes can be used.

   Example: some examples of one-time password Key Types are HOTP

   [RFC4226], S/Key [RFC1760], and SecurID-AES. In DSKPP and PSKC, 

   Key Types are identified by URIs.

Cryptographic Module: A logical component that contains one or more

Keys. Can be implemented in hardware or software.

Device: The physical device implementing the Cryptographic Module.

   Example: For hardware Cryptographic Modules, a single Device

   usually contains only one Cryptographic Module. For software

   Cryptographic Modules, the Device is the host device (laptop,

   server, mobile phone, etc.), and can contain multiple 

   Cryptographic Modules.

Key Package: A data structure for moving a single Key from one

Cryptographic Module to another. Contains data about the Key (e.g. Key

Value and Attributes), Cryptographic Module (e.g. source or intended

destination Key), Device, Issuer (an organization or party that

manages some Keys -- and possibly Cryptographic Modules and/or Devices

-- or has some kind of authority over them), and User (user, account,

role, or other entity that uses the services provided by Key, or is

otherwise associated with it).

Key Container: A data structure or file containing one or more Key

Packages.

These were not discussed, but should be very straightforward:

DSKPP Client: The logical entity implementing the client part of DSKPP

protocol; communicates with an Cryptographic Module to provision Keys

to the Cryptographic Module. In case of Hardware Cryptographic

Modules, the DSKPP Client might run on a PC to which the Hardware

Cryptographic Module is connected.  In case of Software Cryptographic

Modules, the DSKPP Client could be part of the same software package

as the Cryptographic Module itself, or separate.  (The interface

between the Cryptographic Module and the DSKPP Client is not specified

in this document.)

DSKPP Server: The logical entity that communicates with the DSKPP

client; usually communicates with a server-side Cryptographic Module

so that a corresponding Key (with the same Key Value) exists also on

the server side. The interface between the DSKPP Server and the

server-side Cryptographic Module is beyond the scope of this document.

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

<KeyContainer>

<KeyPackage>

...info about Key

...info about Cryptographic Module

...info about Device

...info about Issuer

...info about User

</KeyPackage>

<KeyPackage>

....

</KeyPackage>

<KeyPackage>

....

</KeyPackage>

</KeyContainer>

--------

Best regards,

Pasi

_______________________________________________

KEYPROV mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyprov

_______________________________________________

KEYPROV mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/keyprov