Re: Subpacket 33 and GnuPG Specifics on RFC-4880 Tag ID's, algorithm identifiers, etc

[FuzzyDrawrings via Gnupg-users]

After looking at the content of subpacket 33, it appears to be the 
signing-key's fingerprint prepended by '0x04'.

So I'm guessing subpacket 33 is to be a more robust version of subpacket 16 
(Issuer)?

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Subpacket 33 and GnuPG Specifics on RFC-4880 Tag ID's, algorithm identifiers, etc

[FuzzyDrawrings via Gnupg-users]

​Hello, I am working to better understand the OpenPGP standard and how it is 
handled by the current implementation of GnuPG.

To this end I have created a Python program that reads ASCII-Armor and returns 
details about the encoded data within. This is purely for my own edification 
and understanding of how OpenPGP works and also learn Python in the process.  
I'm at the point where I can parse ascii armor to display almost all of the 
information I could otherwise get using "$ gpg --list-packets", including 
calculate the actual key fingerprint (which took a lot of re-reading the 
section of RFC-4880 that explains all the data that must be hashed to produce 
the fingerprint).

Does anyone know what are the additions or changes there are, in terms of 
packet tags, signature types, subpacket types, and algorithm identifiers used 
in the current version of GnuPG but that are not defined in RFC4880?

I've figured out a few on my own: additional public-key algorithm identifiers 
like 18 and 19 (ECDH and ECDSA, respectively, as defined in RFC-6637). And it 
seems that 22 is the identifier for Curve 25517 and/or EdDSA.

One I haven't been able to figure out is signature subpacket type 33. The 
signature files for the downloads on gnupg.org contain this subpacket type, but 
it isn't defined in RFC-4880. Strangely, even my installation of GnuPG does not 
display anything but "(?)" for the meaning of this subpacket's content:

$ gpg2 --list-packets gnupg-2.2.4.tar.bz2.sig
# off=0 ctb=89 tag=2 hlen=3 plen=307
:signature packet: algo 1, keyid 249B39D24F25E3B6
version 4, created 1513760871, md5len 0, sigclass 0x00
digest algo 8, begin of digest 75 a5
hashed subpkt 33 len 21 (?)
hashed subpkt 2 len 4 (sig created 2017-12-20)
subpkt 16 len 8 (issuer key ID 249B39D24F25E3B6)
data: [2046 bits]
# off=310 ctb=89 tag=2 hlen=3 plen=307
:signature packet: algo 1, keyid 2071B08A33BD3F06
version 4, created 1513762863, md5len 0, sigclass 0x00
digest algo 8, begin of digest 95 36
hashed subpkt 33 len 21 (?)
hashed subpkt 2 len 4 (sig created 2017-12-20)
subpkt 16 len 8 (issuer key ID 2071B08A33BD3F06)
data: [2046 bits]

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Keys clean of all signatures except those made by others I trust

[Robert J. Hansen]

> please don't script based on the output of gpg without using
> --with-colons.

Correction noted, thank you.  Have one in return.  :)

>   for fpr in $(gpg --with-colons --list-keys | \
>awk -F: '/^fpr:/{ print $10 }'); do \
>   gpg --edit-key "fpr" clean save; done

"fpr" should be $fpr, I think.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Keys clean of all signatures except those made by others I trust

[Daniel Kahn Gillmor]

On Tue 2018-01-23 16:55:20 -0500, Robert J. Hansen wrote:
>> From the man page:
>
> Note that this can be done in a bash one-liner:
>
> $ for x in `gpg --list-keys|grep "[A-F0-9]\{40\}"|sed 's/ //g'` ; do gpg
> --edit-key $x clean save ; done

please don't script based on the output of gpg without using
--with-colons.  the "human-readable" form is subject to change, but
--with-colons offers a stable API. 

so a stable bash script would look something like:

  for fpr in $(gpg --with-colons --list-keys | \
   awk -F: '/^fpr:/{ print $10 }'); do \
  gpg --edit-key "fpr" clean save; done

hope this helps,

 --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: failed to convert unprotected openpgp key: Checksum error

[Daniel Kahn Gillmor]

On Mon 2018-01-22 15:37:37 -0500, Phil Pennock wrote:
> So at this point, it looks to me like it really is an incorrect
> checksum, exposing unfortunate edge-case handling in GnuPG.

Thanks for the diagnosis, Phil and Simon.

Please file a bug report about this at https://dev.gnupg.org/ so that
this edge-case doesn't get lost!

 --dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why exactly does pinentry fails with gpg-agent and ssh support?

[André Colomb]

On 2018-01-22 18:06, André Colomb wrote:
>> the systemd user service takes care of automatically launching the
>> gpg-agent when the user connects to it via the ssh-agent protocol, so
>> this isn't required when using systemd.
> 
> I can't see how it does that in my packaged Ubuntu version (2.1.15),
> there is no gpg-agent.socket unit file anywhere?

Seems like the relevant systemd unit file examples were added in commit
57e95f5413e21cfcb957af2346b292686a5647b7, shortly after 2.1.15 (included
in Debian / Ubuntu) was released.

As far as I can see, the new socket-activated user units should be
installed with current packages in Debian testing and Ubuntu bionic.  I
might try manually upgrading to 2.2.4-1ubuntu1 and report any findings.

Regards
André
-- 
Greetings...
From: André Colomb 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPG 2.2.4 on Windows - problems accessing some HKPS keyservers

[David Gray via Gnupg-users]

Thanks, Phil - 

I appreciate your help and your response.

Thanks,

Dave

Sent from my iPhone

> On Jan 23, 2018, at 9:51 PM, Phil Pennock  wrote:
> 
> Looks to me like a GnuPG bug.  In fact, it looks very much like
> https://dev.gnupg.org/T1447 which has been marked resolved.
> 
> The hostname there is a CNAME to Amazon DNS, and my dirmngr logfile
> records:
> 
> 2018-01-23 21:28:10 dirmngr[70787.6] TLS verification of peer failed: 
> hostname does not match
> 2018-01-23 21:28:10 dirmngr[70787.6] DBG: expected hostname: 
> keyserver-prod.v3jierkpjv.eu-west-1.elasticbeanstalk.com
> 
> The untrusted name retrieved from DNS resolution of the CNAME record is
> being used as the name for validation.
> 
> The patches to address the issue seem to focus on SRV records, so
> repaired one way in which the problem manifested, but either didn't fix
> the underlying issue, or there's been a regression.
> 
> I've opened a new ticket for the maintainers to track this.
> https://dev.gnupg.org/T3755
> 
> -Phil


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users