On Thu, 2005-05-19 at 17:27 +1000, Brett Porter wrote: <snip>
> I also though openPGP was an implementation rather than a spec, so maybe > going straight to "commons-crypto" is the best. That gives us scope to > go into encrypt/decrypt as well as signatures and to use other algorithms. > > I'd expect generally to just use JCE for this, but it appears some of > the PGP functions aren't exposed through that - so this API can expose > those things. I guess this should be one of the goals - not to just > reproduce functionality that could otherwise be done via JCE. openPGP is the name used for a group of RFC's inspired by pretty good privacy. http://www.openpgp.org/ is an association of implementors promoting the use of this standard (which is probably the source of the confusion). http://www.ietf.org/rfc/rfc2440.txt is the RFC in question and covers a message format. it included implementation details as well as specification (which is another source for the confusion). it's early days yet but it would be very, very cool to have a pure java openPGP implementation: IMHO one of the reasons why take up has been restricted is the lack of user-friendly open source applications. i really like gnu privacy guard but it is very *nix. a good openPGP library implementation in java would be a great step forward. thinking ahead, i now wonder whether it might be better to think along the lines of a commons-openpgp implementation backed by a commons-crypto library. apache's going to need not only pgp stuff but also user certificate management software. maybe it'd be possible to get enough momentum to think about aiming for a jakarta-crypto in the medium term followed by an apache-crypto project one day... - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
