I assume this list is "best" to "worst"
; Use "3 1 1", the other three are OK, but "3 1 1" is better.
_25._tcp.mx.example.com. IN TLSA 3 1 1 <sha2-256 digest of DER leaf public
key in X.509 SPKI format>
_25._tcp.mx.example.com. IN TLSA 3 0 1 <sha2-256 digest of DER leaf
cert>
_25._tcp.mx.example.com. IN TLSA 3 1 2 <sha2-512 digest of DER leaf public
key in X.509 SPKI format>
_25._tcp.mx.example.com. IN TLSA 3 0 2 <sha2-512 digest of DER leaf
cert>
; Use "2 0 1", the other three are OK, but "2 0 1" is better.
_25._tcp.mx.example.com. IN TLSA 2 0 1 <sha2-256 digest of DER CA
certificate>
_25._tcp.mx.example.com. IN TLSA 2 1 1 <sha2-256 digest of DER CA public
key in X.509 SPKI format>
_25._tcp.mx.example.com. IN TLSA 2 0 2 <sha2-512 digest of DER CA
certificate>
_25._tcp.mx.example.com. IN TLSA 2 1 2 <sha2-512 digest of DER CA public
key in X.509 SPKI format>
I am not sure I understand this. Why are you linking the two?
* Do understand how to coordinate DANE TLSA record updates with
key rotation, and never forget to update DANE TLSA records
as part of that process.
Has anybody published any recommendations as to timing for the life
cycle of a ZSK (and KSK for that matter)? So far the only
recommendation I have seen was a footnote in a paper on DNSSEC. It
recommended 1yr for KSK and 4Yrs for KSKs. I think these number are
unrealistic for a couple of reasons 1) with the growth of hacker nets i
do not think keys can survive that long. 2) on a much more mundane level
- with staff turn over etc., rollover is liable to slip between the cracks.
Are there any know tools to automate rollover? I have not found any and
have been writing my own script but being a lazy s.. i would prefer to
use somebody elses work!
Victor - I have a question and a suggestion which I would like to
explore offline. May I contact you at IETF, or at any other address you
like, you may contact me a j...@klam.ca.
--
John Allen
KLaM
------------------------------------------
You are off the edge of the map, mate. Here there be monsters!
