[jira] Commented: (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=comments#action_12437191 ] Robert Burrell Donkin commented on JAMES-596: - JAMES-525 also covers OpenPGP 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 /keyHolderClassor 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]
[jira] Commented: (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=comments#action_12437192 ] Robert Burrell Donkin commented on JAMES-596: - Classic inline PGP is known to be a tough problem. There are known issues with parsing messages and with implementations on some older clients (such outlook). This approach has many significant differences from SMIME. RFC 3156 OpenPGP/MIME describes a cleaner, modern approach using MIME. It builds on the work done using certificates using SMIME and is congruent with it. I propose to add only RFC 3156 OpenPGP/MIME support. 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 /keyHolderClassor 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]
[jira] Commented: (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=comments#action_12437195 ] Robert Burrell Donkin commented on JAMES-596: - I assume that the right approach to the generation of the new MimeBodyPart content is to register appropriate DataContentHandler implementations for the necessary (pgp-*) MIME types. I also assume that the right way to do this in JAMES is to add the implementation classes to src/meta-inf/mailcap. Let me know if any of these assumptions are wide of the mark. 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 /keyHolderClassor 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]
[jira] Commented: (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=comments#action_12437208 ] Vincenzo Gianferrari Pini commented on JAMES-596: - I would return for getSignerCN() the primary name of the PGP key; for getSignerDistinguishedName() I would return a nice toString of the PGP key, and why not a string like [EMAIL PROTECTED], CN=The Primary Name, consistent with the string returned by X509Certificate.getSubjectDN().toString()? 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 /keyHolderClassor 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]
[jira] Commented: (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=comments#action_12437209 ] Vincenzo Gianferrari Pini commented on JAMES-596: - Regarding your proposal of adding only RFC 3156 OpenPGP/MIME support, I leave it to your judgement; but what is the client support for it? The Classic inline PGP is always available to anyone having PGP or GPG installed, so isn't it a pity to miss its support? 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 /keyHolderClassor 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]
[jira] Commented: (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=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 /keyHolderClassor 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]
[jira] Commented: (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=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 /keyHolderClassor 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:
[jira] Commented: (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=comments#action_12436625 ] Robert Burrell Donkin commented on JAMES-596: - KeyHolder contains properties public String getSignerDistinguishedName(); public String getSignerCN(); which have no obvious analogues in OpenPGP. These do not seem to be used very often. 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 /keyHolderClassor 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]
