Optimising xml schema for iodef data model
1 / 13

Optimising XML Schema for IODEF Data model - PowerPoint PPT Presentation

  • Uploaded on

Optimising XML Schema for IODEF Data model. INCH WG, IETF57 July 16, 2003 Yuri Demchenko <[email protected]>. Outlines. Motivation for moving to Schema definition Changes and Optimisations to IODEF elements semantics Extra features: XML Signature and Multilingual text type.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Optimising XML Schema for IODEF Data model' - ruby

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Optimising xml schema for iodef data model

Optimising XML Schema for IODEF Data model


July 16, 2003

Yuri Demchenko <[email protected]>


  • Motivation for moving to Schema definition

  • Changes and Optimisations to IODEF elements semantics

  • Extra features: XML Signature and Multilingual text type

XML Security

Motivation for moving to xml schema
Motivation for moving to XML Schema

  • DTD is document-oriented

    • Like HTML

  • Schema is data-oriented

    • More object oriented

    • Integrated into development tools

    • Easier maintenance (validation, modification, documentation - using tools)

  • Enabling other useful features

    • XML Signature

    • SAML

    • XPath, XSL and XSLT, XLink, XPointer

XML Security

Semantics change for some attributes 1
Semantics change for some attributes (1)

  • Due to more complex way of naming attributes in the schema, introduced and redefined few attributes:

    • introduced Contact.contactrole

      • was just “role” defined locally for the Contact element

    • introduced Contact.contacttype

      • was just “type” defined locally for the Contact element

    • cloned attribute Expectation.priority from attvals.severity

      • Was priority %attvals.severity; #IMPLIED

    • renamed yesno -> spoofed

    • renamed Expectation.category -> expectation and attvals.expectation

      • Was just “category” defined as attvals.expectations

XML Security

Semantics change for some attributes 2
Semantics change for some attributes (2)

  • Attribute dtype is used for both AdditionalData and RecordItem

    • Was adtype and dtype

    • Problems with IDMEF compatibility?

  • Data types for Telephone and Fax remains “string”

    • Mistakenly was defined in my early comments as "decimal"

XML Security

Container for signature
Container for Signature

  • Added container element Signatures to top level class IODEF-Document

    • May contain multiple signatures ds:Signature with imported namespace

  • <xs:element name="IODEF-Document">     <xs:complexType>      <xs:sequence>      <xs:element ref="Incident" maxOccurs="unbounded"/>      <xs:element ref="Signatures"/>      </xs: sequence>      <xs:attribute name="version" type="xs:string" fixed="0.1"/>     </xs:complexType> </xs:element> <xs:element name="Signatures">     <xs:complexType>      <xs:sequence>       <xs:element ref="ds:Signature" maxOccurs="unbounded"/>      </xs:sequence>     </xs:complexType> </xs:element>

XML Security

Simplified definition elements node service userid
Simplified definition: elements Node, Service, UserId

  • <!ELEMENT Node (name?, Address*, DateTime?, Location?, NodeRole*)>

    • <!ELEMENT Node (((name | Address), Address*), DateTime?, name?, Address*, Location?, NodeRole*)>

    • (domain) name of a node is one but optional; IP Addresses may be many

  • <!ELEMENT Service (((name?, port) | portlist), protocol?, SNMPService?, WebService?)>

    • <!ELEMENT Service (((name | port | (name, port)) | portlist), protocol?, SNMPService?, WebService?)>

    • port primary identified by number, optionally - by name

    • this simplified definition will help to avoid warnings in the future from too strict validators and parsers

    • this definition will also validate initial IDMEF definition and XML text

  • <!ELEMENT UserId ((number, name?) | (name, number?))>

    • Old definition (name | number | (name, number)) generate warning of non-deterministic Schema

    • Other possibility - (name?, number?)

XML Security

New data types
New data types

  • Some elements are defined not as a complexElement but via complexType to allow reuse and easier redefine some complexTypes, in particular:

    • AdditionalDataType

    • IncidentIDType

    • DateTimeType

    • DescriptionType

    • MultilingTextType

    • TextAbstractType

XML Security

Multilingualtexttype and textabstracttype
MultilingualTextType and TextAbstractType

  • To mark-up multilingual text preservation features, introduced two new classes:

    • TextAbstractType to carry language attribute

    • MultilingTextType to describe possible multilingual text transformation by Transform class imported from XMLSig Schema

  • Introduced new element "Name" for Contact class instead of more simple "name"

    • Name defined via MultilingTextType <xs:element name="Name" type="MultilingTextType"/>

XML Security

Ds transform element
ds:Transform element

  • <xs:schema xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xs="http://www.w3.org/2001/XMLSchema">

  • <xs:element name="Transforms" type="TransformsType"/>

  • <xs:complexType name="TransformsType">

  • <xs:sequence>

  • <xs:element ref="Transform" maxOccurs="unbounded"/>

  • </xs:sequence>

  • </xs:complexType>

  • <xs:element name="Transform" type="TransformType"/>

  • <xs:complexType name="TransformType" mixed="true">

  • <xs:choice minOccurs="0" maxOccurs="unbounded">

  • <xs:any namespace="##other" processContents="lax"/>

  • <xs:element name="XPath" type="string"/>

  • ## (1,1) elements from (0,unbounded) namespaces ##

  • </xs:choice>

  • <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/>

  • </xs:complexType>

XML Security

Issue to discuss preserving multilingual text
Issue to discuss: Preserving multilingual text

  • Measures to preserve multilingual non-UTF-8 text look complex, so they better will be limited to elements which are really sensitive to non-UTF-8 encoding: Description Name PostalAddress Impact Location

  • IDN (internationalised domain name) – required to use UTF-8 or other derived encoding.

XML Security

Preserving ml text usage
Preserving ML text - usage

  • Two cases are possible when using XML Signature:

    • Transform to UTF-8 all document and sign the document

    • Use text transformation to keep multilingual text in binary form and sign the document

    • In both cases you need to make conversion to display text on user machine that doesn’t use/handle UTF-8/Unicode

XML Security

Future steps
Future steps

  • Make changes to current DTD-01

  • Include Schema into next IODEF draft?

XML Security