[PGP] API sketch

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[PGP] API sketch

Stefan Bodewig
Sorry for keeping quiet after the first email, but I've been
even more busy than I expected.

So far I don't see any reason to require a JDK > 1.2.

Looking through the immediate needs for Ant and Maven, we'd need
something like

interface Foo {

    /** @param keyId may be null to specify the default key */
    void sign(InputStream data, OutputStream signedOutput,
              String keyId, KeyRing keyRing, boolean asciiArmor)
        throws PGPException;

    /** @param keyId may be null to specify the default key */
    void detachedSign(InputStream data, OutputStream signature,
                      String keyId, KeyRing keyRing, boolean asciiArmor)
        throws PGPException;

    SignatureStatus verifySignature(InputStream data, KeyRing keyRing)
        throws PGPException;

    SignatureStatus verifyDetachedSignature(InputStream data,
                                            InputStream signature,
                                            KeyRing keyRing)
        throws PGPException;
}

class KeyRing {
    InputSteam getStream();
    /** @return null for a public key ring. */
    char[] getPassPhrase();
}

PGPException would be a wrapper for the real exception an
implementation could throw (but I wouldn't want to depend on
commons-lang just for NestableException).

SignatureStatus an enum-like class with ValidSignature, UnknownKey and
InvalidSignature.  We may even include trust calculations here (if
supported), ValidTrustedSignature and ValidUntrustedSignature or
similar.

And finally

class FooFactory {
     static FooFactory getFactory() throws PGPException;
     Foo newFoo() throws PGPException;
}

Foo is a placeholder since (1) I can't come up with a good name right
now and (2) have a long track record of inventing bad names anyway.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PGP] API sketch

Brett Porter-2
Thanks Stefan - feedback inline.

Stefan Bodewig wrote:

>    /** @param keyId may be null to specify the default key */
>    void sign(InputStream data, OutputStream signedOutput,
>              String keyId, KeyRing keyRing, boolean asciiArmor)
>        throws PGPException;
>
>    /** @param keyId may be null to specify the default key */
>    void detachedSign(InputStream data, OutputStream signature,
>                      String keyId, KeyRing keyRing, boolean asciiArmor)
>        throws PGPException;
>
>    SignatureStatus verifySignature(InputStream data, KeyRing keyRing)
>        throws PGPException;
>
>    SignatureStatus verifyDetachedSignature(InputStream data,
>                                            InputStream signature,
>                                            KeyRing keyRing)
>        throws PGPException;
>}
>  
>
These all look fine for most uses, but I would like a default
implementation that builds on something like this:

interface PgpSignatureUpdater {
  void update( byte[] data )
  void update( byte[] data, int offset, int length )
  byte[] finish()
}

This being used to create the detached signature (I'm assuming a
generated detached signature can be later added to the actual message,
and that byte[] is sufficient for both binary and ascii armored output),
and can be used in both signing and verifying. The implementation would
take configuration specifying the keyring, ascii armoring and anything else.

>class KeyRing {
>    InputSteam getStream();
>    /** @return null for a public key ring. */
>    char[] getPassPhrase();
>}
>
>  
>
Seems ok.

>PGPException would be a wrapper for the real exception an
>implementation could throw (but I wouldn't want to depend on
>commons-lang just for NestableException).
>  
>
+1

>SignatureStatus an enum-like class with ValidSignature, UnknownKey and
>InvalidSignature.  We may even include trust calculations here (if
>supported), ValidTrustedSignature and ValidUntrustedSignature or
>similar.
>  
>
Yes, I think all of those would be useful.

>And finally
>
>class FooFactory {
>     static FooFactory getFactory() throws PGPException;
>     Foo newFoo() throws PGPException;
>}
>
>Foo is a placeholder since (1) I can't come up with a good name right
>now and (2) have a long track record of inventing bad names anyway.
>  
>
PgpSigner and PgpSignatureVerifier (I can't think of a unified name
without coffee).

- Brett


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PGP] API sketch

Brett Porter-2
Any more thoughts on this?

Brett Porter wrote:

