OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: FW: [emergency] Signatures etc



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

occurrence as well.


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:


                        <xmlContent xmlns:cap1.0="http://www.incident.com/cap/1.0">


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


                                                            <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>

                                                            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">








                                                <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">











That is, all the payload is inside the <xmlContent> including the encryption and signature.


Cheers...  Renato Iannella

National ICT Australia (NICTA)


This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]