[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - Security Concern - Bullet Items
Thanks for the bullet list. See my answer inline ...
Here is the list of security sections bullet items I promised to put together. I reserve the right to add to the list after thinking about this subject some more.
[Hamid]: Of course you have the right to modify your bullet list since you are the author J (we can only provide you with comments and feedback). Just do it as quickly as possible so that I update the document (vote next Wednesday, and we want to give the TC some time to read the proposed CD 2 document).
- Message signature and encryption is specified in WSS1.0 and WSS1.1.
[Hamid]: Shouldn’t we be more specific on what type of signature (detached, evelopped...) should we allow? I personally prefer a detaiched signature, although you may say it has some limitations. What type of encryption? PKI should be enough I think (should we allow symmetric encryption? If yes, will this key be included –in an encrypted form- with the message?). We need to choose the best options to have a balance between good security (not easy to hack) and easy management (ne need to do key management, exchange key related information out of band prior to any messaging exchange). How about the algorithms used for signing and encrypting? Should we limit the usage to only certain algorithms or allow any possible one?
- The structure and content of the Security element MUST conform to the Web Services Security 1.0 or Web Services Security 1.1 - Depending on conformance profile being utilized.
[Hamid]: That’s a too general statement, and I don’t know how much role the conformance profile can play. Jacques would need to look into this. What do we need to include in the conformance profile about this? Which part goes into the adjuncts, which stays in the core draft and which part the conformance profile would not talk about but the core spec would specify directly and clearly independently of the conformance profile. We need to finalize all these things very quickly as we are going to vote for CD 2 next Wednesday.
- To promote interoperability the security element MUST conform to the WS-I Basic Security Profile Version 1.0, and the WS-I Attachments Profile Version 1.0.
- It is not clear to me if we are requiring Security support in all compliant MSHs. If required the spec should read - Support for the X.509 Certificate Token Profile and Username TokenName Profile are REQUIRED. If Security support is not required, then RECOMMENDED should be stated.
[Hamid]: I don’t know what you call “Compliant” MSH. We have at least two or three profiles. If compliant refers to the main profile (the one that Jacques calls the Gateway Profile), then yes Security is required for this profile. I would say the Username Token and the X-509 token should be the only ones required to support for the Gateway profile.
- It is RECOMMENDED that the eb:Messaging Container Element, the SOAP Body, and all attachments be included in the signature.
[Hamid]: I don’t know if we can go into such recommendations. I think all we can say is something like “Any XML element within the SOAP Part can be signed and/or encrypted and that the attatchments can be signed/encrypted if WSS-1.1 is used”, and that we don’t allow signing/encrypting the whole SOAP Part.
- As outlined in WS-I Basic Security Profile, support for Detached Signatures is REQUIRED. An MSH implementation MAY support Enveloped Signatures as defined in the XML Signature Specification. Enveloped Signatures add an additional level of security in preventing the addition of XML elements to the SOAP Header. Enveloped Signatures may limit the ability of intermediaries to process messages.
[Hamid]: I would prefer that we only use detached signatures. The use of ebMS-3 is really wide-scoped (not only intermediaries and complex topologies may be used, but we want to allow composition of ebMS-3 with any possible SOAP specifications and we defnitely want to always allow addition of headers without breaking a signature).
- It is REQUIRED that compliant MSH implementations support the Attachment-Content-Only transform. It is RECOMMENDED that compliant MSH implementations support the Attachment-Complete transform.
-An MSH implementation may encrypt the eb:Messaging Container Element. The eb:PartyInfo section may be used to aid in message routing before decryption has occurred. It is RECOMMENDED that the eb:PartyInfo elements not be encrypted.
[Hamid]: We don’t know yet what the routing mechanism will be based on. I don’t think it is safe to make such a recommendation and suggest a usage of PartyInfo for routing.
- When both signature and encryption are required of the MSH, sign first and then encrypt.
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS