[ http://issues.apache.org/jira/browse/JAMES-596?page=comments#action_12437231 ] Robert Burrell Donkin commented on JAMES-596: ---------------------------------------------
OpenPGP/MIME and inline PGP are very different approaches to the problem. An OpenPGP/MIME message (usually) consists of a 2 part MIME document: conceptually the message and a detached signature. An inline PGP message is a single part containing a (probably) clearsigned message. There are some good reasons not to attempt to use the same codebase for OpenPGP/MIME and classic PGP inline: 1 OpenPGP/MIME fits well into the design structure in JAMES created for SMIME. Classic inline PGP is too different and would benefit from a different design. 2 Good support for older PGP versions requires full parsing of every part of every message part. The presence of an OpenPGP/MIME signature can be deduce from the content type. A pure OpenPGP/MIME matcher would offer performance advantages. 3 OpenPGP/MIME can be implemeted cleanly. Supporting classic PGP is messy. Most reasonably up to date open source email clients support OpenPGP/MIME (for example, evolution 2+, thunderbird). OpenPGP/MIME is a good standard which can be easily and robustly implemented. So, amongst those clients that support it, support is good. Classic PGP support is often much patchier: there is a lack of standardisation and there are major interoperability issues. Full support for classic PGP is going to be difficult and time consuming. What would be more worthwhile is support for basic OpenPGP clear signed documents embedded in messages. But that would need separate code. > 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]
