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

[Henning Schulzrinne <[e-mail]>]

It might be helpful to explicitly distinguish three models, independent of whether the cert is stored in DNS or some HTTP-accessed data store:

(1) Single CA per country code (CC); no chaining. All delegations and multiple-use are explicitly generated by the CC CA, based on requests by the primary holder of the number.

(2) Single CA per country code, but with chaining.

(3) Lots of CAs per country code, e.g., for proof-of-possession systems. (Example: Existing webCAs get into the E.164 validation business.)

I think we've been commingling the three in discussion, making the trade-offs harder to identify.

On #2 below (expiration), I'm not sure that it matters whether the entry is stored in DNS or data store. With DNS and HTTP, you have to deal with caching just the same.

Also, for DNS, it would be helpful to be specific whether this is run by one entity or, if not, how entries are doled out, given the lack of natural hierarchy.

On Jun 17, 2013, at 3:07 AM, Peterson, Jon wrote:

> 
> I think the advantages below, with the exception of 4, would be true of
> any golden root we created for whatever protocol, be it HTTP or something
> else. I'm sure I could define an HTTP golden root such that the
> verification service could synthesize the proper fetch request from the
> URI in the From with an Identity-Info, one that updated in real time so
> you never needed to worry about revocation, one for which there was only
> one CA, and which you could locally cache (well, okay, 5 does conflict a
> bit with 2). 
> 
> Also, all of the (snipped) concerns you raised about access control,
> middlemen, charging, etc are just as likely to arise for DNS as for any
> other proposal.
> 
> Now that much said, I'm not convinced HTTP is the end-all-be-all for
> Identity-Info. I had high hopes for CID when RFC4474 was written. But more
> seriously, I don't think we should rule out DNS as an access method for
> credentials at this stage. Even if we were just copying public keys out of
> certs from a cert store into the appropriate node of the DNS, and totally
> duplicating effort, if that helped adoption for some use cases it would
> probably be worth it. Maybe some of Henning's "convenience" databases
> could take this form.
> 
> Jon Peterson
> Neustar, Inc.
> 
>> 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
>> 
>> _______________________________________________
>> stir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stir
> 
>