[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - Security Concern - Bullet Items
Ric, Thanks for the bullet list. See my answer inline ... -----Original Message----- 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. Ric --------------------------------------------------------------------- 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 at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]