I have reviewed these Internet-Drafts (I-D) that have been
published so far:
and believe the goals of the KEYPROV IETF WG and the EKMI-TC are
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
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
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
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.
Responded to Phillip Hallam-Baker
Fw: [oasis-charter-discuss] EKMI Pre-Launch Teleconference
reading the charter, and reading the related information the
charter pointed (StongAuth SKML description from here:
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
Specific Charter comments marked <ajn>:
FOR REVIEW AND COMMENT
OASIS ENTERPRISE KEY
MANAGEMENT INFRASTRUCTURE TECHNICAL COMMITTEE
Enterprise Key Management Infrastructure (EKMI) TC
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
been embedded in some of the most popular tools --
and servers, VPN clients and servers, mail user agents,
productivity tools and many industry-specific applications --
underlies many mission-critical environments today.
there are many commercial and open-source
PKI software products available in the market
However, many companies across the world have
that PKI by itself, is not a solution.
<ajn> Also, it seems
that the use of PKI for SSL/TLS communications link protection is
common usage (to
protect various protocols - HTTP, LDAP - and to implement VPN
is also the perception that most standards in PKI have
been established by ISO and the PKIX (IETF), and most
in operations-mode with their PKIs -- just
using it, and adopting it
to other business uses within their
there is not much left to
architect and design in the PKI community.
While companies are "using PKI", they are not, in wide
usage, deploying their own PKI - rather
are procuring certificates from that subset of CAs (PKIs) that
are held within browser
trusted signers lists. Other usages are "hidden"/"buried"
inside products. The current
IMO, with public/private keys is that companies don't know how
their usage really
there is a new interest on the part of many
companies in the
management of symmetric keys used for encrypting
data in their computing infrastructure. While symmetric
have been traditionally managed by applications doing their
encryption and decryption, there is no architecture or
provides for symmetric key management services
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,
(also, the protocols/formats listed here seem tied to CA/RA <->
Entity communication - not the
of keys/certs distributed across a variety of key storage media
within an organization.
latter problem still requires attention.) </ajn>
however, there is no standard that describes how applications
request similar life-cycle services for symmetric keys,
server and how public-key cryptography may be used to
similar problems exist for both symmetric and asymmetric key
management needs to be addressed by enterprises in its
-- for both symmetric and asymmetric keys. While each
of technology will require specific protocols, controls
management disciplines, there is sufficient common ground
discipline justifying the approach to look at
key-management as a
whole, rather than in parts. Therefore,
this TC will address the
0) TC will publish a Note defining the "space" for
these protocols, as distinct from existing work
areas of CA/RA <-> Entity communications </ajn>
The TC will define the request/response protocols for:
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;
protocol pairs as deemed necessary.
What about sending keys TO the server?
of keys (and/or information about such keys) in a
of key(s) </ajn>
To ensure cross-implementation interoperability, the TC
create a test suite (as described under 'Deliverables'
will allow different implementations of this
protocol to be
certified against the OASIS standard (when
Is this a compliance suite ? </ajn>
The TC will provide guidance on how a symmetric
(and asymmetric) key-management
management as distinct from CA/RA <-> Entity
may be secured using asymmetric keys, using secure
generally accepted practices;
D) Where appropriate, and if
possible in conjunction with other
that focus on disciplines
outside the purview of OASIS, the TC
will provide input on how such
infrastructures may be managed, operated
You have lost me here </ajn>
The TC may conduct other activities that educate users about,
promote, securing sensitive data with appropriate cryptography,
and the use of proper key-management techniques and
ensure appropriate protection of the
List of Deliverables
Definitions (XSD) of the request and response protocols
2. A Test Suite of conformance clauses and sample
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
that provides guidelines for how an EKMI may be
operated, secured and audited (by June 2007)
5. Resources that
promote enterprise-level key-management: white
seminars, samples, and information for developer and public
(beginning January 2007, continuing at least through
Based upon what I have seen in the related material this is a far
Any company or organization that has a need for
cryptographic keys <ajn>
which are used </ajn> across
applications, databases, operating systems
and devices, yet
desires centralized policy-driven management of all
keys <ajn> (and multiple
copies of such keys) </ajn> in
the enterprise. Retail, health-care,
finance - every industry has a need to
confidentiality of sensitive data. The TC's
provide an industry standard for protecting
information across these, and other, industries.
services vendors and integrators should be able to fulfill
use cases with the TC's key management methodologies.
of the OASIS PKI TC should be very interested in this new
since the goals of this TC potentially may fulfill some of
goals in the charter of the PKI TC.
<ajn> Also coordinate with WS-SX TC. </ajn>
Coordination with other standards bodies' efforts - known work
underway or existing:
- TCG ESSG
subgroup of Storage WG
- W3C existing XKMS
Royalty Free on Limited Terms under the OASIS IPR
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>
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,
OASIS Web Services Security TC
XMLSignature and XMLEncryption protocols and working group
Digital Signature Services TC
OASIS Public Key Infrastructure
OASIS XACML TC (and other methods for providing granular
access-control permissions that may be consumed or enforced
symmetic key management)
StrongAuth, Inc. anticipates providing a
draft proposal for the EKMI
protocol, at the inception of the
TC. The current draft can be
a working implementation of this protocol is available at:
c. Proposed working title and acronym
Symmetric Key Services Markup Language
(SKSML), subject to TC's
approval or change.
time, and location of the first meeting:
will be by teleconference, with an optional face-to-
gathering as one conference call node, at:
Time: [____ UTC]
Call in details'; to be
posted to TC list
F2F Location: San Francisco Bay Area.
StrongAuth has agreed to
host this meeting.
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
StrongAuth is willing to assist by arranging for
teleconferences; we anticipate using readily available
f. Names, electronic
mail addresses, of supporters:
Ken Adler, individual
June Leung, FundSERV,
John Messing, American Bar
Arshad Noor, individual
individual member, firstname.lastname@example.org
Ann Terwilliger, Visa
g. TC Convener:
Nadalin | Work 512.838.0085 | Cell 512.289.4122
Received comment from Anthony Nadalin
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
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.
Responded to Anthony Nadalin (although the
comment period was closed at this point).