Re: [Enigmail] Keyservers mangle with subkey binding sigs - FIXED (was Re: Sub-Key Look-Up)
Vlad "SATtva" Miller wrote on 19.01.2008 01:58: [snip] > Both subkeys have expired in the end of the last year, but I've chosen > not to generate new and to simply extend life of existing subkeys for > another few years, so I've re-signed them with extended expiration date > and updated to keyservers. A few days later one of my correspondents > contacted me saying that my key is expired and unusable. I've looked at > keyservers, and was very surprised that they're not reflecting the > changes made! > > Here for example (in the bottom) you may see two subkeys with binding > signatures expired at 2007-12-31: > http://pool.sks-keyservers.net:11371/pks/lookup?search=0x8443620A&op=vindex Many thanks for all input. The problem disappeared in the same way it was encountered. Another attempt to search keyservers showed that everything is fine now, both subkeys have all the most recent 0x18 binding sigs. I can't discount the fact that it was I messing here something badly, however this is quite unlikely... Cheers, -- SATtva | security & privacy consulting www.vladmiller.info | www.pgpru.com signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keyservers mangle with subkey binding sigs
Vlad "SATtva" Miller wrote the following on 1/19/08 8:38 AM: [...] So here's an explicit distinction between what we got from a keyserver and from the gpg output. As far as I am concerned, that's what I got from the keyserver I used, yes. I believe <[EMAIL PROTECTED]> posted that: "I'm not too deep into subkeys, but I just downloaded your key 0x8443620A from a keyserver and it had tow subkeys 0x070E0B73 and 0x7D57ED51 both valid till 1.1.2010. But the self-signs on all the different Sub-IDs are expired on 5.1.2008. All this didn't change when I imported the key from www.vladmiller.info So my hint is to sign all the IDs too." [snip] In my system now: I have not signed your key And you should not. Thank you for telling me what I should not, I know the protocol. There is such a thing named 'local sign', that makes a local signature non-exportable, not that I intend to upload your key, that just isn't done. As I indicated in my complete post, I signed (local signature) just in order to find out whether it would make the interrogation point on your *second* "photo" go away, which it didn't, not unexpectedly. Best regards, Charly ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keyservers mangle with subkey binding sigs
Charly Avital wrote on 19.01.2008 18:26: > Vlad "SATtva" Miller wrote the following on 1/19/08 6:01 AM: > [...] > | Here for example (in the bottom) you may see two subkeys with binding > | signatures expired at 2007-12-31: > | > http://pool.sks-keyservers.net:11371/pks/lookup?search=0x8443620A&op=vindex > > So it is. > > | But if you look at the original copy you'll see that all regenerated > | sigs are in place: > | http://www.vladmiller.info/contacts/openpgp.txt > > After importing that keyblock: [snip] > [name]$ gpg --edit-key 8443620A > gpg (GnuPG) 1.4.8; Copyright (C) 2007 Free Software Foundation, Inc. > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > > pub 4096R/8443620A created: 2006-12-21 expires: never usage: SC > ~ trust: unknown validity: unknown . vvv > sub 2048R/070E0B73 created: 2006-12-21 expires: 2010-01-01 usage: S > sub 2048R/7D57ED51 created: 2006-12-21 expires: 2010-01-01 usage: E . ^^^ So here's an explicit distinction between what we got from a keyserver and from the gpg output. [snip] > In my system now: > > I have not signed your key And you should not. -- SATtva | security & privacy consulting www.vladmiller.info | www.pgpru.com signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keyservers mangle with subkey binding sigs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vlad "SATtva" Miller wrote the following on 1/19/08 6:01 AM: [...] | Here for example (in the bottom) you may see two subkeys with binding | signatures expired at 2007-12-31: | http://pool.sks-keyservers.net:11371/pks/lookup?search=0x8443620A&op=vindex So it is. | But if you look at the original copy you'll see that all regenerated | sigs are in place: | http://www.vladmiller.info/contacts/openpgp.txt After importing that keyblock: gpg: key 8443620A: "Vladislav V. Miller (aka SATtva)" 13 new signatures gpg: key 8443620A: "Vladislav V. Miller (aka SATtva)" 11 signatures cleaned gpg: Total number processed: 1 gpg: new signatures: 13 gpg: signatures cleaned: 11 gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 30 signed: 105 trust: 0-, 0q, 0n, 0m, 0f, 30u gpg: depth: 1 valid: 105 signed: 54 trust: 0-, 3q, 0n, 33m, 69f, 0u gpg: depth: 2 valid: 40 signed: 92 trust: 0-, 1q, 2n, 21m, 16f, 0u gpg: depth: 3 valid: 4 signed: 12 trust: 1-, 0q, 0n, 1m, 2f, 0u gpg: depth: 4 valid: 3 signed: 4 trust: 0-, 0q, 0n, 1m, 2f, 0u gpg: next trustdb check due at 2008-02-13 [name]$ gpg --edit-key 8443620A gpg (GnuPG) 1.4.8; Copyright (C) 2007 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub 4096R/8443620A created: 2006-12-21 expires: never usage: SC ~ trust: unknown validity: unknown sub 2048R/070E0B73 created: 2006-12-21 expires: 2010-01-01 usage: S sub 2048R/7D57ED51 created: 2006-12-21 expires: 2010-01-01 usage: E [ unknown] (1). Vladislav V. Miller (aka SATtva) [ unknown] (2) Vladislav V. Miller (aka SATtva) <[EMAIL PROTECTED]> [ unknown] (3) Vladislav V. Miller (aka SATtva) <[EMAIL PROTECTED]> [ unknown] (4) SATtva (openPGP in Russia project admin) <[EMAIL PROTECTED]> [ unknown] (5) Vlad Miller (for private contacts only) <[EMAIL PROTECTED]> [ unknown] (6) [jpeg image of size 7403] [ unknown] (7) [jpeg image of size 7403] In my system now: I have not signed your key Your signature verifies (no longer "..with expired key...". Two user photos are invoked and displayed, one of them shows a person, the other one displays an interrogation mark. After signing (locally) your key, there is no change, still two photos displayed, one is a person, the other one displays an interrogation mark. | [EMAIL PROTECTED] ~ $ cat openpgp.txt | gpg --list-packets | [snip] | :signature packet: algo 1, keyid FAEB26F78443620A | version 4, created 1199529401, md5len 0, sigclass 0x18 | digest algo 2, begin of digest 1f 06 | hashed subpkt 26 len 45 (policy: | http://www.vladmiller.info/services/cert.html) | hashed subpkt 27 len 1 (key flags: 0C) | hashed subpkt 2 len 4 (sig created 2008-01-05) | hashed subpkt 9 len 4 (key expires after 3y11d13h6m) | subpkt 16 len 8 (issuer key ID FAEB26F78443620A) | data: [4095 bits] | | If I understand this correctly and not missing something terribly here, | keyservers just looked at newly uploaded key, thought "huh? I already | have that subkey in place, and this 0x18 sig too!", and discarded it | without going into much trouble of analyzing any binding sigs' | timestamps (maybe marking them as duplicates). I lack the knowledge and background to comment. Charly MacOS X 10.5.1 - GnuPG 1.4.8 - GPG2 2.0.8 with gpg-agent - Thunderbird 2.0.0.9 with Enigmail 0.95.6 - Primary key A57A8EFA - Signing subkey 855B83EF -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.8 (Darwin) Comment: GnuPG for Privacy Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBCAAGBQJHkexVAAoJEM3GMi2FW4PvpLYH/j4v8ZTd1kFItLk33fJW/Dot pOd1IwCHFYMB05FlNYGcmY5NnI1I1za2aCM4I13W28e3/ZV8v8sKjcSodg8b/lQb hvME3BrfgWiCbDjkoMpv3Z4HHGe/e75byVT6nOMOA77n5mCOCwZxUADb+hJ7zfQ/ 6poCh1qW3GRdD0JfttcFx77W7AMNMQSqJ+4WQmuPfyHHqt+/1mbjSA88aVS9KO85 q0v6xatOBZ0WfcbJKsUSTEtZp+8DELzWrZz6sZTmpEQcOhdjzqAs4gx2QU4idd6F GQtuF0eHjLCpvZl4DX5aDVhXSGHnuAi1mX10RH8WbNJwXXuAlUgv7Vi25dzvdVs= =Af0l -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keyservers mangle with subkey binding sigs
Simon Josefsson wrote on 19.01.2008 17:15: > "Vlad \"SATtva\" Miller" <[EMAIL PROTECTED]> writes: [snip] >> If I understand this correctly and not missing something terribly here, >> keyservers just looked at newly uploaded key, thought "huh? I already >> have that subkey in place, and this 0x18 sig too!", and discarded it >> without going into much trouble of analyzing any binding sigs' >> timestamps (maybe marking them as duplicates). >> >> Could anyone confirm this behavior? > > I had similar problems with many key servers, until I switched to > subkeys.pgp.net which is (if I understand correctly) documented to only > point to key servers with full subkey support. subkeys.pgp.net is the first server I send keys to. However, as you can see, it's subkeys support isn't enough: http://subkeys.pgp.net:11371/pks/lookup?search=0x8443620A&op=vindex sub 2048R/070E0B73 2006-12-21 sig sbind 8443620A 2006-12-21 __ 2007-12-31 [] Policy URL: http://www.vladmiller.info/services/cert.html sub 2048R/7D57ED51 2006-12-21 sig sbind 8443620A 2006-12-21 __ 2007-12-31 [] Policy URL: http://www.vladmiller.info/services/cert.html And it's not just an output bug. If you import that key it'll end up like this: gpg: NOTE: signature key 070E0B73 expired Tue 01 Jan 2008 03:26:21 NOVT pub 4096R/8443620A 2006-12-21 uid Vladislav V. Miller (aka SATtva) uid Vladislav V. Miller (aka SATtva) <@> uid Vladislav V. Miller (aka SATtva) <@> uid SATtva (openPGP in Russia project admin) <@> uid Vlad Miller (for private contacts only) <@> uid [jpeg image of size 7403] sub 2048R/070E0B73 2006-12-21 [expired: 2007-12-31] sub 2048R/7D57ED51 2006-12-21 [expired: 2007-12-31] > /Simon > > -- SATtva | security & privacy consulting www.vladmiller.info | www.pgpru.com signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keyservers mangle with subkey binding sigs
"Vlad \"SATtva\" Miller" <[EMAIL PROTECTED]> writes: > While I understand that this place isn't the best for PKS bug reports, > I'm still not sure of what's happening (except it's quite weird). My key > 0x8443620A consists of a main certification key and two subkeys: one for > encryption and one for signing. > > Both subkeys have expired in the end of the last year, but I've chosen > not to generate new and to simply extend life of existing subkeys for > another few years, so I've re-signed them with extended expiration date > and updated to keyservers. A few days later one of my correspondents > contacted me saying that my key is expired and unusable. I've looked at > keyservers, and was very surprised that they're not reflecting the > changes made! > > Here for example (in the bottom) you may see two subkeys with binding > signatures expired at 2007-12-31: > http://pool.sks-keyservers.net:11371/pks/lookup?search=0x8443620A&op=vindex > > But if you look at the original copy you'll see that all regenerated > sigs are in place: > http://www.vladmiller.info/contacts/openpgp.txt > > [EMAIL PROTECTED] ~ $ cat openpgp.txt | gpg --list-packets > [snip] > :signature packet: algo 1, keyid FAEB26F78443620A > version 4, created 1199529401, md5len 0, sigclass 0x18 > digest algo 2, begin of digest 1f 06 > hashed subpkt 26 len 45 (policy: > http://www.vladmiller.info/services/cert.html) > hashed subpkt 27 len 1 (key flags: 0C) > hashed subpkt 2 len 4 (sig created 2008-01-05) > hashed subpkt 9 len 4 (key expires after 3y11d13h6m) > subpkt 16 len 8 (issuer key ID FAEB26F78443620A) > data: [4095 bits] > > If I understand this correctly and not missing something terribly here, > keyservers just looked at newly uploaded key, thought "huh? I already > have that subkey in place, and this 0x18 sig too!", and discarded it > without going into much trouble of analyzing any binding sigs' > timestamps (maybe marking them as duplicates). > > Could anyone confirm this behavior? I had similar problems with many key servers, until I switched to subkeys.pgp.net which is (if I understand correctly) documented to only point to key servers with full subkey support. /Simon ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Keyservers mangle with subkey binding sigs
While I understand that this place isn't the best for PKS bug reports,
I'm still not sure of what's happening (except it's quite weird). My key
0x8443620A consists of a main certification key and two subkeys: one for
encryption and one for signing.
Both subkeys have expired in the end of the last year, but I've chosen
not to generate new and to simply extend life of existing subkeys for
another few years, so I've re-signed them with extended expiration date
and updated to keyservers. A few days later one of my correspondents
contacted me saying that my key is expired and unusable. I've looked at
keyservers, and was very surprised that they're not reflecting the
changes made!
Here for example (in the bottom) you may see two subkeys with binding
signatures expired at 2007-12-31:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x8443620A&op=vindex
But if you look at the original copy you'll see that all regenerated
sigs are in place:
http://www.vladmiller.info/contacts/openpgp.txt
[EMAIL PROTECTED] ~ $ cat openpgp.txt | gpg --list-packets
[snip]
:signature packet: algo 1, keyid FAEB26F78443620A
version 4, created 1199529401, md5len 0, sigclass 0x18
digest algo 2, begin of digest 1f 06
hashed subpkt 26 len 45 (policy:
http://www.vladmiller.info/services/cert.html)
hashed subpkt 27 len 1 (key flags: 0C)
hashed subpkt 2 len 4 (sig created 2008-01-05)
hashed subpkt 9 len 4 (key expires after 3y11d13h6m)
subpkt 16 len 8 (issuer key ID FAEB26F78443620A)
data: [4095 bits]
If I understand this correctly and not missing something terribly here,
keyservers just looked at newly uploaded key, thought "huh? I already
have that subkey in place, and this 0x18 sig too!", and discarded it
without going into much trouble of analyzing any binding sigs'
timestamps (maybe marking them as duplicates).
Could anyone confirm this behavior?
--
SATtva | security & privacy consulting
www.vladmiller.info | www.pgpru.com
signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
