OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-charter-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: EKMI - disposition of comments log

---------- Forwarded message ----------
From: Arshad Noor <arshad.noor@strongauth.com>
Date: Dec 5, 2006 2:25 PM
Subject: Re: Modified EKMI-TC Charter
To: mary.mcrae@oasis-open.org
Cc: James Bryce Clark <jamie.clark@oasis-open.org >, ken@adler.net, June Leung <June.Leung@fundserv.com>, John Messing <jmessing@law-on-line.com >, Davi Ottenheimer <davi@poetry.org>, "Terwilliger, Ann" <aterwil@visa.com>

Not sure how this will look, Mary, but here is an HTML document
that includes the four (4) comments we received and the responses
to each one.  I trust this completes the documentation requirements
at this stage for the TC.  Thank you.


Log of comments on the Enterprise Key Management Infrastructure (EKMI)
Technical Committee charter document, and responses


Comment and Response



Subject: Fwd: [members] FW: Proposed charter for OASIS EKMI TC

The proposed charter notes

The proposers are unaware of any similar work being carried on in 
this exact area.  However, this TC intends to leverage the
products of, and seek liaison with, a number of other existing
projects that may interoperate with or provide functionality to the
EKMI TC's planned outputs, including: 

OASIS Web Services Security TC
W3C XMLSignature and XMLEncryption protocols and working group
OASIS Digital Signature Services TC
OASIS Public Key Infrastructure TC
OASIS XACML TC (and other methods for providing granular 
access-control permissions that may be consumed or enforced by
symmetic key management)

However, it does not reference XML Key Management Specification (XKMS 2.0) which became W3C Recommendation 28 June 2005.  (See http://www.w3.org/TR/xkms2/ .)  The introduction of that Recommendation notes, "This document specifies protocols for distributing and registering public keys, suitable for use in conjunction with the standard for XML Signatures [XML-SIG] defined by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF) and companion standard for XML encryption [XML-ENC] .  The XML Key Management Specification (XKMS) comprises two parts -- the XML Key Information Service Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS)."

How does XKMS relate to the intended work?



Ken Laskey

MITRE Corporation, M/S H305     phone:  703-983-7934

7515 Colshire Drive                        fax:        703-983-1379

McLean VA 22102-7508

Received comment from Ken Laskey

Response #1

Subject: Re: FW: Proposed charter for OASIS EKMI TC

The key words in the XKMS mission are "protocols for
distributing and registering *public* keys", Ken.  In
the initial implementation, EKMI is primarily focused
on key-management of *symmetric* keys with the Symmetric
Key-Management Services Markup Language (SKSML).

Over time, we do envision that EKMI will evolve to serve
public-keys too, and at that time, it is likely that the
EKMI-TC will use XKMS just as it uses XML Signature and
XML Encryption today.

I hope that addresses your question.

Arshad Noor
StrongAuth, Inc.

Responded to Ken Laskey with clarification


Subject: EKMI

In addition to the issue raised re XKMS and SAML I would like to make the members of this group aware of KEYPROV a group proposed to do similar work that has already begun the chatering process in the IETF. A BOF was held last week and a charter is currently being discussed on the mailing list:


To join the mailing list:



Provisional draft charter:


Current developments in inter-domain Shared Symmetric Key tokens and inter-domain use of Kerberos have highlighted the need for a standard protocol for provisioning symmetric keys.

The need for provisioning protocols in PKI architectures has been recognized for some time. Although the existence and architecture of these protocols provides a feasibility proof for the KEYPROV, assumptions built into these protocols make them inapplicable to symmetric keys.

In particular the ability to provision symmetric keys and associated attributes dynamically to already issued devices such as cell phones and USB drives is highly desirable. The working group will develop the necessary protocols and data formats required to support provisioning and management of symmetric key authentication tokens, both proprietary and standards based.


  • Requirements and use cases

  • Protocol specification

  • Key Container specification

Received comment from Phillip Hallam-Baker

Response #2

Subject: Re: [oasis-charter-discuss] EKMI


I have reviewed these Internet-Drafts (I-D) that have been
published so far:

http://www.ietf.org/internet-drafts/draft-vassilev-portable-symmetric-key-container-02.txt http://www.ietf.org/internet-drafts/draft-pei-dynamic-symkey-prov-protocol-01.txt and believe the goals of the KEYPROV IETF WG and the EKMI-TC are quite different. KEYPROV is targeting a protocol for provisioning credentials that, amongst other meta-data, consist of "shared secrets". These *credential-secrets* (referred to as symmetric keys in the I-D's) are used for primarily authenticating resources against validating systems. The EKMI-TC is targeting a protocol - Symmetric Key Services Markup Language (SKSML) - for the life-cycle management (provisioning, escrow, recovery, caching, destruction, etc.) of *symmetric encryption keys* (such as 3DES, AES, etc.). These keys are used for encryption of business data and not for authentication. The confusion between the WG and TC charters arises because of the industry's (sometimes misguided) notion for referring to the "shared secrets" of authentication credentials as "symmetric keys" - which is similar to the term used by cryptographers when referring to encryption/decryption keys used with symmetric ciphers. In addition, the use of such algorithms (3DES, AES) and symmetric- encryption keys by the KEYPROV protocols to protect the "shared credential secret" during provisioning, adds to the confusion. Some might be misled into thinking that 3DES/AES keys are being provisioned by the Provisioning System for general use by business applications, as opposed to the use of those symmetric encryption keys by the Provisioning System and the Credential Container for securely transporting the credential-secret between the two. (Think of SKSML as the protocol that *might* be used by the implementers of a KEYPROV-based Provisioning System, to acquire symmetric encryption keys from a centralized Symmetric Key Sevices server, rather than generating one itself. The implementers might do this if there is a need for long-lived symmetric-encryption key management rather than just for the transient need during the credential-provisioning process). Given the goals and the details in the I-D's, what is misleading, consequently, are the terms in use for the WG and the I-D's. More appropriate terms might have been "CREDPROV", "Portable Credential Container" and "Dynamic Credential Provisioning Protocol" for the WG and the I-D's respectively. If the WG is wedded to the name and terms in the I-D, I would encourage a paragraph or two in the charter and the Drafts, that articulates the difference between the "credential-secrets" provisioned through the protocols in the I-D's, and symmetric encryption keys such as DES, 3DES and AES used for encryption of data like social-security numbers, credit-card numbers, etc. If we are agreed on my understanding of the KEYPROV goals, it is almost certain that the documentation produced by the EKMI-TC will highlight this difference. While XKMS is more closer to the focus of the SKSML, given that XKMS was architected on the premise of provisioning asymmetric keys, trying to extend XKMS to accommodate symmetric-encryption keys would be akin to hammering a round peg into a square hole - while it can be done, it may not look pretty and might become cumbersome to implementers who wish to focus on only one or the other form of key-management. There is nothing to prevent an implementer from implementing both protocols in a single application if two distinct libraries took care of the mechanics; most applications do this today rather than try to shoe-horn every need into a single protocol. SAML, once again, is focused more on authentication rather than on a life-cycle management protocol for symmetric-encryption keys; as such, I see no overlap. I trust this addresses the questions raised. If I have mis- understood the I-D's, and it was indeed, the KEYPROV WG's intention to provision and manage symmetric encryption keys, please point me to the relevant sections of the I-D that focuses on that. I will re-read those sections more carefully and respond again. Thanks. Arshad Noor StrongAuth, Inc.

Responded to Phillip Hallam-Baker


Subject: RE: [oasis-charter-discuss] EKMI Pre-Launch Teleconference

It does not appear to me from reading the charter that there is an overlap here with the IETF KEYPROV work which is concerned with the Provisioning of symmetric keys for use as trust anchors. Such provisioning is by necessity a rather specialised process requiring the ability to make us of out of band authentication information to establish the trust anchors.

What is not clear to me from the charter is the intended field of application (DRM? CRM? Storage of Encrypted Documents?) or the relationship of this work to existing chartered work such as WS-Security, WS-Trust and WS-SecureConversation.

The traditional approach in PKI is to use the framework of trust provided by public key cryptography and PKI to establish session keys amongst the principles that ultimately resolve to a set of shared secrets (in the case of S/MIME or PGP this takes place directly, in the case of IPSEC/IKE there is an intermediate layer of Diffie-Hellman keys used to ensure perfect forward secrecy).

The management of the shared secrets then takes place according to the principles and requirements set out in the application protocol. So in the case of SSL/TLS the application protocol sets out requirements for caching master secrets in clients and the circumstances under which re-key is mandated. Similar provisions are set out in IPSEC.

I do not see where the proposed protocol fits into the existing framework or what identified defects of the existing framework it seeks to rectify.

Perhaps statement of a few concrete use cases would help elucidate the value proposition.

Received suggestion from Phillip Hallam-Baker

Response #3

The convener and supporters have agreed that creating use-cases is a valuable suggestion, and will create such documents as part of the deliverables of the TC.

Suggestion is being adopted by TC


Subject: Fw: [oasis-charter-discuss] EKMI Pre-Launch Teleconference

After reading the charter, and reading the related information the charter pointed (StongAuth SKML description from here: http://www.strongkey.org/resources/documentation/misc/skcl-sks-protocol.html ) to I have the following general comments:

This thing looks to me like it is addressing only a VERY SMALL subset of what is needed. It looks to me like what is there right now covers ONLY the case of requesting retrieval (i.e. "List"/"read" operation) of a symmetric key. This one seems like the relatively EASY one to solve. The others ( add/modify/delete/query ) will require much more work and don't seemed to covered in the related material or in the charter

It is good to see that StrongAuth has shown examples of using "SOAP bindings" but stopped short, as protocols like WS-Trust already handle symmetric and asymmetric keys and provide for a better transport. For Key management/administration though, I think there is quite a bit more that needs to be defined that is not covered in the related material or in the charter. There is no real in/out of scope items for this TC which makes me think that the will be far too much uncertainty.

There is other standards work in this space and there is no clear relationship called out in the charter.

Specific Charter comments marked <ajn>:



OASIS Enterprise Key Management Infrastructure (EKMI) TC

Statement of Purpose

Public Key Infrastructure (PKI) technology has been around for more
than a decade, and many companies have adopted it to solve specific
problems in the area of public-key cryptography.  Public-key
cryptography has been embedded in some of the most popular tools --
web clients and servers, VPN clients and servers, mail user agents,
office productivity tools and many industry-specific applications --
and underlies many mission-critical environments today.
Additionally, there are many commercial and open-source
implementations of PKI software products available in the market
today.  However, many companies across the world have recognized
that PKI by itself, is not a solution.

<ajn> Also, it seems that the use of PKI for SSL/TLS communications link protection is the most
common usage (to protect various protocols - HTTP, LDAP - and to implement VPN with
SSL-based VPN solutions). </ajn>

There is also the perception that most standards in PKI have already
been established by ISO and the PKIX (IETF), and most companies are
in operations-mode with their PKIs -- just using it, and adopting it
to other business uses within their organizations. Consequently,
there is not much left to architect and design in the PKI community.

<ajn> While companies are "using PKI", they are not, in wide usage, deploying their own PKI - rather
they are procuring certificates from that subset of CAs (PKIs) that are held within browser
default trusted signers lists. Other usages are "hidden"/"buried" inside products. The current
situation, IMO, with public/private keys is that companies don't know how fragmented
their usage really is.

Simultaneously, there is a new interest on the part of many
companies in the management of symmetric keys used for encrypting
sensitive data in their computing infrastructure. While symmetric
keys have been traditionally managed by applications doing their own
encryption and decryption, there is no architecture or protocol that
provides for symmetric key management services across applications,
operating systems, databases, etc. While there are many industry
standards around protocols for the life-cycle management of
asymmetric (or public/private) keys -- PKCS10, PKCS7, CRMF, CMS,

 XKMS?  </ajn>etc.

<ajn> (also, the protocols/formats listed here seem tied to CA/RA <-> Entity communication - not the
management of keys/certs distributed across a variety of key storage media within an organization.
This latter problem still requires attention.) </ajn>

-- however, there is no standard that describes how applications may
request similar life-cycle services for symmetric keys, from a
server and how public-key cryptography may be used to provide such

<ajn> similar problems exist for both symmetric and asymmetric key management.

Key management needs to be addressed by enterprises in its
entirety -- for both symmetric and asymmetric keys.  While each type
of technology will require specific protocols, controls and
management disciplines, there is sufficient common ground in the
discipline justifying the approach to look at key-management as a
whole, rather than in parts.  Therefore, this TC will address the


<ajn> 0) TC will publish a Note defining the "space" for these protocols, as distinct from existing work
in areas of CA/RA <-> Entity communications </ajn>

A) The TC will define the request/response protocols for:

