How does revokation work?

[LecrisUT]

Probably this is already covered in the RFC standard, but let's assume that you create two acme certificates for the same account, one for each machine. One machine is compromised, and if they have access to the S/MIME certificate, we can assume they have all other credentials to impersonate you.

Then how can the right person revoke the old certificate. The actor has access to the email account, so how can they be stopped from issuing new certificates?

On a related note, what setups are there to:

• Enforce signature checking either for individual or whole domain. E.g. is there a setting for the dmarc record.
• Would publishing the CACert via dns record (with DNSSEC) make it trustable by any client. I know there is a RFC for that, but in layman terms, how does that work, if any client actually uses it?

[polhenarejos]

Revocation of S/MIME works in the same way as TLS certs. RFC 8823 does not have specific section. The entire process is described in the RFC 8555.

To revoke a certificate you need either:

1. The private key of the account used to request the cert; OR
2. Having the private key of the certificate you want to revoke.

Usually, if you have the PFX/P12 file, you are able to revoke it.

If you do not have the account private key nor the certificate private key, you can contact to the CA the explain the issue and justify the revocation. Usually, if you can demonstrate that you are in possession of the e-mail account, the CA will revoke the certificate on your behalf.

Regarding your points:

• Enforcing signature checking is not trivial in S/MIME. It shares similarities with TLS certs. LE only issues DV certs, since OV/EV certs cannot be issued autonomously, they require human inspection. Setting a dmarc record could be a way to explore. However, I am not too much optimistic since it is poorly deployed. Plus, I do not see how to do the enforcement in the case an attacker gets your e-mail account (login/pw) and your S/MIME private key.
• If you refer to CAA record, it affects to the entire domain of all email addresses. It could be valid for private entreprises or companies with corporative/worker email addresses. But this is not feasible with personal addresses isued by ISP, public email providers or similar. Setting a CAA record would limitate the choices of all email owners for such domain.

[LecrisUT]

Ok, so the burden is on the mail service provider to provide an recovery method, than the user can deactivate the s/mime certificate and make new ones.

But there's also the scenario that when the email account was compromised, the attacker createad their own certbot profile and s/mime certificates. Since the certificate can be used for other purposes besides email like git signing, it can go undetected.

Probably the certificates issued can be verified like the ones issued by letsencrypt, than if there's an email revocation method than this scenario can be mitigated. The alternative would be to allow only one source, but maybe the user has legitimate usecases for having separate certificates issued.

[polhenarejos]

This occurs for every DV certificate. Since the verification is only based domain, if an attacker gets the control of such domain, it will be able to issue new certificates on its behalf. This also happens with LE.

Certificates are usually verified checking the issuers and the added extensions, assuming they pass exhaustive audits to really accomplish their CP/CPS strictly. Besides this, TLS certification community has the Certification Transparency log system, where multiple loggers publish all issued certificates. Every CA can send its issued certificates to the public logs and they are publicly displayed. It is a matter of transparency. For instance, Chrome browser requires at minimum of 2 public logs of this domain to show the green lock. It does not suppose a verification mechanism per se, but it helps to give more transparency to monitor suspicious issued certificates.

However, there is no equivalent paradigm for S/MIME. We are thinking how we can translate the approach of CT to S/MIME realm but the privacy here is a major inconvenient. Legislation of many countries does not allow to publish emails and we also think it is not a good idea to have a public repository with email addresses. S/MIME is one or two steps behind from TLS certificates.

GPG/PGP confidence is based on public repos of serials/fingerprint public keys, but if you loose your private key, you'll need to start from 0 to get the same reputation. First months would be a pain every time you send an email. This may be a possible solution for verification, but it has many other drawbacks. We'll think that the future steps will be oriented to such architectures, but this is a community agreement.

[LecrisUT]

Indeed it seems to be a difficult issue. For paid S/MIME certificates at least there is a payment history that would roadblock attackers. Probably in order to get a root certificate to be publicly trusted something like this has to be resolved.

How about linking to a third-party identifier and a network of identity servers like in matrix. They are also working on decentralizing the identities, and although there are different issues there maybe there's something that can be adapted.

I am curious now how Thunderbird detects the S/MIME certificate to initiate E2E. For PGP I understand that it looks through some of the keyservers, and there's an equivalent S/MIME certificate server, but how about the commercial ones? I don't have a geeky enough friend to test this with, but probably you're already familiar with this?

[polhenarejos]

The way Thunderbird works is much simpler than PGP. There are not any public keyserver. Every time you receive a signed message, TB stores the certificate into its local cert store and since this moment you can send encrypted emails to this person. If you want to send a new fresh email to a person that never before wrote to you, you have to import manually its certificate. You can check it in Options > Security > Certificates > People

Yesterday we released our public repository where all issued certificates by CASTLE CA are stored. It is an exercise transparency while it prevents the privacy. Emails are not displayed (actually they are obfuscated) and for obvious reason certificates cannot be download, but you can check a certificate and track the issues of each certificate by its public key. It is far away from Certificate Transparency purpose, as there are not append-only Merkle trees nor timestamps, but it is a first step.

[LecrisUT]

Yesterday we released our public repository where all issued certificates by CASTLE CA are stored

Interesting. I'm looking forward to see how this can grow.

This would become useful for when a compromised certificate is found in use. Maybe internally the trusted CA servers can communicate with each other and verify/keep a common internal/obfuscated log of the ACME issued certificates. The roots have to be vetted to become publicly trusted anyway, so it should be possible. The possible concern would be if a CA server becomes compromised and the emails are being leaked from other trusted CAs.

Another option could be for the user to register their accepted CA server, like the CAA record but for individual email address, to their CA server of choice. Then the CAs could communicate with each other to confirm/flag/periodically revoke ill-served certificates. You would have the same problem as before if a CA server is compromised, but not all emails would be leaked this way. And if there is a way to obfuscate the email address during this process, maybe with a one-time hash, then that might be eliminated.

Similarly, what if the clients can communicate with the public CA server, encrypt the email they want to search a public key for and have the CA search it up in its network? That would help make the E2E encryption without prior certificate import. The concern would be that an attacker would try to spoof for valid emails, which I don't know if there's a useful counter for it? Maybe requiring the requester to have a valid S/MIME in the network as well so at least they can be tracked down?