Re: [openpgp] 1PA3PC: first-party attested third-party certifications (making Key Server Prefs no-modify actionable)

[Daniel Kahn Gillmor <[e-mail]>]

On Wed 2019-08-28 21:57:38 -0400, Daniel Kahn Gillmor wrote:
> I've made some new demonstration certificates with this new approach
> (and my example does use SHA256):
>
> The signer's certificate (the "third party"):
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
>
> xjMEXWcuXBYJKwYBBAHaRw8BAQdAIjn6AW4wgrQ7hI66BZkaCzL2X/bRX+yf1tm8
> 4OxSkULNJkNlcnRpZmljYXRlIEF1dGhvcml0eSA8Y2FAZXhhbXBsZS5jb20+woQE
> ExYIACwFAl1m9hwCGwECFQgCF4ACGQECHgEWIQTBvMlvJO6/G++jDVQ953dEaeBc
> DQAKCRA953dEaeBcDc8hAP9it7GkIgG1Sisa8e46SJIZRfWAcT1vzAmv8k57jY/P
> HAEAizCu8jGLKp5AHWLNIU2ah9tEEEch5q4GI7tqMbu5IQU=
> =rn/T
> -----END PGP PUBLIC KEY BLOCK-----
>
> The first party, along with a standard self-sig, a third-party
> certification, and an Attestation Key Signature attesting to the
> third-party certification:
>
> -----BEGIN PGP PUBLIC KEY BLOCK-----
>
> xjMEXWcuXBYJKwYBBAHaRw8BAQdAPeDThwKKsiEAR8GwQBzv94FnDhyc9+NtXoH+
> 4LGxhh7NHFRlc3QgVXNlciA8dGVzdEBleGFtcGxlLmNvbT7ChAQTFggALAUCXWb2
> HAIbAQIVCAIXgAIZAQIeARYhBHZ7/PJBbYUZS/wOEE/bnIu8dqmjAAoJEE/bnIu8
> dqmjYvcA+wbxprn1NQfP6uY19plBu/WRPnCAj6Tnte4KUThl48dMAQCuIURYGmK4
> znKmav/bnDgp+bLSrfo/4tE1SK1/fudRAMJ1BBAWCAAdBQJdZvYmFiEEwbzJbyTu
> vxvvow1UPed3RGngXA0ACgkQPed3RGngXA3pGAEAzyIb8BtrLb6Oi1eY/JLje/i/
> lmWO46EoWe0Rh8J8gC8BAPV6/txR65Qa4DaMw26GyHk8uGTzxiRyH6q62Xpwcx8K
> wpcEFhYIAD8FAl1m9jAhJTA+FEO+y68KkjvvIGaLNBfj/pHb2IeYj2/C6ecXEJgy
> FiEEdnv88kFthRlL/A4QT9uci7x2qaMACgkQT9uci7x2qaOxNwD/SLpQxMKZX4ys
> nmjuV2+VwpwOhlBBAZsX+eRkqDlPUicBAI9EZo/fmuzXzG3D6FrUB0rfgVdiDTy6
> EB6DaIpVWGQJ
> =FDhV
> -----END PGP PUBLIC KEY BLOCK-----

The above examples had some silly timestamp issues due to a confusion in
my generation toolchain between localtime and UTC.  I've fixed that
problem now.

Here is an improved example:

The signer's certificate (the "third party"):

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEXWgC1BYJKwYBBAHaRw8BAQdA847Q7k21jU2Io+IZ6ltc4zSxZp8ttgOZZDeG
iySNTOPNJkNlcnRpZmljYXRlIEF1dGhvcml0eSA8Y2FAZXhhbXBsZS5jb20+woQE
ExYIACwFAl1oAtQCGwECFQgCF4ACGQECHgEWIQQfVCvVCBoTud0bdgbSKXzdeDUV
twAKCRDSKXzdeDUVt2PHAP0YiwR2ZRrfJbzH46U6eB2AOtdSpIqfTcNnHLQH2bFC
5QD8CC8Jr0Ym5Ai+qAD9GxkDJtsRkFBXq983oq52DJRJJA0=
=taR1
-----END PGP PUBLIC KEY BLOCK-----

The first party, along with a standard self-sig, a third-party
certification, and an Attestation Key Signature attesting to the
third-party certification:

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEXWgC1BYJKwYBBAHaRw8BAQdA/V1P+p5pp8EloIYF1sqeu5hobtj+BLpEn7zO
XJKZtznNHFRlc3QgVXNlciA8dGVzdEBleGFtcGxlLmNvbT7ChAQTFggALAUCXWgC
1AIbAQIVCAIXgAIZAQIeARYhBBVqOHIbKPae6A3uusaUcjoTcOqxAAoJEMaUcjoT
cOqxTYUA/1ypaVgyqz8KiMtz7sOhbXuS7RJ1gb0RGrtMpL8TaAsuAP4hWDFkLgKy
huz4Aky8l2xJHq/bnzwO9ChDwPxccy/dA8J1BBAWCAAdBQJdaALeFiEEH1Qr1Qga
E7ndG3YG0il83Xg1FbcACgkQ0il83Xg1FbfACwEA72frsa6cbvfwF3gt7TyCWN5f
+U3vxv/PksT5to5PfggA/RHrasr4bWtkvTFiPTLZzsPlJ7JU3JY7S1Zfa+3oY60P
wpcEFhYIAD8FAl1oAughJaeUxunM/i80xn4H94lPu9FZD/rmajysr/7YbfFNGJeU
FiEEFWo4chso9p7oDe66xpRyOhNw6rEACgkQxpRyOhNw6rH/DAEA1rISPgumTkpx
+eKpjV+qyb0FnlM4wOFrh6b3+lpgV6IBAIx35b6rr4yAR1P/gooCQpMfkdV1fbh9
jrjOspJMP8cG
=HMMo
-----END PGP PUBLIC KEY BLOCK-----


Importing these with gpg 2.2.17 yields the following warning messages:

gpg: key D2297CDD783515B7: public key "Certificate Authority <[e-mail]>" imported
gpg: key C694723A1370EAB1: 1 bad signature
gpg: sig issued by C694723A1370EAB1 with class 22 (digest: ff 0c) is not valid over a user id or a key id, ignoring.
gpg: key C694723A1370EAB1: public key "Test User <[e-mail]>" imported
gpg: Total number processed: 2
gpg:               imported: 2

This is noise from the new signature class is what i would expect, but
the result is that the attestation signature itself is simply discarded
by GnuPG.  Works for me -- that seems like a sensible response from a
legacy client that doesn't know about attestations.

     --dkg