You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Stefano Bagnara (JIRA)" <se...@james.apache.org> on 2006/11/20 17:35:03 UTC
[jira] Updated: (JAMES-596) Reorganize SMIME crypto support code to
share it with future new PGP support code
[ http://issues.apache.org/jira/browse/JAMES-596?page=all ]
Stefano Bagnara updated JAMES-596:
----------------------------------
Fix Version/s: Trunk
(was: Next Major)
not a blocker for next-major. Moving to trunk. Being backward compatible and isolated can be included if ready for the branch
> Reorganize SMIME crypto support code to share it with future new PGP support code
> ---------------------------------------------------------------------------------
>
> Key: JAMES-596
> URL: http://issues.apache.org/jira/browse/JAMES-596
> Project: James
> Issue Type: New Feature
> Components: Matchers/Mailets (bundled)
> Reporter: Vincenzo Gianferrari Pini
> Assigned To: Vincenzo Gianferrari Pini
> Priority: Minor
> Fix For: Trunk
>
>
> The current mailet code that does cryptographic activity is specialized for SMIME. In order to support PGP, as requested by some people (Robert Burrel Donkin), it would be nice to have it rearranged in order to share code as much as possible.
> First of all let me recall the current code.
> There are two similar but not identically built "strains", one written by me, and the other by Stefano. But from our point of view they are equivalent.
> My strain is the SMIMESign mailet that extends SMIMEAbstractSign; the split between the two classes is just to allow for some possible massaging of the message before the signature (the "explanation text" in this case).
> Stefano's strain is composed of the SMIMECheckSignature and SMIMEDecrypt mailet, plus the IsSMIMEEncrypted, IsSMIMESigned and IsX509CertificateSubject matchers.
> SMIMEAbstractSign (and SMIMEDecrypt) uses *for all the SMIME related work* the org.apache.james.security.KeyHolder helper class; similarly SMIMECheckSignature uses the org.apache.james.security.KeyStoreHolder helper class.
> The approach I'm thinking about is the following:
> 1) Create an *interface* named KeyHolder with all the needed (and not SMIME dependent) methods.
> 2) Rename the current KeyHolder class to SMIMEKeyHolder, and have it implement the KeyHolder interface doing the SMIME implementation.
> 3) Create a new PGPKeyHolder implementing KeyHolder interface doing the PGP work. My assumption is that *there is a total equivalence* between the SMIME and PGP required/desired functionalities, captured by the KeyHolder interface.
> 4) Have SMIMEAbstractSign instantiate either SMIMEKeyHolder or PGPKeyHolder as the KeyHolder object that will be used, based on the value of a new <keyHolderClass> attribute, that would be either <keyHolderClass> org.apache.james.security.SMIMEKeyHolder </keyHolderClass>or <keyHolderClass> org.apache.james.security.PGPKeyHolder </keyHolderClass>.
> 5) Rename SMIMESign to Sign, that will become the concrete sign malet driven by the <keyHolderClass> attribute.
> 6) Create two new and very simple SMIMESign and PGPSign mailets, whose only job would be to force the <keyHolderClass> attribute to the right one.
> An equivalent job could and should be done for Stefano's mailets.
> The PGP equivalents of Stefano's matchers should be written from scratch.
> I have already done part of the work. If nobody has anything to say against this approach, I will start committing to trunk in the next few days. Robert after that will write the PGP specific code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org