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: 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]