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: 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.


> -----Original Message-----
> From: Mary McRae [mailto:mary.mcrae@oasis-open.org] 
> Sent: Wednesday, November 22, 2006 3:17 PM
> To: oasis-charter-discuss@lists.oasis-open.org; 
> 'Staff-Standards'; ken@adler.net; June.Leung@FundServ.com; 
> jmessing@law-on-line.com; arshad.noor@strongauth.com; 
> davi@poetry.org; aterwil@visa.com
> Cc: 'James Bryce Clark'; mary.mcrae@oasis-open.org
> Subject: [oasis-charter-discuss] EKMI Pre-Launch Teleconference
> 
> A conference call has been scheduled for Monday, 27 November 
> at 1pm PT / 4 pm ET / 9pm GMT to discuss the proposed charter 
> for the EKMI Technical Committee.
> Participants include the TC Convenor, the OASIS TC 
> Administrator, and optionally other members of OASIS staff 
> and TC Proposers. Other interested OASIS Members are invited 
> to observe.
>  
> Call in details:
> US dial in: +1 712 432 4000
> Skype: +9900 827 5537644
> UK: +44 870 119 2350
> Conference Room Number: 5537644
>  
> The proposed charter is included below for reference.
> 
> Regards,
> 
> Mary
> 
> ---------------------------------------------------
> Mary P McRae
> Manager of TC Administration, OASIS
> email: mary.mcrae@oasis-open.org
> web: www.oasis-open.org
> phone: 603.232.9090
> 
>  
> ====
> PROPOSED CHARTER
> FOR REVIEW AND COMMENT
> OASIS ENTERPRISE KEY MANAGEMENT INFRASTRUCTURE TECHNICAL COMMITTEE
> 
> Name
> 
> 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.
> 
> 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.
> 
> 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, etc. 
> -- 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 services. 
> 
> 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
> following:
> 
> Scope
> 
> A) The TC will define the request/response protocols for: 
> 
> 1. Requesting a new or existing symmetric key from a server; 
> 2. Requesting policy information from a server related to 
> caching of keys on the client; 3. Sending a symmetric key 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.
> 
> 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);
> 
> C) The TC will provide guidance on how a symmetric 
> key-management 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;
> 
> 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)
> 
> Anticipated Audiences:
> 
> Any company or organization that has a need for managing 
> cryptographic keys across applications, databases, operating 
> systems and devices, yet desires centralized policy-driven 
> management of all cryptographic keys 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.
> 
> Language:
> 
> English
> 
> 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.  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:
> 
> http://www.strongkey.org/resources/documentation/misc/skcl-sks
-protocol.html
> 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
>  
>  
>  
>  
> 
> 
> 


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