[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bouncycastle-crypto-dev
Subject:    [dev-crypto] Preferences from self-signature of public key
From:       "Eamon, Robert" <Robert_Eamon () bmc ! com>
Date:       2010-02-25 19:45:13
Message-ID: 492379B6AA909E4FAF672AACCA0EADC24A3DD46EED () PHXCCRPRD02 ! adprod ! bmc ! com
[Download RAW message or body]

Hi all. I searched the forums for possible guidance but haven't found the right \
stuff.

I'm using LockBox Labs code on top of BC for flexible crypto operations within a \
webMethods Integration Server environment (Java based integration tool). I'm working \
on the encryption facilities and am trying to make sure I use the \
hash/compression/algorithm preferences from the public keys of partners.

The PreferencesUtil class from LockBox provides static methods for getting the latest \
cert (PGPSignature) for a given public key. When using \
PreferencesUtil.latestCertification(pubRing, userID) I'm getting what to me is an \
unexpected signature.

We sign the public key's of others to establish trust. I'm getting that signature \
back rather than the self-signature of the key owner. This might be a wrong \
expectation on my part so I wanted to check to see if that's what should be happening \
or if the code I'm using should be considering the key ID of the signature along with \
the user ID of the public key.

Here's the code frag:

private static PGPSignature latestCertification(PGPPublicKeyRing pubRing, String \
userID) {
    PGPSignature cert = null;
    for (Iterator it = pubRing.getPublicKey().getSignaturesForID(userID); \
it.hasNext();)  {
        cert = (PGPSignature)it.next();
    }

    return cert;
}

This always returns the last signature entry. For one of the keys I'm working with \
there are 2 sigs in the key. One is the self-signature and the other is our "we trust \
this" signature. For purposes of getting the preferences, only self-signatures should \
be considered, correct?

Public key packet dump below (uid obscured)

> public key packet:
	version 4, algo 17, created 1166730547, expires 0
	pkey[0]: [1024 bits]
	pkey[1]: [160 bits]
	pkey[2]: [1024 bits]
	pkey[3]: [1023 bits]
> user ID packet: "Some partner <noone@bitmosphere.com>"
> signature packet: algo 17, keyid 5538AA5844545C11
	version 4, created 1166730547, md5len 0, sigclass 0x13
	digest algo 2, begin of digest 3b 53
	hashed subpkt 2 len 4 (sig created 2006-12-21)
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
	hashed subpkt 21 len 3 (pref-hash-algos: 2 8 3)
	hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (key server preferences: 80)
	subpkt 16 len 8 (issuer key ID 5538AA5844545C11)
	data: [160 bits]
	data: [160 bits]
> trust packet: flag=00 sigcache=03
> signature packet: algo 1, keyid 8DFB23ACE1BD2748
	version 4, created 1247568055, md5len 0, sigclass 0x12
	digest algo 2, begin of digest 5e 8e
	hashed subpkt 2 len 4 (sig created 2009-07-14)
	subpkt 16 len 8 (issuer key ID 8DFB23ACE1BD2748)
	data: [2046 bits]
> trust packet: flag=00 sigcache=00
> public sub key packet:
	version 4, algo 16, created 1166730552, expires 0
	pkey[0]: [2048 bits]
	pkey[1]: [3 bits]
	pkey[2]: [2047 bits]
> signature packet: algo 17, keyid 5538AA5844545C11
	version 4, created 1166730552, md5len 0, sigclass 0x18
	digest algo 2, begin of digest 7d 97
	hashed subpkt 2 len 4 (sig created 2006-12-21)
	hashed subpkt 27 len 1 (key flags: 0C)
	subpkt 16 len 8 (issuer key ID 5538AA5844545C11)
	data: [159 bits]
	data: [158 bits]
> trust packet: flag=00 sigcache=03


Rob


[prev in list] [next in list] [prev in thread] [next in thread]