On Sun, 26 Jul 2015 11:11, [email protected] said:
> X.509 parsers where not needed. If you don't think X.509 is a problem,
> then you haven't been paying attention to CVE's.
There is a lot more X.509 code in use than OpenPGP code and thus it
might be unfair to compare CVE counts. But sure, BER encoding along
with all bug compatibility stuff is a mess.
> Actually, a quick ldd on /usr/bin/gpg* shows no libraries that I know of
> that do PKIX. And it would be good not to add new ones just because we
Do it on gpgsm and dirmngr and you will find libksba [1] which provides
the X.509 and CMS parser and builder. gpgsm does high level processing
including validation and dirmngr takes care of CRLs and OCSP.
> I also find it _really_ ironic that it is not the openpgp key servers
> that you are calling "vast, aging and vaguely understood infrastructure"
> because if anything is a dangerous misunderstood mess that we cannot
> seem to clean up, it is the current electronic garbage heap of pgp
> keys we can never clean up because the owners lost their keys or
We do not want to clean that up - there is and should be no need to ever
delete a public key from a public server.
Unfortunatly the keyservers are also the only working solution to map
mail addresses to keys/fingerprints. This is the practical problem we
need to solve - not the public storage of the keys.
> the keys were generated and uploaded by those not actually being the
> real owners of those email address specified in the openpgp key id.
What is an "owner" of a mail address? Definitely nothing a keyserver
has to decide.
> It is _really_ difficult to design any other method of openpgp key
> distribution that would be _worse_ than the current key servers.
Nope. As I menotioned: distribution is not the problem. Association of
mail addresses to keys is the problem because the WoT does not really
scale.
> And this is an actual real problem. There is no valid reason for needing
> to "work around" an experimental proposal that has a significant backing
> of people in the IETF, the mail community and opensource software
Experimental? I might be confused but draft-ietf-dane-openpgpkey-03
states Standards Track and Intended Status.
Salam-Shalom,
Werner
[1] KSBA = rot13("XFON") // X-Five-O-Nine
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
