Paul Wouters wrote: > > Gervase Markham wrote: > >> Paul Wouters wrote: >>> >>> Maintaining TLS certificates actually becomes _easier_, because people >>> don't have to frantically read the openssl man page to generate a new >>> certificate when the old one suddenly expired without anyone noticing >>> before the complains hit the help desk. >> >> They have to read other documentation about how to update their DNS >> instead... > > No they do not. Because there is no _expiry date_. By being in the TLSA > record in DNS, it is self-declared valid. No mysterious outages in 1 or > 2 years from now when the certificat expired and the original guy who > know the openssl commandline left the company.
This will still happen if the Web Server cert was issued with a validity of only one year. > > This is another reason for > TLS bare key certificates that just contain the bare public key as SBKI. > To get rid of that obsolete container information (and new CA invoice). > > Until those are common practise, define the certificate to be valid for > 100 years, and you should be good till retirement. Uh-oh, such a recommendation runs shivers down my spine and is seriously ignorant of the real world. Due to a uncounted numbers of bugs in software, some of which get published on a monthly schedule, TLS-enabled Servers may experience break-ins, and there is absolutely no indication that this is going to ever change. So rather than making the keys last forever, the objective should be to make rekeying (a) easy to perform by the staff and (b) performed with sufficient frequency so that it will be a no-brainer for staff to rekey after an alleged or verified security breaches on the server (e.g. the virus-scanner detected malware on the machine). -Martin _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
