Re: [stir] current draft charter

[Hadriel Kaplan <[e-mail]>]

On Jun 16, 2013, at 12:38 PM, Dave Crocker <[e-mail]> wrote:

> RFC 4474 has been standards track for 7 years; that's a long time.
> 
> What is its level of operational deployment and use, so far?  If the answer is "not much", then it's not clear that automatically invoking its application here is as comforting or facilitative as one might wish…

The answer is less than "not much"... more like "not at all".
I'd argue the reasons it has never been deployed are: (1) people didn't believe there was an identity spoofing problem yet, (2) it only really validates email-style identities such as [e-mail], not E.164 numbers, and (3) it's not deployable due to B2BUAs changing the fields it would sign.



> If I understand the RFC 4474 model correctly, a validated Identity field has the semantics of asserting that the From field is valid.  So the assertion is not limited to the owner of the From field value.  Correct?  While such a model is understandable, it dramatically increases the reputation-management complexity of the task.  I'm not aware of an extant service over the public Internet of similar complexity.
> 
> Better still is that it's the entity making the assertion that tells the verifier where to look for verification information...  What's seems to be missing from the text in RFC 4474 is how the verifier can tell whether the credential is a valid authorization for use of the From field value. (If it wasn't clear before, now you can understand why I'm curious about the concrete details of this authentication service.)

I think the general idea was a DKIM-like model, so if the From field value is '[e-mail]', then you check the cert it points you to is for foo.com and signed by a CA you trust.  That works for email-style names like that, because you can verify it's coming from foo.com, and foo.com is the authority for a '[e-mail]' name. (Assuming all CAs you trust are not compromised of course)

The hard part comes with E.164 numbers, because even if they appear as user@domain strings, like '[e-mail]', most SIP devices would treat it as an E.164 number - and that means it's not scoped to foo.com at all but rather a separate, global namespace that foo.com has no natural authority for.  So with 4474 you'd have to believe foo.com is authoritative for the number based on reputation alone - i.e., you have a local list of domains you trust to claim E.164 numbers.  That would work for a limited number of domain names, for example the domain names of the major carriers within a country, but it would fall apart quickly if we ever want Enterprises to sign, or international scenarios to work.

So one proposal so far is that there would be certs which identify the E.164 numbers they're authoritative for (in a CN/SAN field for example), and that cert would be signed by some CA (or chain leading to one) that you trust.  If it's a chain rather than directly signed by a CA, then it's not clear how one goes about retrieving the certs for the chain's links, and doing so could cause unacceptable delay.  It also means we need revocation checks for the chain.  And I'd argue the management aspects for this thing would be just as difficult as anything else proposed so far.

-hadriel