Yo Hal!
On Fri, 08 Mar 2019 19:03:06 -0800
Hal Murray via devel wrote:
> > Here's a proposal off the top of my head:
> > 1) server private key = SYSCONFDIR/ntp/nts.key
> > 2) server certificate = SYSCONFDIR/ntp/nts.crt
> > 3) cookie key file= LOCALSTATEDIR/lib/ntpkeys
>
> We would have to
I recommend having no default at all for the trust store location and
forcing to be set in the config file. Too much risk otherwise of
finding something that looks like a store but isn't actually
trustworthy and entering an insecure state without the user realizing
it. Leave it up to packagers to p
Yo Hal!
On Fri, 08 Mar 2019 19:06:08 -0800
Hal Murray via devel wrote:
> Gary said:
> >>> Is /etc/ssl/certs somewhat standard? at least for the root
> >>> certs?
> >> Somewhat, but I don't know to what extent the contents of it are
> >> standard.
>
> > We are making the standard.
>
> N
Gary said:
>>> Is /etc/ssl/certs somewhat standard? at least for the root certs?
>> Somewhat, but I don't know to what extent the contents of it are
>> standard.
> We are making the standard.
No we aren't. We are using whatever OpenSSL and the distro support.
Looks messy. We'll have to doc
> Here's a proposal off the top of my head:
> 1) server private key = SYSCONFDIR/ntp/nts.key
> 2) server certificate = SYSCONFDIR/ntp/nts.crt
> 3) cookie key file= LOCALSTATEDIR/lib/ntpkeys
We would have to add things like SYSCONFDIR to config.h.
The certificate and private key should probab
Yo Hal!
On Fri, 08 Mar 2019 18:50:11 -0800
Hal Murray via devel wrote:
> I haven't found them on NetBSD - no /etc/ssl/ at all, so maybe the
> basic package doesn't have any certs and I haven't installed the
> right package yet.
Here is how I look for certs:
# find / -xdev -name '*.pem'
man trust may be interesting.
> Is /etc/ssl/certs somewhat standard? at least for the root certs?
That's where they are on Debian - lots of stuff.
It looks like the directory format that libssl is expecting - a hash links to
a sensible name. Example:
67495436.0 -> thawte_Primary_Root_CA_-
Yo Hal!
On Fri, 08 Mar 2019 15:17:40 -0800
Hal Murray via devel wrote:
> Gary said:
> >> So maybe master.keys?
> > Works for me. Hal?
>
> Seems misleading to me. There is nothing master-ish about it. It
> only lets you unlock a subset of the cookies associated with a single
> system.
I
Gary said:
>> So maybe master.keys?
> Works for me. Hal?
Seems misleading to me. There is nothing master-ish about it. It only lets
you unlock a subset of the cookies associated with a single system.
> I care to reduce the vocabulary, and to make the vocabulary match the
> Proposed RFC.
Yo Richard!
On Fri, 8 Mar 2019 16:30:22 -0600
Richard Laager via devel wrote:
> On 3/8/19 3:03 PM, Gary E. Miller via devel wrote:
> >> Here's a proposal off the top of my head:
> >> 1) server private key = SYSCONFDIR/ntp/nts.key
> >> 2) server certificate = SYSCONFDIR/ntp/nts.crt
> >> 3) cookie
On 3/8/19 3:03 PM, Gary E. Miller via devel wrote:
>> Here's a proposal off the top of my head:
>> 1) server private key = SYSCONFDIR/ntp/nts.key
>> 2) server certificate = SYSCONFDIR/ntp/nts.crt
>> 3) cookie key file= LOCALSTATEDIR/lib/ntpkeys
>
> I'd like an extention on #3. Maybe .conf, bu
Yo Richard!
On Fri, 8 Mar 2019 14:50:38 -0600
Richard Laager via devel wrote:
> On 3/8/19 1:42 PM, Gary E. Miller via devel wrote:
> > Is /etc/ssl/certs somewhat standard? at least for the root certs?
>
> Somewhat, but I don't know to what extent the contents of it are
> standard.
We are ma
Yo Hal!
On Fri, 08 Mar 2019 12:41:23 -0800
Hal Murray via devel wrote:
> Gary said:
> >>> Let us not call it the "cookie key", lets use the terminology of
> >>> the RFC.
> >> Please suggest a file name.
>
> > Just for grins: /usr/local/etc/ntp/keys.conf
>
> Why the "etc"?
> "conf" sugges
On 3/8/19 1:42 PM, Gary E. Miller via devel wrote:
> Is /etc/ssl/certs somewhat standard? at least for the root certs?
Somewhat, but I don't know to what extent the contents of it are standard.
Here's a proposal off the top of my head:
1) server private key = SYSCONFDIR/ntp/nts.key
2) server c
Gary said:
>>> Let us not call it the "cookie key", lets use the terminology of
>>> the RFC.
>> Please suggest a file name.
> Just for grins: /usr/local/etc/ntp/keys.conf
Why the "etc"?
"conf" suggests a manually edited configuration file.
"keys" doesn't distinguish it from the certificate key.
Yo Hal!
On Thu, 07 Mar 2019 22:54:45 -0800
Hal Murray via devel wrote:
> > Let us not call it the "cookie key", lets use the terminology of
> > the RFC.
>
> Please suggest a file name.
Just for grins: /usr/local/etc/ntp/keys.conf
> >> I'm assuming that the system defaults will cover 99+% o
> Let us not call it the "cookie key", lets use the terminology of the RFC.
Please suggest a file name.
>> I'm assuming that the system defaults will cover 99+% of the normal
>> cases. I don't have to do anything special for my browser to work.
> Because your browser includes its own cert st
Yo Hal!
On Thu, 07 Mar 2019 21:18:28 -0800
Hal Murray via devel wrote:
> Gary said:
> > Why do you need a cookie file? I would think those should never be
> > stored. Ever.
>
> The cookies are sent from client to server in the clear.
Of course.
> It's the "cookie key" file, not a cookie f
Gary said:
> Why do you need a cookie file? I would think those should never be stored.
> Ever.
The cookies are sent from client to server in the clear.
It's the "cookie key" file, not a cookie file. Do you have suggestions for a
better name?
It holds the K/I used to decode cookies -- but
Yo Hal!
On Thu, 07 Mar 2019 19:36:00 -0800
Hal Murray via devel wrote:
> The client side is easy: just add "nts" to the server line. There
> are no parameters needed so the initialization for the client side
> just works.
How does it know which of the myriad locations that the CA and
intermedi
The client side is easy: just add "nts" to the server line. There are no
parameters needed so the initialization for the client side just works.
That assumes the certificates for the servers you want to use are covered by
the default root certificates on your system.
--
For the server s
21 matches
Mail list logo
