At 17:32 +0200 4/21/09, Stephane Bortzmeyer wrote:
On Tue, Apr 21, 2009 at 11:25:59AM -0400,
Edward Lewis <[email protected]> wrote
a message of 60 lines which said:
My concern is first the database over the key, it's what matters in
the event of catastrophic organizational failure.
From that, it's a matter of "fate sharing." What ever I do to protect my
most vital element (database) can be used to protect other things as
well, including the key.
But the risk for the key is not only people modifying it, it is simply
people *reading* it (a concern which also exists for the database but
is much less important).
I have no practical experience with HSMs but, in my mind, the
interesting thing is that they guarantee noone will read the key
without an authorization (that's quite unlike the database where you
certainly prefer a few unauthorized looks to a complete loss).
Jokingly said, I don't mind someone reading the key, it's the forging
I mind. ;)
Suppose that I tightly constrain who reads the database. I can
constrain reading permissions down to the same set as those who can
make changes, or even access where ever the private key is stored.
What might be confusing is that the general public can "query" the
database via DNS or WhoIS or EPP. But that's not really the database
query, responses are the affect of what's in the database. (For
example, a DNS query can't trigger getting the creation data of the
record, while WhoIs can.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
Getting everything you want is easy if you don't want much.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
