Subject: [KEYPROV] Re Issue 21 (object model)

From: "Doherty, Andrea" <[email-masked]>
Date: Fri, 6 Jul 2007 09:45:03 -0400

Yesterday I added this message to the Issue Tracker, but for some reason
it was not propagated to the mailing list.  Here it is:

Issue 21 - new message (5 July 07)
Device pertains to something physical that the user holds, and
"cryptographic 
token", as stated in PKCS#11, "stores objects and can perform
cryptographic 
functions".  However, the use of the word "token" is often confused with
the 
physical device, and equally often confused with the software that
performs the 
functions.  In addition, note that "token" gets used in different and
equally 
confusing ways in other arenas, e.g., OASIS WS Security.  

Thus, I propose that we do not use "token".  I also propose that we
refer 
to "cryptographic module" wherever the PKCS#11 definition applies (on
first 
look, this will be almost a 1:1 replacement of "cryptographic token" 
with "cryptographic module).  With this proposal in mind, please
consider the 
following alternative to Shuh's initial object diagram:

DSKPP Basic Object Model
========================

-----------          -------------
|User     |          |Device     | 
|---------|*  owns  *|-----------|
|  UserID |--------->|  DeviceID |
|  ...    |          |  ...      |
-----------          -------------
                         | 1
                         |
                         | contains
                         |
                         | 1
                         |
                         V  (DSKPP Client)
                   -----------------------
                   |Cryptographic Module |
                   |---------------------|
                   |                     |
                   |Encryption Algorithms|
                   |MAC Algorithms       |
                   |...                  |
                   -----------------------
                         | 1
                         |
                         | contains
                         |
                         | 1
                         V
                   -----------------------
                   |Key Container        |
                   |---------------------|
                   |                     |
                   |Encryption Algorithms|
                   |MAC Algorithms       |
                   |...                  |
                   -----------------------
                         | 1
                         |
                         | contains
                         |
                         V *
                     -------------
                     |Key        | 
                     |-----------|
                     |  KeyID    |
                     |  ...      |
                     -------------

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/keyprov

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Jul 2007 17:00:48 +0200

Hi Andrea,

when we use the term "cryptographic module" as a replacement for 
"cryptographic token" then I am not sure the cardinality between device 
and "cryptographic module" is correct. Shouldn't it be 1 device may be 
have multiple "cryptographic modules"?

Furthermore, where does the "Key Container" concept come from? Cannot 
you just collapse the "Key Container" and the "Key"?
I believe that the MAC and encryption algorithms belong to the Key 
rather than to the container.

Where does the Key Type fit in there?

Ciao
Hannes

Doherty, Andrea wrote:
>                    |f        |

---

From: "Doherty, Andrea" <[email-masked]>
Date: Fri, 6 Jul 2007 11:21:18 -0400

Hannes,
I agree with your points.  The only challenge I see is that we are
referring to a Key Container in the DSKPP to include key config data
(including key type); the way the PSKC describes the object model for
Key Container implies one container for multiple devices (see
draft-vassilev-portable-symmetric-key-cointainer-02, section 6).
However, because the PSKC view pertains to server-side store more than
client-side, and since it is dealing with a broader set of use cases
than DSKPP (including bulk key provisioning and migration), perhaps it
would indeed be best to do the collapsing here, making a general
reference to "Key Container" as shown below (?) 
Andrea

DSKPP Basic Object Model
========================
                         | *
                         V  (DSKPP Client)
                   -----------------------
                   |Cryptographic Module |
                   |---------------------|
                   |Encryption Algorithms|
                   |MAC Algorithms       |
                   |...                  |
                   -----------------------
                         | 1
                         |
                         | contains
                         |
                         | *
                         V  (Key Container)
                   -----------------------
                   |Key                  |
                   |---------------------|
                   |KeyID                |
                   |Key Type             |
                   |...                  |
                   ----------------------- 

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, July 06, 2007 11:01 AM
To: Doherty, Andrea
Cc: [email-masked]
Subject: Re: [KEYPROV] Re Issue 21 (object model)

Hi Andrea,

Ciao
Hannes

---

From: "Pei, Mingliang" <[email-masked]>
Date: Fri, 6 Jul 2007 08:38:12 -0700

Attendee:

Philip Baker
Mingliang Pei

