0
$\begingroup$

When one OpenPGP public key is signed multiple times by different keys, how these multiple signatures become visible on one OpenPGP certificate/key?

For example, I participated in a key signing party and got my public key signed by different people, some people emailed me my signed key, some people uploaded the signed key to key server by themselves, how all of these signatures become visible on my public key (in the OpenPGP certificate)?

Also how long can OpenPGP certificate be? For example, if I had my key signed by 10.000 people how will it look like?

$\endgroup$
2
$\begingroup$

OpenPGP keys are formed by a whole bunch of individual OpenPGP packets, for example the public key itself, user IDs, and also certifications. RFC 4880, OpenPGP provides the specification and a list of possible packets together with their explanation (very technical indeed, but you're descending into the inner details of OpenPGP now).

When fetching a newer copy of the key from any source (let it be a local file import, from the key server network, from local files, ...), GnuPG or other implementations of OpenPGP just merge the individual packets together, adding those it didn't know yet. There is no artificial limit on the number of signatures or other packets, but the individual implementations are likely to have some technical ones (32 bit integers, addressable memory, ...).

You can look at a key's structure using gpg --list-packets or pgpdump. An example output for my own key with some explanations added, originally this is one large stream:

gpg --export a4ff2279 | gpg --list-packets | less

The public key:

# off=0 ctb=99 tag=6 hlen=3 plen=1037
:public key packet:
        version 4, algo 1, created 1356475387, expires 0
        pkey[0]: [8192 bits]
        pkey[1]: [17 bits]
        keyid: 4E1F799AA4FF2279

A user ID packet:

# off=1040 ctb=b4 tag=13 hlen=2 plen=49
:user ID packet: "Jens Erat (born 1988-01-19 in Stuttgart, Germany)"

Binding signature connecting key and user ID, and carrying configuration:

# off=1091 ctb=89 tag=2 hlen=3 plen=1083
:signature packet: algo 1, keyid 4E1F799AA4FF2279
        version 4, created 1356516623, md5len 0, sigclass 0x13
        digest algo 2, begin of digest 18 46
        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 5 (pref-hash-algos: 8 2 9 10 11)
        hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
        hashed subpkt 30 len 1 (features: 01)
        hashed subpkt 23 len 1 (keyserver preferences: 80)
        hashed subpkt 2 len 4 (sig created 2012-12-26)
        hashed subpkt 25 len 1 (primary user ID)
        subpkt 16 len 8 (issuer key ID 4E1F799AA4FF2279)
        data: [8189 bits]

A newer binding signature:

# off=2177 ctb=89 tag=2 hlen=3 plen=1080
:signature packet: algo 1, keyid 4E1F799AA4FF2279
        version 4, created 1356475387, md5len 0, sigclass 0x13
        digest algo 2, begin of digest 44 77
        hashed subpkt 2 len 4 (sig created 2012-12-25)
        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 5 (pref-hash-algos: 8 2 9 10 11)
        hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
        hashed subpkt 30 len 1 (features: 01)
        hashed subpkt 23 len 1 (keyserver preferences: 80)
        subpkt 16 len 8 (issuer key ID 4E1F799AA4FF2279)
        data: [8192 bits]
# off=3260 ctb=89 tag=2 hlen=3 plen=284

A certification issued by another key:

:signature packet: algo 1, keyid CBC2613CD745722B
        version 4, created 1356529414, md5len 0, sigclass 0x13
        digest algo 2, begin of digest d3 ec
        hashed subpkt 2 len 4 (sig created 2012-12-26)
        subpkt 16 len 8 (issuer key ID CBC2613CD745722B)
        data: [2048 bits]
| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.