Subject: [KEYPROV] PSKC Use Cases

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 9 Apr 2008 16:02:25 -0400

All,

Andrea and I reviewed the use cases in PSKC. The following are some of the
big changes we're suggesting:

 - The online use cases should come before the offline uses cases - this is
the IETF after all.

 - There really are three use cases: client-to-client, server-to-server, and
client-to-server. Further those three use cases are applicable to both
online and offline cases. We'd suggest renaming headings in both the online
and offline cases. We also think the paragraphs can then be combined so
there's one section that applies to both online and offline use cases. 

 - The use cases should be generic. The text in most cases is fine, but
there are follow-on paragraphs that really are examples that we should put
"For example" at the beginning of the paragraph. We also suggest removing
paragraphs that sounded like requirements.

Attached is a word document that shows the changes (and in some cases
provide rationale in []) we'd like to make.

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

---

From: "Philip Hoyer" <[email-masked]>
Date: Thu, 10 Apr 2008 15:58:25 +0200

Sean and Andrea,
First thanks for the review,
I will go through them and comment back.

Quickly though:

there seems to be a use case in the wrong section since server to mobile
phone should be in the server-client section and not crypto module to
crypto module.

I also do not know currently of an offline use case for client to
server.

I agree in using more generic terms instead of OTP specific terms.

I also agree on putting online use cases first.

Philip

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Turner, Sean P.
Sent: Wednesday, April 09, 2008 9:02 PM
To: [email-masked]
Subject: [KEYPROV] PSKC Use Cases

All,

Andrea and I reviewed the use cases in PSKC. The following are some of
the
big changes we're suggesting:

 - The online use cases should come before the offline uses cases - this
is
the IETF after all.

 - There really are three use cases: client-to-client, server-to-server,
and
client-to-server. Further those three use cases are applicable to both
online and offline cases. We'd suggest renaming headings in both the
online
and offline cases. We also think the paragraphs can then be combined so
there's one section that applies to both online and offline use cases. 

 - The use cases should be generic. The text in most cases is fine, but
there are follow-on paragraphs that really are examples that we should
put
"For example" at the beginning of the paragraph. We also suggest
removing
paragraphs that sounded like requirements.

spt

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 11 Apr 2008 21:30:44 +0300

Hi Sean,

thanks for the text proposal.

A proposal for simplication:

3.2.  Server to Server Bulk import/export of keys

 From time to time, a key management system may be required to import or 
export keys in bulk from one entity to another.

Two examples are listed below.

Authentication tokens may have their symmetric keys initialized during 
the manufacturing process in bulk, requiring copies of the keys and 
algorithm data to be loaded into the authentication system through a 
file on portable media.  The manufacturer provides the keys and related 
data in the form of a file containing records in standard format, 
typically on a CD.  Note that the token manufacturer and the vendor for 
the validation system may be the same or different.

An enterprise may want to port keys and related data from system A into 
a different system B. System A provides the administrator with the 
functionality to enables export of keys and related data (e.g. for OTP 
authentication tokens) in a standard format and subsequently import the 
data into system B.

3.3.  Cryptomodule to Server case

An end user may want to update an existing key in the cryptomodule and 
requests a replacement key package.  The package may, for example, 
include a new key and may include new or updated key attributes.

For example, in the case of OTP authentication tokens, updated key 
attributes could include a new counter value, a modified response format 
or length, a new friendly name, etc.

A user may want to activate and use a new key and related data with a 
new system that is not aware of this key.  This key may be embedded in 
the cryptomodule (e.g.  SD card, USB drive) that the user has purchased 
at the local electronics retailer.  Along with the cryptomodule, the 
user may get the key on a CD or a floppy in a standard format.  The user 
can now upload via a secure online channel or import this key and 
related data and start using the key.

Ciao
Hannes

Turner, Sean P. wrote:
> ------------------------------------------------------------------------
>