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


Help: OASIS Mailing Lists Help | MarkMail Help

pki-tc message

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

Subject: Re: [ekmi] SKSML Specification Question

I'm glad many of your questions were answered, Tim.  I agree with you
that the EKMI TC actually has a lot of work to do in this area, and I
have a notion of where it will go in the next 3-5 years.  But I don't
want to overwhelm the TC with new proposals just yet.  I'd like to
chew on this elephant one bite at a time, if I may. :-)

Your ideas are definitely worthy of consideration; ideas which fall
within the purview of the EKMI TC charter, and which I believe this
TC should discuss after we've met our initial milestone (SKSML 1.0).  
I will plan on putting it on the agenda for discussion in the fall 
(summer tends to get a little slow as people take off for vacations).

Once again, welcome to the TC Tim, and thanks for your questions and


----- Original Message -----
From: "Timothy R Bruce" <Timothy.Bruce@ca.com>
To: "Arshad Noor" <arshad.noor@strongauth.com>
Cc: ekmi@lists.oasis-open.org, "PKI TC" <pki-tc@lists.oasis-open.org>
Sent: Thursday, June 19, 2008 8:07:30 AM (GMT-0800) America/Los_Angeles
Subject: RE: [ekmi] SKSML Specification Question

Thank you, Sir.  That answers a lot of questions but I am not sure yet
whether or not there is a need for an additional subcommittee to
consider further extending the standard.

I am concerned about the implication of assumption 5 and your statement
(which I agree with) that "It is my personal belief that within 10
years, ALL data will get encrypted..."

In that world 10 years from now, the Security Officer might be a very
busy person if that person has to be involved in identifying,
classifying and assigning key classes to every application, appliance
and device in an enterprise (every hardware device, software
application, smart card, memory stick, PDA, cell phone, card key, car
keys, etc).  Tools can help an SO with this classification into key
classes and policies, but only if standardized classification
information is embedded within the protocol packet.  The protocol
absolutely should be open to vendor exploitation and innovation, but
that does not preclude a protocol that also facilitates automatic
discovery, registration and classification into policies set up by the

So it seems to me that some additional standards work is needed
somewhere so that the EKM infrastructure can automatically identify and
classify key consumers based upon policies established by the SO.  Those
additional standards may be needed in the SKSML, the PKI or in some
umbrella standard.

Tim Bruce 
Principal Software Architect, Development 
5465 Legacy Drive 
Plano, Tx.  75024 
tel:  214-473-1917 
fax:  214-473-1069
-----Original Message-----
From: Arshad Noor [mailto:arshad.noor@strongauth.com] 
Sent: Wednesday, June 18, 2008 6:42 PM
To: Bruce, Timothy R
Cc: ekmi@lists.oasis-open.org; PKI TC
Subject: Re: [ekmi] SKSML Specification Question

You haven't gone wrong anywhere, Tim; you just have an incomplete
picture of how SKSML can be implemented to address the needs you

Lets establish some assumptions before we delve into the details
of how SKSML will be used in an enterprise:


1) An enterprise will establish an EKMI which consists of two sub-
    systems: a PKI to issue digital certificates to all client and
    server devices, and an SKMS to issue and manage symmetric keys;

2) Through a process - not in scope for this TC, but within the
    scope of the PKI Adoption TC which is part of the same IDtrust
    Member Section we belong to - the clients and servers are issued
    digital certificates to establish their identity;

3) Each of these clients and servers is known to the SKMS through
    the trusted hierarchy of their digital certificates.  How the
    SKMS gets that information is an implementation detail left upto
    the vendors;

    (StrongKey 1.0 - which implements an SKMS using the DRAFT 1 version
    of SKSML - requires that each client/server be entered manually into
    a webform of the SKS server; StrongKey 2.0 intends to change that by
    integrating into an LDAP store of published certificates, or front-
    ending a CA as an Registration Authority to ease that process);

