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

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

MessageWas writing a completely different message, and discovered things =
 are a bit different than I thought originally. The setSign method to =
sign the EbxmlMessage through Request, though you could do it manually =
on the EbxmlMessage as well. The KeyAlg algorithm for acknowledgments =
was added per my request a couple of weeks ago, I never bother with =
signing messages at that point. From the looks of it, your proposed =
change is right on the spot.
I guess it's ok that the signature params can be set by the client. That =
way we can use the MSH in ASP mode so that it can be used with different =
sigs for different companies sharing the MSH (for instance)

--Gait.
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Monday, May 12, 2003 1:09 AM
  Subject: RE: [ebxmlms-develop] Using alternative signing key =
algorithms


  I agree with you, but how do I do it? Where do I tell Hermes to sign =
the message at the MSH on the way out, rather than having it signed by =
the client?

  PJDM
  --
  Peter Mayne
  Technology Consultant
  Spherion Technology Solutions
  Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
  T: 61 2 62689727  F: 61 2 62689777=20
    -----Original Message-----
    From: Gait Boxman [mailto:gai...@ti...]=20
    Sent: Friday, 9 May 2003 8:07 PM
    To: ebx...@li...
    Subject: Re: [ebxmlms-develop] Using alternative signing key =
algorithms


    Hi Peter,

    why would you want the clients to sign messages? The purpose of the =
sig as I read it from the spec is non-repudiation of origin *from the =
MSH*, not from the client. While I can see a point in having the client =
(or effectively the business app/user) sign the message as well, this =
does not replace the MSH signature. I wouldn't place such support on the =
Request, but rather on the ebXMLMessage (probably already is there, =
maybe not public).
      ----- Original Message -----=20
      From: Mayne, Peter=20
      To: 'ebx...@li...'=20
      Sent: Friday, May 09, 2003 3:15 AM
      Subject: [ebxmlms-develop] Using alternative signing key =
algorithms


      If I'm using an RSA key, there's no way to tell Request.setSign() =
to use a different algorithm from the default when creating a message. =
(The msh.properties.xml file has =
"MSH/DigitalSignature/AckSign/KeyStore/Algorithm" so Hermes can sign =
messages, but it appears to have been overlooked so Hermes clients can =
sign messages.)

      I fixed this by adding another definition of Request.setSign:=20

      -- BEGIN --=20
          /**=20
           * Set keystore properties.=20
           *=20
           * @param alias         Alias of the keystore.=20
           * @param password      Keystore password.=20
           * @param keyStoreFile  Keystore file.=20
           * @param keyAlgorithm  Key algorithm.=20
           */=20
          public void setSign(String alias, char[] password, String =
keyStoreFile, String keyAlgorithm) {=20
              this.alias =3D alias;=20
              this.password =3D password;=20
              this.keyStoreFile =3D keyStoreFile;=20
              this.keyAlgorithm =3D keyAlgorithm;=20
          }=20
      -- END --=20

      (This obviously requires a private String keyAlgorithm to be =
defined in Request.)=20

      In the two places in Request where the signing actually happens, =
replace the existing code with:=20

      -- BEGIN --=20
              if (alias !=3D null && password !=3D null && keyStoreFile =
!=3D null) {=20
                  try{=20
                      if(keyAlgorithm=3D=3Dnull)=20
                      {=20
                          ebxmlMessage.sign(alias, password, =
keyStoreFile);=20
                      }=20
                      else=20
                      {=20
                          ebxmlMessage.sign(alias, password, =
keyStoreFile, keyAlgorithm);=20
                      }=20
                  }=20
                  catch (Exception e) {=20
                      throw new RequestException(e.getMessage());=20
                  }=20
              }=20
      -- END --=20

      Can you please add this (or similar) to the nightly build.=20

      Thanks.=20

      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:

(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

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

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