RE: [ekmi] Discussion on comment received on 15-day review of SKSML

["Roddy, Sue " <s.roddy@radium.ncsc.mil>]

I agree with Tomas' assessment of the impact of "legacy" equipment.

Without a clear transition plan/strategy to migrate to new capabilities,
it is almost impossible to effect change.  Especially in today's
cost-sensitive environments. 

-----Original Message-----
From: Tomas Gustavsson [mailto:tomas@primekey.se] 
Sent: Tuesday, December 30, 2008 4:50 AM
To: Arshad Noor
Cc: ekmi
Subject: Re: [ekmi] Discussion on comment received on 15-day review of
SKSML


Hi,
I didn't study the pskc document in detail now, only went over it
briefly. It seems quite, perhaps overly, complex.

In general the idea of standardizing key container is good. If it were
PKI we were talking about I would be suspicious of any new protocol that
did not allow piggy-backing of existing standard messages such as
pkcs#10 requests and pkcs#12 keystores.

The pskc seems to be simply such a standardized keystore, similar to
pkcs#12 but for symmetric keys. If it is as Philip says that there are
already wide-spread implementation of this keystore type, I think it
would be beneficial for ekmi to support this.

Regarding your point 5 Arshad, I think this would be the benefit of
supporting pskc, easing integration with existing implementations that
already use pskc containers AFTER the delivery of the key by the SKS. 
Being able to "EKMI-ify" existing systems.

This is one of the areas where I think for example XKMS failed. It did
not acknowledge the vast installed base of implementations using pkcs#10
but required implementing something completely new, making it impossible
to easy "XKMS-ify" existing systems.

Happy new year to all,
Tomas

Arshad Noor wrote:
> All,
> 
> Many people are probably still on vacation and enjoying the holidays 
> with their families/loved ones, but I thought that it would be useful 
> to start the discussion on the comment received from Philip Hoyer on 
> the 15-day review of SKSML that concluded last week:
> 
> http://lists.oasis-open.org/archives/ekmi-comment/200812/msg00000.html
> 
> Here are my thoughts (in no particular order of importance):
> 
> 1) We have not received any objections or concerns with the current
>    definition of the SKSML protocol itself;
> 
> 2) Harmonizing key-management standards are good for the industry and
>    for customers; those amongst us at the Key Management Summit held
>    in Baltimore in September 2008 heard this very clearly from the
>    customers that attended the summit;
> 
> 3) The IETF key-management effort has always been focused on symmetric
>    authentication keys, which is a very different objective than what
>    the EKMI TC is focused on.  This was discussed even before the TC
>    came into existence:
> 
> http://lists.oasis-open.org/archives/oasis-charter-discuss/200611/msg0
> 0003.html
> 
> 
>    Since it was agreed that there was no overlap between KEYPROV and
>    EKMI TC (other than that both groups used symmetric cryptographic
>    keys to achieve their different objectives), the OASIS TC was
>    allowed to be created.
> 
> 4) The key-container is an integral part of the SKSML protocol, but
>    not the most critical part of the protocol.  The truly critical
>    element is the KeyUsePolicy element, since this is what defines
>    policy and establishes control.  Without the KUP, there is no
>    key-management system;
> 
> 5) The key-container in SKSML is tied to the use of XML Encryption
>    and X509 digital certificates for transporting the key; this not
>    only provides us the transport security, but also ties it to the
>    authentication credential of the client (also an X509 digital
>    certificate).  Without having studied the KEYPROV protocol, I am
>    not certain what additional benefits SKSML will gain by allowing
>    for different key-containers to carry the key.  At a minimum, it
>    will require studying the impact on the security and assumptions
>    we need to make about the requesting client;
> 
> 6) We are at the point of only voting on a Committee Specification,
>    not an OASIS standard.  The next 3-6 months will be spent in
>    creating implementations to validate our choices and learn from
>    the experience before voting on the standard.
> 
> I would recommend that, given the effort we have put in over the last 
> two years, we continue with making the current spec a Committee 
> Specification to validate our work through implementations.  At the 
> same time, I also recommend that one or more TC members engage in 
> discussions with Philip to understand the details and implications of 
> his suggestion.  The engaging-member(s) can then report back to the TC

> with an analysis on what impact this suggestion has on SKSML and 
> his/her/their recommendation.  The analysis can occur concurrently 
> with the implementation validation so we will have a fair amount of 
> information before deciding on what to do before going for an OASIS 
> standards vote.
> 
> Let me know what others think about this.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php