TC
We have used the newest schema (the <valueListURN>
and corresponding <value> elements corrected) to create the attached
messages. Included are EDXL messages before and after signature/encryption,
corrected EDXL-DE schema and short readme. The actual radiation detection
content object was removed to allow open release. The only change needed to
the original messages was moving the <combinedConfidentiality>Unclassified</combinedConfidentiality> to a location which matched the attached schema.
In response to comments
below.
Without inclusion of the <any>
element, the signature elements will cause the EDXL-DE schema to flag
validation errors. What validation is being referred by “truly validate”
below (database rules)?
The inclusion of minOccurs=0 allows a signature
as an option but is not required to create a message. This is demonstrated
by the included before and after messages. Furthermore, based on our
experience, the EDXL-DE header is modified during each phase (location/role) of
the data workflow (changing raw data into actionable information).
Therefore even if other applications would sign entire EDXL-DE messages, we do
not see this as the norm.
We used http://www.w3.org/TR/xmldsig-core/
as a reference for correctly signing the
contentObjects. The use of one contentObject per message does not support
our workflow CONOPs. Also, we need to sign nonXMLContent (e.g. picture of
suspect vehicle) which are included in messages.
David E. Ellis
Information Management Architect
(505) 844-6697
From: Renato Iannella
[mailto:renato@nicta.com.au]
Sent: Sunday, January 15, 2006
8:06 PM
To: Emergency_Mgt_TC TC
Subject: [emergency] Signatures
etc
I think the addition of the <any> element to the ContentObject is
not a good idea.
It now means that you cannot truely validate that element - simply
because *any* element
can now appear there from any namespace.
It seems that this element is being used *primarily* for digital
signatures.
However, it then forces you to put your digital signature inside the
content object.
It does not then allow you to sign the entire EDXL statement, would
would be a common
I am not sure if the examples given in Appendix B are correct (the 2nd
example) as the
digital signatures don't seem to be referring to any content/resource
that they are signing.
For example, using the "enveloped-signature" transforms needs
you to reference the bit
of XML that you are signing? This then means that you usually need an
additional id attribute in some
other XML parent element.
As I showed in previous emails, we can simplify this but support just
one <xmlContent> element
and then allowing, if required the encrypted and signed payload in
there.
Consider the first payload from example 2 on Appendix B, it could be
re-expressed as:
<KeyName>deskey.bin</KeyName>
<CipherValue></CipherValue>
<SignatureValue>data</SignatureValue>
<KeyName>rsakey.pem</KeyName>
That is, all the payload is inside the <xmlContent> including the
encryption and signature.
Cheers...
Renato Iannella
National ICT
Australia (NICTA)