Certify one's public PGP key. Problems figuring how

Help
1

I am looking for the possibility to have my public PGP key certified by a CA, so that anyone who receives my public PGP key could confirm with the CA that the CA verifies I am the author of that particular PGP key.
PGP keys are otherwise horribly easy to falsify the author of.

I have heard about numerous persons who has managed to arrange this. But I cannot seem to find a category within Let's Encrypts services offers which matches this, nor do I find a way to ask this specific request to a Sales rep.

When talking to other CAā€™s sales department about this, I never manage to make myself understood, or they divert to responses like ā€œWe offer S/MIME certificates at competitive pricesā€ (I assume S/MIME meaning SSL encryption certificates).

I would like to ask if anyone possibly knows if Let's Encrypt might provide this service, or if not, any other CA which may provide this service? (if allowed in the Let's Encrypt forum ;))
Or is it possible I am misunderstanding the kind of arrangement needed for this to work, and therefore presenting my desired solution erroneously to the CA sales rep? I am quite sure offerings about S/MIME does not include PGP, or at least not certifying one's public PGP key.

I find this a really difficult subject to talk over. So I would really(!) appreciate any forms of comments or suggestions about this idea.
Thank you

2

S/MIME aren't TLS certificates.

S/MIME is a different encipherment and digital signature email standard, please look it up :wink:

I don't know of CAs that verify OpenPGP keypairs.

2 Likes
3

Even if there was a Certificate Authority that signed GPG keys, I donā€™t think thereā€™s any widespread software that would understand or trust those signatures.

What is the problem youā€™re trying to solve? Maybe thereā€™s something else we can suggest to help.

S/MIME may actually be the solution, but it depends on what youā€™d like to do.

3 Likes
4

This recent post (Reconsider S/MIME) contains many links and comments about S/MIME. Reading through it may help you understand that technology and it's potential applications.

4 Likes
5

I'm also not aware of any implementation that signs PGP/GPG keys using X.509 certificates. This is certainly not something that is intended or supported by the standard PGP ecosystem. It is technically possible though.

Generally, the Web PKI and PGP/GPG are different ecosystems. The CA PKI system Let's Encrypt is part of uses X.509 certificates, while PGP has its own format and associated infrastructure.

You can sign PGP keys using other PGP keys. That's fairly standard. That however has nothing to do with X.509 CA-certificates like those used in the web domain or in S/MIME.

S/MIME on the other hand uses X.509 certificates and is largely compatible with common (web) PKI systems. S/MIME is a different standard to encrypt emails and is unrelated to PGP.

In the end there are different design philosophies at play here. The X.509 PKI system used in S/MIME and TLS (SSL) has a concept of anchored trust: Some parties are trusted by (almost) everyone and trust is derived from those central parties.

PGP on the other hand has no such thing. There is no ultimate PGP key trusted by everyone. If a given PGP key is trusted is generally a highly local decision - users are expected to verify keys themselves. However PGP does have a concept where some keys sign other keys, creating transitive trust similar to how Web PKI systems work. The difference is that there is no central distribution mechanism that sends out "root" keys to everyone.

5 Likes
6

Hi, thanks for chiming in :slight_smile:

What I would like to achieve, is for the receiver of signed files, to be able to verify that it's actually signed by Me/my company/operation. Not just by "some private key" or some anonymous checksum file.
Packaged file archives can be shared to one person, to the next person, to a 3rd person, 4th, 5th person, in a long chain from me. If keys or checksums are anonymous (or super easy to fake), then 'man-in-the-middle' attacks somewhere in that chain, or manipulations, are super easy to do, and hard to spontaneously detect. I want to remedy that, signing files in a way that can't be faked, and verifies "unaltered file from origin" and "me" as origin, both at the same time.

Myself Iā€™m open for any standard, but Iā€™m informed PGP/GPG, that ecosystem anyway, is by far the most inter-compatible among people in general. So I guess I need to go with PGP, unless some other option presents itself.

Downside with PGP keys/signatures is that they have no native attribution method. Thereā€™s no built-in way for the receiver the key actually comes from me, as opposed to some imposter. Anyone can make a PGP keypair, sign my name and e-mail into it, and fake being me.

Having a CA sign off on that ā€œThisā€ particular key have been verified as belonging to ā€˜thisā€™ individual or company, thatā€™s .. what the original idea/need was..

Goes for PGP keys for e-mail too of course. 'Traditional' S/MIME (SSL-analogous cert) usually can verify the buyer of the cert, which can be seen via e-mail. But I donā€™t think you can sign lots of individual files with S/MIME and send those via FTP or HTTP etc.

In my imagination, I envisioned sort of certificate use similar to the padlock icon in a browser, which enables you to click and immediately see the particulars of the certificate.Things like owner name, other details about owner, verification authority, home domain etc - if it's an EV cert anyway. But it may not be that simple for PGP. Youā€™re right. No conventional software support.

So .. hm .. a bit of a quandary here.

1 Like
8

i using pka dns txt record for pgp

9

Indeed S/MIME is most popular for signing emails, but it can be used for signing other things. For example, GitHub - github/smimesign: An S/MIME signing utility for use with Git is a tool to sign git commits with S/MIME. In many ways S/MIME and PGP accomplish similar things, except that S/MIME assumes you're using a PKI, and PGP assumes you aren't.