>Thanks Stefan - feedback inline.
>
>Stefan Bodewig wrote:
>
> > /** @param keyId may be null to specify the default key */
> > void sign(InputStream data, OutputStream signedOutput,
> > String keyId, KeyRing keyRing, boolean asciiArmor)
> > throws PGPException;
> >
> > /** @param keyId may be null to specify the default key */
> > void detachedSign(InputStream data, OutputStream signature,
> > String keyId, KeyRing keyRing, boolean asciiArmor)
> > throws PGPException;
> >
> > SignatureStatus verifySignature(InputStream data, KeyRing keyRing)
> > throws PGPException;
> >
> > SignatureStatus verifyDetachedSignature(InputStream data,
> > InputStream signature,
> > KeyRing keyRing)
> > throws PGPException;
> >}
> >
> >
>These all look fine for most uses, but I would like a default
>implementation that builds on something like this:
>
>interface PgpSignatureUpdater {
>  void update( byte[] data )
>  void update( byte[] data, int offset, int length )
>  byte[] finish()
>}
>
>This being used to create the detached signature (I'm assuming a
>generated detached signature can be later added to the actual message,
>and that byte[] is sufficient for both binary and ascii armored output),
>and can be used in both signing and verifying. The implementation would
>take configuration specifying the keyring, ascii armoring and anything else.
>
> >class KeyRing {
> > InputSteam getStream();
> > /** @return null for a public key ring. */
> > char[] getPassPhrase();
> >}
> >
> >
> >
>Seems ok.
>
> >PGPException would be a wrapper for the real exception an
> >implementation could throw (but I wouldn't want to depend on
> >commons-lang just for NestableException).
> >
> >
>+1
>
> >SignatureStatus an enum-like class with ValidSignature, UnknownKey and
> >InvalidSignature. We may even include trust calculations here (if
> >supported), ValidTrustedSignature and ValidUntrustedSignature or
> >similar.
> >
> >
>Yes, I think all of those would be useful.
>
> >And finally
> >
> >class FooFactory {
> > static FooFactory getFactory() throws PGPException;
> > Foo newFoo() throws PGPException;
> >}
> >
> >Foo is a placeholder since (1) I can't come up with a good name right
> >now and (2) have a long track record of inventing bad names anyway.
> >
> >
>PgpSigner and PgpSignatureVerifier (I can't think of a unified name
>without coffee).
>
>- Brett
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PGP] API sketch

Dave Brondsema
It would be useful, I think, to get a keyid from a signature, fetch and
update keys from a keyserver, and get names and email addresses from a
public key.

Just verifying the signature without showing who's key created it (which
depends on the above functionality) doesn't do a whole lot of good.
Although computing a trust value is what *really* does good.

Brett Porter wrote:

> Any more thoughts on this?
>
> Brett Porter wrote:
>
>> Thanks Stefan - feedback inline.
>>
>> Stefan Bodewig wrote:
>>
>> > /** @param keyId may be null to specify the default key */
>> > void sign(InputStream data, OutputStream signedOutput,
>> > String keyId, KeyRing keyRing, boolean asciiArmor)
>> > throws PGPException;
>> >
>> > /** @param keyId may be null to specify the default key */
>> > void detachedSign(InputStream data, OutputStream signature,
>> > String keyId, KeyRing keyRing, boolean asciiArmor)
>> > throws PGPException;
>> >
>> > SignatureStatus verifySignature(InputStream data, KeyRing keyRing)
>> > throws PGPException;
>> >
>> > SignatureStatus verifyDetachedSignature(InputStream data,
>> > InputStream signature,
>> > KeyRing keyRing)
>> > throws PGPException;
>> >}
>> >
>> >
>> These all look fine for most uses, but I would like a default
>> implementation that builds on something like this:
>>
>> interface PgpSignatureUpdater {
>>  void update( byte[] data )
>>  void update( byte[] data, int offset, int length )
>>  byte[] finish()
>> }
>>
>> This being used to create the detached signature (I'm assuming a
>> generated detached signature can be later added to the actual message,
>> and that byte[] is sufficient for both binary and ascii armored output),
>> and can be used in both signing and verifying. The implementation would
>> take configuration specifying the keyring, ascii armoring and anything
>> else.
>>
>> >class KeyRing {
>> > InputSteam getStream();
>> > /** @return null for a public key ring. */
>> > char[] getPassPhrase();
>> >}
>> >
>> >
>> >
>> Seems ok.
>>
>> >PGPException would be a wrapper for the real exception an
>> >implementation could throw (but I wouldn't want to depend on
>> >commons-lang just for NestableException).
>> >
>> >
>> +1
>>
>> >SignatureStatus an enum-like class with ValidSignature, UnknownKey and
>> >InvalidSignature. We may even include trust calculations here (if
>> >supported), ValidTrustedSignature and ValidUntrustedSignature or
>> >similar.
>> >
>> >
>> Yes, I think all of those would be useful.
>>
>> >And finally
>> >
>> >class FooFactory {
>> > static FooFactory getFactory() throws PGPException;
>> > Foo newFoo() throws PGPException;
>> >}
>> >
>> >Foo is a placeholder since (1) I can't come up with a good name right
>> >now and (2) have a long track record of inventing bad names anyway.
>> >
>> >
>> PgpSigner and PgpSignatureVerifier (I can't think of a unified name
>> without coffee).
>>
>> - Brett
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
Dave Brondsema : [hidden email]
http://www.splike.com : programming
http://www.brondsema.net : personal
                <><

signature.asc (264 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PGP] API sketch

robert burrell donkin
On Sun, 2005-05-29 at 23:41 -0400, Dave Brondsema wrote:
> It would be useful, I think, to get a keyid from a signature, fetch and
> update keys from a keyserver, and get names and email addresses from a
> public key.
>
> Just verifying the signature without showing who's key created it (which
> depends on the above functionality) doesn't do a whole lot of good.
> Although computing a trust value is what *really* does good.

automatically fetching a public key from a server and then presenting
the name and email from it would need to approached carefully. for
example, the key may say "Robert Burrell Donkin (CODE SIGNING KEY)
<[hidden email]>" but may not be B1313DE2. it would be very unwise
to trust such a key.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [PGP] API sketch

