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

[Hadriel Kaplan <[e-mail]>]

On Jun 16, 2013, at 5:39 PM, Henning Schulzrinne <[e-mail]> wrote:

>> I mean ultimately some of us might want to actually implement the signing and verification into our systems.  If it uses public-key signatures, then we need a standardized protocol by which our systems can query for a certificate signed by some authority we trust for a given E.164 number.  If DNS tells us "go look over at FOO": then what standardized protocol does FOO use that we need to implement?
> 
> Wouldn't plain HTTPS do the trick, as in 4474?

Of course that's one possibility - my only point was we can't just make the solution be "have DNS refer to another database"; we have to specify what that referred-to database protocol would be so we can use it.  And if we're going to do that, then just stick that URL in the Identity-Info header and avoid DNS.  One of the advantages of the DNS proposal was the DNS would *be* the database access protocol, and we wouldn't need a URL in the Identity-Info header - we wouldn't even need the header at all.


> * Very small number of entities (1-10ish per country code) sign "public key X is entitled to use TN [range] A". The cert is conveyed in some proprietary fashion to the number holder, similar to how today's web CA's deliver certs to their customers. A single entity can have any number of public keys, if they want to obscure their number holdings or for operational reasons. Working group to-do: Define appropriate X.509 content for numbers.

The "magic" part of that which I was referring to was how a CA would know what entities are entitled to what TNs, and for which various country-codes.  For example, let's assume Thawte is a trusted CA for E.164's for +1 NANP... when some mom&pop "carrier" gets a number ported into them, how does the process work to get Thawte to agree that mom&pop now owns the ported number, and that the previous CA (if it's different) revokes it for its previous carrier?  When mom&pop get a number block, how does Thawte verify that?


> * Small number of "convenience" database providers host certs, including possibly carriers (if they don't care about identifying themselves). The database providers offer scaling and access control. National policy decides what kind of access needs to be granted to whom (fees, non-discrimination, etc.).
> * Certs are retrieved via the HTTPS URL that's included in 4474bis header. Clearly, the entity doing the signing has to know where to find the cert, but as long as the number of entities signing is small, this seems quite manageable.

I'm not so sure.  If we actually use the literal URL to get the cert, then all the HTTPS servers have to be accessible to any querying device of any carrier in the World.  That doesn't scale if "access control" is involved and charging for it.  If we expect some service bureaus act as middlemen for this retrieval instead, to alleviate the headache of billing and access control between all carriers in the world, then we have to create some standard way for the devices in the carriers to talk to the middlemen and give them the URL for each call and get the cert or have the signature verified; and that's assuming that their particular middleman has a relationship with all databases in the World to access the URL, or else they too have to use a protocol to give the URL to another middleman, etc.

Besides which the possible charging models for this thing probably needs to be discussed.  I'm not sure it makes sense for the caller side to charge the called side to verify the caller-id it sent; nor vice-versa.  I'm all for letting each nation decide how to manage their numbers and certs and authority model and so on, but letting each determine fees for every other nation worries me in terms of the viability of getting this to happen.  I'm no expert in that area, but I would think it would be a lot messier to get this stuff done if charging money between nations is involved.  It'd almost be better to make that not possible, and if a nation doesn't want to play along and have its caller-ids verifiable by everyone else then so be it.


> * The validator knows trusted root CAs. Future work: A DANE-like mechanism to list those, e.g., based on prefixes (e.g., +1 might list the number administrator(s) in the US and other +1 countries). As long as the number of CAs for each country code prefix is very small (which seems likely, at least initially), there's no great need to have references for each TN, while still preventing the Nigerian NRA signing +1 numbers.
> It might be interesting to see how much of EPP is applicable here.
> As far as I can tell, assuming 4474bis header mods and the X.509 customs, you could build a system that allows interoperable validation. The only proprietary piece, initially, would be the cert delivery to the number holder.
> Is that a bit less magic?

Almost all of that lends itself to having the certs simply be in the DNS.  There's nothing secret about the certs - they don't need to convey any information about the organization that has the E.164 and signs the SIP message using the private key.  And the organization that has the E.164 and signs doesn't even need a copy of the cert, because they never give it to anyone themselves - they use the private key to sign the SIP message stuff, while the public DNS serves the cert and thus its public key to anyone asking; the only thing they need is a way to give the public key (or pre-signed cert info) to the DNS to be installed there for the E.164 numbers they own.

The advantages of using the DNS as the repository for the cert data, instead of giving an HTTP URL in a header to get a cert from, are:
1) There's no header needed for carrying a URL.
2) There's no need to worry about revocation, because the instant a number changes ownership, the DNS entry of its cert changes.
3) There're far fewer potential CAs to have to trust - ideally only one per country-code, the same one that's authoritative for its country-code branch of the DNS tree; and we'd be using DNSSEC so its cert is in the DNS, and it's the signer of its entries.  In fact you might be able to just have the raw public key in the DNS instead of the whole cert, because the rest of the DNSSEC-provided info is redundant with the stuff in a cert for this use-case.
4) It's generally faster, and with tighter client control for retransmit/timeout because it's UDP.
5) For bigger carriers, they can have local DNS servers with copies of the frequently accessed data (e.g., local nation E.164s) that their verification systems can query.

-hadriel