> Which means it's time for a serious on-list conversation about what our next
> major objective beyond wrapping up NTS is.
Other ideas to consider...
Randomize client side ports. (big messy discussion on IEFT list)
We may want/need servers supporting NTS to support non standard port number,
> Yeah, but I'm not sure it would be efficient to pull the trigger on anything
> like this until we figure out how many months out the Go port is.
We could also use the "simple" client/server NTS-KE samples as warm ups on the
Go port. I think the client side is pretty simple - OpenSSL does al
Hal Murray :
>
> >> Does ntpdig know about NTS? Seems like it should be able to ue NTS.
> > That would be pretty tricky, actually. We'd have to expose the NTS crypto
> > and key-exchange primitived as a C extension to Python.
>
> Another possibility...
>
> On my back burner, is a pair of NTS-
>> Does ntpdig know about NTS? Seems like it should be able to ue NTS.
> That would be pretty tricky, actually. We'd have to expose the NTS crypto
> and key-exchange primitived as a C extension to Python.
Another possibility...
On my back burner, is a pair of NTS-KE programs, one for server
Gary E. Miller via devel :
> Does ntpdig know about NTS? Seems like it should be able to ue NTS.
That would be pretty tricky, actually. We'd have to expose the
NTS crypto and key-exchange primitived as a C extension to Python.
I'm unwilling to do that until we know we're *not* going to migrate
Yo All!
Does ntpdig know about NTS? Seems like it should be able to ue NTS.
RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Verita
