You pretty much open a business with the name you want ("Apple Inc.") in a different jurisdiction from the actual Apple Inc.
And in fact, Apple has gone from using an EV cert to using a dedicated intermediate CA, so it looks like they verified themselves.
Oh .. what the 
And since nobody but cyber-investigators will dig into it, might as well create a self-signed SSL with any optional name to it then ...
Wow .. Murphy's law is making me Limbo here, under a really low bar.
Thanks for a great detailed help. 
So DKIM+DMARC+SPF is an email filtering which I can tell an outside user can be trusted. I can also sign the e-mail which I send the public key in, and that will act as a quite safe verification. At least one way: outgoing from me. Not designed for file signing though.
I will be sure to keep that in my notes for a while and learn more about it.
It's a paradigm that allows your recipient to check if the email comes from an authorized server.
Only the sender can implement it, by configuring the mailserver and some DNS records. The filtering part can be DMARC, where you can specify a policy for messages that fail the test, but it's up to the recipient to actually drop the message or mark as spam automatically.
Yes.
Implemented together, they help you ensure recipient mail servers that emails claiming to be from your domain are actually from your domain.
Layering in a GPG signature, you ensure the end-user mail recipient the email is from your private key.
You can then publish your public key somewhere on your domain's website, or a known place, so that key pairing is associated with you as an entity.
Thanks.
I'm still clinging on to some hope here. 
: In my Kleopatra app (GPG4win) I can create a personal X.509 key pair, which is auto-prepped (by the app) for immediate sendoff to a CA for verification. Truly this must be PGP? It specifies it as RSA up to 4096bit, and Kleopatra doesn't deal with any other encryption format than PGP, to my knowledge(?)
Plus I've been browsing a dozen pages which claims the X.509 certification is commonly used to sending both the shared files, the digital signing of those files, and the certificate with cert holder's general ID enclosed. The X.509 is new to me, so I'm not sure how one would access these resources, software-wise. Sure isn't just JPEGs.
So, PGP and certified public key possible?
I know I'm putting my hopes in harms way here. So ...hit me: what am I misunderstanding about it? 
You might be looking for something like Sigstore. They are using x509 certificates and transparency logs to add signing and verification to packages.
sigstore is a set of tools developers, software maintainers, package managers and security experts can benefit from. Bringing together free-to-use open source technologies like Fulcio, Cosign and Rekor, it handles digital signing, verification and checks for provenance needed to make it safer to distribute and use open source software.
AFAIK, Kleopatra also supports S/MIME, so that dialog just generates a CSR to submit to any CA signing S/MIME.
I just looked at my own Kleopatra and noticed that it is additionally using the term OpenPGP certificate, which refers to the PGP key block with associated data. Absolutely not confusing.
The X.509 standard is part of the X.500 family which includes lots of stuff, so you may have mixed something X.509 is a standard that defines certificates (and some PKI stuff like CRLs).
Actually double checked, it's X.509 all the way, the very basics.
But hmm .. decoding here .. so Kleopatra DOES create a PGP type keypair, for use with certification? It's just .. formatted for S/MIME convention usage? And the only reason CAs may offer to verify this keypair, is because they- and the subsequent certificate will adhere to the ITU standard and prescribed usage format?
And if this is correct, that would mean it's perfectly feasible for a CA to verify regular (non S/MIME) PGP keys with a certificate, only it is not commonly offered by CAs, partly because there is no customary convention in place, and no real prescriptive usage for software to access/control the combo of PGP key and certificate?
The underlying private keys used by OpenPGP and X.509 can be the same keys, because these technologies are "just" transport formats and ontologies for key-to-identity bindings and messages using those. In fact, I remember some efforts a few years ago to try to make these technologies interoperable by literally using the same subject key in an OpenPGP identity and an X.509 certificate, or maybe one of them was OpenSSH instead.
You can, in principle, extract the subject key in each case and then import it into a different identity ecosystem. That's not at all impossible. The big challenge with that is that the tools and concepts in each ecosystem are so different that you're unlikely to find other people who will successfully interoperate with such a crossover system, unless you personally persuade them to install custom software to do so. You might also have to write some of that software yourself, depending on which exact crossover you want to do.
I remember discussing this quite a lot before Let's Encrypt was set up when many privacy activists were expressing skepticism toward the centralization (and, at the time, limited transparency) of the CA system. Since then, it's remained pretty centralized but become more transparent, which I think is great progress. There was a question about making OpenPGP and X.509 interoperate so that you could sign website keys with your OpenPGP key (thereby confirming that you agreed that that website was supposed to be using that key), or so that you could receive OpenPGP e-mail with your X.509 key (thereby allowing people to bootstrap trust in certificate authorities in order to send you encrypted e-mail, especially if they preferred OpenPGP to S/MIME).
These ideas are not technically impossible, but as people have mentioned in this thread, they start with somewhat different trust and identity models, and the software ecosystem to interoperate between them is significantly lacking.
I think the energy around developing some of that software has also been hindered by a series of events that have led to decreased popularity of end-to-end e-mail encryption as a whole, even though of course the OpenPGP technology can also be used for other applications.
Anyway, my summary is, yes, these things could interoperate at a low cryptographic level (in the specific sense of exporting and importing subject keys), but they can't directly consume or verify one another's trust assertions, and the software to make any kind of crossover between X.509 and OpenPGP practical is not widespread or well-developed. You also can't convert between an existing X.509 signature and an OpenPGP signature because the signature is taken over specific bytes, so the holder of the private key would have to regenerate it explicitly in each format.
I've only skimmed the thread so far. But did anyone suggest code signing certs yet aside from sigstore?
Hi. No suggestions of that (outside sigstore) yet.
I was thinking about this option, before I got into this more 'traditional' signing idea.
Initially I suspected that 'Code signing' certs are probably targeted to be used with executable or similar software, and applying it on files in general probably isn't a use which is catered to.
But perhaps that might be the case still ....? Code signingseems to be available for simple things like scripts too, as in plain-text (I guess?). If if it can do plaintext, then maybe image files or binary files too? Interesting. 
There are products with "Document Signing" but you're again getting into a pretty niche area, probably most interesting to high value legal contracts, DocuSign and Adobe have products in this space. I know very little about them but worth a few minutes of your research if you care about this.
As to EV, mostly for the value of anybody else following who wonders about EV rather than @Mariano I will point out a crucial flaw. Your web browser doesn't care about EV, and the web browser, not you, makes crucial security decisions.
Imagine Big Bank control bigbank.example, and some nefarious actor has somehow obtained a (DV) certificate for bigbank.example from Let's Encrypt plus they're interfering with your network, maybe you are using the WiFi in a Starbucks and the nefarious actor secretly owns that Starbucks. Does Big Bank's real EV certificate save you? We will suppose you are very meticulous in checking. You go to Big Bank, your browser loads the page, and it presents the real EV certificate. You check this certificate by eye, it is genuine. Then you type in your credentials to use the Big Bank site and you click the "Login" button. The bad guy intercepts your network access at this moment. Your browser connects over the network, and sets up a TLS connection, it receives a certificate during that process - but you don't see that certificate yet, it would be very annoying to need to read and acknowledge every certificate processed by the browser so that is not an option in any browser software. Unknown to you it receives the bad guy's DV cert, but the browser doesn't care that's valid so it continues. It sends the credentials to the remote server (to the bad guy) and receives an HTTP 30x code back, redirecting it, so, it tries to reconnect for the new URL. The bad guy ceases intercepting, the browser connects to Big Bank successfully, gets the EV certificate and this time say, a 404 code. Stupid Big Bank's website is faulty, you got a "Not Found" error when you tried to log in. Checking the certificate doesn't reveal a problem though, it's the EV certificate. You believe there's some weird technical glitch on the site, on second attempt logging in succeeds. But meanwhile the nefarious actor has control over your Big Bank account.
EV was never intended as a security measure by the technical people involved. It's a compromise with the for-profit Certificate Authorities, dating back to the early 21st century, they agree to important improvements in their practises and the browsers agree to give them an amazing new marketing tool in popular new desktop browsers like Internet Explorer. Overall this actually worked out pretty well for everybody, but the actual EV technology is not a security product.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.