getdnsapi
SPKI validation for public DOT systems
With limited memory environments (e.g. routers) where no real space is available to store certicates on the local system and running Stubby a way to configure things is to extract SPKI pinset of given certificates from DOT resources and add these to stubby.yml config. This sort of aligns with how to work with self-signed resources, but is not recommended by parties like Cloudflare and Google.
Certainly Google nowadays seemingly has a certificate refresh policy with lifetimes of only 3 months, meaning refreshes (and therefore pinset updates) are more frequent than updates to a router OS. If there however is no way to store root certificates and SPKI pinsets become invalid as soon as they come out this could lead to a chicken and egg problem.
Can you however also add the SPKI off an issuing CA instead of the server certificate? If that is the case you could actually extend on the lifespan of certificates (CA certs usually go for 10 years or more) while also supporting low resource devices.
There is no question in requiring to validate either the certificate itself for the whole chain or via a preset pinset for strict mode, but if these pinsets could be those of a CA that would require a very limited list (bytes in size instead of 200 kiB).
Maybe there is a smarter way to solve this one, but the documentation is not really clearing things up for me.
Further analysis shows that rfc7858 does not really leave room here (provide pins that are specific to the service being pinned), but could in that case e.g. SPKP data be used to validate dns.google?
I do however for HPKP bits read this: The easiest, but not most secure place to pin is the first intermediate CA certificate. That would imply you could use pinsets in the chain instead of only at the system name itself. That could then extend when using SPKP data as provided by Google for their DNS service (e.g. an SSLLabs check can get you all the relevant data).
@JayQ2K I sort of like that idea to extend what exactly will be matched (like the usage field of a TLSA RR)
