Open maxweisspoker opened 2 years ago
I understand that Hagrid does include signature data when it's attested, but GnuPG doesn't support that?
Correct. GnuPG does not support it because it does not conform to the OpenPGP standard, and GnuPG attempts to remain complaint to the standard. OpenPGP requires a user data field (and signature for that) for a key to be a compliant key. Keys without that data are invalid and cannot be imported into any OpenPGP-compliant software, including GnuPG. Therefore, "non-attested" keys cannot be imported.
Additionally, it looks like Hagrid strips signatures from other keys, which breaks the Web of Trust functionality of PGP.
openpgp.org should not be hosting a key server that violates its own standard and breaks the Web of Trust.
Re-opening as this issue remains unresolved.
fwiw, GnuPG itself supports the ingestion of standalone key revocation packets as a "Revocation certificate", which is also not specified in the OpenPGP standard. The upcoming revision to RFC 4880 does describe both formats adequately.
The first-party approved third-party certifications, as supported by keys.openpgp.org, are documented in an internet-draft. My understanding is that keys.openpgp.org does not distribute unapproved third-party certifications to avoid flooding attacks, which seems like a reasonable posture to me.
There is no reason to avoid linking to keys.openpgp.org from this website.
That is an upstream bug as well then. The official website and software should comply with the spec, or at the very least have big blaring notifications about being non-compliant. The official keyserver completely undermining the web of trust is not a good solution to spam prevention.
Sorry, i don't see how keys.openpgp.org is "completely undermining the web of trust". Permitting anyone to attach arbitrary third-party certifications to any OpenPGP certificate (as the old SKS keyservers used to do) also undermines the web of trust by permitting various forms of flooding attacks.
keys.openpgp.org is significantly more reliable and stable for fetching OpenPGP certificates, expiration updates, and revocation information than the SKS keyserver network ever was. This is a significant benefit to the OpenPGP community.
People who want to distribute third-party certifications with their own certificate can do so via WKD, OPENPGPKEY records in the DNS, by publishing them on their own website, or just distributing them directly in e-mail.
You can use, today, the first-party approved third-party certification mechanism described in the 1PA3PC draft to publish third-party certifications on keys.openpgp.org. If your objection is that this draft is not a formal RFC, i encourage you to participate in the OpenPGP working group and offer to help standardize it. It's currently something that i'm holding the editor's pen on because it wasn't in charter until the recent rechartering, and i happened to have the time to write it down formally. But i'm currently stretched quite thin (and i'm a co-chair in the WG as well, which makes it awkward for me to be the document editor too). i'd be happy for someone responsible to pick up this useful draft and try to push it through the working group to standardization. @maxweisspoker, any interest in helping out?
Sorry, i don't see how keys.openpgp.org is "completely undermining the web of trust".
The PGP web of trust relies on third party signatures for a key, which you can trust or not trust. Therefore, in order for it to work, a key server needs to both allow key signatures, as well as sync with other key servers to update keys with new signatures and revocations.
Whether or not you think that is worth while compared with the risks of spam, it is an integral part of the PGP ecosystem and relied upon by many system participants. It's perfectly fine to disagree and host a key server that doesn't do this, but that key server should not be the representative for the OpenPGP standard.
Permitting anyone to attach arbitrary third-party certifications to any OpenPGP certificate (as the old SKS keyservers used to do) also undermines the web of trust by permitting various forms of flooding attacks.
Yes, spam and attacks have been a problem for systems since the beginning of time, but few of those systems have decided that the best method of fighting such attacks are to dismantle themselves and turn the distributed nature of their systems into centralized silos that no longer offer offer provide the utility that the system was designed for.
keys.openpgp.org is significantly more reliable and stable for fetching OpenPGP certificates, expiration updates, and revocation information than the SKS keyserver network ever was.
That utiliy remains solely in the hands of the keys.openpgp.org server, as it does not sync with other servers. If that server goes down, the utility is lost.
People who want to distribute third-party certifications with their own certificate can do so via WKD, OPENPGPKEY records in the DNS, by publishing them on their own website, or just distributing them directly in e-mail.
While it is true that more savvy users who own domains can "kick the can" of trust from their PGP key to their domain, not everybody can do so. The purpose of third party certificates was to allow the delegation of trust to chosen keys, and the keys in question could be obtained from any key server, because the servers would sync with each other. This prevented the need for running one's own domain or having to rely on centralized silos as the only solutions.
You can use, today, the first-party approved third-party certification mechanism described in the 1PA3PC draft to publish third-party certifications on keys.openpgp.org. If your objection is that this draft is not a formal RFC, i encourage you to participate in the OpenPGP working group and offer to help standardize it.
No, my complaint is that the current standards and expectations are not adhered to by the server representing the official standard.
i'd be happy for someone responsible to pick up this useful draft and try to push it through the working group to standardization. @maxweisspoker, any interest in helping out?
While I appreciate the offer, I too have my hands full running and testing my own highly available hockeypuck instance, which accepts key signatures, syncs with other instances, and blocks spam and flood attacks via traditional methods.
I don't intend to be so adversarial about this, but I very strongly feel that the deprecation of certificates for keys as well as the deprecation of keyservers syncing with eachother represents a significant existential threat to the PGP ecosystem. If people want to go that direction, that's on them, but the public face of the software should not be pushing towards centralized silos and stripping key signatures.
Hagrid is perfectly good software, and useful for organizations that want a private centralized keyserver for their private use. It is not useful for the wider public use case of ensuring that public keys are available anywhere and their trustworthiness can be validated by examination of signatures by other trusted keys. Large populations of participants, such as users validating Linux distro packages, rely on the wide availability of keys as well as the third-party signatures to validate new software maintenance contributors. The distirbution of keys and of attached signatures is a vital component of the PGP ecosystem.
Thanks for running a syncing, highly-available hockeypuck instance, @maxweisspoker ! that's much appreciated, and i agree that public keyservers are an important part of the OpenPGP ecosystem.
This issue seems to conflate a number of properties with "OpenPGP compliance", and i'm interested in teasing them apart a little bit. Here are the things that i think you're saying are required for compliance with the standard:
It's not clear to me which of these things are actually related to compliance with the OpenPGP specification. The only thing that seems directly relevant to the wire spec is the last bullet, but that argument seems specious to me: while RFC 4880 does require a User ID in a certificate, it doesn't require a valid self-sig over that User ID. Hagrid could conceivably work around this supposed non-compliance by simply adding a User ID packet to the certificate that contains the empty string. While this wouldn't change the cryptographic information contained in the certificate, and it would make it nominally compliant, GnuPG would still not agree to import the certificate. So the compliance issue appears to be on GnuPG's side, not on Hagrid's side. And, GnuPG also is willing to accept a key revocation signature packet on its own (without the associated primary key packet), which isn't standardized anywhere. So it's not like GnuPG is only going to accept packet sequences that are standards-conformant. And, the pending update to the OpenPGP specification explicitly describes both formats of revocation certificate, so that suggests that Hagrid will be compliant anyway.
The other two bullets above don't look to me like they are OpenPGP wire format compliance issues at all. Rather are assertions about how the OpenPGP ecosystem should make tradeoffs related to reliability, performance, robustness, and centralized distribution.
You mention that your hockeypuck instance defends against spam and abuse with "traditional methods". I'd love to hear more detail about those methods, because i suspect that the details would describe some different decisions about reliability, performance, robustness, and centralized distribution.
If you'd like to retitle this issue as less about strict wire format compliance and more about these other topics, i'd be happy to continue the discussion, and we can invite people to weigh in on what they think the important characteristics are for OpenPGP services that are advertised on openpgp.org.
The Hagrid software which strips signature data from keys produces keys which are not OpenPGP compliant and cannot be imported into GnuPG or other OpenPGP-compliant software. This is problematic in and of itself, but it also degrades the Web of Trust, weakening the security of the PGP ecosystem at large. If people want to run non-compliant software, they are of course free to do so, but the OpenPGP website should not be running non-OpenPGP software.