[openpgp] Re: I-D Action: draft-ietf-openpgp-hkp-01.txt

--===============3721662125300883444==
Content-Type: multipart/alternative; boundary="000000000000c1cf35065398a50a"

--000000000000c1cf35065398a50a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Andrew, all,

I took a first pass through the -01 text with the JSON/schema and
static-serving points in mind.

For the JSON side, I think the useful thing would be to keep the schema
appendix fairly small and directly aligned with the tables already in the
draft:

   - v2 index certificate objects;
   - algorithm objects;
   - User ID objects;
   - subkey objects;
   - submission response objects;
   - the JSON-LD sendtoken example, if the WG wants that covered by the
   same appendix or by a separate one.

The compatibility point I would try to preserve is that required fields
match the current tables, while clients still ignore unknown fields and
servers can omit optional arrays such as algorithms, subkeys, and User IDs
where the draft already permits that.

For the static-serving case, a short non-normative checklist might be
enough. Something like:

   - serve /pks/v2/canonical/<identity> for discovery;
   - serve certificate bundles with application/pgp;
   - return 404 or another appropriate unsuccessful response for absent
   static files;
   - do not rely on 400/404 distinction for client behavior;
   - make clear whether submission and OPTIONS are unsupported.

If this direction seems useful, I can write a first cut of either the
schema-alignment checklist or the static-serving checklist for the draft,
whichever is more helpful.

Best,
Songbo Bu

On Fri, 5 Jun 2026 16:23:44 +0100, Andrew Gallagher
[email protected] wrote:

Hi, all.

I=E2=80=99ve published a new HKP draft that contains (almost!) all the chan=
ges
discussed on the list. The only caveat is that there is not yet a formal
JSON schema in the document.

The corresponding hockeypuck PR has been merged and is running on
test.pgpkeys.eu now.

Thanks,
A

On 05/06/2026 16:00, [email protected] wrote:

Internet-Draft draft-ietf-openpgp-hkp-01.txt is now available. It is a work
item of the Open Specification for Pretty Good Privacy (OPENPGP) WG of the
IETF.

Title: OpenPGP HTTP Keyserver Protocol
Authors: Daphne Shaw
Andrew Gallagher
Daniel Huigens
Name: draft-ietf-openpgp-hkp-01.txt
Pages: 51
Dates: 2026-06-05

Abstract:

This document specifies a series of conventions to implement an
OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As
this document is a codification and extension of a protocol that is
already in wide use, strict attention is paid to backward
compatibility with these existing implementations.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-openpgp-hkp/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-hkp-01

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-openpgp-hkp-01

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts

openpgp mailing list =E2=80=93 [email protected]
To unsubscribe send an email to [email protected]

--000000000000c1cf35065398a50a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hi Andrew, all,</p>
<p>I took a first pass through the -01 text with the JSON/schema and static=
-serving points in mind.</p>
<p>For the JSON side, I think the useful thing would be to keep the schema =
appendix fairly small and directly aligned with the tables already in the d=
raft:</p>
<ul>
<li>v2 index certificate objects;</li>
<li>algorithm objects;</li>
<li>User ID objects;</li>
<li>subkey objects;</li>
<li>submission response objects;</li>
<li>the JSON-LD sendtoken example, if the WG wants that covered by the same=
 appendix or by a separate one.</li>
</ul>
<p>The compatibility point I would try to preserve is that required fields =
match the current tables, while clients still ignore unknown fields and ser=
vers can omit optional arrays such as algorithms, subkeys, and User IDs whe=
re the draft already permits that.</p>
<p>For the static-serving case, a short non-normative checklist might be en=
ough. Something like:</p>
<ul>
<li>serve <code>/pks/v2/canonical/&lt;identity&gt;</code> for discovery;</l=
i>
<li>serve certificate bundles with <code>application/pgp</code>;</li>
<li>return 404 or another appropriate unsuccessful response for absent stat=
ic files;</li>
<li>do not rely on 400/404 distinction for client behavior;</li>
<li>make clear whether submission and OPTIONS are unsupported.</li>
</ul>
<p>If this direction seems useful, I can write a first cut of either the sc=
hema-alignment checklist or the static-serving checklist for the draft, whi=
chever is more helpful.</p>
<p>Best,<br>
Songbo Bu</p>
<p>On Fri, 5 Jun 2026 16:23:44 +0100, Andrew Gallagher <a href=3D"mailto:an=
[email protected]" target=3D"_blank">andrewg=3D40andrewg=
[email protected]</a> wrote:</p>
<blockquote>
<p>Hi, all.</p>
<p>I=E2=80=99ve published a new HKP draft that contains (almost!) all the c=
hanges<br>
discussed on the list. The only caveat is that there is not yet a formal<br=
>
JSON schema in the document.</p>
<p>The corresponding hockeypuck PR has been merged and is running on<br>
<a href=3D"http://test.pgpkeys.eu" target=3D"_blank">test.pgpkeys.eu</a> no=
w.</p>
<p>Thanks,<br>
A</p>
<p>On 05/06/2026 16:00, <a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a> wrote:</p>
<blockquote>
<p>Internet-Draft draft-ietf-openpgp-hkp-01.txt is now available. It is a w=
ork<br>
item of the Open Specification for Pretty Good Privacy (OPENPGP) WG of the<=
br>
IETF.</p>
<p>Title: OpenPGP HTTP Keyserver Protocol<br>
Authors: Daphne Shaw<br>
Andrew Gallagher<br>
Daniel Huigens<br>
Name: draft-ietf-openpgp-hkp-01.txt<br>
Pages: 51<br>
Dates: 2026-06-05</p>
<p>Abstract:</p>
<p>This document specifies a series of conventions to implement an<br>
OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As<br>
this document is a codification and extension of a protocol that is<br>
already in wide use, strict attention is paid to backward<br>
compatibility with these existing implementations.</p>
<p>The IETF datatracker status page for this Internet-Draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-openpgp-hkp/" target=
=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-openpgp-hkp/</a></p=
>
<p>There is also an HTMLized version available at:<br>
<a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-hkp-01"=
 target=3D"_blank">https://datatracker.ietf.org/doc/html/draft-ietf-openpgp=
-hkp-01</a></p>
<p>A diff from the previous version is available at:<br>
<a href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-openpgp-h=
kp-01" target=3D"_blank">https://author-tools.ietf.org/iddiff?url2=3Ddraft-=
ietf-openpgp-hkp-01</a></p>
<p>Internet-Drafts are also available by rsync at:<br>
rsync.ietf.org::internet-drafts</p>


<p>openpgp mailing list =E2=80=93 <a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]" t=
arget=3D"_blank">[email protected]</a></p>
</blockquote>
</blockquote>
</div>

--000000000000c1cf35065398a50a--


--===============3721662125300883444==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK

--===============3721662125300883444==--