Sorry its taken me so long to get back to this.
On 3/31/2018 7:09 PM, Tony Finch wrote:
There are a few pertinent differences between trust anchor witnesses and
the undeployed RFC 5011 many-keys setup:
* in RFC 5011 each key is completely trusted, whereas no witness is
trusted; compromise o
On Sun, Apr 1, 2018 at 1:59 PM, Paul Vixie wrote:
>
>
> Tony Finch wrote:
>
>> Paul Vixie wrote:
>>
>>> i suggest that bind, unbound, powerdns, and so on change their packaging
>>> to
>>> put the trust anchor in a different upgradeable package (.deb, .rpm, etc)
>>> than the software itself. unti
Tony Finch wrote:
Paul Vixie wrote:
i suggest that bind, unbound, powerdns, and so on change their packaging to
put the trust anchor in a different upgradeable package (.deb, .rpm, etc)
than the software itself. until and unless the package manager is secured by
DANE rather than by ssh/pgp/x5
Paul Vixie wrote:
>
> i suggest that bind, unbound, powerdns, and so on change their packaging to
> put the trust anchor in a different upgradeable package (.deb, .rpm, etc)
> than the software itself. until and unless the package manager is secured by
> DANE rather than by ssh/pgp/x509/etc, then
Tony Finch wrote:
Paul Vixie wrote:
devices which cannot be updated by their makers must expire
Definitely.
I think the problem that most concerns me is the device that spends 3 or 6
months in a box between manufacturing and deployment, and which expects to
do a software update when it is
Paul Vixie wrote:
>
> devices which cannot be updated by their makers must expire
Definitely.
I think the problem that most concerns me is the device that spends 3 or 6
months in a box between manufacturing and deployment, and which expects to
do a software update when it is plugged in, but ther
Tony Finch wrote:
Phillip Hallam-Baker wrote:
So don't you dare claim that software updates are essential, that is an
ideological position learned from a limited set of experience.
...
devices which cannot be updated by their makers must expire. see:
http://geer.tinho.net/geer.blackhat.
Phillip Hallam-Baker wrote:
> So don't you dare claim that software updates are essential, that is an
> ideological position learned from a limited set of experience.
My position is that software updates extend the lifetime of a device. If a
device depends on external services then there's no wa
It is a hard problem and it is possible that there is actually no solution.
All these systems consist of a chain or a graph of signed assertions. There
is no intrinsic ground truth in PKI. All that you can do is to define a
particular key or set of keys as producing the ground truth for your
parti
Michael StJohns wrote:
>
> There are three questions I have about your solution -
> 1) Do you expect it to be usable each time a device boots?
Yes.
(It's only necessary to consult the witnesses if the device's stored trust
anchor doesn't work, for whatever reason. This might include an incorrec
Apologies for the top post.
Thanks for the commentary. My guess is that we're starting from
different assumptions.
There are three questions I have about your solution - 1) Do you expect
it to be usable each time a device boots? 2) If (1), how long in years
to you expect it to be usable?
Michael StJohns wrote:
>
Interesting thoughts, thanks. I have a slightly different starting point,
which doesn't disagree with your argument, but leads to somewhat different
consequences.
> Proposition 1 (P1): The initial selection of a root of trust (ROT) on behalf
> of a validator ALWAYS invo
Hi -
Joe Abley introduced draft-jabley-dnsop-bootstrap-validator [jabbootval]
at the DNSOP session this past week. I was the only (one of the few?)
person who suggested that this was a bad idea. Later that week, we ran
into each other in the bar and chatted for not long enough to sync, but
l
13 matches
Mail list logo