1. Requesting a new or existing symmetric key
<ajn> (why just symmetric?)  </ajn> from a server;
2. Requesting policy information from a server related to caching of
keys on the client;
3. Sending a symmetric key
<ajn> (why just symmetric?) </ajn> to a requestor, based on a request;
4. Sending policy information to a requestor, based on a request;
5. Other protocol pairs as deemed necessary.

<ajn> What about sending keys TO the server?
Query of keys (and/or information about such keys) in a server?
Add/Generate/Modify/Delete/List/Query of key(s)

B) To ensure cross-implementation interoperability, the TC will
create a test suite (as described under 'Deliverables' below) that
will allow different implementations of this protocol to be
certified against the OASIS standard (when ratified);

</ajn> Is this a compliance suite ? </ajn>

C) The TC will provide guidance on how a symmetric
(and asymmetric) key-management
(key management as distinct from CA/RA <-> Entity communications).

infrastructure may be secured using asymmetric keys, using secure
and generally accepted practices;

D) Where appropriate, and if possible in conjunction with other
standards organizations that focus on disciplines
outside the purview of OASIS, the TC will provide input on how such
enterprise key-management infrastructures may be managed, operated
and audited;

</ajn> You have lost me here </ajn>

E) The TC may conduct other activities that educate users about,
and promote, securing sensitive data with appropriate cryptography,
and the use of proper key-management techniques and disciplines to
ensure appropriate protection of the infrastructure.

