Closed fpedrei closed 2 years ago
There are a major problem, which also affects to TLS, with DV certificates. All these certificates are domain based certificates. Thus, the control of the domain (the email account for S/MIME) is the only requirement to issue a certificate. If an attacker may request successfully a certificate of your email account, it implies that it is under its control and, thus, from the server perspective, it is a legit account. This also happens with, for instance, Let's Encrypt. If an attacker takes the control of your domain, it will be able to issue new certificates for your domain and keep them under its control. The same applies for emails and S/MIME.
Said that, regarding with Mozilla Root Store Policy, we do not think that violate them. CPS states that the renewals are treated as new applications. This is because Certbot does not allow to renew a certificate with CSR without making a complete new order. This is not bad but probably it could be optimized.
What CASTLE CA does is to revoke all certificates that are valid when receive a new request with an existing email address in its database. Therefore, if an attacker steals your account and issues a certificate, when you recover the control of your email account you must to request a new certificate in order to revoke the bad one (attacker's cert). When CASTLE CA receive a new order with the same email account, all previous certificates that match are revoked.
You can do the test. Perform two request and check that the first cert is revoked. You can do check it with the CASTLE OCSP service.
Is there a project/issue tracker for the ACMECastle service? I'm writing here, because I couldn't find any.
Any news here?
[...], which also affects to TLS, [...]
That's different, TLS certificates have certificate transparency, shorter validity periods, and are much more difficult to exploit, after the domain owner has reclaimed her domain.
[...] What CASTLE CA does is to revoke all certificates that are valid when receive a new request with an existing email address in its database. Therefore, if an attacker steals your account and issues a certificate, when you recover the control of your email account you must to request a new certificate in order to revoke the bad one (attacker's cert). When CASTLE CA receive a new order with the same email account, all previous certificates that match are revoked.
I appreciate this, but I cant find this process in your CPS where you have to describe this.
Is there a project/issue tracker for the ACMECastle service? I'm writing here, because I couldn't find any.
Any news here?
You can use this issue tracker or contact through the web/email.
[...], which also affects to TLS, [...]
That's different, TLS certificates have certificate transparency, shorter validity periods, and are much more difficult to exploit, after the domain owner has reclaimed her domain.
Certainly, S/MIME certs do no have the equivalent CT infrastructure. This is the reason of impulsing and promoting our transparency portal, where all issued S/MIME certs are publicly displayed (with email obfuscation).
https://acme.castle.cloud/acme/certificates/
[...] What CASTLE CA does is to revoke all certificates that are valid when receive a new request with an existing email address in its database. Therefore, if an attacker steals your account and issues a certificate, when you recover the control of your email account you must to request a new certificate in order to revoke the bad one (attacker's cert). When CASTLE CA receive a new order with the same email account, all previous certificates that match are revoked.
I appreciate this, but I cant find this process in your CPS where you have to describe this.
We've updated CPS to include this clarification.
Thanks for the update
Is there a project/issue tracker for the ACMECastle service? I'm writing here, because I couldn't find any.
Your CPS states:
This contradicts with Mozilla Root Store Policy:
When my email account gets compromised, I have no possibility to revoke certificates an attacker creates with it, because I neither have the account key nor the certificate private key in this case. Wouldn't it be better to revoke all valid certificates with matching SAN and keyUsages upon renewal to prevent this?