RE: [emergency] XML Content namespacing

ALL

The use of partial encryption of elements might work on medium security industrial applications, but for pre event sensor and intelligence-related messaging activity for national security, bulk encryption of the entire embeddedXMLContent will undoubtedly be required. The use of name spacing elements for keyXMLContent keeps everything usable but it does require prefixing elements copied with the namespace attribute used by keyXMLContent.

I am not a convinced we need to make CAP “default namespace copying” as such an important requirement. The release of CAP 1.1 and in the future resource management and sensor systems payloads will most like require applications to use XSLT processes to create new messages and adding prefix element names during transformation would be trivial (CAP1.0:alert , CAP1.1:alert etc.)

Changes in this method now are significant and would break many prototype EDXL DE applications created during public comment of the EDXL Distribution Element.

The distribution element will require additional review for EDXL Distribution Element 1.1 as contentObject location (Physical and Network) and probably contentObject confidentiality will require ValueListURN (for classification guide) and Value (for content classification level) pairs.

David E. Ellis

Information Management Architect

(505) 844-6697

From: Renato Iannella [mailto:renato@nicta.com.au]
Sent: Tuesday, December 06, 2005 11:43 PM
To: Emergency_Mgt_TC TC
Subject: [emergency] XML Content namespacing

In today's teleconf, I promised to propose a solution to the namespacing issues dealing

with the two children elements of the <xmlContent> element, namely <keyXMLContent>

and <embeddedXMLContent> (as there was lots of discussion on this point).

The problem arises since there maybe XML namespaces used in the <embeddedXMLContent>

that you wish to also use in the <keyXMLContent>, or, in some cases, the <embeddedXMLContent>

is being encrypted and you don't expose the XML namespaces.

Part of the problem is that we have two child elements to deal with, and one (possibly more)

namespace(s) to support.

The reason for having two child elements was to support the use case of the xml content

being encrypted, but still having some (non critical) elements exposed in clear text.

However, there is a way we in which we can use one (and only one) element for xml content that

can support this use case.

Consider the below example, where the xml payload is all expressed within the <xmlContent>

element (assume there is no <keyXMLContent>and <embeddedXMLContent> children elements.

The payload is a CAP message that is encrypted (ie all the stuff between the <EncryptedData>

elements) and three CAP elements at the beginning of the payload that you want to be open and

readable.

<ed:xmlContent>

<scope>Public</scope>

</alert>

<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"

xmlns="http://www.w3.org/2001/04/xmlenc#">

----encrypted CAP elements are here--

</EncryptedData>

<ed:xmlContent>

In this example, we also show the use of XML namespace defaulting. That is, the CAP

and XML Encryption namespace prefixes are not used - although you can - and are default

to the enclosing elements.

You could also express the above with explicit XML namespaces as:

<ed:xmlContent>

<cap:alert xmlns:cap= "urn:oasis:names:tc:emergency:cap:1.1">

<cap:identifier>KAR0-0306112239-SW</cap:identifier>

<cap:source>SW</cap:source>

<cap:scope>Public</cap:scope>

</cap:alert>

<ec:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"

xmlns:ec="http://www.w3.org/2001/04/xmlenc#">

----encrypted CAP elements are here--

</ec:EncryptedData>

<ed:xmlContent>

So, my proposal would be to simplify the specification by using one element <xmlContent>

for all XML payloads. You can use default and/or explicit XML Namespace prefixes.

And since you can include any XML, you can expose any encrypted XML in the same element.

Cheers... Renato Iannella

National ICT Australia (NICTA)

emergency message