Noel J. Bergman
robert burrell donkin wrote:

> Dave Brondsema wrote:

> > It would be useful, I think, to get a keyid from a signature, fetch and
> > update keys from a keyserver, and get names and email addresses from a
> > public key.

> automatically fetching a public key from a server and then presenting
> the name and email from it would need to approached carefully.

You might want to involve Ben Laurie in this discussion.

See also:

  http://mail-archives.apache.org/mod_mbox/incubator-general/200505.mbox/%3c
[hidden email]%3e

  http://mail-archives.apache.org/mod_mbox/incubator-general/200505.mbox/%3c
[hidden email]%3e

        --- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PGP] API sketch

Dave Brondsema
In reply to this post by robert burrell donkin
robert burrell donkin wrote:

> On Sun, 2005-05-29 at 23:41 -0400, Dave Brondsema wrote:
>
>>It would be useful, I think, to get a keyid from a signature, fetch and
>>update keys from a keyserver, and get names and email addresses from a
>>public key.
>>
>>Just verifying the signature without showing who's key created it (which
>>depends on the above functionality) doesn't do a whole lot of good.
>>Although computing a trust value is what *really* does good.
>
>
> automatically fetching a public key from a server and then presenting
> the name and email from it would need to approached carefully. for
> example, the key may say "Robert Burrell Donkin (CODE SIGNING KEY)
> <[hidden email]>" but may not be B1313DE2. it would be very unwise
> to trust such a key.
>
Exactly.  It might be best then to only add functionality for getting a
keyid from a signature.  If keyid is added as a member of
SignatureStatus, then the verify* methods are fine how they are.

--
Dave Brondsema : [hidden email]
http://www.splike.com : programming
http://www.brondsema.net : personal
                <><

signature.asc (264 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: [PGP] API sketch

robert burrell donkin
In reply to this post by Noel J. Bergman
On Mon, 2005-05-30 at 11:18 -0400, Noel J. Bergman wrote:

> robert burrell donkin wrote:
>
> > Dave Brondsema wrote:
>
> > > It would be useful, I think, to get a keyid from a signature, fetch and
> > > update keys from a keyserver, and get names and email addresses from a
> > > public key.
>
> > automatically fetching a public key from a server and then presenting
> > the name and email from it would need to approached carefully.
>
> You might want to involve Ben Laurie in this discussion.

that'd be great. what's the best way to organise this?

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [PGP] API sketch

Noel J. Bergman
robert burrell donkin wrote:
> Noel J. Bergman wrote:
> > You might want to involve Ben Laurie in this discussion.
>
> that'd be great. what's the best way to organise this?

Well, cc'ing him as I've done would be one way to invite Ben to participate.
:-)  And I'll add that I've already posted URLs to his comments in the
Incubator about his own PGP project.

        --- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PGP] API sketch

Stefan Bodewig
In reply to this post by Brett Porter-2
On Thu, 19 May 2005, Brett Porter <[hidden email]> wrote:

> Thanks Stefan - feedback inline.

Oh my time flies when you are having fun, not.  Sorry for the delay
(again).

> These all look fine for most uses, but I would like a default
> implementation that builds on something like this:
>
> interface PgpSignatureUpdater {
>   void update( byte[] data )
>   void update( byte[] data, int offset, int length )
>   byte[] finish()
> }
>
> This being used to create the detached signature (I'm assuming a
> generated detached signature can be later added to the actual
> message, and that byte[] is sufficient for both binary and ascii
> armored output),

I think you can't mix unarmored and armored data, but I'm not sure.
Honestly I'm not even sure you can combine the signature and the
payload at all.

The interface is fine with me.

> The implementation would take configuration specifying the keyring,
> ascii armoring and anything else.

OK.

>>And finally
>>
>>class FooFactory {
>>     static FooFactory getFactory() throws PGPException;
>>     Foo newFoo() throws PGPException;
>>}
>>
>>Foo is a placeholder since (1) I can't come up with a good name
>>right now and (2) have a long track record of inventing bad names
>>anyway.
>>
> PgpSigner and PgpSignatureVerifier (I can't think of a unified name
> without coffee).

I still can't, even after several litres of coffee between my original
mail and now.  Anybody else?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PGP] API sketch

Stefan Bodewig
In reply to this post by Dave Brondsema
On Sun, 29 May 2005, Dave Brondsema <[hidden email]> wrote:

> It would be useful, I think, to get a keyid from a signature, fetch
> and update keys from a keyserver, and get names and email addresses
> from a public key.

I'd prefer to have "fetch key" and "add key to keyring" as separate
activities - and separate from verifying as well.

> Just verifying the signature without showing who's key created it
> (which depends on the above functionality) doesn't do a whole lot of
> good.

True.  So verify*() should not only tell us whether the signature was
valid, but also which key was used to sign.

> Although computing a trust value is what *really* does good.

That's why I had the ValidTrustedSignature and ValidUntrustedSignature
states.  So far I haven't looked into our implementation options to
see whether they support trust calculations at all.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]