namecoin / safetlsa

Generate TLS certificates from TLSA DNS records that are safe to add to a root CA trust store

safetlsa

safetlsa is a library that generates TLS certificates from TLSA records that are safe to use as trust anchors. It uses name constraints and dehydrated certificates to eliminate most of the attack surface of the X.509 specification.

Projects who use safetlsa

Send a pull request if you'd like to be included.

• TODO

Licence

safetlsa is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

safetlsa is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with safetlsa. If not, see https://www.gnu.org/licenses/.

safetlsa's Issues

Support placing a name constraint on the Root CA

Even though the RFC says that name constraints don't have any effect in self-signed CA's, it shouldn't hurt to put a name constraint on the root CA, and it might boost security in some cases (I have no idea how many implementations follow the RFC on this).

Generate 2 "Domain CA" certs, use AIA to link them

We can use AIA to link the root of a server's supplied cert chain to a cert locally supplied by Namecoin, without needing real-time write access to the intermediate CA store. The AIA URL would be a special URL with a reserved .bit domain name, which ncdns would resolve to a locally running HTTP server. AIA is supported by all mainstream browsers (on all platforms) except Firefox (which supports ncp11).

We should use 2 "Domain CA" certs for this purpose, as follows:

1. A "Domain Blockchain CA" cert should be supplied by the AIA server (or by ncp11), and be signed by the TLD CA. Its public key matches the blockchain's TLSA record; it does not have an AIA extension; it should not be included in the TLS ServerHello cert chain.
2. A "Domain ServerHello CA" cert should be supplied as part of the TLS ServerHello cert chain, and be signed by the Domain Blockchain CA. Its public key is not present in the blockchain. It has an AIA extension pointing to a reserved .bit domain name.

Why are we using 2 Domain CA's, instead of simply putting the AIA extension in the end-entity cert? Because some TLS infrastructure (e.g. Facebook) may not be designed to place specific AIA extensions into subject certs that it signs, whereas we expect TLS infrastructure to not care about the AIA extensions in issuer certs that it uses to sign certs. Thus, the generate_nmc_cert tool produces the Blockchain CA and the ServerHello CA, and the ServerHello CA is used as the issuer in whatever infrastructure is applicable.

Credit to yanmaani for inquiring whether it's necessary to mandate that the end-entity cert use AIA, which led me to the 2-CA approach.

Set EKU extension on CA certs

Although the RFC does not define the behavior of EKU on CA certs, a lot of implementations will use it as a constraint on the EKU of end-entity certs transitively issued by that CA. Thus, any safetlsa CA that's exclusively used for positive overrides can set EKU to ExtKeyUsageServerAuth and gain some extra security.

Include .bit.onion as well as .bit in SAN/NameConstraints

We should include the .bit.onion eTLD in the SubjectAlternateNames and NameConstraints fields, in addition to the current .bit eTLD. Any given TLSA record for www.example.bit will also be valid for www.example.bit.onion.