There's a related subject of "document signing" but that's more meant as a replacement of wet-ink signatures on documents with digital signatures on PDFs.

In the end, Let's Encrypt does not offer anything other than TLS server certificates now, so this isn't going to be a problem you'll get solved here.

4 Likes
10

If "your domain" (as in dns) is enough, you can use DKIM (and DNSSEC, otherwise it's nearly pointless)

2 Likes
11

Got it. Thanks for explaining If the X509 format or other alternates doesn't open up more options, then it seems clear I need to investigate other options.

A website guarded by an EV type SSL cert, where ppl can fetch the public key from .. might be a second best workaround - if I'm staying with PGP. Can EV type SSL certs be purchased by individuals? or just companies/organizations?

1 Like
12

What benefit do you see the EV cert providing?

No, by definition they can only be issued to organizations.

3 Likes
13

15+ years ago, I actually co-founded a startup that tried to do that. Inspired by existing standards like DSIG and FOAF , we created the public FindMeOn Node Standard and an online directory service which never took off. (IMHO that was largely in part because Google decided to compete with our other products under an identical name, and we ended up having to fight with them over trademarks and patents which consumed our limited resources and killed growth.)

That being said, I'm somewhat of an expert in what you're talking about - securely mapping a single entity and their relationships across multiple identities and networks - and have the oldest and most cited patent family in this field (stemming from US10007895B2 - System and method for indexing, correlating, managing, referencing and syndicating identities and relationships across systems - Google Patents).

The solution you think is right is shortsighted:

You're essentially looking at the equivalent of a CA performing Extended Validation (aka Entity Validation), which is highly problematic and what the internet security industry has been steadily moving away from -- reference Troy Hunt: Extended Validation Certificates are (Really, Really) Dead. The problems with this were exemplified in 2017 when a researcher formed a legal entity called "Stripe" and consequently obtained an EV certificate that can be easily confused with a more well known payment company called Stripe (see Nope, this isnā€™t the HTTPS-validated Stripe website you think it is | Ars Technica ).

In your proposed use-case, a CA can only validate the entity who applied for a certificate has legal/business/financial documentation that proves they have a certain name ā€“ but there are numerous entities who share the same name. Often times, all these entities are in the same locale - so a geographic identifier is useless.

IMHO, the solution that you're looking for is what we were trying to achieve 15 years ago ā€“ securely and transparently associating a network of identity facets to one another; said identity facets each being network specific profiles/handles, cryptographic keys, etc; which all belong to the same underlying entity. The goal is not to ensure a given key pairing is correlated with a "legal name", but the nexus of combined entities. Doing so does not require the involvement of a CA, but simply requires each identity facet stating a publicly verifiable ownership of their identity resource though a shared key pairing.

Involving a CA does not preclude this from happening, as repeatedly shown by security researchers, which is why EV certificates are essentially dead and the industry has been moving to simply utilize DV certificates.

As @9peppe noted, utilizing DKIM ideally alongside DMARC and SPF, can address your concern to ensure email comes from a domain; and publishing your PGP key can ensure those you communicate with know it is you.

4 Likes
14

No, but QWAC can.

And QWAC is not a good thing by itself.

1 Like
15

I believe EV ensures a very strict verification process, CA carefully verifying the purchaser actually is the entity it claims to be. In a way like opening a bank account .. ?
Plus being rather verbose and explicit with details about the owner.
A higher insurance for the user that the web resource is actually owned/run by whoever the user thinks owns/runs it ..?

Ah, no individuals.
Why do I smell Murphy's law in the air .. :stuck_out_tongue:

16

But so what? What benefit does that have to the end-user? Sure, it lines the pockets of the CAs, but what does it do for the users?

3 Likes
17

Yeah, but:

  1. noone ever reads those
  2. you can fake them.

Do you want to open a business? There are websites that offer that service, with a choice of incorporation country.

1 Like
18

Well, since the CA really(!) needs to verify the buyer of an EV, and post that ID in the cert, it's a really verified ownership, right? Higher insurance than DV/OV, lesser chance of being insecure or potential scam? The EV cert acts almost like an identity document for the owner, verified by a CA too, which DV/OV doesn't really do?
Sure it's alot more expensive too ..

19

Sure, in theory, the CA does this. But it's almost completely invisible to the user. Yes, if the user really wants to dig through the cert details, they can see that it's an EV cert--but there are no longer any obvious UI cues for the EV cert compared to others (and haven't been for a couple of years now, IIRC). How many users do you think are going to do this? The answer is somewhere between "vanishingly few" and "none."

3 Likes
20

I am slowly evolving a business activity. It's on a person to person basis atm, and I am spreading files around, to people I do trust, but I don't know where the files might end up from them. Just wanted to put something in the packages, saying "if this seal is still intact, then the material is unaltered". And if not, I will disclaim any connection with them.

EVs can be faked too? :woozy_face:
Wh .. hm .. care to shortly expand a bit on how?

21

Damn, you guys are Bulldozering my entire strategy here .. but in the end for the better.
I hope :stuck_out_tongue: