Re: [stir] current draft charter

[Hadriel Kaplan <[e-mail]>]

On Jun 17, 2013, at 2:05 PM, Michael Hammer <[e-mail]> wrote:

> That is a key distinction and ties into my assertion that the CC numbering
> authority must control that.
> 
> But, clarify one thing for me.  Does DNSSEC ensure both:
> -  that the uploading of information is authentic,

I am not-at-all an expert on DNSSEC, but I don't believe it covers how the info gets uploaded into the DNS database.  Of course neither does anything else.

Regardless of what protocol and architecture we end up using, at the end of the day the administrator of a given database has to provision the "customers" that can upload for which E.164 entries.  Each customer account is provisioned with some set of credentials with which to do so - for example a username+password, or whatever.  The customers then use some mechanism to upload/update their entries with the credentials.  This could be through a web portal, or Dynamic DNS, or sending faxes.

It would definitely be nice to provide a defined protocol means of doing some of that, for at least the part of: customer-X which already has an account with credentials in database Y, and is already assigned E.164 number Z, being able to upload a public-key or unsigned cert for number Z into the database Y.  I don't really care what the protocol is for that to happen, although defining something over HTTPS makes the most sense to me for that.


> -  attempts to read the data actually get to that secure entry?

If I understand it right, it doesn't actually matter if you reach the right server or not - if another server responds with a false/fake entry, you'll correctly detect it is fake; if another server responds with a correct entry, you'll detect that it's not fake and it's perfectly ok to use it.

-hadriel