Not sending the user id packet, is just a bad idea because that user id exists and from my understanding they are sending the self-signatures anyway. They should not try to argue with the GDPR here, that is privacy theater. The key itself is a personal data and due to technical reasons this data is required. What they can do is to accept only user ids which carry just only mail address and no comments or name. posteo.de for example requires this for years and the WKD drafts has a feature to support this.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 5 2019
You are right. I again mixed this up with gpg-wks-client. Over there we have a limit implemented unsing --max-output to avoid compression based attacks.
Jul 4 2019
@werner, i don't think there is a 64K limit either, at least not in 2.2.16. Here is 2.2.16 with an empty homedir fetching Zack's certificate here which is > 97KiB:
Just want to weigh in here to say this would be incredibly useful given the shift to the new keyserver model. See T4604 for more context.
Not every incoming certificate that has no user ID will lack a user ID once it is merged with the local copy of the same certificate. T4393 describes that use case, so if you're interested in receiving user-ID-lacking updates to certificates that you already have a copy of, @jaymzh, you should follow up on that ticket.
Once a revocation is added (to any part of the certificate), perhaps all the certification packets that are clearly made obsolete by the revocation could be dropped from the certificate? That would certainly free up space to be able to import additional revocations if needed.
Given the recent problems with the keyservers, I expect that the keyserver feature will go away anyway and thus I do not think we will put any more effort into this. Thus I re-tag this as gpg 2.3.
And of course, thanks for your fix.
Applied to both branches. I have run no tests myself, though.
Fix will be in 2.2.17
Fix will be in 2.2.17.
See T4612 for the revocation case.
Re 1.: I don't view this as a bug. gpg prints stats on what it has been done and clearly it has processed a key. If it would have imported the key you would see another stat line telling about this. There was however a bug in the stats output which has been fixed.
I tried to implement this but this is troublesome for other programs using the interface because a common patter is to use --search-keys to get a listing and then use --recv-key to import the keys - That won't work and will require changes to --recv-key too. Thus this change will not go into 2.2. Anyway, it is not dangerous to have --search-keys because the new default for import from keyservers will be to strip all key-signatures.
Well, I mixed this up. On sending a a new key to the server export-minimal is used. Receiving a key uses keep-uid=REQUESTED and a 64k limit.
Because we use dot-locking in GnuPG and copy-update-write for keyrings. Granted: For gpgv this is not required but the code is identical to the gpg code and adding new code does not make much sense. After all gpgv is a stripped down version of gpg I once wrote for Debian. I see your use case but tehre are other ways to do this and thus anthing here has low priority.
Aha, thank you. Sorry I saw the original post about the flood attacks (https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f) which said to change your keyserver and I did, but I hadn't realized there were such significant differences.
Jul 3 2019
I think what you're missing is the keys.openpgp.org documentation which makes it clear that they will not distribute identity information (read: "User IDs") without an explicit confirmation by the operator of the e-mail address named in the User ID. They strip down the certificate pretty significantly before redistribution, especially if the e-mail address hasn't been confirmed directly with the operators of that server.
I know the keyservers have been under attack, I'm using 'keys.openpgp.org' which is supposed to be more resilient to these, as I understand it?
I'm also interested in fine details especially w.r.t. interfacing with GnuPG. I've seen multiple timestamping standards starting from RFC3161, to blockchains or secure time protocols even (ab)using Certificate Transparency logs and ideas on how to append the signature (timestamp flag vs unhashed notations) so I'll be eager to hear the details on the ML @stm!
out of curiosity, why does gpgv need the name of the file?
in 2.2.16, anyway, gnupg does not appear to apply import-minimal for WKD.
In that case, you can treat this ticket as a bug in the documentation, which still needs to be resolved.
We need random access and the name of the file. Thus a file descriptor is not sufficient.
Indeed we are in urgent need for a timestamping service. I was already pondering with the idea to integrate existing X.509 stamping services into OpenPGP signatures. Please write to gnupg-devel if you want to reach a wider audience. Unfortunately I need to abstain for getting involved in your project; there are too many other things to do.
One reason is that you may want to look at older key- or self-signatures which import-clean removes. I can imgine use cases where this has been used for something. People are ofteh doing inetresting things with standard tools.
Recently, I started a new project at savannah for developing free software and documentation in order to operate a Distributed OpenPGP Timestamping Service. Everyone is welcome to join.
@dkg I believe @aheinecke gave the GpgOL description just as an example of why WKD-first retrieval would be beneficial (for details of that see https://wiki.gnupg.org/AutomatedEncryption#Trust_Levels) and I believe this ticket is a follow-up to my question on gnupg-devel ML: https://lists.gnupg.org/pipermail/gnupg-devel/2019-June/034372.html
auto-key-retrieve happens in the context of signature verification when the certificate is missing. If no signer User ID subpacket is present in the signature, then WKD simply won't work.
hm, i see your point. If you could spell out what the specific regression(s) in more detail, though, that might help us to reason about their impact.
I agree for keyserver imports. For all other imports this would be a severe regression and thus the wrong thing to do.
I asked you to carry this to a mailing list and not re-open this task.
if you want to add a separate subcommand for that, i would be happy to abandon migrate-pubring-from-classic-gpg.
My plan is to let --search-key be the same as locate-key but without local lookups, thus it will be the same as
Okay, if an attacker exactly hist that limit your case is valid. I see no easy fix here, though. What we can do is what is done on Unix file systems to give average users a disk full erroreven if there a few percent of the disk is free; root can use that extra space then. Revocation certificates would be what root is on Unix file systems.
That was pretty easy to reproduce thanks to your still not working server.
I somehow expected such a feature request ;-). However, I do not think that an automatic migration is is appropriate for the stable branch.
I did some manual tests using netcat and KS_FETCH to test the redirection.
I think you're suggesting accepting *any* path if the hostname of the proposed redirection matches openpgpkey.example.org when querying the WKD direct URL for an @example.org address. That would also be a fine solution from my point of view.
I head the same idea when I read your configuration. Given that the advanced lookup was not reallydeployed (see T4590) I also expect that we will receive complains now that it works. Thus white listing any "openpgpkey." seems to me a reasonable easy solution.
Will be in 2.2.17