4) The Security Officer at the enterprise defines KeyUsePolicies and
    corresponding KeyClasses for some standard encryption policies.
    So, to use your example, one KeyClass might be "TapeLibraryClass"
    and its corresponding KeyUsePolicy might be "AES 256-bit key valid
    for 10 years".  Another KeyClass might be "Web Server Cookie Class"
    and its KeyUsePolicy might be "AES 128-bit and valid for 30-days".

    (In StrongKey, the SO also defines a "Default" KeyClass and a
    "Default" KeyUsePolicy, which might be "3-DES and 1-year" validity,
    or whatever is decided by that enterprise to be their default;

5) Now the SO will assign all computers, LTOs and Management Consoles
    of tape-devices (which have been previously issued certificates in
    step #2) are assigned to the "TapeLibraryClass" KeyUsePolicy.  The
    SO will also assign all *web-servers* and *web-applications* to the
    "Web Server Cookie Class" KeyUsePolicy.

    All these definitions are done BEFORE a client has requested even a
    single key.

    The reason the TC probably would not want to standardize on KeyClass
    definitions, is because they imply a KeyUsePolicy - what type of
    algorithm to use, for how long, with what applications, at what time
    of day, in which location, etc.  These decisions are unique for
    enterprise, and really not within the scope of the TC's work
    Every enterprise must decide these for themselves as part of their
    SKMS deployment.  (But, if there is a plug-and-play way of doing it,
    you should propose it for a sub-committee deliverable - see below).

Now lets look at the mechanics:

A) When the SKMS is turned on, client applications - which have
    integrated an SKCL and the keystore/certificate-store that has their
    digital certificate credential (this can be a smartcard, TPM, HSM,
    or - yikes - a file-based software module) - will just request a
    key from the pre-configured SKS servers list.

    (In StrongKey, this list is a .properties file, and can be
     in advance and distributed through SMS - for Windows machines, or
     NFS for Linux/UNIX machines, or equivalent mechanisms for
     much like the resolv.conf file for DNS server information;

B)  The client application can choose to either specify a KeyClass, or
     not designate a KeyClass in its SymkeyRequest to the SKS server.
     it does request a specific KeyClass, it makes sense for it to only
     ask for classes that it knows it is authorized to request - the
     developers of the application can learn that through the .property
     files, if necessary.  But, I believe, it is best to leave the
     KeyClass out unless it absolutely needs it to specify it;

C) The SKS server, upon receiving the request and verifying the identity
    and authorization of the client (through the certificate validation
    process and a lookup of the DN in its own database), will determine
    ALL the authorized KeyClasses for that client.

    If the client did NOT request a specific KeyClass, the SKS server
    will choose the most rigorous KeyClass from its list of authorized
    key-classes for *that* client to generate the key.  If there is not
    a single specific key-class that applies to that client, the Default
    KeyClass will be used;

D) SKS Server now generates the key, escrows it, and returns the object
    in a SymkeyResponse using the SKSML protocol.

Some important things to note:

i) The SKS server NEVER deletes a key on its own regardless of when it
    expires.  The SO can choose to deactivate keys they don't use, or
    delete them either through the Administration Console or through a
    scheduled job.  In any case, a client cannot just automatically get
    an existing symmetric key because it asked for it.  It must be
    explicitly authorized to get a specific key, through an individual
    KeyGrant or a group KeyGrant (where the client is part of a group of
    clients that are authorized to get a specific key.  Groups can also
    be granted access to all keys within a KeyGroup, thereby avoiding
    the need to keep providing explicit grants to every key in the

ii) An SKMS is designed to not just manage millions, but trillions -
    2^64 actually - of keys (subject to hardware limitations).  It is my
    personal belief that within 10 years, ALL data will get encrypted,
    since it will be less expensive to encrypt all data than to make a
    decision of what to encrypt and what not to encrypt.  As a result,
    there will be an EKMI in every enterprise serving up billions of
    for every application in their infrastructure.  So, the design is
    deliberate and conscious.

iii) A client is NEVER expected to generate a key on its own.  Why?
    Here is an excerpt from the ACM paper I published some months ago,
    which answers the question:

An alternative architecture is to define policies centrally and push 
them down to the clients, and similarly have the clients generate keys 
locally and push them up to the server.  However, the SKMS architecture 
avoided this design for one reason: to avoid the possibility of 
catastrophic data-loss.

If a client were to generate a symmetric key locally, encrypt the 
plaintext, delete the plaintext (to eliminate the vulnerability), but 
cannot persist or send the generated symmetric key to the server for any

reason, the plaintext might be lost forever.

While it is possible to design around such conditions, the complexity of

the SKCL increases significantly because it is difficult to predict 
potential catastrophic conditions on a client machine - especially 
mobile devices.  With centralized policy-definition and key-generation, 
this loss is avoided altogether by escrowing the symmetric key first, 
and then sending it to the client for use.

In conclusion, there are a number of things that are not explicit in the
SKSML protocol.  This is deliberate because vendors need the flexibility
to innovate above the protocol.  All the capability I've described above
are in StrongKey 1.0 (whose source is available openly, as you know).
But, if another wants to above and beyond this, they should feel free to
do so, while conforming to the SKSML protocol (if they want to be OASIS
standards compliant).

If the TC believes that more of this capability needs to be in an OASIS
standard, this can be done in a sub-committee of the EKMI TC.  As a
member of the TC, you are entitled to - and even encouraged - to start
new sub-committees that focus on new aspects of EKMI if you wish.  The
only thing you need to be cognizant of, are the OASIS rules for how it
needs to get done; that's all.