List of Deliverables

1. XSchema Definitions (XSD) of the request and response protocols
(by April 2007)
2. A Test Suite of conformance clauses and sample transmitted keys
and content that allows for clients and servers to be tested for
conformance to the defined protocol (by September 2007)
3. Documentation that explains the communication protocol (by
April 2007)
4. Documentation that provides guidelines for how an EKMI may be
built, operated, secured and audited (by June 2007)
5. Resources that promote enterprise-level key-management: white
papers, seminars, samples, and information for developer and public
use. (beginning January 2007, continuing at least through 2008)

</ajn> Based upon what I have seen in the related material this is a far too aggressive
schedule </ajn>

Anticipated Audiences:

Any company or organization that has a need for managing
cryptographic keys
<ajn> which are used </ajn> across applications, databases, operating systems
and devices, yet desires centralized policy-driven management of all
cryptographic keys
<ajn> (and multiple copies of such keys) </ajn> in the enterprise. Retail, health-care,
government, education, finance - every industry has a need to
protect the confidentiality of sensitive data. The TC's
deliverables will provide an industry standard for protecting
sensitive information across these, and other, industries.
Security services vendors and integrators should be able to fulfill
their use cases with the TC's key management methodologies.
Members of the OASIS PKI TC should be very interested in this new TC,
since the goals of this TC potentially may fulfill some of the
goals in the charter of the PKI TC.
<ajn> Also coordinate with WS-SX TC. </ajn>

<ajn> Coordination with other standards bodies' efforts - known work underway or existing:
- TCG ESSG subgroup of Storage WG
- IETF Keyprov BOF
- W3C existing XKMS work </ajn>



IPR Policy:

Royalty Free on Limited Terms under the OASIS IPR Policy

Additional Non-normative information regarding the start-up of the TC:

a. Identification of similar or applicable work:

The proposers are unaware of any similar work being carried on in
this exact area.
<ajn> (See above - there is other work underway) </ajn>  However,
this TC intends to leverage the
products of, and seek liaison with, a number of other existing
projects that may interoperate with or provide functionality to the
EKMI TC's planned outputs, including:

OASIS Web Services Security TC
W3C XMLSignature and XMLEncryption protocols and working group
OASIS Digital Signature Services TC
OASIS Public Key Infrastructure TC
OASIS XACML TC (and other methods for providing granular
access-control permissions that may be consumed or enforced by
symmetic key management)

b.  Anticipated contributions:

StrongAuth, Inc. anticipates providing a draft proposal for the EKMI
protocol, at the inception of the TC.  The current draft can be
viewed at:

and a working implementation of this protocol is available at:
http://sourceforge.net/projects/strongkey for interested parties.

c. Proposed working title and acronym for specification:

Symmetric Key Services Markup Language (SKSML), subject to TC's
approval or change.

d.  Date, time, and location of the first meeting:

First meeting will be by teleconference, with an optional face-to-
face gathering as one conference call node, at:
Date:  [December ____, 2006]
Time:  [____ UTC]
Call in details'; to be posted to TC list
F2F Location:  San Francisco Bay Area.  StrongAuth has agreed to
host this meeting.

e. Projected meeting schedule:

Subject to TC's approval, we anticipate monthly telephone meetings
for the first year. First version of the protocol to be voted on by
Summer 2007. StrongAuth is willing to assist by arranging for the
teleconferences; we anticipate using readily available free
teleconference services.

