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

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

I think this list has gotten bogged down in the question of how to
download credentials at the verification service. I sense this is
motivated by a feeling that we are going to have a beauty contest and pick
one way to download credentials, and everyone would like it to be their
favorite way.

I don't really look at the STIR problem that way, though. I don't really
care, at the end of the day, how a verification service downloads
credentials. I don't think we even need to arrival a single way of doing
it. The Identity-Info header of RFC4474 gives verification services a hint
of where they could acquire credentials. Nothing about RFC4474 assumes
though that the verification service doesn't already have a public key for
the auth service, or that the verification service doesn't have its own
means of looking up credentials in a store, say (see Step 1 of Section 6
of RFC4474). Dereferencing the Identity-Info is not in that strict sense
required.

Even when there verification service does dereference the URI in
Identity-Info to get a credential, RFC4474 leaves the door pretty wide
open for what protocols can be used: it does specify HTTP as MTI, but this
is not exclusive. We discussed using SIP itself (with a fetch SUB), CID
for multipart MIME and several other options. I can even imagine using a
DNS URI for this, especially for a DANE or DANE-like case where you want
to tip off the verifier that the public key can be found in the DNS.
Again, the presence of a DNS URI in Identity-Info would just be a hint, a
"in case you didn't know, my public key is in a DANE record." Maybe some
verification services wouldn't need that hint as they always check the DNS
for a public key.

So you could argue even that at an over-the-wire level, we wouldn't even
need to change Identity-Info to support using the DNS as a way to access
credentials. What would need to change, of course, is the logic used by
auth/verification services to handle telephone numbers, and for DANE-like
cases, to check reference integrity. This, I think, is where the actual
STIR work should lie. I don't think we should try to legislate a one true
way that services must make credentials available. We should introduce
flexibility here, even if it means perhaps having two MTIs for
Identity-Info URI schemes instead of one. But we shouldn't get caught up
on what protocol you use to fetch credentials.

Jon Peterson
Neustar, Inc.

On 6/19/13 10:23 AM, "Lee, Yiu" <[e-mail]> wrote:

>Can we get the dnskey record and verify it by the ds record and forget the
>whole CA thing?
>
>On 6/19/13 1:12 PM, "Hadriel Kaplan" <[e-mail]> wrote:
>
>>We have can't just look up the DNS domain key of 'foo.com' to get the
>>certificate