Re: [stir] draft-peterson-stir-threats-00.txt

["Gorman, Pierce A [NTK]" <[e-mail]>]

In addition to the examples of certifying organizations that Henning provided, there are Barron's, Moody's, Dun & Bradstreet, Equifax, Experion, KPMG, Deloitte-Touche, NYSE, NASDAQ, et cetera.

Do we even need the categories, or do we just need 3rd parties to be expert at vetting the authenticity of an originator?  If it is the latter, I remain unconcerned about the business model aspects.

Pierce

-----Original Message-----
From: Henning Schulzrinne [mailto:[e-mail]]
Sent: November 07, 2013 10:13 AM
To: 'Michael Hammer'; Gorman, Pierce A [NTK]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

Yes, that's a problem, but as long as the number of categories is small, you can build UIs that only render information that's appropriate to the declaration. For practical reasons, I think the number of useful categories is likely going to be fairly limited:

-          Financial institution (FDIC and a few others)

-          Health care (each health care facility has a gov't number)

-          Charity (501c3, state registered)

-          Contractor (state-licensed)

-          Public safety organization (police, fire)

-          Lawyer (bar association)

-          Local, state and federal government (.gov in the US)

I suspect that list encompasses a large fraction of the fraudulent (impersonation) calls. For all of the above, at least within a country, it's pretty clear who can attest to the membership. Yes, this requires some UI work or some server logic, but these categories and the organizations don't change all that often - in most cases, the certifying entities have probably been the same for the past 50+ years. I'm not as worried about figuring out whether the beautician, mortician or florist is licensed and properly identified, although I'm sure we can all come up with potential fraud stories.

From: Michael Hammer [mailto:[e-mail]]
Sent: Thursday, November 07, 2013 10:28 AM
To: Henning Schulzrinne; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [stir] draft-peterson-stir-threats-00.txt

So, would you trust a certificate from the City of Reston, Virginia police department?

(Hint:  you can find Reston on a map, but there is no City of Reston.
  The only police are Fairfax County.)

My concern is that one you dilute or disperse authority, it becomes a free-for-all again, and anybody's guess.

Mike


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Henning Schulzrinne
Sent: Thursday, November 07, 2013 10:00 AM
To: 'Gorman, Pierce A [NTK]'; Brian Rosen; Richard Shockey
Cc: [e-mail]<mailto:[e-mail]> List; Fernando Mousinho (fmousinh); [e-mail]<mailto:[e-mail]>
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

As a thought experiment, Kumiko Ono and I had published a draft

http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00

to allow third parties to validate property information. If the validating party (e.g., a bank regulator) is willing to sign a certificate, similar in spirit to the framed gold-leaf diplomas in your dentist's office or, more lowly, to the health departments rating in a restaurant window, and it can be tied to a phone number, this shouldn't be too hard.

It's a bit harder if the certifying authority (regulator, Realtor board, local bar association, ...) is not involved.

Henning

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Gorman, Pierce A [NTK]
Sent: Thursday, November 07, 2013 9:54 AM
To: Brian Rosen; Richard Shockey
Cc: [e-mail]<mailto:[e-mail]> List; [e-mail]<mailto:[e-mail]>; Fernando Mousinho (fmousinh)
Subject: Re: [cnit] [stir] draft-peterson-stir-threats-00.txt

I'll admit I am not familiar with v/x/jcard encoding differences or the implications of their use so I'll encourage educating me if it isn't too onerous.

I'm not sure what is the concern with a 3rd party providing "validation" though.  There are numerous examples of 3rd parties providing validation of information including NASDAQ, NYSE, Barron's, Moody's, and the federal reserve banking system to name a few.

Pierce

From: Brian Rosen [mailto:[e-mail]]
Sent: November 06, 2013 11:59 PM
To: Richard Shockey
Cc: Fernando Mousinho (fmousinh); Gorman, Pierce A [NTK]; [e-mail]<mailto:[e-mail]> List; [e-mail]<mailto:[e-mail]>
Subject: Re: [stir] draft-peterson-stir-threats-00.txt

I think this would be a heavy lift.

If the responsible entity was a carrier, then it would have to validate the data, which it has very little basis to validate.  It could get a 3rd party to do the validation, but then it's putting its reputation on the back of some hired hand validator.

If the responsibility is the end user/device, then the signature has no value.

I do not argue that Call-Info is suitable,  it is.

I do question JCARD vs xCard, but that's an encoding detail.  All of SIP Is XML described by schema, not json.

Brian

On Nov 6, 2013, at 1:10 PM, Richard Shockey <[e-mail]<mailto:[e-mail]>> wrote:

URI for a JCARD in the CALL INFO header provisioned by the calling party and ultimately signed by the responsible entity.  The carrier could provision this for their mobile or hosted customers.  Enterprises could do this themselves.  This also has advantages in Enterprise to Enterprise UC as well where the data is derived from the Enterprise "directory" and could facilitate end to end PPX to PBX communications especially in point to point video communications.

There are certainly privacy and security issues to be addressed.  The Push vs Pull model.  This really would be PII in the clear but then its done voluntarily.

There would have to be some work around restructuring the Header and adding some parameters but it's underutilized right now and this Use Case is a perfectly appropriate use.

https://tools.ietf.org/html/draft-ietf-jcardcal-jcard-06

Obviously it would need to be signed but we don't need to worry about that ..yet.

________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.