Re: [cnit] CNIT Charter bashing..

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

This is more or less how I imagine it could work.

Not to get ahead of a draft I haven't submitted yet, but basically the
revised rfc4474bis text creates an optional Identity-Extension header
which allows future specifications to define a new field or set of fields
that a signature would fall over. The main Identity signature also covers
the contents of Identity-Extension, when it is present. So, if CNIT were
to decide to just use the From display-name, a new Identity-Extension
header signature over the display-name alone could be defined. If CNIT
defines a new header, like hypothetically a CNIT-Name header, then the
contents of the Identity-Extension header field could be a signature over
CNIT-Name. This seemed like the way we could accommodate the broadest set
of design choices for CNIT.

So effectively this mechanism should allow a separate header that binds
the signature over the phone number to the signature in the
Identity-Extension header, which in turn would cover the name. If it turns
out that a hypothetical CNIT-Name header contains its own signature from
the authority attesting for the display name, separate from the rfc4474bis
sig, then either that could be signed via the Identity-Extension header or
not. That also covers cases where the originator of a SIP request isn't
the authority for the number (like, if the request enters the SIP world
through a PSTN gateway).

Jon Peterson
Neustar, Inc.

On 6/29/15, 7:28 PM, "Henning Schulzrinne" <[e-mail]>
wrote:

>I was wondering if it would work to have two STIR headers, with the
>second binding the phone number to the display name (and other SIP
>headers, to prevent replay). Obviously, downstream validating parties
>have to have a reason to trust the signing party, but that always seems
>to be the case when you don't have the number signer as the implied
>originating carrier computing the signature.
>
>________________________________________
>From: Peterson, Jon [[e-mail]]
>Sent: Monday, June 29, 2015 7:47 PM
>To: Richard Shockey; Henning Schulzrinne; Dwight, Timothy M (Tim)
>Cc: [e-mail]
>Subject: Re: [cnit] CNIT Charter bashing..
>
>It's not clear to me that we need any STIR-like mechanisms to be in place
>before embarking on CNIT. What I've basically written in to STIR is an
>extension field that CNIT could use to hook into the signature. All it
>would require is that CNIT create a specification (as currently written, a
>Standards Track RFC) that designates what the field(s) that will be
>signed, and then the necessary procedures and so on.
>
>Fundamentally I agree that hooking CNIT into STIR will only provide part
>of a solution. There are going to be cases when the entity that originates
>(or signs) SIP signaling is not going to be the right party to attest to
>the proper display name for a user.
>
>Architecturally, what I'd probably prefer is to think about this work as
>designing a small, but somewhat extensible block of information which
>someone could sign. Small enough that it could fit in a SIP message, and
>be signed there by hooking into the STIR extension field. But also
>something that could be carried by an external protocol for those cases
>when the STIR signer might not be the authority on the display name. Maybe
>the STIR signer would fetch it via that external protocol, and then pass
>along the signature of the authority from whom they acquired it, in
>addition to signing it themselves. Or maybe the recipient would use the
>external protocol if there is no STIR hook. If we build a system with
>roughly those qualities, and focus more on the info block than on how it
>gets transported necessarily, I think we'll do some valuable work.
>
>Jon Peterson
>Neustar, Inc.
>
>On 6/15/15, 3:32 PM, "Richard Shockey" <[e-mail]> wrote:
>
>>
>>Tim Henning .. This is uniquely timely and important because the SIP
>>Forum
>>is at this moment attempting to revise its SIPConnect Recommendation for
>>PBX / hosted to SSP interface where the data may be originated by the
>>enterprise and it needs to be treated in some way by the NNI. (hopefully
>>maybe not stripped if its seen in the FROM or P-AI)
>>
>>Its a complication but not insurmountable. It clearly shows we need to
>>rethink the charter and look at some baby steps vs demanding that all the
>>STIR like mechanisms be in place before there is progress.
>>
>>
>>
>>‹
>>Richard Shockey
>>Shockey Consulting LLC
>>Chairman of the Board SIP Forum
>>www.shockey.us
>>www.sipforum.org
>>richard<at>shockey.us
>>Skype-Linkedin-Facebook rshockey101
>>PSTN [phone]
>>
>>
>>
>>
>>
>>On 6/15/15, 6:11 PM, "Henning Schulzrinne" <[e-mail]>
>>wrote:
>>
>>>Agreed that the terminating carrier can provide added value, e.g., by
>>>linking to other information. You could imagine mapping numbers to BBB
>>>information, or databases or registered charities, or Yelp... I am
>>>somewhat surprised that this isn't happening already more broadly.
>>>
>>>________________________________________
>>>From: Dwight, Timothy M (Tim) [[e-mail]]
>>>Sent: Sunday, June 14, 2015 1:58 PM
>>>To: Henning Schulzrinne
>>>Cc: [e-mail]
>>>Subject: RE: [cnit] CNIT Charter bashing..
>>>
>>>Henning,
>>>
>>>I'm not sure 'carrier B' would in the "in-band case" have no incentive
>>>to
>>>use a 3rd party service.  It might be that the 3rd party service
>>>provides
>>>additional information and/or is considered more trustworthy than
>>>whoever
>>>provided the in-band information.  We can (and I hope will) change the
>>>incentives.  I think it would be a reasonable objective to carry
>>>whatever
>>>content is deemed "necessary" to serve the public, in-band.  If people
>>>want to operate databases full of calling party's cat pictures, and
>>>Carrier B wants to provide this to their customer (or allow their
>>>customer to obtain it themselves, e.g., provide them a link to it)
>>>that's
>>>all OK with me.
>>>
>>>I agree with you about the importance of being able to know
>>>unambiguously, who inserted the information.
>>>
>>>Tim
>>>
>>>_______________________________________________
>>>cnit mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/cnit
>>
>>
>>_______________________________________________
>>cnit mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/cnit
>