A sensible "3 1 1" + "3 1 1" key rotation approach

[Viktor Dukhovni]

To avoid (even temporary) mismatches always publish multiple (two
are enough) TLSA records.  One for matching the current certificate
chain, and another matching the *future* certificate chain.

You might ask how the *future* certificate chain can be predicted,
but the answer is simple enough.  While you may not know all the
certificate details, you can control the public key that goes into
the future certificate.  This can be matched with a "3 1 1" record.

Therefore, the recommended key rotation approach is:

  1.   Whenever you *deploy* a certificate chain with a new key,
       at the same time (that way you won't forget later) generate
       the next key!  And that time update your TLSA records to match
       both keys.  You only need the next public key for this, the
       next private key could be password protected if you like, but
       for most sites just rotating the keys often and letting the OS
       protect the keys from all but the authorized account is enough.

       _25._tcp.smtp.example.com. IN TLSA 3 1 1 <sha256(curr key)>
       _25._tcp.smtp.example.com. IN TLSA 3 1 1 <sha256(next key)>

  2.   When it is time to obtain a new certificate, generate the CSR
       from the previously generated *next* key (this may require
       decryption of the private if stored encrypted initially) and
       request the certificate, *but* do that only if the corresponding
       TLSA record is already published!  Do the DNS lookup to verify.

  3.   To deploy the newly obtained certificate go back to step 1.

-- 
	Viktor.