Gary said: >>> Just look to the SSL/TLS mess for how upwardly compatible change in >>> crypto can be badly managed. >> That's a public API. The cookie format is private. > Uh. lost me?
SSL/TLS is documented in various RFCs. That's what public means. We expect systems written by different groups to interoperate so all the details need to be documented. Only the NTP server needs to know the format of a cookie. It doesn't need to be documented. That's what private means. If you want the NTS-KE server to generate initial cookies rather than asking the NTP server for them, then you have to bundle the NTS-KE server with the NTP server. That makes them semi-private. You have to keep both ends in sync. But we already have to keep both ends in sync since the the protocol between NTS-KE server and NTP server is also private. Same for NTP client and NTS-KE client. We could document those if we wanted to give the admin more choices. That all assumes we are packaging NTS-KE server and NTS-KE client as separate run time programs. That seems unlikely for the client. It's also unlikely for the initial server, but reasonably likely for the future. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
