Motivation
To be compatible with the Verifying Keyserver (VKS) API used by keys.openpgp.org (Hagrid), the server should expose:
| Method |
Path |
Description |
| GET |
/vks/v1/by-fingerprint/{fingerprint} |
Fetch by full fingerprint |
| GET |
/vks/v1/by-keyid/{keyid} |
Fetch by 16-char key ID |
| GET |
/vks/v1/by-email/{email} |
Fetch by email (verified UIDs only) |
| POST |
/vks/v1/upload |
Upload a key (JSON body: {"keytext": "..."\}) |
| POST |
/vks/v1/requestverify |
Re-request verification for pending UIDs |
All GET responses return application/pgp-keys. All error responses return application/json (or application/problem+json per #133).
Approach
These endpoints can largely delegate to the same ports as the HKP endpoints — KeyRepositoryService for reads and CommandService for writes. A new web/vks war module (or sub-path in web/rest) is appropriate.
Interface note
Defining a Java interface (VksKeyserver) that both the implementation and future test stubs implement would allow integration tests to verify protocol compliance without a running server.
Motivation
To be compatible with the Verifying Keyserver (VKS) API used by keys.openpgp.org (Hagrid), the server should expose:
/vks/v1/by-fingerprint/{fingerprint}/vks/v1/by-keyid/{keyid}/vks/v1/by-email/{email}/vks/v1/upload{"keytext": "..."\})/vks/v1/requestverifyAll GET responses return
application/pgp-keys. All error responses returnapplication/json(orapplication/problem+jsonper #133).Approach
These endpoints can largely delegate to the same ports as the HKP endpoints —
KeyRepositoryServicefor reads andCommandServicefor writes. A newweb/vkswar module (or sub-path inweb/rest) is appropriate.Interface note
Defining a Java interface (
VksKeyserver) that both the implementation and future test stubs implement would allow integration tests to verify protocol compliance without a running server.