[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [KEYPROV] My notes from today

Ming,
PIN is interesting again since normally it spans multiple keys and is
shared hence the reference mechanism used today. 

In this sense it might be better to wrap PIN as a separate KeyPackage
and refer to it from within PINPolicy

Philip

-----Original Message-----
From: Pei, Mingliang [mailto:mpei at verisign.com] 
Sent: Wednesday, March 25, 2009 6:15 PM
To: Philip Hoyer; Pasi.Eronen at nokia.com; keyprov at ietf.org
Subject: RE: [KEYPROV] My notes from today


I just add one point that we also discussed and agreed:

A key may have multiple "secrets" - for example, a PIN associated with a
key in addition to KeyValue. Keypackage means to contain one single key
and it can still conceptually cover the case. A keypackage should be
able to contain all such related information for a key. It is our data
structure choice today in PSKC that we reuse <Key> to carry a PIN. But
that was a structure choice, not the logic concept. The structure inside
Keypackage should allow a key value and PIN. The PIN is conceptually an
attribute of the key. The data structure could continue to use <Key> or
a variant within KeyPackage. KeyPackage can mostly replace the current
<Device> in PSKC but we need some more structure reorganization for
proper fit to handle all three kinds of attributes (device,
cryptographic module, and key).

- Ming

-----Original Message-----
From: keyprov-bounces at ietf.org [mailto:keyprov-bounces at ietf.org] On
Behalf Of Philip Hoyer
Sent: Wednesday, March 25, 2009 2:36 AM
To: Pasi.Eronen at nokia.com; keyprov at ietf.org
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: keyprov-bounces at ietf.org [mailto:keyprov-bounces at ietf.org] On
Behalf Of Pasi.Eronen at nokia.com
Sent: Wednesday, March 25, 2009 1:46 AM
To: keyprov at ietf.org
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
KEYPROV at ietf.org
https://www.ietf.org/mailman/listinfo/keyprov

_______________________________________________
KEYPROV mailing list
KEYPROV at ietf.org
https://www.ietf.org/mailman/listinfo/keyprov