Re: [stir] current draft charter - ENUM and databases

[Hadriel Kaplan <[e-mail]>]

On Jun 17, 2013, at 8:47 PM, "Peterson, Jon" <[e-mail]> wrote:

> 
> Definitely I agree that there needs to be a root here, at least at the
> national level. A few people have commented that working from the national
> level makes more sense than trying to delegate something globally from on
> high. Choosing that scope could make it harder to guarantee your vision of
> a tariff-free identity, admittedly. I've name-dropped LoST a couple times
> here as a place to look for inspiration, perhaps.

I read LoST a long time ago, and skimmed it again today, but I don't get any inspiration relative to STIR.  What dots am I supposed to be connecting?
No need for a long explanation, just some hints would be good. :)


> But at the end of the day I was also envisioning that this revisited
> identity system would still work for regular domain names per RFC4474, and
> that we'd probably even keep CID as an option for Identity-Info (or its
> successor). So I was anticipating there'd be diversity in the means by
> which credentials could be indicated by Identity-Info, and that having a
> "root" wouldn't be exclusive in that there are identifiers other than
> telephone numbers in the system too.

Right, so I was thinking about that too, if we were to use a DNS-based approach (or anything with a derived URL).

I think that's still possible even for email-style names.  For example, when receiving a request from '[e-mail]' we could do a DNS lookup for '_cid.foo.com' or some such pre-defined naming scheme, to get the caller-id cert for 'foo.com'; or the RR for that DNS key could redirect us to somewhere else if need be.  Or we could do an HTTP automatically for 'http://foo.com/cid', or even 'http://foo.com/cid/ldkjhlashl' where the last part is a hash of the username.

Or if we want the signer to be able to specify different certs for different requests, we support including a small token that gets appended to the automatic DNS or URL scheme for cert retrieval.  For example up to a 16-character token.  The only reason to limit its size would be to possibly get it (along with the signature and other info) through PSTN links in a UUI or whatever, but if we don't care about that for the email-style name cases then we could continue using the Identity-Info header for that case.  I recognize the nice property of Identity-Info giving the URL was the cert could be hosted somewhere else, separate from the From's domain.


> So again, to the question of how golden the root is, I at least pictured a
> national-level root for telephone number identity that would, if at all
> possible, eliminate the problem of multiple trust anchors issuing
> credentials for the same identity.

Right so I think we're all on the same page for that then. :)


> Just like the same cert could be
> included by CID or referred to by HTTP, though, I imagine there could be
> more than one protocol for getting at those credentials.

I'm ok with specifying multiple protocols for accessing it - I mean that'll probably happen anyway (my company's products support half a dozen different ones to access routing DBs, for example) - but I think there needs to be one that's mandatory-to-implement, to get interoperability.  Even if we believe *only* carriers will be the ones to query for STIR certs, many carriers buy products from multiple vendors they need to interoperate.  Even the ones that buy the SIP-based equipment from only one vendor, often get the databases (or access to a separately managed one) from someone else.


> As for whether or not we need NPAC-style databases - agreed that here we
> don't need most of the data that's in them (like, LRNs aren't obviously
> material to solving our problem), but the authority structures they
> reflect are absolutely integral to this. Ultimately, STIR proposes only to
> project onto the Internet the authority over numbers that is today
> administered in those databases.

Yup.  As I said, it would help a heck of a lot to get this into the NPAC-type databases. :)

-hadriel