From nobody Thu Nov 20 12:31:26 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDDC1ACD49 for ; Thu, 20 Nov 2014 12:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, USER_IN_WHITELIST=-100] 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 LT2MUk8UJJho for ; Thu, 20 Nov 2014 12:31:23 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id B94171AC436 for ; Thu, 20 Nov 2014 12:31:23 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 15FB19A444E for ; Thu, 20 Nov 2014 15:31:13 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id zlIFSoA0kbOV for ; Thu, 20 Nov 2014 15:30:52 -0500 (EST) Received: from [192.168.2.108] (pool-96-255-26-251.washdc.fios.verizon.net [96.255.26.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5E5789A4447 for ; Thu, 20 Nov 2014 15:30:52 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Nov 2014 15:30:41 -0500 Message-Id: <3D659F70-3E6E-448B-8AE5-70BCAA0D67C7@vigilsec.com> To: IETF STIR Mail List Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/IQhKC8eCR57J8f61aK9CGMO0oaA Subject: [stir] Certificate Policy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 20:31:25 -0000 Does the STIR certificate profile need to mandate the use of a single = certificate policy throughout the world? The RPKI uses a single = certificate policy, but the web PKI uses many. I'd like to hear what = people think on this topic. Russ From nobody Thu Nov 20 12:53:44 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4221A6FC4 for ; Thu, 20 Nov 2014 12:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 xcTyk8E-3cIn for ; Thu, 20 Nov 2014 12:53:41 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 8CBE61A6FC7 for ; Thu, 20 Nov 2014 12:53:40 -0800 (PST) Received: (qmail 12207 invoked by uid 0); 20 Nov 2014 20:53:36 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 20 Nov 2014 20:53:36 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id HwtT1p0041MNPNq01wtWKz; Thu, 20 Nov 2014 13:53:36 -0700 X-Authority-Analysis: v=2.1 cv=B+wqjodM c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=7JBLy9WdcIcA:10 a=8nJEP1OIZ-IA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=5y4faFyK3SkA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=tGX7uwomAAAA:8 a=48vgC7mUAAAA:8 a=GKfX5ykNvEQC91-4A1IA:9 a=wPNLvfGTeEIA:10 a=ivbTfD_dPm4A:10 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date; bh=zZFbYQj+CzKXzsjqKXRdrs1O3iGF6Mg1wdGRmgbtEuo=; b=JWR3a/0+yC8RBMMdQOgFwNVcj9Z0MsoxsqWpxG0BVy57uMEg/mLT1jAJfGjgV+gVz4t7P/EAMSqmwywvJloIu+XCOAZZ5z8dW+6aK75ESe0/1ImgNEj90D3U+QrC4ymk; Received: from [108.56.131.201] (port=60276 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XrYjG-0008T4-Mr; Thu, 20 Nov 2014 13:53:26 -0700 User-Agent: Microsoft-MacOutlook/14.4.6.141106 Date: Thu, 20 Nov 2014 15:53:21 -0500 From: Richard Shockey To: Russ Housley , IETF STIR Mail List Message-ID: Thread-Topic: [stir] Certificate Policy References: <3D659F70-3E6E-448B-8AE5-70BCAA0D67C7@vigilsec.com> In-Reply-To: <3D659F70-3E6E-448B-8AE5-70BCAA0D67C7@vigilsec.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/nC82e2883K1z3QJYrcvXmG6K_54 Subject: Re: [stir] Certificate Policy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 20:53:42 -0000 Short answer No. IMHO the policies might be similar with each numbering numbering administration but the ultimate decision is still a national matter. The best we could do would be almost a BCP. =8B=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us Www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 11/20/14, 3:30 PM, "Russ Housley" wrote: >Does the STIR certificate profile need to mandate the use of a single >certificate policy throughout the world? The RPKI uses a single >certificate policy, but the web PKI uses many. I'd like to hear what >people think on this topic. > >Russ > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir From nobody Thu Nov 20 14:31:15 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4591A6F64 for ; Thu, 20 Nov 2014 14:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 9ASMaC2JxZsZ for ; Thu, 20 Nov 2014 14:31:11 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B890B1A88BA for ; Thu, 20 Nov 2014 14:31:08 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.2-0) over TLS secured channel with ESMTP id cab6e645.0.3496529.00-2362.9908860.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 20 Nov 2014 22:31:09 +0000 (UTC) X-MXL-Hash: 546e6bad1f9e53cd-01211c38325da7afae5ec15fa4408030b4aff643 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sAKMV7Kb024090; Thu, 20 Nov 2014 17:31:07 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id sAKMV2ss023578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 20 Nov 2014 17:31:03 -0500 Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (MISOUT7MSGHUBAA.itservices.sbc.com [130.9.129.145]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 20 Nov 2014 22:30:46 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.24]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 17:30:40 -0500 From: "DOLLY, MARTIN C" To: Richard Shockey , Russ Housley , IETF STIR Mail List Thread-Topic: [stir] Certificate Policy Thread-Index: AQHQBQD8wSG6/xyBREKuFT/pvuoX15xqUdmA///GdvA= Date: Thu, 20 Nov 2014 22:30:45 +0000 Message-ID: References: <3D659F70-3E6E-448B-8AE5-70BCAA0D67C7@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.232.65] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=Fq2yCRXq c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=GHISkpOTkwcA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP] X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=5y4faFyK3SkA:10 a=48vgC7mUA] X-AnalysisOut: [AAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=tGX7uwomAAAA:8 a] X-AnalysisOut: [=R1ykoES7hepzqNGmerkA:9 a=CjuIK1q_8ugA:10 a=ivbTfD_dPm4A:1] X-AnalysisOut: [0 a=6fpOX-4qs7AA:10 a=BQYh4w-RC7EA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/stir/rWAVNUekDQUeACnEa-SF2Xhy0p8 Subject: Re: [stir] Certificate Policy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:31:13 -0000 I agree with Mr. Shockey -----Original Message----- From: stir [mailto:stir-bounces@ietf.org] On Behalf Of Richard Shockey Sent: Thursday, November 20, 2014 3:53 PM To: Russ Housley; IETF STIR Mail List Subject: Re: [stir] Certificate Policy Short answer No. IMHO the policies might be similar with each numbering numbering administration but the ultimate decision is still a national matter. The best we could do would be almost a BCP. <=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us Www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 On 11/20/14, 3:30 PM, "Russ Housley" wrote: >Does the STIR certificate profile need to mandate the use of a single >certificate policy throughout the world? The RPKI uses a single >certificate policy, but the web PKI uses many. I'd like to hear what >people think on this topic. > >Russ > >_______________________________________________ >stir mailing list >stir@ietf.org >https://www.ietf.org/mailman/listinfo/stir _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir From nobody Thu Nov 20 16:43:52 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9F41A8A3C for ; Thu, 20 Nov 2014 16:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.229 X-Spam-Level: X-Spam-Status: No, score=-0.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no 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 mnw9VCyihBtQ for ; Thu, 20 Nov 2014 16:43:48 -0800 (PST) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA66D1A87EC for ; Thu, 20 Nov 2014 16:43:48 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id ft15so4108294pdb.32 for ; Thu, 20 Nov 2014 16:43:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=yFJ7piHPJ6JvthoerlW9/j52wU1cTWLrbKftLADQyeI=; b=hjYwW9yuFqMjfBqp2KIrfPCgd7yu8kKBNTyQxK8GpvLjXt16rrQvGmy9rNqqLw3L/u vhRzNH9vxUxPe+vxoz4aiei9Ci9FIguClVelk0NJ2eHar/QDhMciQTOJokmEWx/RGTSd CQQPfcl8Wgv1vZsXSWedqgNfCPR2ozKDNV2W99qtdBXNwygbkbTS23aCazWh4gRXvU/u RGOiwezEfn3VGFew4nFrTORIElfxtX+VazKXS2x1LOfGZivD/NnSH/iJD2ia0Xaqs874 B37roMK+De0OWQWIAxaa/oXLfQex1YBkfKazfUYPl3k3RgJX5fwsxoVp+RuGd3i2HYTA 40Kg== X-Gm-Message-State: ALoCoQnGLn9aAupBequaYvF80bACkxlJjjfkvXx4TjbXub8LEmi8bRBNkFl7gsEeGvXIDu1SSjS5 X-Received: by 10.70.125.164 with SMTP id mr4mr2165128pdb.36.1416530628363; Thu, 20 Nov 2014 16:43:48 -0800 (PST) Received: from [192.168.4.131] (ip-64-134-228-174.public.wayport.net. [64.134.228.174]) by mx.google.com with ESMTPSA id tv4sm3115741pab.28.2014.11.20.16.43.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Nov 2014 16:43:47 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Rosen In-Reply-To: Date: Thu, 20 Nov 2014 13:05:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D659F70-3E6E-448B-8AE5-70BCAA0D67C7@vigilsec.com> To: Richard Shockey X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/stir/xY7Zx3q_3RBpV5mksoGxPWsi9xc Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Certificate Policy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:43:50 -0000 I agree. A BCP would be VERY nice, but I doubt it could be normative > On Nov 20, 2014, at 12:53 PM, Richard Shockey = wrote: >=20 >=20 > Short answer No. IMHO the policies might be similar with each = numbering > numbering administration but the ultimate decision is still a national > matter. >=20 > The best we could do would be almost a BCP. >=20 > =8B=20 > Richard Shockey > Shockey Consulting LLC > Chairman of the Board SIP Forum > www.shockey.us > Www.sipforum.org > richardshockey.us > Skype-Linkedin-Facebook rshockey101 > PSTN +1 703-593-2683 >=20 >=20 >=20 >=20 >=20 > On 11/20/14, 3:30 PM, "Russ Housley" wrote: >=20 >> Does the STIR certificate profile need to mandate the use of a single >> certificate policy throughout the world? The RPKI uses a single >> certificate policy, but the web PKI uses many. I'd like to hear what >> people think on this topic. >>=20 >> Russ >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir >=20 >=20 > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir From nobody Thu Nov 20 18:30:22 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6082D1A8A93 for ; Thu, 20 Nov 2014 18:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 R5a3DJFWAZO4 for ; Thu, 20 Nov 2014 18:30:18 -0800 (PST) Received: from gproxy1-pub.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) by ietfa.amsl.com (Postfix) with SMTP id B59731A8A80 for ; Thu, 20 Nov 2014 18:30:18 -0800 (PST) Received: (qmail 19658 invoked by uid 0); 21 Nov 2014 02:30:17 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 21 Nov 2014 02:30:17 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id J2WA1p00T1MNPNq012WDdU; Thu, 20 Nov 2014 19:30:17 -0700 X-Authority-Analysis: v=2.1 cv=W++rC3mk c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=7JBLy9WdcIcA:10 a=IkcTkHD0fZMA:10 a=8WrITzYgnNwA:10 a=HGEM6zKYvpEA:10 a=5y4faFyK3SkA:10 a=HLLxP2VMAAAA:8 a=JL-7mqT1AAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=tGX7uwomAAAA:8 a=48vgC7mUAAAA:8 a=uHrXvdX1uaZ635IlArMA:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date; bh=dsNK6deckifSFXwIxFE4AMGH3w3/Qo8BPeXgtpNelQw=; b=KvnuxoSu/HGWJHeRFK0hkaPDW3XRzMnutSJJ8QfGhLqvS8t8QIRKbQDSZ+gA1x3IgGhA0UxXOkuKQeowgUm79GQ27/lUb/Ws7lb+8liFgIir4igjoqj+QTTPhXgCayja; Received: from [108.56.131.201] (port=60613 helo=[192.168.1.11]) by box462.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Xrdz8-0003p9-0k; Thu, 20 Nov 2014 19:30:10 -0700 User-Agent: Microsoft-MacOutlook/14.4.6.141106 Date: Thu, 20 Nov 2014 21:30:04 -0500 From: Richard Shockey To: Brian Rosen Message-ID: Thread-Topic: [stir] Certificate Policy References: <3D659F70-3E6E-448B-8AE5-70BCAA0D67C7@vigilsec.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.56.131.201 authed with richard+shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/stir/LSknhsK86W8e85_npbGN_O2aEOE Cc: IETF STIR Mail List , Russ Housley Subject: Re: [stir] Certificate Policy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 02:30:20 -0000 On 11/20/14, 4:05 PM, "Brian Rosen" wrote: >I agree. A BCP would be VERY nice, but I doubt it could be normative Well Well at least the beginning of consensus. The work on CRL needs to start ASAP. The issue is there can be no true root for E.164. Been there done that.=20 Every nation state has some unique policy on how Certificates are managed for Government sanctioned applications. They are not hard to find. Do the G. Beyond the basic STIR protocol issues we (IETF) do have a valuable role in providing guidance to NRA=E2=80=99s on how these things should be implemented. FCC OFCOM CRTC EU etc. http://berec.europa.eu/eng/links The more interesting question is should there be some formal liaison here. Is this something the Internet Society should be involved in at this point or is it too early? This is actually something ISOC is uniquely positioned to deal with. IMHO ISOC should be involved and the sooner the better. Thoughts? >> On Nov 20, 2014, at 12:53 PM, Richard Shockey >>wrote: >>=20 >>=20 >> Short answer No. IMHO the policies might be similar with each numbering >> numbering administration but the ultimate decision is still a national >> matter. >>=20 >> The best we could do would be almost a BCP. >>=20 >> =E2=80=B9=20 >> Richard Shockey >> Shockey Consulting LLC >> Chairman of the Board SIP Forum >> www.shockey.us >> Www.sipforum.org >> richardshockey.us >> Skype-Linkedin-Facebook rshockey101 >> PSTN +1 703-593-2683 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 11/20/14, 3:30 PM, "Russ Housley" wrote: >>=20 >>> Does the STIR certificate profile need to mandate the use of a single >>> certificate policy throughout the world? The RPKI uses a single >>> certificate policy, but the web PKI uses many. I'd like to hear what >>> people think on this topic. >>>=20 >>> Russ >>>=20 >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >>=20 >>=20 >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > From nobody Fri Nov 21 01:51:47 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADB81A014A for ; Fri, 21 Nov 2014 01:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 dJtfI3h6xSRu for ; Fri, 21 Nov 2014 01:51:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9F41A014F for ; Fri, 21 Nov 2014 01:51:37 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 84F4EC02AC; Fri, 21 Nov 2014 10:51:35 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 5EAC715804E; Fri, 21 Nov 2014 10:51:35 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Fri, 21 Nov 2014 10:51:35 +0100 From: To: Russ Housley , IETF STIR Mail List Thread-Topic: RE : [stir] Certificate Policy Thread-Index: AQHQBXC8zML+mJiLtEWpW2PqT1VWmA== Date: Fri, 21 Nov 2014 09:51:34 +0000 Message-ID: <23658_1416563495_546F0B27_23658_4004_1_6wvo8yo1bu3k4yp74scb4wyf.1416563488932@email.android.com> References: <3D659F70-3E6E-448B-8AE5-70BCAA0D67C7@vigilsec.com> In-Reply-To: <3D659F70-3E6E-448B-8AE5-70BCAA0D67C7@vigilsec.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6wvo8yo1bu3k4yp74scb4wyf1416563488932emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.72720 Archived-At: http://mailarchive.ietf.org/arch/msg/stir/yx7nfBJgjXuiBjm2GHA8UNz9x5w Subject: Re: [stir] Certificate Policy X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 09:51:43 -0000 --_000_6wvo8yo1bu3k4yp74scb4wyf1416563488932emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Russ, I do not think the profile needs to mandate a unique certificate policy =E0= la RFC 6484, nor do I think it realistic for it to do so given the variati= ons that exist between national numbering plan management schemes. If, however, the WG identifies elements that must be common to all policies= along the way (or if the technical options would vary depending on these p= olicies) for this work to be truly relevant and progressed as far as possib= le, those elements/options should be captured in some way. But I don't thin= k it should or could be a one-size-fits-all sort of approach (even with opt= ional extensions) Regards, Philippe Fouquart Orange Labs Networks +33 (0) 1 45 29 58 13 -------- Message d'origine -------- De : Russ Housley Date :20/11/2014 21:31 (GMT+01:00) =C0 : IETF STIR Mail List Objet : [stir] Certificate Policy Does the STIR certificate profile need to mandate the use of a single certi= ficate policy throughout the world? The RPKI uses a single certificate pol= icy, but the web PKI uses many. I'd like to hear what people think on this= topic. Russ _______________________________________________ stir mailing list stir@ietf.org https://www.ietf.org/mailman/listinfo/stir ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6wvo8yo1bu3k4yp74scb4wyf1416563488932emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Russ,

I do not think the profile needs to mandate a unique certificate polic= y =E0 la RFC 6484, nor do I think it realistic for it to do so given the va= riations that exist between national numbering plan management schemes.&nbs= p;

If, however, the WG identifies elements that must be common to all pol= icies along the way (or if the technical options would vary depending on th= ese policies) for this work to be truly relevant and progressed as far as p= ossible, those elements/options should be captured in some way. But I don't think it should or could be a = one-size-fits-all sort of approach (even with optional extensions)

Regards,
Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13


-------- Message d'origine --------
De : Russ Housley
Date :20/11/2014 21:31 (GMT+01:00)
=C0 : IETF STIR Mail List
Objet : [stir] Certificate Policy

Does the STIR certificate profile need to mandate = the use of a single certificate policy throughout the world?  The RPKI= uses a single certificate policy, but the web PKI uses many.  I'd lik= e to hear what people think on this topic.

Russ

_______________________________________________
stir mailing list
stir@ietf.org
https://www.ietf.org= /mailman/listinfo/stir
 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6wvo8yo1bu3k4yp74scb4wyf1416563488932emailandroidcom_-- From nobody Tue Nov 25 08:08:22 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CE01AC3A1 for ; Tue, 25 Nov 2014 08:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.99 X-Spam-Level: * X-Spam-Status: No, score=1.99 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 HKOt1nB_kKxA for ; Tue, 25 Nov 2014 08:08:09 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209A71AC3AE for ; Tue, 25 Nov 2014 08:06:23 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAPG6MIs049672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 25 Nov 2014 10:06:22 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <5474A8F9.6040908@nostrum.com> Date: Tue, 25 Nov 2014 10:06:17 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: stir@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/stir/rSu4Hxei9eS_Zs993uXGhbwgt7I Subject: [stir] Minutes: STIR: IETF91 X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 16:08:13 -0000 Please send any necessary corrections to the chairs. The proceeding submission cutoffs are 5-Dec for draft and 26-Dec for corrections. ------------- Minutes : STIR : IETF 91 : 11-Nov-2014 Key Points and Action Items: ITU Liaison Statements: * Richard Barnes will drive creation and review of responses to the two statements from ITU-T SG 17 draft-ietf-stir-rfc4474bis: * Discussion supported the need to speak about multiple fingerprints. The next revision of 4474bis will propose a mechanism * The broad latitude for local policy in canonicalization will be preserved, and reasoning behind leaving this latitude will be explained in the text. * Discussion supported including To: in the canon parameter. * Discussion supported accepting that given the protection of the fingerprint, gatewaying through other protocols (at least those that are not using DTLS-SRTP) is very likely to fail. No additional work will occur in 4474bis around gatewaying other than to ensure this consequence is clearly documented. * Discussion converged on recommending a one-minute threshold for inspecting Date header fields for staleness. * Compliance examples would be useful - Robert Sparks and Cullen Jennings will investigate whether prior work on tools generating 4474 examples can help * While some editorial work is expected in addition to the points above, the draft is essentially complete, and the next version will likely be ready for WGLC. draft-ietf-stir-certificates: * Discussion supported moving forward with a baseline mechanism for retreiving credentials by dereferencing the Identity-Info URI. The mechanic should support credential caching (including invalidation). * Discussion supported exploring an indirection mechanism for determinining what set of numbers a certificate is currently covered by a certificate. The chairs and ADs will discuss how to structure this work. * Discussion of what should be telegraphed through the certificate's subject name was inconclusive and will continue on list. Checkpoint: out-of-band: * It is likely the certificates being defined for the in-band solution will be reusable for out-of-band. Please keep out-of-band in mind as the work progresses. Details (based on notes from Peter Yee): Cullen Jennings says that the Cisco may have some IPR draft-ietf-stir-rfc4474bis. He's working with Cisco legal to make that determination and will let the WG know as soon as possible. ***** ITU Liaison Statements: (Jon Peterson) 2 liaisons received. ITU-T SG 17 (Security) indicates that voice spam may have a solution in draft Recommendation ITU-T X.ticvs. This is done by analyzing SS7 data and blocking calls within the network. There are privacy concerns over the methods used to combat voice spam. A reply to liaison is due by the end of the March. The IETF solution to voice spam is more VOIP focused, so there may be no clash between the two solutions. A volunteer is needed to write the response. The other liaison also from SG 17, but it VoIP oriented (via VoLTE). An IMS-based server hanging off the IMS core would make determinations of whether to pass calls based on their determination of the spaminess of a call. They are interested in hearing from the IETF for feedback and information on what we are doing in this space. This liaison seems more like a request for info than the previous one which seemed more defensive. Keith Drage: Calling out IMS is a red herring. You don't need to know anything about IMS to respond. It's just a centralized server accessed via SIP. Peterson notes that the accompanying picture does show a lot of IMS infrastructure and seems specific to IMS. Drage reiterates that you shouldn't need to know anything about IMS to answer the liaison. The IMS Core doesn't really matter. 3GPP has discussed something similar to the question in the second liaison, but their new study item is more closely related to STIR. Richard Barnes: summary: don't see a lot of conflict, they seem to cover separate domains, STIR's work would cover both cases. Barnes accepted the pen for writing the responses, although he kept the right to pass the pen on to others. ***** RFC4474bis: (Jon Peterson) Jon Peterson: rfc4474bis-02: Work is separated into two buckets: 1) signaling (what is signed, how signing/verification works, canonicalization) and credentials (how signers enroll, how verifiers acquire credentials, how to determine the authority of a credential for a identity). This draft deals with signaling. Since the -01 draft, changes are: 1) added mandatory signature over a=fingerprint; 2) integrated "canon"; 3) split the references; 4) filled in IANA Considerations; 5) added pointers to the STIR problem statement and threats. For 1) generally there isn't a problem with using multiple certificates – it's a corner case. Jennings suggests sorting the fingerprints by value and dropping them in. We need to make sure the case is covered, but more consideration is needed. Is something more beyond media security needed to address baiting attacks? Robert Sparks thinks Peterson's text on the issue is fine. On the "canon" issue: a) Is the latitude for local policy too broad? If it is too broad, it's harder for the far side to successfully generate the value. "canon" is only used with From. Should it cover To? Perhaps not. Example given is that a toll-free number ends up translated to a different destination URL than the number dialed. Since the auth service can munge the To/From headers before signing, text has been added to make this possibility clear. Is there a narrower constraint that can be added to delimit the scope of the further transformations that are applied to the To/From fields and the repercussion of those transformations – how far can transformations be taken before the recipient is unable to recreate the canonical values. There's a real problem with cut-and-pasting of packet headers to spoof calls. Brian Rosen: "canon" is not part of the signature. So you can't use it to determine the origin of the call. Peterson: the recipient canonicalizes the To field and compares it with the To field in "canon". If they match, then it's probably worth processing the call. Otherwise, perhaps not. On the gateway issue, what about tunneling cryptographic signatures across non-SIP protocols. Protocols such as XMPP, SS7 UUI, etc. Rosen (channeling Hadriel Kaplan) a=fingerprint will not work through gateways, so don't bother trying. Other data could work through a gateway and would have meaning to other protocols. Martin Dolly: gatewaying shouldn't be done. With AT&T and Verizon doing VoLTE interop, there's much less call for gatewaying. Peterson will not continue working on gateway for the draft, other than to document (or verify that the existing text documents) that all but the simplest of gateway scenarios will likely cause failures. Path forward: 1) the Date threshold text is inconsistent for what the cut-off is. 1 hour is far too generous. Input is requested on the duration that provides suitable security without requiring ultra precise synchronization. Brian Rosen thinks a minute would be a suitable value. The draft should have a recommendation and explanation of that value, but it shouldn't be a hard requirement because some unusual scenarios might take several sigmas more time than the usual case. The group consensus is that a minute should be fine as the default value when no other value has been determined by the use case. 2) Are compliance examples merited? It seems like they are genuinely useful to get the draft right. 3) The major stuff is in place. Any cruft remaining that should be excised? Any objection to going to WGLC with the next draft? ***** Certificates: (Jon Peterson) Jon Peterson: STIR Certificate Credentials: the draft is now a working group item for a certificate-based STIR credential system. Covers telephone numbers and number ranges with some new attributes. Defines ways to obtain these certificates. But it uses certs differently from X.509 PKIs. Enrollment can be done through 1) direct assignment (from an authority or provider, which is the traditional model), delegation from above (from intermediate holders of numbers), and 3) proof of possession (demonstrated ability to use the number "proves" it's yours; Cullen Jennings will present on this topic later). Do we need to have different levels of assurance for the different enrollment schemes and the resulting credentials? It should be made clear that signing can be done by endpoints or (more likely) intermediaries. Credential verification can be done an intermediary or endpoint as well. Question: how does a verifier find a credential? Given an incoming call, what does the verifier need in order to retrieve a credential from a certificate store? Peterson suggests using the Identity-Info URI to provide the disambiguating information that allows for a certificate retrieval. Sean Turner says a lookup pointer is mandatory. This particular one seems fine. Rosen: I thought this was a hint, not the answer. Peterson: the original 4474 does say this is a hint. Rosen: what about going to the logical authority and asking for all of the certificates assigned to a number. That's not likely to be a large number. Russ Housley: this doesn't work in the delegated certificate issuing model. Rosen: a delegator should cause the certificate to be issued by the logical authority. Housley: it's unlikely that we're going to see a single certificate issuer. Delegated issuance is pretty certain. Rosen: remember, we had the logical authority to prevent long, difficult-to-handle chains of trust. Credential caching is migrating to the credential specification rather than being in the RFC4474bis. Question: should the Identity-Info contain a lightweight credential hash to allow verifiers to know they already have the relevant credential. Jennings: a serial number suffices for this need. Turner: Agreed. That way you don't have to worry about picking among hashing algorithms. Peterson: there are options for how the hash is represented in the URI. Rosen thinks that the URI should change with the certificate. Peterson feels that a single URI with a changing hash attribute would be helpful for cleaning up the cache. Otherwise, stale URIs are cached with no way direct way to find and remove them. For credential acquisition protocols, there are (too) many methods: push/pull/prefetch/others. Do we need a mandatory-to-implement method such as dereferencing the Identity-Info URI? Rosen: I'm leaning that way. We want to document push, make Identity-Info URI mandatory, and have a bulk/go-to-the-source method available as well. Peterson: why isn't there a notification system to alert an entity when a new credential is available? Housley: historical perspective: way back when, LDAP was believed to be on a trajectory to be available ubiquitously as a way to find certificates. Peterson: do we take prefetch off the table? Or do we actually run with it? Jennings: we should talk to the Security Area and ask them for a way to do it. SIP SUBSCRIBE is probably not the right way to do it. Peterson: I could add web push. Turner: I do have an extension to EST that allows for pulling down other certificates. Rosen: I really want to have a simple web service where I supply a phone number and get all the assigned certificates in response. Consensus to go with Identity-Info URI as the MTI. HTTPS will be used for confidentiality, primarily, not integrity. Another open issue: how to handle ranges. STIR certificates can have handle many numbers in it. A major carrier might have a single certificate that can sign for any of their numbers. Delegation might split an authorities range of numbers over multiple sub-authorities. Adam Roach: how is number portability handled? Numbers can be moved to new authorities with ease, but that would lead to constantly changing certificates, especially if a certificate covers a large range. If putting the number or number range in the certificate is problematic, how about putting a pointer (URL) into the certificate that points to the list of numbers. Or perhaps the URL points to a service that can answer whether the number is covered by the certificate. Peterson: please give me input on these ideas. He doesn't feel, given the threat model, that a CA would be unwilling to sign a certificate that points to a non-signed list of numbers. Rosen: if you have a cert, you need to do cert validation, and you could use something like OCSP with extensions to check both the validity of the cert and the validity of the cert for a particular number. Barnes: are lists meant to solve a bloat problem or some other problem. And it would be a good idea to make sure the certificate/number binding validator is actually correlated with the provider. Jennings: the churn on a certificate depends on how many numbers are covered by a certificate. Knowing the optimal number for entries covered by a certificate would be really useful to know in order to reduce churn without having a massive number of small-range certificates. This also seems to point to using the by-reference approach as a solution. Rosen: a simple OCSP extension seems like it would be do the trick with ease. Peterson: I hope this would be palatable to others; I like the idea. Barnes: in the WebPKI, OCSP is not very popular at the moment due to the latency it adds. A new charter item for this scheme seems reasonable. And there are optimizations that can be done to reduce latency. Last issue: should certificates be public or confidential. The subject name is the attribute in question, giving the ability to assemble of list of numbers that are affiliated with which provider. We need feedback from the operator community to know if they care about this issue. Martin Dolly (AT&T): we do see some value in the terminating carrier being able to display a message that says "verified by ". There is some information we would want to protect from our competitors, but it's not a problem. Barnes: from the RPKI, subject names are not meaningful. There's also the PKIX subject information access attribute that can be used as well. Housley: consider the overlap between the RPKI and WHOIS as a useful example. Jennings: I question whether confidentiality is really an issue. ***** Out-of-Band: (Cullen Jennings) (This discussion was pressed for time) Cullen Jennings: trying to revive the out-of-band signaling case. (It was originally agreed to work on the in-band case first). In the out-of-band case, the security data is sent to a CRS (Call Recording Service) while the actual call is cleanly passed over a network that doesn't handle in-band signaling. The receiving entity talks to a proxy that verifies the calling identity via the CRS. There are 3 pieces of work to be done in specifying out-of-band certificate usage: Proof-of-possession enrollment, proof-of-possession acquisition, and out-of-band certificate discovery. Let's pay attention to out-of-band requirements while we are working on in-band certificate support. It's not clear that in-band and out-of-band certificates are the same. They might be. From nobody Tue Nov 25 09:23:10 2014 Return-Path: X-Original-To: stir@ietfa.amsl.com Delivered-To: stir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F8D1ACDD0 for ; Tue, 25 Nov 2014 09:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 zzZo-N_OgpEL for ; Tue, 25 Nov 2014 09:22:53 -0800 (PST) Received: from GB-IP-1.fcc.gov (gb-ip-1.fcc.gov [208.31.254.166]) by ietfa.amsl.com (Postfix) with ESMTP id E010A1ACE40 for ; Tue, 25 Nov 2014 09:21:40 -0800 (PST) From: Henning Schulzrinne To: "stir@ietf.org" Thread-Topic: S-2956: US Senate invokes STIR Thread-Index: AdAI0/2LHGXI/PBzQMCVwg4f6KXyyQ== Date: Tue, 25 Nov 2014 17:21:36 +0000 Message-ID: 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/stir/9w4FCzc_mAhMlRI7mj1Dj5ev-gk Subject: [stir] S-2956: US Senate invokes STIR X-BeenThere: stir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Telephone Identity Revisited List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 17:22:55 -0000 Senator Bill Nelson, D-Fla.=0A= =0A= =93The Phone Scam Prevention Act of 2014 seeks to address this critical iss= ue by directing the [FCC] to develop authentication standards within 5 year= s to ensure caller-ID information is accurate, or warn consumers when such = information cannot be verified.=94 The bill =93provides the impetus to spee= d that process up,=94 directed at the Secure Telephone Identity Revisited W= orking Group, the summary page said. Nelson is expected to lead Democrats o= n the Commerce Committee in the next Congress and currently chairs the Spec= ial Committee on Aging.=0A= =0A= No text yet at=0A= =0A= https://www.congress.gov/bill/113th-congress/senate-bill/2956=0A= =0A= --=0A= =0A= Henning =0A= =0A= =