Description
Loading a full root certificate store into memory in the way it is currently implemented in axTLS will quickly cause an out-of-memory condition on the ESP8266. Certificates themselves, in DER format, can also occupy significant chunk of program memory. For this reason, in the past we have implemented certificate fingerprint verification. Certificate fingerprint verification suffers from poor UX though, as certificates get renewed and fingerprints change. Recently merged SPKI verification (#31) can potentially help with the renewal issues, but support for displaying SHA-256 hash of SPKI is not present in all major browsers, complicating the process for new users.
Considering the way axTLS performs certificate chain verification, we don't actually need to know the full contents of root certificate. AxTLS only uses the public key to perform verification. In addition to that, DN is used to identify the root certificate to be used, and basic constraint info is checked in the latest version.
The basic constraint info can be checked before creating a root certificate bundle for axTLS, in a way similar to curl's mk-ca-bundle.pl.
Instead of using DN to match root certificate, we can use authority key identifier extension, which "MUST be included in all certificates generated by conforming CAs" according to the RFC. Authority key identifier is basically a SHA-1 hash of the CA's public key.
With this in mind, for each root certificate we need about (RSAkeySize/8 + 30) bytes of storage. SHA-1 hashes of authorityKeyIdentifiers can be stored in a heap structure in program memory (PROGMEM), making RAM overhead essentially zero. Limiting the number of root certificates in the store to ~20 most common ones we can keep the program memory cost small, and provide good out of the box experience for users at the same time.
This issue seeks discussion about the overall idea and specific APIs which will be used to expose this new mechanism.