Re: [ebxmlms-develop] Using alternative signing key algorithms

[Gait B. <gai...@ti...>]

RE: [ebxmlms-develop] Using alternative signing key algorithmsthnx =
Peter, that was the section that I remembered triggering me on the MSH =
signing earlier.
Yes, per the spec it is the MSH that must sign the message, and the =
client (application) may sign it as well. When the client signs the =
message, the MSH must as well.
When you send something to another party, you can only send it to the =
endpoint URL, so the acknowledgment will have to be signed by the MSH =
(message acks are never signed by the app as it is not involved, =
however, a separate business ack may be sent and signed by the app, but =
that's a regular message as far as ebMS is concerned).
Still, this does not imply that only one key pair is in use for any =
given MSH. While the ack key will be exactly one per MSH, the key for =
outgoing messages might be different. Which signatures you accept only =
depends on the certificates that are trusted. There may be a key K1 =
saying 'MSH Y on behalf of client A' and another K2 saying 'MSH Y on =
behalf of client B'. For the ack, the only thing you need to say is 'MSH =
Y' (K3), since the ack does not imply routing to either client A or B, =
just that MSH Y got the message intact. Then, partners of client A will =
only trust the certificates for their partner (K1 and K3) while partners =
of client B will only trust certificates for K2 and K3.

And yet, it is still the MSH that must do the signing of the message, at =
least for the first dsig entry in the message, so we need to change the =
behaviour such that:
Request provides a way to add one or more client signature(s) to the =
message before sending it over to the MSH (suggest addSignature...).
Request provides a way to specifically request the MSH to add a =
signature of its own (suggest setSigned...)
Request provides a way to specify an alternate key location fo the MSH =
signature (could use setSign here)
The MSH signs with a default key (from msh.properties.xml, we need =
entries for this as it may not be the same as for acks) or provided key =
(through setSign) whenever:
- a signature was explicitly requested with setSigned(true), or
- a signature was explicitly set with setSign(....), or
- a client signature was added with addSignature or directly on the =
EbxmlMessage.
And we need to make sure that when the MSH adds a signature, it adds it =
before any client signatures.

sorry, no patches on this one, I have to revert back to my paid project.

One open issue is who should verify the client sigs, the MSH or the =
client? Anyway we probably also need a version of EbxmlMessage.verify =
that verifies a specific signature.

--Gait.
Request.setSign merely forwards these parameters to the MSH, while the =
MSH does the actual signing prior to sending out the message (I would =
suggest having another property signed that triggers the signing by the =
MSH). Client signing is to be done on the EbxmlMessage directly prior to =
sending, .=20
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Tuesday, May 13, 2003 4:16 AM
  Subject: RE: [ebxmlms-develop] Using alternative signing key =
algorithms


  From the ebXML spec:=20

  <quote>=20
  1.2.4 Modes of operation=20

  Security Services - digital signature creation and=20
  verification, encryption, authentication and authorization.=20
  These services MAY be used by other components of the=20
  MSH including the Header Processing and Header Parsing=20
  components.=20

  4.1.1 Signature Element=20

  If there is more than one Signature element contained=20
  within the SOAP Header, the first MUST represent the digital signature =
of the ebXML Message as signed=20
  by the From Party MSH in conformance with section 4.1.=20
  </quote>=20

  A casual reading of the above would lead me to believe that the =
message must be signed by the MSH, not by a client. Admittedly, I =
couldn't find anywhere that says what certificates may be used, so I =
suspect that doing it the way that it is makes no difference.

  A consequence is that I can send a message to Party A (the actual =
trading partner), and get an acknowledgement from Party B (the MSH). Do =
you allow for that?

  PJDM=20
  --=20
  Peter Mayne=20
  Technology Consultant=20
  Spherion Technology Solutions=20
  Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602=20
  T: 61 2 62689727  F: 61 2 62689777=20
  -----Original Message-----=20
  From: Patrick Yee [mailto:kc...@ce...]=20
  Sent: Tuesday, 13 May 2003 11:22 AM=20
  To: ebx...@li...=20
  Subject: Re: [ebxmlms-develop] Using alternative signing key =
algorithms=20



  For this, we had a debate internally before. We concluded that the =
nature of message signing and acknowledgement signing are different. =
Message signing is used to testify the message (and the most important, =
the payloads) is sent by the real sender. Acknowledgement signing is =
used to testify the message has been safely arrived at the real =
destination (i.e. the real MSH). Following this model, we can accept all =
applications to "share" the private key for signing acknowledgement =
messages. While at the same time, we think the non-repudiation property =
of message signing drives us to think carefully about holding all keys =
in a central point. Basically our concept is following the ASP model. As =
a result, as you can see in the current desi gn, we perform the signing =
in Request object, i.e. in the client side.

  Regards, -Patrick=20



  Mayne, Peter wrote:=20

  >> I agree that there should also be a way of having the MSH sign the =
outgoing message, so there wouldn't=20
  >> need to be more than one copy of the private key lying around.=20
  >=20
  > Yes and no. It may be more handy. But I'm just feeling a bit =
unsecured to have MSH to hold the private=20
  > key for the application. What do you think?=20
  But Hermes already has the private key for message signing =
(MSH/DigitalSignature/AckSign/KeyStore) so it can sign acknowledgements. =
I don't see any way around that.

  Given that the MSH must have a copy of the private key (like it or =
not), it makes sense under some circumstances to have that be the only =
copy of the private key.

  As usual, there's more than one configuration to think about.=20
  1) One single key at the MSH to do all outgoing message signing =
(including originals and acknowledgements). This makes sense for a =
single business sending messages to trading partners.

  2) All messages signed by the message clients. This makes sense for =
Gait's suggestion of running the MSH in ASP mode for different clients. =
The trouble with this is that message acknowledgements are still signed =
by the MSH, rather than a client's key, so running Hermes in ASP mode =
won't currently work.

  PJDM=20
  --=20
  Peter Mayne=20
  Technology Consultant=20
  Spherion Technology Solutions=20
  Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602=20
  T: 61 2 62689727  F: 61 2 62689777=20
  The information contained in this email and any attachments to it:=20

  (a) may be confidential and if you are not the intended recipient, any =
interference with,=20
  use, disclosure or copying of this material is unauthorised and =
prohibited; and=20

  (b) may contain personal information of the recipient and/or the =
sender as defined=20
  under the Privacy Act 1988 (Cth). Consent is hereby given by the =
recipient(s) to=20
  collect, hold and use such information and any personal information =
contained in a=20
  response to this email, for any reasonable purpose in the ordinary =
course of=20
  Spherion's=20
  business, including forwarding this email internally or disclosing it =
to a third party. All=20
  personal information collected by Spherion will be handled in =
accordance with=20
  Spherion's Privacy Policy. If you have received this email in error, =
please notify the=20
  sender and delete it.=20

  (c) you agree not to employ or arrange employment for any candidate(s) =
supplied in=20
  this email and any attachments without first entering into a =
contractual agreement with=20
  Spherion. You further agree not to divulge any information contained =
in this document=20
  to any person(s) or entities without the express permission of =
Spherion.=20



   =20
  ------------------------------------------------------- Enterprise =
Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only =
event dedicated to issues related to Linux enterprise solutions =
www.enterpriselinuxforum.com =
_______________________________________________ ebxmlms-develop mailing =
list ebx...@li... =
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop