Details

    • Type: New Feature
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.3.0
    • Labels:
      None

      Description

      Add Vincenzo's S/MIME related code.

        Issue Links

          Activity

          Hide
          vincenzo Vincenzo Gianferrari Pini added a comment -

          Just added four classes:
          1) org.apache.james.transport.mailets.SMIMEAbstractSign is an abstract mailet providing common SMIME signature services. It can be subclassed to make authoring signing mailets simple.
          2) org.apache.james.transport.mailets.SMIMESign is a mailet that puts a server-side SMIME signature on a message. It is a concrete subclass of SMIMEAbstractSign, with very few modifications to it.
          3) org.apache.james.security.KeyHolder is a helper class dealing with all the cryptography related issues.
          4) org.apache.james.security.SMIMEAttributeNames contains some SMIME related mail attribute names of general usage.

          They seem to work fairly well; I just need to add some more javadoc to KeyHolder.

          I found a solution (already of common use) to the Outlook Express problem reported in http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache.org&msgNo=9935, so I went on with the work I started in September 2003.

          In a few days I will put something in the wiki about all this.

          The classes I wrote (specifically KeyHolder) depend heavily on the Bouncy Castle libraries, and bcmail-jdk14-124.jar and bcprov-jdk14-124.jar must be in the

          {james}

          /lib directory both to compile and to run. I didn't do such CVS commit. Who should do this (including updating the build scripts)?

          I choosed also to break the compatibility with jdk 1.3, as the crypto functionalities are heavily dependent on jdk 1.4+. I could anyhow (I tested it already) make it work also with 1.3, but compilation/deployment would be messy.

          Next steps are to build an SMIMECheckSignature mailet, that sets some attributes to be used by other matchers and mailets. I plan to do it possibly in August.

          Show
          vincenzo Vincenzo Gianferrari Pini added a comment - Just added four classes: 1) org.apache.james.transport.mailets.SMIMEAbstractSign is an abstract mailet providing common SMIME signature services. It can be subclassed to make authoring signing mailets simple. 2) org.apache.james.transport.mailets.SMIMESign is a mailet that puts a server-side SMIME signature on a message. It is a concrete subclass of SMIMEAbstractSign, with very few modifications to it. 3) org.apache.james.security.KeyHolder is a helper class dealing with all the cryptography related issues. 4) org.apache.james.security.SMIMEAttributeNames contains some SMIME related mail attribute names of general usage. They seem to work fairly well; I just need to add some more javadoc to KeyHolder. I found a solution (already of common use) to the Outlook Express problem reported in http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache.org&msgNo=9935 , so I went on with the work I started in September 2003. In a few days I will put something in the wiki about all this. The classes I wrote (specifically KeyHolder) depend heavily on the Bouncy Castle libraries, and bcmail-jdk14-124.jar and bcprov-jdk14-124.jar must be in the {james} /lib directory both to compile and to run. I didn't do such CVS commit. Who should do this (including updating the build scripts)? I choosed also to break the compatibility with jdk 1.3, as the crypto functionalities are heavily dependent on jdk 1.4+. I could anyhow (I tested it already) make it work also with 1.3, but compilation/deployment would be messy. Next steps are to build an SMIMECheckSignature mailet, that sets some attributes to be used by other matchers and mailets. I plan to do it possibly in August.
          Hide
          sbrewin@apache.org Steve Brewin added a comment -

          As I understand it, the 2.2.1_fcs branch is intended to support JDK 1.3 and we shouldn't be committing code depending on JDK 1.4 to this branch.

          Such code will break the build if a JDK 1.3 compiler is used. If a JDK 1.4 compiler is used it will build OK but will not run under JDK 1.3.

          A similar problem is dealt with by the Ant "prepare-jdbc3" target in 'build.xml' (the JDBC version varies with JDK). Perhaps a similar approach will deal with this issue?

          Alternatively solutions include:

          • Only committing JDK 1.3 compliant code
          • Continuing to use JDK 1.3 for the official build but add an option to 'build.xml' to allow JDK 1.4 and add a set of JDK 1.4 reliant sources which are only included if this option is set. In this way anyone building from source can elect to discard JDK 1.3 support.

          In any event, IMHO we should always simultaneously commit any required updates to resources such as 'build.xml' or the libs to ensure a clean build under the officially supported JDK.

          Of course, opinions may differ.

          – Steve

          Show
          sbrewin@apache.org Steve Brewin added a comment - As I understand it, the 2.2.1_fcs branch is intended to support JDK 1.3 and we shouldn't be committing code depending on JDK 1.4 to this branch. Such code will break the build if a JDK 1.3 compiler is used. If a JDK 1.4 compiler is used it will build OK but will not run under JDK 1.3. A similar problem is dealt with by the Ant "prepare-jdbc3" target in 'build.xml' (the JDBC version varies with JDK). Perhaps a similar approach will deal with this issue? Alternatively solutions include: Only committing JDK 1.3 compliant code Continuing to use JDK 1.3 for the official build but add an option to 'build.xml' to allow JDK 1.4 and add a set of JDK 1.4 reliant sources which are only included if this option is set. In this way anyone building from source can elect to discard JDK 1.3 support. In any event, IMHO we should always simultaneously commit any required updates to resources such as 'build.xml' or the libs to ensure a clean build under the officially supported JDK. Of course, opinions may differ. – Steve
          Hide
          vincenzo Vincenzo Gianferrari Pini added a comment -

          Referring to Steve's comment, I thought that jdk 1.3 support was related to the current official release (2.2.0) and not to the cvs branch, knowing that we are discussing on whether dropping or not such support for the next release, whatever it may be (after Noel's merge: 2.2.1?).
          Obviously I know that no decision has been made about jdk 1.3 support, and I'm sorry if I created any problem.
          In the meantime, I'm going to remove any jdk 1.4 dependency as soon as possible, and today or tomorrow I'm going to commit it. Such new code will be compileable and runnable both under jdk 1.3 and 1.4, but will depend in a stronger way on the Bouncy Castle libraries (fact that IMHO is not so bad).
          Anyway, we must take a decision about the jdk support issue, as my fear is that we will get problems for cryptography functionalities when we will get to jdk 1.5: the 1.3 version of the crypto code works with jdk 1.4, and the 1.4 version works with jdk 1.5, but I'm afraid that the 1.3 version will not work with jdk 1.5. I havent't made any testing with jdk 1.5 though, and this issue may simply be premature.

          Show
          vincenzo Vincenzo Gianferrari Pini added a comment - Referring to Steve's comment, I thought that jdk 1.3 support was related to the current official release (2.2.0) and not to the cvs branch, knowing that we are discussing on whether dropping or not such support for the next release, whatever it may be (after Noel's merge: 2.2.1?). Obviously I know that no decision has been made about jdk 1.3 support, and I'm sorry if I created any problem. In the meantime, I'm going to remove any jdk 1.4 dependency as soon as possible, and today or tomorrow I'm going to commit it. Such new code will be compileable and runnable both under jdk 1.3 and 1.4, but will depend in a stronger way on the Bouncy Castle libraries (fact that IMHO is not so bad). Anyway, we must take a decision about the jdk support issue, as my fear is that we will get problems for cryptography functionalities when we will get to jdk 1.5: the 1.3 version of the crypto code works with jdk 1.4, and the 1.4 version works with jdk 1.5, but I'm afraid that the 1.3 version will not work with jdk 1.5. I havent't made any testing with jdk 1.5 though, and this issue may simply be premature.
          Hide
          vincenzo Vincenzo Gianferrari Pini added a comment -

          Removed all dependencies from JDK 1.4.

          The new code compiles and runs under JDK 1.4 and is supposed to behave the same way under JDK 1.3 (I cannot test it). A test under JDK 1.5 should be done someday.

          I'm not able to update build.xml and add the required jars to (james)/lib. Can someone else do it in my place?

          The required jars are:
          bcmail-jdk13-124.jar
          bcprov-jdk13-124.jar
          jce-jdk13-124.jar

          They can be found in
          http://www.bouncycastle.org/latest_releases.html

          The "124" in the jar names above means the last available release from Bouncy Castle.

          Show
          vincenzo Vincenzo Gianferrari Pini added a comment - Removed all dependencies from JDK 1.4. The new code compiles and runs under JDK 1.4 and is supposed to behave the same way under JDK 1.3 (I cannot test it). A test under JDK 1.5 should be done someday. I'm not able to update build.xml and add the required jars to (james)/lib. Can someone else do it in my place? The required jars are: bcmail-jdk13-124.jar bcprov-jdk13-124.jar jce-jdk13-124.jar They can be found in http://www.bouncycastle.org/latest_releases.html The "124" in the jar names above means the last available release from Bouncy Castle.
          Hide
          noel Noel J. Bergman added a comment -

          The JDK 1.3 fix is incomplete. java.security.cert.X509Certificate does not support getSubjectX500Principle() until JDK 1.4, as noted in the javadocs for that method. There are three uses of this in KeyHolder. Until this is resolved, this new code won't compile under JDK 1.3.

          Show
          noel Noel J. Bergman added a comment - The JDK 1.3 fix is incomplete. java.security.cert.X509Certificate does not support getSubjectX500Principle() until JDK 1.4, as noted in the javadocs for that method. There are three uses of this in KeyHolder. Until this is resolved, this new code won't compile under JDK 1.3.
          Hide
          vincenzo Vincenzo Gianferrari Pini added a comment -

          Removed another dependency from JDK 1.4 pointed out by Noel: changed java.security.cert.X509Certificate#getSubjectX500Principal() calls to java.security.cert.X509Certificate#getSubjectDN() calls.

          Show
          vincenzo Vincenzo Gianferrari Pini added a comment - Removed another dependency from JDK 1.4 pointed out by Noel: changed java.security.cert.X509Certificate#getSubjectX500Principal() calls to java.security.cert.X509Certificate#getSubjectDN() calls.
          Hide
          bago Stefano Bagnara added a comment -

          We removed jdk 1.3 compliance, so this issue "open tasks" don't apply anymore.

          Show
          bago Stefano Bagnara added a comment - We removed jdk 1.3 compliance, so this issue "open tasks" don't apply anymore.
          Hide
          danny@apache.org Danny Angus added a comment -

          Closing issue fixed in released version.

          Show
          danny@apache.org Danny Angus added a comment - Closing issue fixed in released version.

            People

            • Assignee:
              vincenzo Vincenzo Gianferrari Pini
              Reporter:
              noel Noel J. Bergman
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development