Hey list,
OpenKeychain maintainer here. As Werner chose to omit some details here
that seem pertinent, I will add:
No, it is not because you are delaying the deployment of new and a much
faster algorithm mode.
The packet format referred to here is GnuPG-specific. In November 2023,
GnuPG
Hey Bruce,
On 04.03.24 21:53, Bruce Walzer wrote:
* https://articles.59.ca/doku.php?id=pgpfan:noae_shame
There is more if you search for it:
https://kagi.com/search?q=gpg+%22packet+type+20%22=no_region=HeSUA3hoI5SeCuA2TTrNig
Cheers
- V
___
Hi Martin,
Could you please explain this, I don't understand really. So there are
public and no public keys on the this key-server? Who decides that a
key is public or non-public? Who or how can I request a non-public
key?
Sorry, that wasn't as clear as it could have been. There are no
Hey list,
Keyserver records are public and spammers can scan those
Just quickly noting, since keys.openpgp.org was mentioned at the
beginning of the thread:
For traditional (sks-style) keyservers, it is true that the list of all
certificates
and email addresses is public, and must be by
> Overall I believe that attaching pubkeys (like autocrypt proposes) is not a
> good idea (the arguments put forward elsewhere).
For the record, Autocrypt does not attach public keys, it includes them in
headers. I concur that attaching public keys is a bad idea.
> apparently, Thunderbird is
Hi Yuri,
> Is something wrong with the key that resides on keys.openpgp.org? Are
> the keys that are one these 3 keyservers the same?
Unlike the other keyservers, keys.openpgp.org has a [privacy policy] that
doesn't permit distributing email addresses without consent. The key in question
has
> Okay, then... All the keyservers have the key. But keys.openpgp.org
> doesn't let it get imported because the owner didn't consent to making
> his email address publicly known by verifying his email address.
>
> Which means that the owner doesn't care much about this, otherwise he
> would not
> Now I'm a bit confused :O
> I thought WKD can be used with your own webserver. So why do I have to
> make a CNAME recort pointing to "wkd.keys.openpgp.org"?
>
> Or did I understand anything wrong?
Sorry, that was confusing without context. Yes, WKD is bound to the domain of
the email
Daniel Kahn Gillmor via Gnupg-users wrote:
> On Mon 2021-01-11 22:59:10 +0100, Ángel wrote:
> > The "make a CNAME of your openpgpkeys subdomain to
> > wkd.keys.openpgp.org" couldn't work with https certificate validation,
> > thouth (or are they requesting a certificate on-the-fly?)
>
> In fact,
> My understanding is that sequoia pgp, due to the fact that it is written in
> Rust may
> probably see not it's light in major Linux distributions as an apt-get option
While it's true that Rust crates aren't straightforward to package in Debian,
sequoia-the-library in version 1.0.0 is indeed
> keys.gnupg.net is a CNAME for hkps.pool.sks-keyservers.net -- which is
> now returning zero results.
Let me break the prose down into the simple facts:
* the "HKPS" pool is no longer actually a "pool". it is a [single server].
* the "HKP" pool still contains a few servers, but using it
> What is the status of WKD now, and is it to superseed centralized key
> servers ?
Not for folks who have their email address at the domain of an email provider,
or an organization that doesn't support WKD. So statistically, everyone but
a rounding error.
That said, for folks who run their
> A closer inspection of the key ID showed that it was encrypted with my master
> key. A key that is not marked to be used for encryption. So how the heck did
> that happened?
I believe what you're experiencing here is actually a direct consequence of
a GnuPG policy decision: Subkeys that don't
Hey folks,
this thread touches on userid-less keys, and keyservers.
I agree with Peter and Rob's points that userid-less keys are questionable for
use as-is. OpenPGP transfers information in the self-signatures of user ids. If
we use keys without any known UID, we might miss out on e.g.
> Werner sits as secretary of the (largely dormant) group that guides
> OpenPGP development, but there are a lot of non-GnuPG people who are
> deeply involved in giving feedback on proposed changes. He's the
> secretary, not the dictator.
Not everyone agrees.
Hi Andrew,
> I feel your pain. I've been trying for the past few years to knock
> together a menu-driven offline-key management interface[1] for PGP CAs,
> for use in corporate environments.
Have you seen openpgp-ca? It's an effort that sounds similar to what you are
describing, based on
> Werner's implementation has an excellent reputation, and it's the only one
> I personally trust completely.
You state this so matter-of-factly, I feel compelled to point out that among
cryptographers, libgcrypt's reputation is not all that great...
> Especially if the key is shipped alongside the message already
Are you sure that it is though? Seems to me you're giving out ill-informed
advice here.
- V
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
> It would be nice if you can add to the keyserver list also the
> mailvelope.com keyserver,
I concur keys.mailvelope.com is a fine keyserver today. However, you might want
to consider:
> because it requires users to authenticate their keys against the keyserver
> with an received encrypted
> 1. How should we handle the SKS keyserver attacks?
Worth mentioning that at the openpgp summit recently, Kristian announced some
plans that the SKS pool would:
1) Move implementation from SKS to Hockeypuck
2) Disable search by user id entirely
3) Filter out third party signatures, at least
The simple truth is: For the SKS servers, it is not technically possible to
remove keys, and never will be.
People have speculated, postulated, counterargued, rambled on several mailing
lists about how great or terrible a thing that is. But no matter what anyone
tells you or how many mails are
> Thus the current wording is sufficient and has served us well over the last 25
> years
If your statement here includes the "by convention contains an rfc2822
name-addr" part of the wording, please bring this opinion up on the openpgp-wg
thread.
The argument is being made (and I agree) that
> but as far as I have understood my communication with Vincent, it's such IDs
> which are a problem for keys.openpgp.org.
Right, that's because we currently use an actual rfc2822 parser on
keys.openpgp.org. This works fine for *most* users, but in the end causes more
trouble than it's worth,
Hi Binarus,
> I got confirmation emails for three of that four keys, but it seems that
> the key server isn't in the mood to send a confirmation email for the
> fourth. I have uploaded that one multiple times since then (again via
> Enigmail's key management), each time getting a success
> The algorithm is designed to withstand very well funded actors,
> oppressive regimes were what the designers were thinking of.
We are talking about a sand castle here that was kicked down by a kid. It's
a bit bizarre to claim that it was built to withstand rockets.
Given that the recon
> To be frank - putting this code on Github whist demonstrating a point -
> was foolish
No it's not. It is the basis of cryptograhpy.
See also: https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
> Now you have put the code into the public domain - to prove a point?
Yes. And that point is
Friendly reminder: There are no developers working on SKS right now. Zero. No
actual work has been done on SKS in years.
- V
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
> Unless you are on Windows where the server can't be accessed because it
> uses a pretty limited set of TLS cipher suites. Thus the majority of
> GnuPG encryption users are out of luck.
Huh, that's interesting. I was not aware of this issue, and wish you had reached
out to me, or to
> 3. interoperability. The replacement service would need to be fully compatible
> with all existing clients.
Depending on what you mean by "fully compatible". The single biggest issue is
importing keys that don't have identity info on them. I submitted a patch to
GnuPG to fix this issue, but
> Please cite the section from the GDPR
I assume you have looked into this already and are not asking this out of
uninformedness. But, I'll bite.
Article 2, "Material Scope":
> (1) This Regulation applies to the processing of personal data wholly or
> partly by automated means (...).
There
> The Upload should be restricted to the key owner in some way.
We restrict upload of user ids to the owner of the user id, identified by email
verification. Non-identity data (subkeys, revocations, ...) can be freely
distributed, but only with a verified self-signature.
Is there any other
> Hi @ll.
Hi Dirk,
thanks for your thoughts!
> I don't think it's such a good idea to drop Signatures on keys.
As mentioned in our FAQ, the reason we don't support those is that with the SKS
model, anyone can attach arbitrary data to others' keys. It's hard to overstate
how problematic that
Pretty happy with how this turned out so far. :)
Feedback I received was almost universally positive, other than the folks on
heise comments who really really really like the Web of Trust. In particular,
I heard of almost no isues with the verification flow, which hopefully means
things "just
33 matches
Mail list logo