The topic focused on draft submission plan before 69-th IETF meeting. We
originally thought to have another conf call next Monday while it is a
holiday week this week but it would be too late before the submission
cut off date. We have had two meetings in the past two weeks, and have
had many comments and changes agreed. 

1. We are going to revise PSKC to include the changes agreed.
2. One concern is that some changes in PSKC may not be get to DSKPP in
time while both drafts are revising. We consider that a revised PSKC is
better for discussion in IETF. There are some issues that have not been
completely resolved, which we can discuss in IETF meeting, and update
into the draft afterwards.

- Ming

> From: Doherty, Andrea [mailto:[email-masked]] 
> Sent: Friday, July 06, 2007 8:21 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: RE: [KEYPROV] Re Issue 21 (object model)
> 
> Hannes,
> I agree with your points.  The only challenge I see is that 
> we are referring to a Key Container in the DSKPP to include 
> key config data (including key type); the way the PSKC 
> describes the object model for Key Container implies one 
> container for multiple devices (see 
> However, because the PSKC view pertains to server-side store 
> more than client-side, and since it is dealing with a broader 
> set of use cases than DSKPP (including bulk key provisioning 
> and migration), perhaps it would indeed be best to do the 
> collapsing here, making a general reference to "Key 
> Container" as shown below (?) Andrea
> 
> DSKPP Basic Object Model
> ========================
> when we use the term "cryptographic module" as a replacement 
> for "cryptographic token" then I am not sure the cardinality 
> between device and "cryptographic module" is correct. 
> Shouldn't it be 1 device may be have multiple "cryptographic modules"?
> 
> Furthermore, where does the "Key Container" concept come 
> from? Cannot you just collapse the "Key Container" and the "Key"?
> I believe that the MAC and encryption algorithms belong to 
> the Key rather than to the container.
> 
> > "cryptographic token", as stated in PKCS#11, "stores 
> objects and can 
> > perform cryptographic functions".  However, the use of the word 
> > "token" is often confused
> with
> > the
> > performs the functions.  In addition, note that "token" 
> gets used in 
> > different and equally confusing ways in other arenas, e.g., 
> OASIS WS 
> > Security.
> >
> > refer to "cryptographic module" wherever the PKCS#11 definition 
> > applies (on first look, this will be almost a 1:1 replacement of 
> > "cryptographic token"
> > consider the following alternative to Shuh's initial object diagram:
> >
> > DSKPP Basic Object Model
> > ========================
> >

---

From: "Pei, Mingliang" <[email-masked]>
Date: Fri, 6 Jul 2007 09:01:39 -0700

I think that this version is better. Key Container is used by server
side to store and transport set of keys which can serve for multiple
devices, and it doesn't have to reflect in client side logical diagram.

- Ming

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 06 Jul 2007 20:42:13 +0200

Hi Andrea, 

what about the following minor modification? 

| User    |          | Device    | 

Is there something that identifies a particular a specific instance of a 
cryptographic module?

Ciao
Hannes

PS: Regarding the terminology in the other documents: Once we got the 
terminology right then we have to clean-up the other docs as well.

Doherty, Andrea wrote:
>> Yesterday I added this message to the Issue Tracker, but for some
>>     
> reason
>   
>> functions".  However, the use of the word "token" is often confused
>>     
> with
>   
>> the

---

From: "Doherty, Andrea" <[email-masked]>
Date: Fri, 6 Jul 2007 15:53:56 -0400

Hannes,

Great question about the instance identifier.  We replaced "TokenID"
with "DeviceID" in the merge, where "TokenID" is what describes the
instance of the crypto module. So, what if we add the element back in,
but call it "CryptoModuleID"?  See below:

                   |CryptoModuleID
                   |Encryption Algorithms|
                   |MAC Algorithms       |
                   |...                  |
                   -----------------------
                         | 1
                         |
                         | contains
                         |
                         | *
                         V  
                   -----------------------
                   |Key Container        |
                   |---------------------|
                   |KeyID                |
                   |Key Type             |
                   |...                  |
                   -----------------------  

Andrea

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Friday, July 06, 2007 2:42 PM
To: Doherty, Andrea
Cc: [email-masked]
Subject: Re: [KEYPROV] Re Issue 21 (object model)

Hi Andrea, 

cryptographic module?

Ciao
Hannes