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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: Re: [ebxml-msg] Groups - Security Concern - Bullet Items

Title: Re: [ebxml-msg] Groups - Security Concern - Bullet Items
I am having email issues again. So I am resending.

On 3/3/06 5:43 PM, "Ric Emery" <remery@cyclonecommerce.com> wrote:

My answers are in line as well.

Hamid Ben Malek wrote:


Thanks for the bullet list. See my answer inline ...

-----Original Message-----
From: Ric Emery [mailto:remery@cyclonecommerce.com]
Sent: Thursday, March 02, 2006 3:17 PM
To: Ric Emery
Cc: Hamid Ben Malek; Dale Moberg; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Groups - Security Concern - Bullet Items

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?

[ric] My original Security section outlined all of this info.. The committee preference was for a slimmed down security section. So I spent time reviewing the WS-I Basic Security Profile and the WSS 1.0 Spec. I tried not to duplicate any information in this bullet list that is already included in the Basic Security Profile. The Basic Security Profile requires detached signatures, and specifies the algorithms that are required for signature and encryption.
No I do not think we should limit usage. If two MSHs support an algorithm they should be free to use it. All MSHs should support the algorithms discussed in the Basic Security Profile.



- 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.

[ric] It is a general statement. Not sure how to narrow it down. But we must say that the Security element MUST conform to WSS 1.0 or 1.1. How ever we choose to word that is  fine.



- 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.

[ric] I am not sure how the compliance profiles can be reflected back into the Security Section. For the conformance profiles that require security - Username Token and X-509 are required. I think we are in agreement here.



- 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.

[ric] Why should we not be going into such recommendations? Yes any element can be signed or encrypted. But this committee has the expertise to make such recommendations. Does our shared experience and knowledge not back up the claim made above?
Shouldn't we be making recommendations to ensure implementors have the knowledge to ensure security of ebMS messages?
I think the fact that “Any XML element” can be signed and encrypted is exactly why we should make a recommendation.



- 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).

[ric] I am fine with only supporting detached signatures. Other committee members argued for support of Enveloped signatures. If I remember correctly, Ian and Pete asked that the spec include language that would allow Enveloped Signatures.



- 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.

[ric] I need to think about this one. And need to run out.... Have a good weekend.



- 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



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