---------- Forwarded message ----------
From:
Arshad NoorDate: Dec 27, 2007 1:50 PM
Subject: [Fwd: [ekmi] [Fwd: [ekmi-sksml] Groups - SKSML DRAFT version 02 (
SKSML-DRAFT-2.0.zip) uploaded]]
To: Matt Ball
Matt, FYI. Feel free to forward to your WG. Happy new year to you.
Arshad
-------- Original Message --------
Subject: [ekmi] [Fwd: [ekmi-sksml] Groups - SKSML DRAFT version 02
(SKSML-DRAFT-2.0.zip) uploaded]
Date: Thu, 27 Dec 2007 12:47:44 -0800
From: Arshad Noor
Organization: StrongAuth, Inc.
To:
ekmiFYI. Happy new year to all.
Arshad Noor
StrongAuth, Inc.
-------- Original Message --------
Subject: [ekmi-sksml] Groups - SKSML DRAFT version 02
(SKSML-DRAFT-2.0.zip) uploaded
Date: 27 Dec 2007 20:39:38 -0000
From:
arshad.noorTo:
ekmi-sksmlNotes from the documentation section of EKMICoreLibrary.xsd are given
below.
Please review the notes & the ZIP file contents, and provide comments
before the end of January 31, 2008. I would like to take this to the
EKMI TC for a vote to promote this to a Committee DRAFT if there are no
major changes/objections from this subcommittee. Thanks and a happy
new year to all.
Arshad Noor
StrongAuth, Inc.
--------------
DRAFT Version 02 is very different from DRAFT Version 01. It has
incorporated input from many TC members and consists of the following
changes (in the order of their appearance in this file):
01) An XSD group called LocationCoordinateGroup has been created to
enforce that a location coordinate includes the longitude and
latitude, if specified, or not at all.
02) An XSD group called MessageDigestGroup has been created to
enforce that DigestAlgorithm and DigestValue are specified
together, or not at all.
03) Three ID types have been created to accommodate for the
concatenated identifier types found within EKMI objects, each
consisting of one, two and three parts to their identifiers.
They are aptly named: OnePartIDType, TwoPartIDType and
ThreePartIDType.
04) An EncryptionAlgorithmType was created to enumerate the
different encryption algorithms supported within the Symmetric
Key Management System (SKMS).
05) The GKID in the GKIDType was modified to include a Domain ID
(DID) based on the IANA-issued Private Enterprise Number thus
expanding the namespace to the internet, and extending the
maximum length of the GKID to be 62-bytes.
06) Added a KeySizeType to enumerate the different sizes of
symmetric keys supported within the SKMS.
07) Added a LevelClassificationType to enumerate the different
security classifications supported in the Bell-LaPadula model
of access control.
08) Added a PermittedDurationType to indicate the validity duration
of a symmetric key (in seconds) under the new Permissions model
for KeyUsePolicy.
09) Added a PermittedTransactionsType to indicate the number of
encryption transactions a client application can perform with a
specific symmetric key under the new Permissions model for
KeyUsePolicy.
10) Added an ApplicationsType to identify details of an application
that is permitted to use a symmetric key within a specific KUP.
11) Added a PermittedApplicationsType to identify the list of
applications permitted to use a symmetric key defined within a
KUP. If this element is missing, by default, all applications
are assumed to be permitted to use the symmetric key.
12) Added a PermittedDatesType to implement the older date-based
KUP. It identifies a list of dates during which the symmetric
key defined within such a KUP can be used. If this element is
missing, it is assumed that the symmetric key can be used on any
date.
13) Added a PermittedLevelsType to identify the list of levels (from
a Multi-Level Security, or MLS, based system) that a symmetric
key can be used. If this element is missing, it is assumed that
the symmetric key can be used at all MLS levels. The element
also adds an "Other" element of "anyType" to permit the addition
of custom XML elements to extend the capability of this schema.
14) Added a PermittedLocationsType to identify the list of locations
that a symmetric key can be used. If this element is missing,
it is assumed that the symmetric key can be used in all
locations. The element also adds an "Other" element of
"anyType" to permit the addition of custom XML elements to
extend the capability of this schema.
15) Added a PermittedTimesType to identify a list of times during
the day, during which the symmetric key defined within such a
KUP can be used. If this element is missing, it is assumed that
the symmetric key can be used at all times during a 24-hour
day.
16) Added a PermittedUsesType to identify the list of uses that a
symmetric key can be used for. If this element is missing, it
is assumed that the symmetric key can be used for all purposes.
The element also adds an "Other" element of "anyType" to permit
the addition of custom XML elements to extend the capability of
this schema.
17) Added a PermissionsType which creates a new, more flexible and
extensible model for defining key-use policies. It replaces the
old Date, Duration and TxAllowed-based policies from DRAFT
version 01 and allows implementers to customize which
applications can use a key, on what dates, times, at which
locations, for what purposes, etc. It also adds an "Other"
element of "anyType" to permit the addition of custom XML
elements to extend the capability of the Permissions model.
18) Added a StatusType to enumerate the various status values that
KCPs and KUPs can have.
19) Added a KeyCacheDetailType to organize the detail information
that SKMS clients need to manage their symmetric key-cache.
20) Changed the KeyCachePolicyType element to better organize it by
creating a NewKeys and UsedKeys element of KeyCacheDetailType,
and adding a PolicyCheckInterval to indicate the frequency
interval at which an SKMS client checks for KCP updates.
21) The KCPID within the KeyCachePolicyType is no longer an integer,
but a string containing a DomainID concatenated with a unique
policy ID within that domain. The string can now have a maximum
length of 41-bytes.
22) Removed the maxnewdays and maxuseddays within KeyCachePolicyType
and replaced it with CacheDuration from KeyCacheDetailType which
uses seconds instead of days to indicate the caching period.
23) Removed the usefirst element from KeyCachePolicyType; it is
redundant.
24) Reorganized the KeyUsePolicyType to implement the new
Permissions model for defining the policy for how keys may be
used.
25) The KUPID within the KeyUsePolicyType is no longer an integer,
but a string containing a DomainID concatenated with a unique
policy ID within that domain. The string can now have a maximum
length of 41-bytes.
--------------
-- Arshad Noor*
The document named SKSML DRAFT version 02 (SKSML-DRAFT-2.0.zip) has been
submitted by Arshad Noor* to the EKMI Symmetric Key Services Markup
Language (SKSML) SC document repository.
Document Description:
An update to the XML Schema Definitions (XSD) of SKSML that takes into
account feedback received on the client-server protocol within an SKMS.
While many common elements remain from DRAFT version 01, the XSD has
undergone a radical overhaul with a new Permissions-based model for
KeyUsagePolicy that makes it more flexible and extensible.
Additionally, the XSD has been better organized by breaking out elements
into data-types.
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/ekmi-sksml/document.php?document_id=26670
Download Document:
http://www.oasis-open.org/apps/org/workgroup/ekmi-sksml/download.php/26670/SKSML-DRAFT-2.0.zip
PLEASE NOTE: If the above links do not work for you, your email application
may be breaking the link into two pieces. You may be able to copy and paste
the entire link address into the address field of your web browser.
-OASIS Open Administration
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php