Re: [cnit] CNIT Charter bashing..

Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> Fri, 12 June 2015 22:51 UTC

Return-Path: <Henning.Schulzrinne@fcc.gov>
X-Original-To: cnit@ietfa.amsl.com
Delivered-To: cnit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E366F1A1AA2 for <cnit@ietfa.amsl.com>; Fri, 12 Jun 2015 15:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjz-gamxYJ3Y for <cnit@ietfa.amsl.com>; Fri, 12 Jun 2015 15:51:16 -0700 (PDT)
Received: from DC-IP-1.fcc.gov (dc-ip-1.fcc.gov [192.104.54.97]) by ietfa.amsl.com (Postfix) with ESMTP id 87ECD1A1A55 for <cnit@ietf.org>; Fri, 12 Jun 2015 15:51:16 -0700 (PDT)
Message-ID: <E6A16181E5FD2F46B962315BB05962D07D35597A@fcc.gov>
From: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
To: Brian Rosen <br@brianrosen.net>
Thread-Topic: [cnit] CNIT Charter bashing..
Thread-Index: AQHQpF27t1IjTQnD9Ee6If5FuC7/752nvtOAgAAcbYD//73Z54ABUaEAgAA9LQD//8LlU4AARHQAgAAZ6QCAAArCAIAAJydF
Date: Fri, 12 Jun 2015 22:51:15 +0000
References: <D19F23AD.26CEA%richard@shockey.us> <E42CCDDA6722744CB241677169E8365603614617@MISOUT7MSGUSRDB.ITServices.sbc.com> <9588_1434045613_5579CCAD_9588_574_1_fki5dyxdmgyv92b6hugpfuoy.1434045608655@email.android.com> <E6A16181E5FD2F46B962315BB05962D07D354C94@fcc.gov> <9384_1434103912_557AB068_9384_7221_1_B5939C6860701C49AA39C5DA5189448B14C216E0@OPEXCLILM42.corporate.adroot.infra.ftgroup> <D1A05A04.26E84%richard@shockey.us> <E6A16181E5FD2F46B962315BB05962D07D355543@fcc.gov> <557AE9E4.5030205@cs.tcd.ie> <D1A0761F.26EE1%richard@shockey.us>, <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net>
In-Reply-To: <15E9AA29-E9F1-4DA6-ADA4-E201F8F07B7A@brianrosen.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cnit/vGdGN7cB9oNyrD9apa33ywviPkY>
Cc: "philippe.fouquart@orange.com" <philippe.fouquart@orange.com>, "cnit@ietf.org" <cnit@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [cnit] CNIT Charter bashing..
X-BeenThere: cnit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Calling Name Identity Trust discussion list <cnit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cnit>, <mailto:cnit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cnit/>
List-Post: <mailto:cnit@ietf.org>
List-Help: <mailto:cnit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cnit>, <mailto:cnit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2015 22:51:18 -0000

Once numbers have public (STIR) keys, the sender should indeed be able to encrypt the information without creating a new infrastructure for distributing keys, and the destination carrier can decrypt. (I think I'm just amplifying slightly what you are saying, not disagreeing.)

Agreed on "who", although this may be implicit in some cases (e.g., if signed by the number-signing entity).

________________________________________
From: Brian Rosen [br@brianrosen.net]
Sent: Friday, June 12, 2015 12:28 PM
To: Richard Shockey
Cc: Stephen Farrell; Henning Schulzrinne; philippe.fouquart@orange.com; cnit@ietf.org
Subject: Re: [cnit] CNIT Charter bashing..

One possible extra bit is that we need to know WHO signed.  That could be easy (identity in a cert for the signature), but it’s a requirement.

I still want an optional confidence value, because the source is often not authoritative.

If we’re thinking we’re using the existing display name, and coming up with a way to sign it, then, like stir, the termination side can decide what it wants to do if it gets a display name but no signature.  The sender has the option to provide the name or not, and provide the signature or not.

We COULD consider a new header that would contain the name encrypted for a destination TN (To:).  That would afford privacy to the name to middle boxes that we would not have today with display name.  I would not be opposed to that.  This would work like the offline stir proposal, where the sender obtains the public key of the recipient and encrypts the name for the recipient.

Brian