Listing signatures in edit mode?

[John Lane]

On 06/10/16 19:41, Peter Lebbing wrote:
> On 06/10/16 21:10, John Lane wrote:
>> Would I not expect to see sigs by FC91A390 and 63AB1D1A on E8BB8D0 ?
> No, the cross-certification signature is part of the signature of
> 1E8BB8D0 on 63AB1D1A. This cross-certification signature is not really
> that well visible.
>
> For instance, take my key:
>
> -----------------8<------------------->8-----------------
> pub   rsa2048/DE500B3E 2009-11-12 [C] [expires: 2017-10-19]
> uid         [ultimate] Peter Lebbing <peter at digitalbrains.com>
> sub   rsa2048/DE6CDCA1 2009-11-12 [S] [expires: 2017-10-19]
> sub   rsa2048/73A33BEE 2009-11-12 [E] [expires: 2017-10-19]
> sub   rsa2048/B65D8246 2009-12-05 [A] [expires: 2017-10-19]
> -----------------8<------------------->8-----------------
>
> If you do
>
> $ gpg2 --export-options export-minimal --export de500b3e|gpg2
> --list-packets |less
>
> you get a big amount of technical detail (I've left out certifications
> by other people, or I would have been swamped by irrelevant data and
> would have lost track). Among it we see a signature of DE500B3E on DE6CDCA1:
>
> -----------------8<------------------->8-----------------
> :signature packet: algo 1, keyid AC46EFE6DE500B3E
>         version 4, created 1445346807, md5len 0, sigclass 0x18
>         digest algo 2, begin of digest 65 31
>         hashed subpkt 27 len 1 (key flags: 02)
>         hashed subpkt 2 len 4 (sig created 2015-10-20)
>         hashed subpkt 9 len 4 (key expires after 7y342d23h58m)
>         subpkt 32 len 284 (signature: v4, class 0x19, algo 1, digest algo 2)
>         subpkt 16 len 8 (issuer key ID AC46EFE6DE500B3E)
>         data: [2046 bits]
> -----------------8<------------------->8-----------------
>
> If I'm not mistaken, the cross-certification signature is "subpkt 32",
> but unfortunately it is not parsed by --list-packets. What broadly
> happens, if memory serves me correctly, is that DE6CDCA1 issues a
> signature on DE500B3E, which becomes the subpkt 32. Then DE500B3E issues
> this whole signature packet, which includes the signature just made by
> DE6CDCA1.
>
> The gory details are in RFC 4880.
great explanation, thanks. found it in rfc too 0x19 "primary key binding
signature" (sec 5.2.1, 5.2.4, 11.1). Sec 15 notes interestingly that
"implementing software may handle these [keys without a back signature]
as it sees fit"

I think the page I quoted misled me when it said this binding signature
was "just like the primary key signature on the subkey" which, while
conceptually true, isn't technically true.

but I get it now, so another thing learnt. thanks v. much.

>
> Note that only signing subkeys issue a cross-certification, not
> encryption or authentication subkeys. Some encryption subkeys might even
> be mathematically incapable of issuing such a signature, depending on
> the type.
>
> HTH,
>
> Peter.
>