For the initial goal, this TC decided that standardizing SKSML 1.0 was a
priority.  It also decided that it will create Implementation and Audit
Guidelines as its next steps.  But, there's nothing to prevent a new
sub-committee from spinning up and starting a new activity at any time.
(That's exactly what we did with the Flash Demo subcommittee a couple of
months ago).

I apologize for this long e-mail response, Tim, but I hope it gave you
the answers you were looking for.  If not, keep asking even if it
appears you are sinking the boat - you won't be, I assure you. :-)

Arshad Noor
StrongAuth, Inc.

Bruce, Timothy R wrote:
> Forgive me if I am seen as, "rocking the boat," but I do need some 
> clarification on the current SKSML specification.  I do see how the 
> current specification could be employed to implement a network enabled

> symmetric key management architecture, but I am concerned about the
> of information about the client application or device as seem from the
> The vision as described by the OASIS TC assumes the existence of a 
> variety of traditional and non-traditional applications and devices 
> scattered about within an enterprise all capable of cryptography and 
> therefore all needing an integrated key management solution.  The 
> proposed architectural solution from the TC involves the client-server

> model enabled by a standardized protocol for requesting and delivering

> key materials. 
> Clearly the proposed SKSML specification delivers such a protocol, but

> what I am concerned about is how well the server will scale based upon

> the proposed specification.  To get right to the point, what I see as 
> missing from an SKS server standpoint is the ability to intelligently 
> create and maintain policy-based key pools at the server where
> pools or types of pools have different characteristics based upon how 
> the key is used by the application requesting the key.
> Take a simple scenario where I have a need to encrypt at-rest data on 
> backup tape devices and ensure that the keys are retained for 10-years

> from their last use in encrypting data, and I have a second need like 
> the one Arshad mentioned during the June meeting where I want to
> browser cookies across every desktop and laptop in my enterprise (say 
> 60,000).  Clearly from a server perspective I probably do not need to 
> keep the key used to encrypt cookies for 10-years, and with 60,000 
> desktops and laptops running browsers and requesting new keys on a 
> regular basis this could result in millions of keys being retained at 
> the server way beyond their usefulness.
> Now I could define key classes on the server and establish policies
> how to manage the keys based upon the key class, but that means that
> every application or device I want to bring on-line and manage in
> ways I will need to define a new key class at the server and every 
> instance of that application or device would need to be configured to 
> request keys from that key class.
> What I was hoping to see in terms of an EKMI specification was one
> supported plug-and-play as well as customized configurations.  To be 
> plug-and-play, I believe the standard needs to also contemplate 
> standardized protocol elements and values to place client applications

> and devices into a finite series of classifications.  And so backup 
> applications and/or devices could be easily identified as such by the 
> SKS server and a policy at the server could associate all backup 
> applications and devices with a specific key class (key pool with
> management characteristics).  A web browser would also have a assigned

> value that was part of the SKSML specification, which again would
> the SKS server to properly classify the client application and assign 
> the proper key class without having to configure anything outside of
> SKS server (plug-and-play).  The SKSML already allows an application
> request a key from a specific key class, so the flexibility is there
> customize applications and SKS policies could choose to honor keys
> specific classes or could decide to ignore the key class requested by 
> the application and based upon other controlling SKS server policies
> the application's "classification" the SKS server would decide upon
> proper key class.  SKS server policies could also be written to
> information based upon the application's or device's classification
> information from the CN of its X.509 certificate and/or it's requested

> key class to provide a more granular set of managed key classes.  But
> the SKS server is not provided with some sort of information that
> allow the server to classify the type of application or device, then 
> plug-and-play becomes very difficult without treating all keys as
> in terms of retention, access and caching policies.
> In the interest of plug-and-play, I also believe it is necessary for
> SKSML to allow the client to request a key for a specific algorithm in
> strength that is supported by the client application.  Of course, one 
> implementation would be to have key classes associated with specific 
> algorithms and key strengths but if we are to enable industry-wide 
> plug-and-play then the SKSML should establish standardized key classes

> that are part of the specification and must therefore be supported by 
> any SKS server implementation.
> To achieve some of this application and device awareness at the SKS 
> server, the key class is one possibility or this information could be 
> passed via the CN information of the X.509 certificate, but either way

> if the values to classify the generic types of applications and
> as well as the algorithms supported by the client are not industry 
> standardized values then I do not see how this could foster a 
> plug-and-play key management capability.
> Where have I gone wrong?
> */Tim Bruce/*
> /Principal Software Architect, Development/
> /5465 Legacy Drive/
> /Plano, Tx.  75024/
> /tel:  214-473-1917/
> /fax:  214-473-1069/
> <http://www.ca.com/>

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