[guardian-dev] OpenPGP Keychain 2.1 with new API

[Hans of Guardian]

On Sep 16, 2013, at 12:13 PM, Oliver Gasser wrote:

> Hi all,
> 
> On 09/16/2013 05:01 PM, Dominik Schürmann wrote:
>> Sry for the double-email.
>> 
>> After re-reading the old emails in this thread:
>> It seems we disagree on the part whether MIME should be handled by
>> k9mail or the PGP app.
> 
> exactly, this is a very important decision that needs to be taken as it
> massively influences the API and its interaction with clients.
> 
>> 
>> I think it's a two sided sword: On one side, I don't want to add much
>> more parameters to these functions and I think MIME support is actually
>> something that is more part of the mail program than the PGP app.
>> 
>> On the other side, it _could_ help its adoption when implemented in the
>> PGP app. This would also mean, that normal MIME handling in k9mail must
>> be ignored when handling PGP emails and instead letting the PGP app
>> parse it. If we want to do this, I would also introducing special Mime
>> functions, like you proposed.
>> 
>> Regards
>> Dominik
> 
> If we let the mail program do the parsing and the API does just basic
> encryption/decryption and signing/verification the API stays small and
> simple. The mail program would have to identify the multipart
> boundaries, hand them to the API and display the result.
> 
> If the API would fully support PGP/MIME itself (like e.g. GnuPG already
> does) the mail client could hand the complete PGP/MIME message to the
> API which would then identify the relevant parts, decrypt and/or verify.
> The mail client would then display the returned result.
> 
> Both approaches are viable. What is the opinion of the gpg-android
> people about this?
> 
> Two more questions:
> 1) How do we intend to handle versioning of the API? What if we change a
> function after the API had been released?
> 2) How do we handle application/pgp-keys in messages?
> 
> Regards,
> Oliver

I'm thinking at this point that it makes sense to keep the org.openintents.openpgp API only simple operations on only ASCII-armored or byte[] data.

Then for the PGP/MIME API, we would make it separate, like org.openintents.pgpmime, and it would do what Oliver proposes: take the entire raw email, parse it and return all the info.  Since GPG is obviously based on GnuPG, that should be really easy to implement for us.

Then app developers can choose based on their app's architecture.

.hc








> 
>> 
>> On 16.09.2013 16:31, Dominik Schürmann wrote:
>>> Hi Oliver,
>>> 
>>> thanks for your feedback. This helps getting forward :)
>>> 
>>> On 16.09.2013 15:44, Oliver Gasser wrote:
>>>> Regarding PGP/MIME and the API's (future) support for it: Did you
>>>> envision that PGP/MIME encryption/signing would also be handled by
>>>> IOpenPgpService.signAndEncrypt()? How would you signal this (parameter
>>>> or maybe different function "signAndEncryptMime()")?
>>> 
>>> I am not sure if we need to differentiate. The actual handling of MIME
>>> should be solely done on k9mail's side in my opinion. The content parts
>>> of MIME emails are normal ascii armored (Radix-64) OpenPGP conform
>>> content. Do I miss something?
>>> 
>>>> The comment of IOpenPgpService.decryptAndVerify() states, that it
>>>> handles also the case of signature only. What about encryption only?
>>>> There should be something like
>>>> OpenPgpSignatureResult.SIGNATURE_NOT_AVAILABLE. Is this what
>>>> OpenPgpSignatureResult.SIGNATURE_UNKNOWN is for? Some more documentation
>>>> about the constants would be great :-)
>>> 
>>> You are right. I added more documentation to these classes:
>>> https://github.com/dschuermann/openpgp-keychain/blob/master/OpenPGP-Keychain/src/org/openintents/openpgp/IOpenPgpService.aidl
>>> https://github.com/dschuermann/openpgp-keychain/blob/master/OpenPGP-Keychain/src/org/openintents/openpgp/OpenPgpSignatureResult.java
>>> 
>>> So encrypted-only content have signatureResult=null in callback's
>>> onSuccess() after decryptAndVerify().
>>> I renamed SIGNATURE_UNKNOWN to SIGNATURE_UNKNOWN_PUB_KEY
>>> 
>>> Regards
>>> Dominik
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Guardian-dev mailing list
>>> 
>>> Post: Guardian-dev at lists.mayfirst.org
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> 
>>> To Unsubscribe
>>>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>>        Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/dominik%40dominikschuermann.de
>>> 
>>> You are subscribed as: dominik at dominikschuermann.de
>> 
>> 
>> 
>> _______________________________________________
>> Guardian-dev mailing list
>> 
>> Post: Guardian-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> 
>> To Unsubscribe
>>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>        Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/oliver%40flowriver.net
>> 
>> You are subscribed as: oliver at flowriver.net
>> 
> _______________________________________________
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe
>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>        Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info
> 
> You are subscribed as: hans at guardianproject.info