Subject: [KEYPROV] KEYPROV 13/07 conf call minutes

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 17 Jul 2009 12:48:40 +0300

Participants:
 
  - Ming Pei 
  - Andrea Doherty
  - Salah Machani
  - Hannes Tschofenig

Plan for PSKC in advance of Stockholm meeting:

1. Hannes to prepare PROTO writeup 
   Talk to Ming and Philip about the validation of the example using
   their implementation.    

2. Hannes to check the extensibility regarding algorithm profiles 
(draft-hoyer-keyprov-pskc-algorithm-profiles-00.txt)

3. Ming to release reference implementation before the IETF meeting.

4. Submit PSKC draft update by July 27 addressing the WGLC comments.  

Plan for DSKPP in advance of Stockholm meeting:
 
1. Ming will update DSKPP document by July 19:
    * Alignment with latest PSKC (including examples)
    * Schema validation
 
2. Andrea will review changes and update DSKPP document based on comments
received:
    * Add "Principal syntax is XML and it is layered on a transport
mechanism such as HTTP" to Section 3.1.
    * Add text to Basic DSKPP Exchange describing beginning, middle, end of
protocol exchange; as well as what an attacker can/cannot do
    * Remove <TokenPlatformInfoType> and <PlatformType>; these entities can
be handled by <ClientInfoType>
    * Editorial (clean up Figure 3, remove "NOTES" and forward references,
fix hanging indents)
 
3. Submit DSKPP by July 27.

4. Salah volunteered to review the new version of DSKPP

Plan for Symmetric Key Container in advance of Stockholm meeting:

1. Hannes to talk to Sean about the possibility to update the draft to align
it with PSKC. 
   Only the XML elements/attributes need to be mapped and not the entire
draft replicated. 

2. Ideally, submit an updated version by July 27.

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 20 Jul 2009 02:00:45 -0700

Here is status on my action items:

1. DSKPP update on examples and schema

It appears that the last version I sent had the latest PSKC schema. I
double checked the PSKC schema and DSKPP examples - they are compliant.
One work remains: the actual MAC data for DSKPP messages are correct in
syntax but in value. PSKC examples have correct data in examples on the
other hand. I plan to work on this next while Andrea proceeds to work on
the draft update in other sections this week.

Andrea, please go ahead to update the draft with the version I sent you
earlier for the items you have. When I got the computed MAC values, I
can send you to just update the values without schema or element
changes.

2. Terminologies look to be mostly consistent. DSKPP and PSKC may define
a term in complementary ways in some cases. I don't see needs for text
update. 

Examples:

a. CryptoModule:

DSKPP: 

"S2.1 Cryptographic Module:
A component of an application, which enables symmetric key cryptographic
functionality"

S3.1 Cryptographic Module:
The cryptographic module to which the symmetric keys are to be
provisioned, e.g., an authentication token."

PSKC:

"The <CryptoModuleInfo> element identifies the cryptographic module to
which the symmetric keys are or have been provisioned to."

b. Key Package

DSKPP:
Key Package (KP):
An object that encapsulates a symmetric key and its configuration data

PSKC:
KeyPackage entity - representing the package of upmost one key and its
related provisioning endpoint or current usage endpoint, such as a
physical or virtual device and a specific CryptoModule

3. Reference implementation is under working, targeting to deliver by
the IETF meeting time.

- Ming

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hannes Tschofenig
Sent: Friday, July 17, 2009 2:49 AM
To: 'KEYPROV'
Subject: [KEYPROV] KEYPROV 13/07 conf call minutes

Participants:
 
  - Ming Pei
  - Andrea Doherty
  - Salah Machani
  - Hannes Tschofenig

 
 
2. Andrea will review changes and update DSKPP document based on
comments
received:
    * Add "Principal syntax is XML and it is layered on a transport
mechanism such as HTTP" to Section 3.1.
    * Add text to Basic DSKPP Exchange describing beginning, middle, end
of protocol exchange; as well as what an attacker can/cannot do
    * Remove <TokenPlatformInfoType> and <PlatformType>; these entities
can be handled by <ClientInfoType>
    * Editorial (clean up Figure 3, remove "NOTES" and forward
references, fix hanging indents)

1. Hannes to talk to Sean about the possibility to update the draft to
align it with PSKC. 
   Only the XML elements/attributes need to be mapped and not the entire
draft replicated. 

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