This issue of XML Daily Newslink is sponsored by:
Sun Microsystems, Inc. http://sun.com
- Cloud Security Alliance Publishes Revised Security Guidance Document
- NIST Public Review: Security Content Automation Protocol (SCAP) Version 1.1
- ZigBee Remote Control Standard Released
- Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
- W3C Invites Implementations of MathML Version 3.0 and CSS Profile
- W3C Proposed Recommendation for Cascading Style Sheets: Selectors Level 3
- Sun Microsystems Launches GlassFish Enterprise Server v3
- Modular Java: Declarative Modularity
Cloud Security Alliance Publishes Revised Security Guidance Document
Staff, Cloud Security Alliance Announcement
CSA has released a second version of its "Security Guidance for Critical Areas of Focus in Cloud Computing (Version 2.1). This white paper outlines key issues and provides advice for both Cloud Computing customers and providers within thirteen (13) strategic domains. Version 2.1 provides more concise and actionable guidance across all domains, and encompasses knowledge gained from real world deployments over the past six months in this fast moving area... This second version of the guidance tops off a strong inaugural year for the CSA, in which it first published its guidance and, grew to 23 corporate members strong, and joined forces with numerous leading industry groups (such as ISACA, ENISA, the DMTF and the Jericho Forum) to help advance the goal of cloud security.
The Cloud Computing security domains are divided into two broad categories: governance and operations. The governance domains are broad and address strategic and policy issues within a cloud computing environment, while the operational domains focus on more tactical security concerns and implementation within the architecture. Domain 1 ('Cloud Computing Architectural Framework') provides a focus on the description of Cloud Computing that is specifically tailored to the unique perspective of IT network and security professionals. The following three sections define this perspective in terms of: (1) The terminology used throughout the guidance, to provide a consistent lexicon. (2) The architectural requirements and challenges for securing cloud applications and services. (3) A reference model that describes a taxonomy of cloud services and architectures...
Document section Section III ('Operating in the Cloud') addresses: Domain 7: Traditional Security, Business Continuity, and Disaster Recovery; Domain 8: Data Center Operations; Domain 9: Incident Response, Notification, and Remediation; Domain 10: Application Security; Domain 11: Encryption and Key Management; Domain 12: Identity and Access Management; Domain 13: Virtualization.
The Cloud Security Alliance is a not-for-profit organization with a mission to promote the use of best practices for providing security assurance within Cloud Computing, and to provide education on the uses of Cloud Computing to help secure all other forms of computing..."
See also: the CSA announcement
NIST Public Review: Security Content Automation Protocol (SCAP) Version 1.1
Staff, National Institute of Standards and Technology Announcement
NIST has announced a public comment release of "The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.1 (Draft Special Publication 800-126 Revision 1). NIST requests comments on draft SP 800-126 Revision 1 by January 23, 2010. This 71-page document was produced by members of the U.S. National Institute of Standards and Technology, Information Technology Laboratory, Computer Security Division, and edited by Stephen Quinn, David Waltermire, Christopher Johnson, Karen Scarfone, and John Banghart.
"SCAP consists of a suite of specifications for standardizing the format and nomenclature by which security software communicates information about software flaws and security configurations. SP 800-126 defines and explains SCAP version 1.1, including the basics of the SCAP component specifications and their interrelationships, the characteristics of SCAP content, and the SCAP requirements not defined in the individual component specifications. Major changes from SCAP version 1.0 to 1.1 include the addition of Open Checklist Interactive Language (OCIL) and an upgrade to Open Vulnerability and Assessment Language (OVAL) version 5.6.
Basics of SCAP Components includes three languages: Extensible Configuration Checklist Description Format (XCCDF) v1.1.4, Open Vulnerability and Assessment Language (OVAL) 5.6, and Open Checklist Interactive Language (OCIL) 2.0. The SCAP languages provide standard vocabularies and conventions for expressing security policy, technical check mechanisms, and assessment results. The specifications for enumerations includes Common Platform Enumeration (CPE) 2.2, Common Configuration Enumeration (CCE) v5, and Common Vulnerabilities and Exposures (CVE). Each SCAP enumeration defines a standard nomenclature (naming format) and an official dictionary or list of items expressed using that nomenclature. For example, CVE provides a dictionary of publicly known information security vulnerabilities and exposures. SCAP also incorporates the Common Vulnerability Scoring System (CVSS) v2.0. This refers to evaluating specific characteristics of a vulnerability and, based on those characteristics, generating a score that reflects the vulnerability's severity... SCAP utilizes software flaw and security configuration standard reference data, also known as SCAP content. This reference data is provided by the National Vulnerability Database (NVD), which is managed by NIST and sponsored by the Department of Homeland Security (DHS)...
Most of the formalisms provide definitions for XML data formats, so some of the requirements and conventions used in the document reference XML content. Table 1-1 'Conventional XML Mappings' presents 18 XML namespaces and prefixes for CPE Dictionaries, Embedded CPE references, NVD/CVE data feed elements and attributes, Common OVAL elements and attributes, OVAL system characteristics, OVAL results, Schematron validation scripts, Interoperable XML digital signatures, XCCDF policy documents, Simple Dublin Core elements, etc...."
See also: Application Security Standards
ZigBee Remote Control Standard Released
"The ZigBee Alliance has announced publication of ZigBee Remote Control, a standard for advanced remote controls. ZigBee Remote Control is the first public application profile designed specifically for use with the ZigBee RF4CE specification... ZigBee Remote Control provides a global standard for advanced and easy-to-use RF remotes that delivers non-line-of-sight operation, two-way communication, longer range of use and extended battery life. It was designed for a variety of consumer electronic devices including HDTV, home theater equipment, set-top boxes and other audio equipment. ZigBee Remote Control frees consumers from pointing remotes at devices. It offers consumers more flexibility, allowing control of devices from nearby rooms and placement of those devices almost anywhere—including behind wood, interior walls or glass.
The ZigBee RF4CE specification defines a simple, robust and low-cost communication network that allows wireless connectivity in consumer electronics applications. The ZigBee RF4CE specification enhances the IEEE 802.15.4 standard by providing a simple networking layer and Alliance developed public application profiles that can be used to create multi-vendor interoperable solutions for use within the home.
Replacing decades old IR technology with the ZigBee RF4CE radio frequency (RF) standard will improve product robustness and user experience. Devices using the standard will free consumers from pointing a remote at an exact target, allowing them to more easily control entertainment equipment accurately and easily. Devices will confirm to the remote control that a command was executed, no longer making the consumer repeatedly hit buttons to execute a command. This two-way communication provides the consumer electronics industry with a new platform and standard designed to accommodate growth beyond traditional device control. Ultimately, these new capabilities will spur innovation and integration with other automation devices using ZigBee technology.
ZigBee Smart Energy offers utilities and energy service providers secure, easy-to-use wireless home area networks (HAN) for managing energy. ZigBee was created to address the market need for a cost-effective, standards-based wireless networking solution that supports low data-rates, low-power consumption, security, and reliability. ZigBee standards-based technology addresses the unique needs of most remote monitoring and control and sensory network applications. The initial markets for the ZigBee Alliance include Consumer Electronics, Energy Management and Efficiency, Health Care, Home Automation, Building Automation and Industrial Automation..."
See also: ZigBee Remote Control
Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
James Winterbottom, Martin Thomson, Hannes Tschofenig (et al, eds.), IETF Internet Draft
Members of the IETF Geographic Location/Privacy (GEOPRIV) Working Group have published an Internet Draft specification for "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)." Document sections 7-8 present the XML schema and XML Schema Registration details.
Overview: "Protocols for requesting and providing location information require a way for the requestor to specify the location that should be returned. In a location configuration protocol (LCP), the location being requested is the requestor's location. This fact can make the problem of identifying the Device simple, since IP datagrams that carry the request already carry an identifier for the Device, namely the source IP address of an incoming request. Existing LCPs, such as HTTP-Enabled Location Delivery (HELD) and DHCP (RFC 3825, RFC 4776) rely on the source IP address or other information present in protocol datagrams to identify a Device. When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.
Two additional use cases are addresses by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.
This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted... Specifically, it extends the HELD protocol to support the inclusion of additional identifiers for the Device in HELD location requests. An XML schema is defined that provides a structure for including these identifiers in HELD requests..."
W3C Invites Implementations of MathML Version 3.0 and CSS Profile
David Carlisle, Patrick Ion (et al, eds), W3C Technical Reports
Members of the W3C Math Working Group now invite implementation of the Candidate Recommendation specifications for "Mathematical Markup Language (MathML) Version 3.0" and the companion "MathML for CSS Profile." The goal of MathML is to enable mathematics to be served, received, and processed on the World Wide Web, just as HTML has enabled this functionality for text...
The MathML Version 3.0 specification for MathML as a markup language is intended primarily for a readership consisting of those who will be developing or implementing renderers or editors using it, or software that will communicate using MathML as a protocol for input or output. It is not a User's Guide but rather a reference document. MathML can be used to encode both mathematical notation and mathematical content. About thirty-eight of the MathML tags describe abstract notational structures, while another about one hundred and seventy provide a way of unambiguously specifying the intended meaning of an expression. Additional chapters discuss how the MathML content and presentation elements interact, and how MathML renderers might be implemented and should interact with browsers. Finally, this document addresses the issue of special characters used for mathematics, their handling in MathML, their presence in Unicode, and their relation to fonts.
While MathML is human-readable, authors typically will use equation editors, conversion programs, and other specialized software tools to generate MathML. Several versions of such MathML tools exist, both freely available software and commercial products, and more are under development.
The "MathML for CSS Profile" specification describes a profile of MathML 3.0 that allows formatting with Cascading Style Sheets (CSS). The group is developing a Test Suite for specifications, starting from the MathML 2.0 Test Suite.
See also: 'A MathML for CSS Profile'
W3C Proposed Recommendation for Cascading Style Sheets: Selectors Level 3
Tantek Çelik, Elika Etemad, Daniel Glazman (eds), W3C Technical Report
Members of the W3C Cascading Style Sheets (CSS) Working Group have published a Proposed Recommendation specification for "Selectors Level 3." Selectors are patterns that match against elements in a tree, and as such form one of several technologies that can be used to select nodes in an XML document. Selectors have been optimized for use with HTML and XML, and are designed to be usable in performance-critical code.
This document describes the selectors that already exist in CSS1 and CSS2, and further introduces new selectors for CSS3 and other languages that may need them. Selectors define a function such that, given an element and a selector, the specification defines whether that element matches the selector. These expressions can also be used, for instance, to select a set of elements, or a single element from a set of elements, by evaluating the expression across all the elements in a subtree. STTS (Simple Tree Transformation Sheets), a language for transforming XML trees, uses this mechanism.
A "Selectors Level 3 Implementation Report" is also available. The results show that each test was passed by at least two of the tested implementations. Because of the complexity of the tests (for each implementation there are four sets of results: HTML, XHTML, XML, and XML with namespaces) each implementation is reported separately. Four implementations were tested; three HTML browsers and one print formatter: Konqueror 4.2.2 by KDE, Firefox 3.5.3 by Mozilla Corporation, Opera Browser! 10.0 by Opera ASA, and Prince 7.0 by YesLogic..."
Sun Microsystems Launches GlassFish Enterprise Server v3
Staff, Sun Announcement
"Sun Microsystems and the GlassFish community have announced the immediate availability of Sun GlassFish Enterprise Server v3, the latest release of Sun's commercial Java Platform Enterprise Edition (Java EE) application server and its open source counterpart, GlassFish v3. GlassFish is the industry's most downloaded Java EE compatible application server, with over 24 million downloads to date. Sun GlassFish Enterprise Server v3 provides provides customers with an enterprise grade, open source based application server solution focused on reducing application and deployment complexity...
The flexibility and extensibility of Sun GlassFish Enterprise Server v3 enables third parties to leverage an embedded API to create a customized, integrated solution within a single Java Virtual Machine. Sun GlassFish Enterprise Server v3 administration is extensible and enables extensions to be exposed through the web console, Command Line Interface (CLI) and RESTful API administration facilities. In addition, Sun GlassFish Enterprise Server v3 provides the ability for OEMs to re-brand the administration interface, install custom OSGi bundles and leverage the RESTful administration API for secure, remote programmatic administration and monitoring...
See also: Sun GlassFish Enterprise Server v3
Modular Java: Declarative Modularity
Alex Blewitt, InfoQueue
This fourth article in the Modular Java series covers declarative modularity. We describe how to define components and then hook them up together, without having a programmatic dependency on the OSGi APIs...
The previous instalment, 'Modular Java: Dynamic Modularity', described how to bring dynamic modularity to an application through the use of services. These are implementations that export one (or more) interfaces that can be discovered dynamically at runtime. Whilst this allows for full de-coupling between client and server, it leads to a question of how (and when) the services start up...
Declarative Services provides both wiring between components and registering of services, which helps to avoid any start-up ordering dependencies. Furthermore, the dynamic nature means that as our dependent services come and go, so too does our component/service come and go as well. Finally, whether using DS or manually managed services, they all use the same OSGi service layer in order to communicate. Therefore, one bundle could provide services via a manual method, and another could consume it using declarative services (or vice versa). We should be able to mix and match the 1.0.0 and 1.1.0 implementations and they should transparently work..."
XML Daily Newslink and Cover Pages sponsored by:
|Sun Microsystems, Inc.
XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: firstname.lastname@example.org
Newsletter unsubscribe: email@example.com
Newsletter help: firstname.lastname@example.org
Cover Pages: http://xml.coverpages.org/