f. Names, electronic mail addresses, of supporters:

Ken Adler, individual member, ken@adler.net
June Leung, FundSERV, June.Leung@FundServ.com
John Messing, American Bar Association, jmessing@law-on-line.com
Arshad Noor, individual member, arshad.noor@strongauth.com
Davi Ottenheimer, individual member, davi@poetry.org
Ann Terwilliger, Visa International, aterwil@visa.com

g. TC Convener:

Arshad Noor, arshad.noor@strongauth.com


Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122

Received comment from Anthony Nadalin

Response #4

Subject: Re: Fw: [oasis-charter-discuss] EKMI Pre-Launch Teleconference

Thank you for your comments, Anthony.  I apologize for the delay
in responding but I had been traveling last week and am just now
getting caught up. However, your comments were discussed in the
OASIS con-call and we are incorporating some of your suggestions
in the charter document.

For the record, I do want to respond to your comments on the forum,
so that you are aware of how we're addressing them.

It appears that I may not have explained the premise on which the
EKMI architecture and the SKSML protocol is based, and that would
explain the conclusion to which you have arrived. I will attempt
to correct that error.

The architecture and protocol are based on the premise that a

1) wants to define encryption policy centrally;
2) wants to manage symmetric keys centrally and uniformly; and
3) wants to optimize the TCO of such an infrastructure;

While there are many models that can meet these requirements, we
based the architecture of SKMS on that of Domain Name Service (DNS).

DNS, as I'm sure you're familiar with, requires that the namespace
and IP addresses be defined on centrally-managed DNS servers, and
that clients only query the nameservers for information. DNS
clients do not add/update/delete nameservice information on the
servers (except within the limited scope of DHCP, which is but a
variation of the centralized policy definition and name-IP address
management principle); so their protocol is mostly limited to
querying the DNS server for name-service information.

The implementation requirements that we heard from customers were

a) the server must do all the heavy-lifting of key-generation, key-
management, access-control, etc.;
b) client applications must require minimal modifications to
participate in this architecture and process;

Given these, while it is possible to have a client generate symmetric
keys and send it to a server for addition/update/deletion, it would
require far more of the client-application and of the security
infrastructure to trust such add/update/deletes from client devices.
Secondly, ensuring that all clients conform to policy would require
that all clients be continually updated to know of such policies and
when such policies are updated.

By having the server perform ALL the work wrt key-generation, policy
conformance and key-management, it simplifies client-requirements to
using just one call - that of requesting a symmetric key (new or
existing) and using that key within the policy-constraints embedded
inside each key (the SKSML protocol embeds a KeyUsePolicy inside each
symmetric key). The server handles the rest.

Consequently, client applications in a Symmetric Key Management System
(SKMS) need only know how to request a key and where to request it from.
The Symmetric Key Client Library (SKCL) handles the rest - just like the
nameservice library in DNS handles all name-resolution activties for all
applications on a machine.

WRT to your comments in the scope section:

1) The "space" in which the SKSML protocol will be used is between
any client and server that needs symmetric key-management services
in any domain. The need for asymmetric key-management services are
currently addressed by IETF-PKIX protocols and are not within scope
of the EKMI charter;

2) Sending of keys TO the server is not within the initial scope of
this TC, given the premise described earlier. However, as the TC
addresses the initial problem and evolves, business requirements
from constituents may expand the scope to address sending keys to
the server;

3) Yes, the interoperability test suite is a compliance suite;

4) WRT scope item D, this TC has heard business requirements from
customers that would like to see implementation, operational and
audit guidelines for building, operating and auditing EKMI
infrastructures for compliance to specific regulations such as
PCI-DSS (as an example). This TC intends to create papers that
provide such guidelines for implementing and operating EKMI's.
WRT the audit requirements, it is the intention of this TC to
work cooperatively with organizations such as ISACA to create
audit guidelines that would be used by auditors to audit EKMI

WRT timelines, the original draft of this charter was written up in
August; the timelines are being revised to recognize the passage of
time to create this TC.

The EKMI-TC will have a liaison relationship with the WS-Trust TC.
I have already addressed the XKMS question in response to Phillip
Hallam-Baker's comments on this forum.

I trust the above helps clarify some of the confusion that may have
been caused by the charter. We anticipate writing up use-cases as
part of the documentation produced by the TC to further clarify how
and where the SKSML protocol may be used.


Arshad Noor
StrongAuth, Inc.

Responded to Anthony Nadalin (although the comment period was closed at this point).

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]