[ http://issues.apache.org/jira/browse/JAMES-596?page=comments#action_12437211 ] Vincenzo Gianferrari Pini commented on JAMES-596: -------------------------------------------------
About the right approach to the generation of the new MimeBodyPart content, I'm unable to answer; perhaps someone else of the committers can. Post the question to server-dev. > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
