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

["Wendt, Chris" <[e-mail]>]

+1 
We are very much on-board with the direction of this discussion, DNS lookup is the way we would lean given vendor support for DNS/ENUM vs. HTTP.  I think there is also something to say for keeping a limited scope of DNS as a good thing, vs. the infinite extensibility of HTTP.

Does the current draft charter include this general direction as in scope?


On Jun 18, 2013, at 1:36 PM, Hadriel Kaplan <[e-mail]> wrote:

> 
> 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
> 
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir