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

["Lee, Yiu" <[e-mail]>]

I pretty much agree what you said. The Identity-Info field is very
flexible. I guess we need to agree with the problem we tried to solve
first in stir. My gut feeling is we may be able to use rfc4474 plus some
minor twists to get what we want.


On 6/19/13 2:18 PM, "Peterson, Jon" <[e-mail]> wrote:

>
>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
>