- User Since
- Mar 27 2017, 4:48 PM (116 w, 6 d)
It's been a while, any word on this? I sent the DCO as requested. Are there any technical concerns left to address?
Fri, Jun 21
A possible exception here is that .onion TLDs should stick with HKP by default
May 10 2019
Apr 5 2019
I disagree that it's conceptionally the same, unless you also consider any key on an HTTP server to be "conceptionally the same" as WKD.
Certain origins do have special treatment but in general the key origin is meta data for the frontend.
Apr 4 2019
I'm a bit confused. The origin of Autocrypt keys is clearly different from keyservers ("ks"), why would they use the same value? I was aware that origin values are mapped to integers, but your description seems to imply that these integers have significant ordering in terms of trust. The documentation in the man page is a bit bare bones, but my interpretation of "key-origin" was that it simply stated the method of discovery for a key, leaving any implications of trust to the client. Is this incorrect?
Nov 8 2018
Fair enough. Let's wait and see what others think.
Oct 29 2018
The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.
Oct 27 2018
Aug 29 2018
I'm sorry but the explanation you give does not address the original issue I described, and which dkg then clarified. The discussion about AE is tangentially related, but the issue I described relates to the gpg interface:
Feb 1 2018
Sorry, I don't understand. Can you describe your use case in more detail?
Jan 31 2018
a key that is signed as its own subkey, in a construct where the key and subkey have the same fingerprint? what ever could be a valid use case for such a scenario?
uploaded the offending key for reference:
Nov 7 2017
Well, I gues it's complex enough to warrant strategic discussion, which can be done in this ticket :)
Jul 19 2017
Hm. Could you elaborate on that? Why do you think it's dangerous?
Isn't it much nicer if we semantically convey that a key doesn't have associated user id information, compared to just listing such keys between "Andre" and "Arnold"? I'd much rather special case the empty string in the key list than an arbitrary string that may or may not have a universally obvious meaning.
I think "anonymous" user ids are a valid use case, since openpgp doesn't allow "no" user ids. Disallowing zero-length user ids will just cause implementations that intend to use anonymous user ids to use another type of "empty", like a single space character. And the effect of that will be that it's no longer trivially defined what an "anonymous" user id is for special handling, e.g. showing a localized "anonymous key" placeholder. Please don't restrict zero-length user ids.
Jul 13 2017
Well, yes, it's not general authentication like AE provides, didn't think this through entirely. However, handing encrypted data to gnupg and then not being sure if it was actually decrypted with a passphrase makes even the confidentiality property questionable.
Jun 23 2017
seems this was fixed along the way, then. I only tested with 2.1.18.
Jun 17 2017
here's a public key version of the same key. it was available easier and should reproduce the bug just as well
Jun 13 2017
user ids with length 0 do conform with rfc4880, though
The key was created programmatically by my standard approach, which is bastardizing openkeychain unit tests. good question about the passphrase - I don't remember exactly, but I'm guessing it's either empty or "x". doesn't really matter in the context of this particular bug I guess :)
Jun 12 2017
-----BEGIN PGP PRIVATE KEY BLOCK-----