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

["Peterson, Jon" <[e-mail]>]

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