From nobody Sun Aug 2 11:34:21 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C6E3A0AA8 for ; Sun, 2 Aug 2020 11:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 vw9g5QoMADA9 for ; Sun, 2 Aug 2020 11:34:18 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2062.outbound.protection.outlook.com [40.107.236.62]) (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 1A4103A0AA7 for ; Sun, 2 Aug 2020 11:34:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n96ekwU/IsUDS+n8Q6p+AlYeqYvrwFbWa4cAYTLWld/Vd2Kx6S+T/DSLqs0ZcE3fNzInVseR0ZZeVuNpPYyZvJ3tmLVEpXH3d0H4GG1vryIsnGR9UBSMYmoY5tsCgS895ZU7wVHCo0VEYrmNtmjBlM8GIrqLJ/5WPy4e36pF+jAxwHf0//tYKrbHwJMXqSCo2869CBw/p4YvQQQg4tPKt9v3T7T9qN/3YuzUrsqhLzH7Q9skwLQH/Hz97YhOTEYx+kHKa6lUJLL9wm6OGBsBEth6I9PMjtkgKdvG9qVO1ew9SwkeIZxgiF0pNJkQPA89XoM8mU2t9b/pVQp3HmV0HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7e3C1OGW840RIiZmM6T4jpa/RGiS/oehXLyEpIVk3mo=; b=ePDPG0HIh4D2Sh4EVkgB9L60w33++1GyyvF5Eo4whFmmOkUh+pUMSMfp6xraVEz8eHktMAObLcbrLK/ZH+pCTProj1epx2JKPPzEffKtUkFuuRW6QfWvDYo2Ckup81XoC7zzrBT4FdGU8BABA8RiogHde26IeZSfI2Mvt/6xj43OM/F4cTuSsgNyT0wy9+hiGSg6EXaR4G8sXTYzImURNCgcw9D3Kor8tIB7eJwpUyJx+yslJXoitze8i5GOjsul4ubmlbtueviAz2a3sxqNPJMtn3U/VOWNevMM0qhmvLg9otLAXa9YY3KHtwmbVIA/7Zhj5mPGGKMa/R62OHvSHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7e3C1OGW840RIiZmM6T4jpa/RGiS/oehXLyEpIVk3mo=; b=FyPtFjQpOpUPQiRb2LZ4XRzHi3S+nfdraCjqPfhnHrySSx3y5Bs6eHCaXgu/BNgpC+sSgNNFZkiRo2ld4brBroTmf2KAz9NJPI0jCLn/GW2Or0/ypDI+6jiVV8ohbtYebYuklxfS06bfa9LJ5JVGp/xOUNEw3VtHr9k4QNj1y/U= Received: from SN4PR0501CA0066.namprd05.prod.outlook.com (2603:10b6:803:41::43) by BN6PR12MB1731.namprd12.prod.outlook.com (2603:10b6:404:106::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Sun, 2 Aug 2020 18:34:16 +0000 Received: from SN1NAM02FT061.eop-nam02.prod.protection.outlook.com (2603:10b6:803:41:cafe::6d) by SN4PR0501CA0066.outlook.office365.com (2603:10b6:803:41::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.13 via Frontend Transport; Sun, 2 Aug 2020 18:34:16 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT061.mail.protection.outlook.com (10.152.72.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20 via Frontend Transport; Sun, 2 Aug 2020 18:34:15 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 072IYDXm023477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 2 Aug 2020 14:34:14 -0400 To: sipcore@ietf.org References: <87AF4B58-D947-417D-AD26-D2D47EE53338@team.neustar> From: Paul Kyzivat Message-ID: <05017c3b-55e5-c74a-2730-3ba349e14a3d@alum.mit.edu> Date: Sun, 2 Aug 2020 14:34:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <87AF4B58-D947-417D-AD26-D2D47EE53338@team.neustar> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f488cbcf-5bc0-4a54-227c-08d83712a91f X-MS-TrafficTypeDiagnostic: BN6PR12MB1731: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0D7Zq0QqOQlTB8w58zAiQeCEe3jXBCsgiuDbcWiEVtP4/b6x5acGmz90KmDD9hg8cGMAbzPKfgfU+KeBbHKHUZ6RIVsHWcqjGtza8jEqO6+/feIbv3sj93tPaTDOUxiuYdarWl7+U2hzvnrSTcPHHpVwHf/ZUvl8VbcNq5bN66SoUeGsviFp4kTkoGR2cukTav1G+42npuuXxN7QmeOzrTXjGAR7Wa1sG7JFt5HLUZou3JAFOcEgHC3mZNI+KovN7vplPdRYHJjWEv3V1BvPhbgXefywGBF7VOeYEoRM+5J1Zzkvep7GhYYmoupypK9uL51XAvvDrrYHhtpe4AmikhLNB51Vn2afUKiu6udqNJv/oN0YNKdjKS4Uk4aS6ZsSCkVP9kbM2e9cFFFHdyKGINJAsFd7Db31SJs88rqYqMDewujm2YkdDcQkTGWz6lRbcGnAsnjcgmmWt5eq0ANNuYdAervkOQG+zctCIaxGscsh9LM0sIM7N1DWyq7xsaVK X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(136003)(396003)(346002)(376002)(39860400002)(46966005)(31696002)(2616005)(86362001)(47076004)(7596003)(26005)(2906002)(8676002)(70586007)(83380400001)(956004)(336012)(53546011)(6916009)(31686004)(70206006)(75432002)(5660300002)(36906005)(186003)(82310400002)(316002)(8936002)(966005)(356005)(786003)(82740400003)(478600001)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2020 18:34:15.7465 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f488cbcf-5bc0-4a54-227c-08d83712a91f X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT061.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1731 Archived-At: Subject: Re: [sipcore] draft on rich call data and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2020 18:34:20 -0000 On 7/31/20 1:36 PM, Peterson, Jon wrote: > > Hello, > > Chris Wendt and have a draft that has split off from our work toward delivering rich call data (RCD) in the STIR WG. This is for carrying data elements like a caller name, a jCard, call reason, and potentially related elements that will be rendered to the called party to help them decide if they should pick up the phone. We ultimately decided that, instead of doing a one-off for conveying RCD within the PASSporT object, we should instead focus on how that information is best relayed in baseline SIP, and keep the STIR part of the problem confined to signing over those fields as they appear in SIP requests. > > So this draft is the core SIP part: > > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-wendt-sipcore-callinfo-rcd-03__;!!N14HnBHF!qN-QsYPq0MvWk7reTKb984Mry91INiEDfIoc4rQhKA_mMt9ysIG4-Yz2itA0$ > > We'd be interested in the thoughts of the SIPCORE WG about the fundamental approach here, and ultimately if there's interest in adopting this as a WG item here. This seems to be a good start. I question the decision to add the "jCard" purpose. The existing "card" purpose is not bound to any particular representation. It makes perfect sense to use a purpose of "card" with content type of application/vcard+json. Similarly, I think it need do discuss the need for the "call-reason" parameter. As the draft notes, the contents of the Subject header could be used for this purpose. I would like to some some further in investigation of why it is unsuitable before giving up on it. There is a lot of overlap between jCard properties mentioned in section 6 and other sip header fields that are capable of carrying similar information. At the least I think there should be some discussion of how these do/don't interact and how a caller should choose which to use. Thanks, Paul Thanks, Paul From nobody Tue Aug 4 06:58:56 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FAF3A0B9D for ; Tue, 4 Aug 2020 06:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-net.20150623.gappssmtp.com 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 NIC4MmnUq-Dh for ; Tue, 4 Aug 2020 06:58:54 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43E93A0B9C for ; Tue, 4 Aug 2020 06:58:53 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id m7so6276434qki.12 for ; Tue, 04 Aug 2020 06:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ksfjR1Azb0UXKD8WbsTPushpRo/AbrByIrdOQKiSpDQ=; b=PfRqp7XBXl8KkTfIBQYZ4V+bfcr41m7Hv/l0mFgdXxo41HCvijG++wcOCfQspO3Jwb zKz1tMNPkFbJGj9zfru06BfC6cHkHJxQTDPTKXF0QmvIJRIfE+AcnxNTi9NnRtn207c5 dmfwJiTGMgMIlwRLx+41dPqCbeSsJV6rwO0nd2H7twE+x34vk0sjfZ0N/unl/M6UCy+H tqsSg6gEJIRP/tAkBBXdAJW3gwoOQMbklbGR22mq541V5Wxx0dWXnNDQyYaLAbc8qPsq snsu6wXYTTNMebQKnHDWOhLfSTCjSZDmn50joKCqKSDcbKBId8fVAPTfDUnoLqaqahDF XX7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ksfjR1Azb0UXKD8WbsTPushpRo/AbrByIrdOQKiSpDQ=; b=Yudimk+9ZEsDy/jsTHgNEPyLuvHZrhpjx3BuBIXG8jzu4EgVeYdEwOqeUxxYwjRGQ6 3Sikahjp+rFM/XR77IvtDuUAhUBj9nAfNKLHCrFL8hvmlBYIjlYSHpAZ+5fgYzEWS0+X 2Cp8Msh67/ECAMA2zm05Q1okRoGbSu1SjvVQRpt8XgeUrn91TNx+ElrreiU1F4P6cb1l k1u1tY2TOgOgiP9cTgGg0+JP+a2AVWHzyRQHqPMmPz0MosfjtHPB1974MVKZGNWGyAGY 9wn/OM0OPnBY/HNBWvt/4VTZrpVRsOEcFWf2qWJMqU8KcdgQ5LR6Nke0l8xkRsYM8+s0 Raaw== X-Gm-Message-State: AOAM5305ZhZjpJXhY6ESAGaB/cDnpcG5kY/tnmgMoEa1jsIx2kxppH0b FGnQCcShLG+e/NFq+pk5XEggwg== X-Google-Smtp-Source: ABdhPJx+Ra/PjsnDNB1cSakaRgFTgool/wdGWinkFSlHcqHrVY/cPpCyCQJBpYDvbv7NI/IZBZrZMw== X-Received: by 2002:ae9:e00b:: with SMTP id m11mr19641021qkk.341.1596549532673; Tue, 04 Aug 2020 06:58:52 -0700 (PDT) Received: from [10.0.0.125] (c-69-139-1-231.hsd1.pa.comcast.net. [69.139.1.231]) by smtp.gmail.com with ESMTPSA id j15sm20781606qkl.63.2020.08.04.06.58.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2020 06:58:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Chris Wendt In-Reply-To: <05017c3b-55e5-c74a-2730-3ba349e14a3d@alum.mit.edu> Date: Tue, 4 Aug 2020 09:58:50 -0400 Cc: sipcore@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <69350136-0C7A-40F2-B833-9218A6F7DE89@chriswendt.net> References: <87AF4B58-D947-417D-AD26-D2D47EE53338@team.neustar> <05017c3b-55e5-c74a-2730-3ba349e14a3d@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [sipcore] draft on rich call data and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 13:58:55 -0000 > On Aug 2, 2020, at 2:34 PM, Paul Kyzivat = wrote: >=20 > On 7/31/20 1:36 PM, Peterson, Jon wrote: >> Hello, >> Chris Wendt and have a draft that has split off from our work toward = delivering rich call data (RCD) in the STIR WG. This is for carrying = data elements like a caller name, a jCard, call reason, and potentially = related elements that will be rendered to the called party to help them = decide if they should pick up the phone. We ultimately decided that, = instead of doing a one-off for conveying RCD within the PASSporT object, = we should instead focus on how that information is best relayed in = baseline SIP, and keep the STIR part of the problem confined to signing = over those fields as they appear in SIP requests. >> So this draft is the core SIP part: >> = https://urldefense.com/v3/__https://tools.ietf.org/html/draft-wendt-sipcor= e-callinfo-rcd-03__;!!N14HnBHF!qN-QsYPq0MvWk7reTKb984Mry91INiEDfIoc4rQhKA_= mMt9ysIG4-Yz2itA0$ >> We'd be interested in the thoughts of the SIPCORE WG about the = fundamental approach here, and ultimately if there's interest in = adopting this as a WG item here. >=20 > This seems to be a good start. >=20 > I question the decision to add the "jCard" purpose. The existing = "card" purpose is not bound to any particular representation. It makes = perfect sense to use a purpose of "card" with content type of = application/vcard+json. >=20 > Similarly, I think it need do discuss the need for the "call-reason" = parameter. As the draft notes, the contents of the Subject header could = be used for this purpose. I would like to some some further in = investigation of why it is unsuitable before giving up on it. >=20 > There is a lot of overlap between jCard properties mentioned in = section 6 and other sip header fields that are capable of carrying = similar information. At the least I think there should be some = discussion of how these do/don't interact and how a caller should choose = which to use. Valid comments, i guess one perspective is that we may want to have a = more specific =E2=80=98rcd=E2=80=99 approach vs conflicts with existing = usage of other headers/parameters and avoiding the potential confusion = of what is being used for legacy purposes vs what should generally be = signed. But, i guess we sort of backed into this, first building = =E2=80=98rcd=E2=80=99 PASSporT then defining Call-Info. I=E2=80=99d hate to have a complex map of when you can and when you = can=E2=80=99t use jCard fields, i see that as potentially a bit messy, = but curious what others think. -Chris >=20 > Thanks, > Paul >=20 > Thanks, > Paul >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Aug 4 07:21:59 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A49F3A0BCA for ; Tue, 4 Aug 2020 07:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com 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 koQQw73twI6I for ; Tue, 4 Aug 2020 07:21:55 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1623A0BC6 for ; Tue, 4 Aug 2020 07:21:54 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id l17so24102586ilq.13 for ; Tue, 04 Aug 2020 07:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8pTzOsAs/j10lSzBnNVR3DiRB9XS/okjHOC4PHweR44=; b=BagVpiJLRUFiDiynWJ2oK4Zj0HvN1zHK2n3c/PxCMHMwKQWq87jn7tnaQ+qYpZUu5T sBE1nNLORxI+nLAkhnOb9GpdQuoKivulcMy+kYNYbzEx/w0J+jPXGfpfkbzjsrdb2h/M lIsv9U35mF2YwI96NgqZbjAc20WzryPgYC8XfAvn2p6HV2r+zAMh5McoXyWOmBkTdiJZ jRDfOYQpF2QiuJXIldUlLDy3bTeBNkZcKVAc3zH8r63qnPou+Hpnnr7R/jECL/lX9ur6 nnMIXRtNNCK00r8whnjtbWQmBwpCegOogXKIID1E+joqtsJHZJVt0b4yPpUDcUKtljxp Koug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8pTzOsAs/j10lSzBnNVR3DiRB9XS/okjHOC4PHweR44=; b=TA7BQGxv+fz1imlkhHdmyYs7x2WqeSdp6JIpbMxwYxSg78M+gvfwUIlPgAheLH+k1C GC4J2qDXOvIkNsRqtFgLwKGqorjOUIbL0YavOiMkxAQNed/0urXnZBK0Vw3WD2+YrXmT dh9iVrUl+Sum1XytmOBMw3P8NlcGgMaFqQxTe1ZX6AdDbWpm6AOdqPB3vzgjgFK0L9PN VPvJedRalAaTuYDBKohh0B/aQgs3xq8HEpfHLl2JFuortHFqO5M1ANbZsFDyjw5dZs72 bJ3pHNH3s7Q/G6WmUNhfknW9txNQ/qMlbg6um1AVB/fFTkWhKvBERwuKBQZUtSxjiCeE 88Dg== X-Gm-Message-State: AOAM533AuAkfG+RtMgn3Yo6K46AX73LXxnTWOnhTb/kvzerPfdPi1T7W IlE4R8VmN8bZzJLroi+LaV8pmA== X-Google-Smtp-Source: ABdhPJywE9ABk/2DKDoPwzOD3yCAcw6iFxS7HAMo5whNQamFW9Li28FGIu4MNPbenoAFn6GpB03VzA== X-Received: by 2002:a92:330f:: with SMTP id a15mr4755100ilf.158.1596550914124; Tue, 04 Aug 2020 07:21:54 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id k14sm11915552ion.17.2020.08.04.07.21.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2020 07:21:53 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9D7DB6D5-BB84-41AA-A8A8-2E422D6C2B69" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 4 Aug 2020 10:21:51 -0400 In-Reply-To: <69350136-0C7A-40F2-B833-9218A6F7DE89@chriswendt.net> Cc: Paul Kyzivat , sipcore@ietf.org To: Chris Wendt References: <87AF4B58-D947-417D-AD26-D2D47EE53338@team.neustar> <05017c3b-55e5-c74a-2730-3ba349e14a3d@alum.mit.edu> <69350136-0C7A-40F2-B833-9218A6F7DE89@chriswendt.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [sipcore] draft on rich call data and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 14:21:57 -0000 --Apple-Mail=_9D7DB6D5-BB84-41AA-A8A8-2E422D6C2B69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I prefer the JCard fields. Everything together, in a format other = systems can reasonably deal with. Brian > On Aug 4, 2020, at 9:58 AM, Chris Wendt = wrote: >=20 >>=20 >> On Aug 2, 2020, at 2:34 PM, Paul Kyzivat = wrote: >>=20 >> On 7/31/20 1:36 PM, Peterson, Jon wrote: >>> Hello, >>> Chris Wendt and have a draft that has split off from our work toward = delivering rich call data (RCD) in the STIR WG. This is for carrying = data elements like a caller name, a jCard, call reason, and potentially = related elements that will be rendered to the called party to help them = decide if they should pick up the phone. We ultimately decided that, = instead of doing a one-off for conveying RCD within the PASSporT object, = we should instead focus on how that information is best relayed in = baseline SIP, and keep the STIR part of the problem confined to signing = over those fields as they appear in SIP requests. >>> So this draft is the core SIP part: >>> = https://urldefense.com/v3/__https://tools.ietf.org/html/draft-wendt-sipcor= e-callinfo-rcd-03__;!!N14HnBHF!qN-QsYPq0MvWk7reTKb984Mry91INiEDfIoc4rQhKA_= mMt9ysIG4-Yz2itA0$ >>> We'd be interested in the thoughts of the SIPCORE WG about the = fundamental approach here, and ultimately if there's interest in = adopting this as a WG item here. >>=20 >> This seems to be a good start. >>=20 >> I question the decision to add the "jCard" purpose. The existing = "card" purpose is not bound to any particular representation. It makes = perfect sense to use a purpose of "card" with content type of = application/vcard+json. >>=20 >> Similarly, I think it need do discuss the need for the "call-reason" = parameter. As the draft notes, the contents of the Subject header could = be used for this purpose. I would like to some some further in = investigation of why it is unsuitable before giving up on it. >>=20 >> There is a lot of overlap between jCard properties mentioned in = section 6 and other sip header fields that are capable of carrying = similar information. At the least I think there should be some = discussion of how these do/don't interact and how a caller should choose = which to use. >=20 > Valid comments, i guess one perspective is that we may want to have a = more specific =E2=80=98rcd=E2=80=99 approach vs conflicts with existing = usage of other headers/parameters and avoiding the potential confusion = of what is being used for legacy purposes vs what should generally be = signed. But, i guess we sort of backed into this, first building = =E2=80=98rcd=E2=80=99 PASSporT then defining Call-Info. >=20 > I=E2=80=99d hate to have a complex map of when you can and when you = can=E2=80=99t use jCard fields, i see that as potentially a bit messy, = but curious what others think. >=20 > -Chris >=20 >=20 >>=20 >> Thanks, >> Paul >>=20 >> Thanks, >> Paul >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = --Apple-Mail=_9D7DB6D5-BB84-41AA-A8A8-2E422D6C2B69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = prefer the JCard fields.  Everything together, in a format other = systems can reasonably deal with.

Brian

On Aug 4, 2020, at 9:58 AM, = Chris Wendt <chris-ietf@chriswendt.net> wrote:


On Aug 2, 2020, at 2:34 PM, Paul = Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 7/31/20 1:36 PM, Peterson, Jon wrote:
Hello,
Chris= Wendt and have a draft that has split off from our work toward = delivering rich call data (RCD) in the STIR WG. This is for carrying = data elements like a caller name, a jCard, call reason, and potentially = related elements that will be rendered to the called party to help them = decide if they should pick up the phone. We ultimately decided that, = instead of doing a one-off for conveying RCD within the PASSporT object, = we should instead focus on how that information is best relayed in = baseline SIP, and keep the STIR part of the problem confined to signing = over those fields as they appear in SIP requests.
So this = draft is the core SIP part:
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-w= endt-sipcore-callinfo-rcd-03__;!!N14HnBHF!qN-QsYPq0MvWk7reTKb984Mry91INiED= fIoc4rQhKA_mMt9ysIG4-Yz2itA0$
We'd be interested in = the thoughts of the SIPCORE WG about the fundamental approach here, and = ultimately if there's interest in adopting this as a WG item here.

This seems to be a good start.

I question the decision to add the "jCard" = purpose. The existing "card" purpose is not bound to any particular = representation. It makes perfect sense to use a purpose of "card" with = content type of application/vcard+json.

Similarly, I think it need do discuss the need for the = "call-reason" parameter. As the draft notes, the contents of the Subject = header could be used for this purpose. I would like to some some further = in investigation of why it is unsuitable before giving up on it.

There is a lot of overlap between jCard = properties mentioned in section 6 and other sip header fields that are = capable of carrying similar information. At the least I think there = should be some discussion of how these do/don't interact and how a = caller should choose which to use.

Valid comments, i guess one = perspective is that we may want to have a more specific =E2=80=98rcd=E2=80= =99 approach vs conflicts with existing usage of other = headers/parameters and avoiding the potential confusion of what is being = used for legacy purposes vs what should generally be signed.  But, = i guess we sort of backed into this, first building =E2=80=98rcd=E2=80=99 = PASSporT then defining Call-Info.

I=E2=80=99d hate to have a complex map of when you can and = when you can=E2=80=99t use jCard fields, i see that as potentially a bit = messy, but curious what others think.

-Chris



= Thanks,
Paul

= Thanks,
Paul

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_9D7DB6D5-BB84-41AA-A8A8-2E422D6C2B69-- From nobody Wed Aug 5 09:01:27 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095E23A0B95 for ; Wed, 5 Aug 2020 09:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar header.b=AVv+TUZF; dkim=pass (1024-bit key) header.d=neustar.onmicrosoft.com header.b=m/n+6mP5 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 H6vWMwndIqUO for ; Wed, 5 Aug 2020 09:01:24 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 AD35B3A0B4C for ; Wed, 5 Aug 2020 09:01:24 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 075FgKva007956; Wed, 5 Aug 2020 12:01:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=team-neustar; bh=nFV+W/VGK65MGZuvwEcCA+GZF0L5xHZm5s331wIBE/E=; b=AVv+TUZFFPHCTWx2GudAIeOhyAkvvBHmG+xVsz/TqRP59bQC7iOoOvi8vdEEAH3fIYjv 12H/Rui4uibhORZoiw/N18R7TrDR//Q2N9MJHFcaXmH7FDCUR8WwrcI4Gnpwj26Bhq0w QWbtr1DDAvkdE0fKdhnoVlu3swfsOqzELrl5oQ+BvDSt+LjpwL62MnM+ho+zeaM05Vwa RWAsqRbh8mWDYEGRGeL0DUK1edwjPfTg+J3EUIAwVIAmi/Xe0hXblplCe+2NUspW8PfV n+FxYyHzs3UMod/RydGIuXKs7wtJzzMc3Wq3rcqHhiDvp4+z7SjslbMzp7AzOMQNUfHL zw== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2050.outbound.protection.outlook.com [104.47.45.50]) by mx0b-0018ba01.pphosted.com with ESMTP id 32n5u4a8fn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Aug 2020 12:01:19 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l9FpuZD1HeO4p5DnNqcVRE/6d0qdC03rXigxBvS3tDbLvQC9PyDtpsWeV02PZhwRjXt+eEzgvhyiOsaUX83tdQ1z0mObTFV7b585iPXdFjmmP0JxUCQz0LtYXaOd3Zg6Ey43Lzn72IH10G5SxanEXGjqkydzqYJY2/LwAUwm1YJPGQ3afV8JDq+mghJecpnjbBiGz9T0bhS0bVYOCvc8ZvB9bOEfeEk2+SJbjpUq2tlzFTBVAVE/tOCjSP+IwE3QGQUz+DYWDpRBnA0fhvEi5O6kCaxGOhShqgPgTT4muM65OKMSlQuJQRApSZIXUss4YvnYJFdRWW7hJf4o6PtKDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nFV+W/VGK65MGZuvwEcCA+GZF0L5xHZm5s331wIBE/E=; b=Af2fLzCWt40f0hwA7+RM2/KPogpxMQh8GRGsVDQdRSEA4eN4M554/UY37jjtCG9o2ssOsYp13y9yLvqEXoD5TGj9mhk2TdMpQYd9aMSyQTACO1bTYZW8VG1vGC4ixxQeYGfK5sHjGN//MTIjz2aFkPp+XRHRoieF72uN7WQw08pRCXU/SJbzu2puvRfy7xH3e4TlqZSXyj0NhIw0rY8pbAzPLlSUNdxJmjTQjz+fU41fLuAk+rRA+U0hAfevJ1zi/+bJIKxS4HOJZPFFVgJdSy+Kpn9mv4T8tFUV/PJOoThvdAo5d6u4D3TXptB6ZKSCCY2spgeStyE0tQSRegVgEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=team.neustar; dmarc=pass action=none header.from=team.neustar; dkim=pass header.d=team.neustar; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.onmicrosoft.com; s=selector1-neustar-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nFV+W/VGK65MGZuvwEcCA+GZF0L5xHZm5s331wIBE/E=; b=m/n+6mP5xC4wGaBpShVUBrKzwjdb8se9zj1hiy1HMSnonSe6/NrJxzzV7fcvTxxJqc0kXoM7jkvR1kxpQncgaP3cqKBN593rzUyZh9Po73j2lm3zPV1Gi2faDV9ZDRtGEjUutp9GXfgb2Mt3Y7T3GL/GoeoFxRVOzqRaGnZ+v3k= Received: from BY5PR17MB3569.namprd17.prod.outlook.com (2603:10b6:a03:1b9::20) by BY5PR17MB3954.namprd17.prod.outlook.com (2603:10b6:a03:21c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Wed, 5 Aug 2020 16:01:14 +0000 Received: from BY5PR17MB3569.namprd17.prod.outlook.com ([fe80::503b:2ce0:8d8b:6b15]) by BY5PR17MB3569.namprd17.prod.outlook.com ([fe80::503b:2ce0:8d8b:6b15%5]) with mapi id 15.20.3239.022; Wed, 5 Aug 2020 16:01:14 +0000 From: "Peterson, Jon" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] draft on rich call data and Call-Info Thread-Index: AQHWZ2ExQtFvv+YumkmWEeP6FPEu6KklKEeAgAQW5oA= Date: Wed, 5 Aug 2020 16:01:14 +0000 Message-ID: <3A143F2A-2E4D-4B08-8E61-3F32CB3FB9B4@team.neustar> References: <87AF4B58-D947-417D-AD26-D2D47EE53338@team.neustar> <05017c3b-55e5-c74a-2730-3ba349e14a3d@alum.mit.edu> In-Reply-To: <05017c3b-55e5-c74a-2730-3ba349e14a3d@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.17.200615 authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=team.neustar; x-originating-ip: [108.208.24.189] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 25f0b55d-e6a9-43d1-52f0-08d83958c7b4 x-ms-traffictypediagnostic: BY5PR17MB3954: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q/wLh060lBUCXBYlIpp+QDa64zVdTnflcU5amZzRWKdp0ZGUNF4UAVfctj/pi5S4+b2jpuFJyRDNV9A3CokbmEulpOEkkg1zb6pwJwNVDlhbK8BJxlwtlz4YJBlptVmj69eVZiUxKDFIzmsJZblO4TJsBwR40GzKETw26Rh0drUuMiS/BXYNlIAneRglnqs0KSmXnoHFs9wEp2alUFJfhBHdaUtaA9IWrGr+zLLj8ynSEXvuqFZUjszYt5yNsj770ZkTCq0m2vGsrskFeaHLMSI6AkcYiNytJzUwYxpP8Hoh0+K6Cl8DxA3SkXVIyFZvsxoN33IDTm1F2Obh4U7TuMjVLYdiOEyT6byi6fL7QqCMA8mXxRqJ7O5/0I6YGI+h x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR17MB3569.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(346002)(396003)(376002)(136003)(83380400001)(33656002)(2616005)(8676002)(66556008)(71200400001)(66476007)(64756008)(66446008)(8936002)(4744005)(76116006)(2906002)(66946007)(86362001)(186003)(478600001)(5660300002)(110136005)(6486002)(6512007)(6506007)(316002)(26005)(46492007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: MAVoZtDsCGbIrbhCXxaqS9eKanPsqxtOj7Mqg2FVoC3gtXrdW3XwyoMTbYF4pZ/Zb7QWoHRo+sZ/3yzq8p/IFxw0gPYD9mo9UQqZnpH4jFVS93pk9LNk9HHTBHJQpBbOlK34ji1z4CbbbCLv4VEC5/DRcC4Pj4fQJ6lUuYCvQjWwX4gc8RsP1jrT6nz3F1kzhQR5pfXNz44SR2VXq0gbu2O6pyIKx8FAqUJ1OSbTPEg8J9v6l0qm4dBAfrpL07dFtbG/hgq2WYsFNobipyABWILi2TL+DnkoQm+Db7WHiULP/ndeASGsd2IQkBycLNs+aJyM5lmPW7za3GNfOOQPzbL2z9eYlvJKMDReLjPGH3eqgAQaJ8VivZqVicoxNyEMp5KWB5sYdxgwHcKz+uYsPYdCM88dhOv3hjmb9vPthb0HLYBiIj0bxicXIld6oGLh8uIAiyIgB0Z46odumMj9+j0B8h504XlquZ3N2y07fjl+O4j2twqZNv4uteWUf56DSapWGe5XwssNA1qbwrdCFQkTBwE7atjo6k+G/LXg43MpDsZM7fn2Yi3v15xEMJbwx+27h756JxI/UsslAm5vVVbFeQK8bSBVt5K7KbVe7wB37DFry8G1v9FtIeNKCyUaGoeJYeAl5UL4+CeuRFVrcg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: team.neustar X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR17MB3569.namprd17.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 25f0b55d-e6a9-43d1-52f0-08d83958c7b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2020 16:01:14.0965 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 73a2bbc1-f307-47c4-8f94-5f379c68bc30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uuc7eSaoF5ecGCc35IpS1kVVBbw/UI91lEvCgykG4oyWJ0qQmG3vo4NFYLQk4/uJy3CBFl3giFOgYQWXT+SOQI2/kpTJU4vuCXfPa1yO+Og= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR17MB3954 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-05_10:2020-08-03, 2020-08-05 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=859 phishscore=0 priorityscore=1501 spamscore=0 adultscore=0 bulkscore=0 suspectscore=0 lowpriorityscore=0 malwarescore=0 impostorscore=0 mlxscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008050126 Archived-At: Subject: Re: [sipcore] draft on rich call data and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:01:26 -0000 DQpUaGFua3MgZm9yIHRha2luZyBhIGdsYW5jZSBQYXVsLiBKdXN0IHRvIHRoZSBtYXR0ZXIgb2Yg Y2FsbCByZWFzb24gYW5kIFN1YmplY3Q6DQogICAgDQogICAgU2ltaWxhcmx5LCBJIHRoaW5rIGl0 IG5lZWQgZG8gZGlzY3VzcyB0aGUgbmVlZCBmb3IgdGhlICJjYWxsLXJlYXNvbiIgDQogICAgcGFy YW1ldGVyLiBBcyB0aGUgZHJhZnQgbm90ZXMsIHRoZSBjb250ZW50cyBvZiB0aGUgU3ViamVjdCBo ZWFkZXIgY291bGQgDQogICAgYmUgdXNlZCBmb3IgdGhpcyBwdXJwb3NlLiBJIHdvdWxkIGxpa2Ug dG8gc29tZSBzb21lIGZ1cnRoZXIgaW4gDQogICAgaW52ZXN0aWdhdGlvbiBvZiB3aHkgaXQgaXMg dW5zdWl0YWJsZSBiZWZvcmUgZ2l2aW5nIHVwIG9uIGl0Lg0KICAgIA0KQnJvYWRseSBJIGltYWdp bmUgdGhhdCBjYWxsIHJlYXNvbiBtaWdodCBldmVudHVhbGx5IGNhbGwgZm9yIHN0cnVjdHVyZWQg ZGF0YSB0byBoYW5kbGUgY2FzZXMgbGlrZSBpbnRlcm5hdGlvbmFsaXphdGlvbiAoZGlzcGxheSB0 aGUgU3BhbmlzaCB2ZXJzaW9uIGlmIHRoZSBVRSBpbmRpY2F0ZXMgYSBuYXRpdmUgU3BhbmlzaCBz cGVha2VyKSBvciBicm9hZCBjYXRlZ29yaWVzIG9mIHN1YmplY3QgdHlwZXMgKCJhcHBvaW50bWVu dC9yZXNlcnZhdGlvbiBjb25maXJtYXRpb24iIG9yICJJVlIgY2FsbGJhY2siKSB0aGF0IG1pZ2h0 IGJlIGhhbmRsZWQgcHJvZ3JhbW1hdGljYWxseSBpbiBzb21lIHdheS4gSSBndWVzcyBJIGxvb2sg YXQgdGhlIFN1YmplY3QgaGVhZGVyIGFzIHByZXR0eSBzeW50YWN0aWNhbGx5IHBvb3IsIGFuZCBt b3Jlb3ZlciBzb21ldGhpbmcgdGhhdCBsZWdhY3kgaW1wbGVtZW50YXRpb25zIG1pZ2h0IGV4cGVj dCB0byB0cmVhdCBhbHJlYWR5IGluIHNvbWUgdW5oZWxwZnVsIHdheSAobW9zdCBsaWtlbHkgYnkg c3RyaXBwaW5nL2lnbm9yaW5nIGl0KS4gQnV0IEknbSBpbnRlcmVzdGVkIHRvIGhlYXIgd2hhdCBw ZW9wbGUgdGhpbmsgYWJvdXQgdGhpcyBvbmUuDQoNCkpvbiBQZXRlcnNvbg0KTmV1c3RhciwgSW5j Lg0KDQoNCg0K From nobody Wed Aug 5 09:16:48 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A603A0C8E for ; Wed, 5 Aug 2020 09:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 mvbaEjBHvDpP for ; Wed, 5 Aug 2020 09:16:42 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2073.outbound.protection.outlook.com [40.107.243.73]) (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 7E6743A0C89 for ; Wed, 5 Aug 2020 09:16:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZikRBGXbcISKNUbE13r09wVCQK9NUSZyvjjFNm6gOzMhxIxWMtH+6LULR5y4JvPqQUWa+dPybugRXBEBZG/Gzl9CjjlTfKyOfUKOhXhEMxGKZSaJQZJ7WkXRMoiA3rShDk0Xh5zELugJ2RAct78+gJEnjWhlmlv4GO+idHVgYSUS9GN7xpiNyKohJAInG9POUFCzlRA558SH8u7mXR+hsLHBPG2omhp8svbmjS94tnZIHRdXzP0iNeQoE+agKYmN7hvrW4fzdsfT1klJY6O96pDID9dWNKRrxf/0YJ3EHLePGMWgX0kc9E/io9Jt7Dz20/wexV0VQPdZbO6VLv2/qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gro5idTVfKOylyc39NfdovUHC2Mn2jbiKfdHIhNv5e0=; b=UatsJnDP9vuyit/r0lzYqStIQ9+adw9JXn2INVdOclL7SCB9Q3qUiV3vfD+JchjJbhU/isB1dNf/gFy9IE27UHp6ejwWooHCmMq0xI6Ry4c1c86mcX8pInRNyrcwS01Yft7X8G4UUGCk46DGYLIbOWcGIyFnG+7epnhN6Rma6oRjphjQxOAZDrKSpxoiM2IkxUrXMDhAVzqYlQP5JVriZTiM6Wwt7bJr+F+XsV3PBGdKGWJewG33raYNft0leVliYnJl31KEqXBxuNeJwAebLA8VWoYh7hASKrr2SYgv//Y8IuBTDbPJQHyptPB899Uxhhby7mZ6RX0IARrxXdvs4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=team.neustar smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gro5idTVfKOylyc39NfdovUHC2Mn2jbiKfdHIhNv5e0=; b=Sk7A1yN7J/oMKgTyUN6SrCF2qkM50aicTJXUazXec5ggBa+VBNBuFiXqqBnZYC7yWS880Fn9pUjq57cX9WxfZJjuIHmyIlrgJrXv4K+FPCu3ymA3srQ8U3d6B0tAQcYHrP4vjqJFx4sJPfv8jt7O+2+MEm+HV9aNsQKXrqEMLVg= Received: from SN6PR01CA0036.prod.exchangelabs.com (2603:10b6:805:b6::49) by DM6PR12MB4171.namprd12.prod.outlook.com (2603:10b6:5:21f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Wed, 5 Aug 2020 16:16:41 +0000 Received: from SN1NAM02FT052.eop-nam02.prod.protection.outlook.com (2603:10b6:805:b6:cafe::5d) by SN6PR01CA0036.outlook.office365.com (2603:10b6:805:b6::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17 via Frontend Transport; Wed, 5 Aug 2020 16:16:40 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; team.neustar; dkim=none (message not signed) header.d=none;team.neustar; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT052.mail.protection.outlook.com (10.152.72.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17 via Frontend Transport; Wed, 5 Aug 2020 16:16:40 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 075GGbO1027938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Aug 2020 12:16:38 -0400 To: "Peterson, Jon" , "sipcore@ietf.org" References: <87AF4B58-D947-417D-AD26-D2D47EE53338@team.neustar> <05017c3b-55e5-c74a-2730-3ba349e14a3d@alum.mit.edu> <3A143F2A-2E4D-4B08-8E61-3F32CB3FB9B4@team.neustar> From: Paul Kyzivat Message-ID: Date: Wed, 5 Aug 2020 12:16:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <3A143F2A-2E4D-4B08-8E61-3F32CB3FB9B4@team.neustar> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 17e9cd32-5a89-4e57-c01e-08d8395aefc7 X-MS-TrafficTypeDiagnostic: DM6PR12MB4171: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: d6O+3T5Ob54d9kP2f7RGe75DBM+7QP2iDb1qBs1/Xjrni5zfZbad6MdMq63y3ariKGjnIsA87xVYE5bgxcvRvH2hhld0o1/wU/2+AJt0kW5Xn4bckWA2uPIyjS/vjJS8Oap798mIubMrRWPrKkPyE5ViQGFAyp+M4vravn9u6bfDuWr5Gg3Vr/9Q+nqtiEb6fKoAajTCEsIfTyiRZ/fJKVol3wVvaCZTbGuQpPqeCkfqs2eiay9lSc1DTiXjaqnVp3VtemjpZSmt9LBhHyB8cwSJnLeDNLv+sgfA1cPY/jKMRPOEHjpPRnR05MsVR6KKaxgSRABpBcte+bE1e3al6iTiRGJCeYXpMNGJ+1cOWCMIk5Yo2wy/byUKLrtmbDU2ntcfJEOb0Qoub+uUkB+W5ljkRqCcqeCy+WdLzCP2zswbX7Jh22CYEh5F61zXgJxo X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(136003)(346002)(376002)(396003)(39860400002)(46966005)(110136005)(2906002)(336012)(82740400003)(36906005)(316002)(356005)(786003)(5660300002)(82310400002)(47076004)(478600001)(7596003)(956004)(31696002)(26005)(8676002)(70586007)(2616005)(86362001)(8936002)(53546011)(31686004)(83380400001)(70206006)(186003)(75432002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2020 16:16:40.2781 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 17e9cd32-5a89-4e57-c01e-08d8395aefc7 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT052.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4171 Archived-At: Subject: Re: [sipcore] draft on rich call data and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:16:48 -0000 On 8/5/20 12:01 PM, Peterson, Jon wrote: > > Thanks for taking a glance Paul. Just to the matter of call reason and Subject: > > Similarly, I think it need do discuss the need for the "call-reason" > parameter. As the draft notes, the contents of the Subject header could > be used for this purpose. I would like to some some further in > investigation of why it is unsuitable before giving up on it. > > Broadly I imagine that call reason might eventually call for structured data to handle cases like internationalization (display the Spanish version if the UE indicates a native Spanish speaker) or broad categories of subject types ("appointment/reservation confirmation" or "IVR callback") that might be handled programmatically in some way. I guess I look at the Subject header as pretty syntactically poor, and moreover something that legacy implementations might expect to treat already in some unhelpful way (most likely by stripping/ignoring it). But I'm interested to hear what people think about this one. This all makes sense to me. It just needs to make it into the document. Thanks, Paul From nobody Wed Aug 5 09:24:12 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873C83A0CFA for ; Wed, 5 Aug 2020 09:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 RHiKTikMHD7j for ; Wed, 5 Aug 2020 09:24:10 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2067.outbound.protection.outlook.com [40.107.244.67]) (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 DFFE53A0CC1 for ; Wed, 5 Aug 2020 09:23:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jFLNNqDHwf2Gf6lL6VkNI37Y64XQ1mBeVa6SlVl898HZ6LYnMoHpKdlTdEiMCl24201w/RNLTESb8CY153iFVgHk6LXdBGuur/e1PbnELFN4BYLgse61pAzWrgJLbvt6eOUjVcouIaJy3KtARKhoj0hFNACWODfMkuTCtYmeAN3pDQ6KY0+Fn/KZO1ssAkVSdYvKbOVxNRKP0tk6H1E4QeA4U6ajnEx7vCGNGMtno5sIeyR28eYVmCKSgMQ04i7W1WMTYBkIxsJgmz3C3P8FLEg1jcowoX8o6++iwRLtOumaDb3pSMuYgt0wCEYE04Wcb8c2i4pHcR+VKMZ2ijM6ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yU5BR7jAmQUH5eUMRpvedMIO8iqzJzq2WKGHx8M/f0U=; b=Y9IKjGQVraWh9TqrA5MCNPmeDMGBO6IPN9qRVJB8FjALPWXgnbJgBayzMg7wPuLlIZvFkzmLyLDbulnTTccIXV/U95vH7jM5ig2JsHN6my6v1KogiTcFhvuahUEHYcELVGDJHBLwMwcHh078yBUkicht3kDUUTrbUf4eRe0uUovV2CZ69Fc/O6mEnhyJMuG2LBIAPVpvC9kS2Ib6immTyY4vtdj4PvrgjOQiEQdjJUwgSrE/byCqED2ad8UyvLcOVg5fWTOEOMKFRhmanxJ9vKXvqbeir9jVHmjaLX42YicQxky3OmzhQBVW5VhJzEIZADlKwdBlST0ehBRXymxJag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=team.neustar smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yU5BR7jAmQUH5eUMRpvedMIO8iqzJzq2WKGHx8M/f0U=; b=AYczdsE8xrLt13ZcaBoLd/RQvdORR71ftQtMGJ/ZULuNmgVwXoPH/TCemH4d2Di2Lbft6INN/JpqfiB15dfJyCc8Tx0BLFFx4gLSmU75nwMPpzaVaeD7taE3MMUHEFoA0VBhKz0ZR4rNj+hSK+w0A99rhL1RLflOwhl4ZjM3n1M= Received: from MN2PR11CA0016.namprd11.prod.outlook.com (2603:10b6:208:23b::21) by BYAPR12MB3510.namprd12.prod.outlook.com (2603:10b6:a03:13a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Wed, 5 Aug 2020 16:23:34 +0000 Received: from BL2NAM02FT026.eop-nam02.prod.protection.outlook.com (2603:10b6:208:23b:cafe::78) by MN2PR11CA0016.outlook.office365.com (2603:10b6:208:23b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.17 via Frontend Transport; Wed, 5 Aug 2020 16:23:34 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; team.neustar; dkim=none (message not signed) header.d=none;team.neustar; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT026.mail.protection.outlook.com (10.152.77.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20 via Frontend Transport; Wed, 5 Aug 2020 16:23:34 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 075GNWhm028438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Aug 2020 12:23:33 -0400 From: Paul Kyzivat To: "Peterson, Jon" , "sipcore@ietf.org" References: <87AF4B58-D947-417D-AD26-D2D47EE53338@team.neustar> <05017c3b-55e5-c74a-2730-3ba349e14a3d@alum.mit.edu> <3A143F2A-2E4D-4B08-8E61-3F32CB3FB9B4@team.neustar> Message-ID: <778633be-5252-d5e2-3272-af615f41e8a2@alum.mit.edu> Date: Wed, 5 Aug 2020 12:23:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <3A143F2A-2E4D-4B08-8E61-3F32CB3FB9B4@team.neustar> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7bb7975d-d828-4eba-01ad-08d8395be66b X-MS-TrafficTypeDiagnostic: BYAPR12MB3510: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Jiv0i59CBaO4sFYG01FIE+wkDNm2Z7BeRFApvv306Rt9TCLu7Aw1hdQkqPmjBqdhRl/UX28uQOgxsDClXWVbVIk3OdtMhPjjNjq4PseoRjEelbsnfIcdjbeqP6PRyYKctxvKbRO09f8+fNr1FBzziXOl20Qhl1l8hHNIlOwypS/dJLsdgoYiKmq8IzIp4VAqPBtkwEdQ0bJIR8vXrlCHtgm15Ti/2XU88rvwS0wisIU3VZP/U0AFspdmjX+vVEgSHy3J5bOshQWMbwN+fXzDyO9few7VucC/GaWbSsvdWp95riFH4Vl02Wr/XgfoFvbQ3cYSsLc9MxPp+fsvxGp1Mx7skrXbNpRQ83qlnq0mpsQa8T+PfnMDSD+58LWplldFx0UFpdJeqnsKnSFpIPrWmJCcIl2RfM8FfUa1HY1eAX9SoSlB+1BHoqdcv7Y/3wyLTNv1C6sJOhh/WpK+OhRd7jMAHF+MnwyTwnCiGso6c5idFpNSPexLUpa1y5ySNrnX X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(376002)(346002)(136003)(39860400002)(396003)(46966005)(70206006)(70586007)(53546011)(47076004)(956004)(336012)(82740400003)(83380400001)(2616005)(31686004)(356005)(478600001)(86362001)(31696002)(7596003)(82310400002)(966005)(186003)(8936002)(110136005)(36906005)(5660300002)(75432002)(2906002)(8676002)(26005)(316002)(786003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2020 16:23:34.2625 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7bb7975d-d828-4eba-01ad-08d8395be66b X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT026.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB3510 Archived-At: Subject: Re: [sipcore] draft on rich call data and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:24:12 -0000 I had more thoughts after hitting send. So elaborating: On 8/5/20 12:01 PM, Peterson, Jon wrote: > > Thanks for taking a glance Paul. Just to the matter of call reason and Subject: > > Similarly, I think it need do discuss the need for the "call-reason" > parameter. As the draft notes, the contents of the Subject header could > be used for this purpose. I would like to some some further in > investigation of why it is unsuitable before giving up on it. > > Broadly I imagine that call reason might eventually call for structured data to handle cases like internationalization (display the Spanish version if the UE indicates a native Spanish speaker) or broad categories of subject types ("appointment/reservation confirmation" or "IVR callback") that might be handled programmatically in some way. I guess I look at the Subject header as pretty syntactically poor, and moreover something that legacy implementations might expect to treat already in some unhelpful way (most likely by stripping/ignoring it). But I'm interested to hear what people think about this one. This all makes sense to me. It just needs to make it into the document. While it makes sense to me that you might want a syntactically richer call reason than what fits in the Subject header, as defined it isn't any richer - it is still just a string. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Aug 6 06:39:41 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2043A0BC2 for ; Tue, 4 Aug 2020 07:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=jakpTUFV; dkim=pass (1024-bit key) header.d=tmobileusa.onmicrosoft.com header.b=jakpTUFV 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 NefoUCTzEZKD for ; Tue, 4 Aug 2020 07:17:01 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2133.outbound.protection.outlook.com [40.107.92.133]) (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 2A8DA3A0BC0 for ; Tue, 4 Aug 2020 07:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CS+tCCmpIH+EJrpHqA3959YQreDzvEbcIbmswk3koy0=; b=jakpTUFVbncYicT/vgtI5OvPDpu7tWSZrlwQizx+BoxtR0bLh+NWtZ0ineHCdPw9gQm/EsRPdUrboZGepUaVag4VeTFpfKpRW7aL5JubjrY2PztkzTi/AIvgiN7ydAVbLNT6MHtcRobNb1Foo32JHcfah4crpxTUcPsDmWkhFeE= Received: from CY4PR18CA0059.namprd18.prod.outlook.com (2603:10b6:903:13f::21) by CY4PR02MB3269.namprd02.prod.outlook.com (2603:10b6:910:7c::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.21; Tue, 4 Aug 2020 14:16:59 +0000 Received: from CY1NAM02FT022.eop-nam02.prod.protection.outlook.com (2603:10b6:903:13f:cafe::f8) by CY4PR18CA0059.outlook.office365.com (2603:10b6:903:13f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Tue, 4 Aug 2020 14:16:59 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 18.237.140.177) smtp.mailfrom=t-mobile.com; ietf.org; dkim=pass (signature was verified) header.d=TMobileUSA.onmicrosoft.com;ietf.org; dmarc=none action=none header.from=t-mobile.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning t-mobile.com discourages use of 18.237.140.177 as permitted sender) Received: from mail.ds.dlp.protect.symantec.com (18.237.140.177) by CY1NAM02FT022.mail.protection.outlook.com (10.152.75.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17 via Frontend Transport; Tue, 4 Aug 2020 14:16:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=TMobileUSA.onmicrosoft.com; s=selector1-TMobileUSA-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CS+tCCmpIH+EJrpHqA3959YQreDzvEbcIbmswk3koy0=; b=jakpTUFVbncYicT/vgtI5OvPDpu7tWSZrlwQizx+BoxtR0bLh+NWtZ0ineHCdPw9gQm/EsRPdUrboZGepUaVag4VeTFpfKpRW7aL5JubjrY2PztkzTi/AIvgiN7ydAVbLNT6MHtcRobNb1Foo32JHcfah4crpxTUcPsDmWkhFeE= Received: from CY4PR01CA0015.prod.exchangelabs.com (2603:10b6:903:1f::25) by MWHPR02MB2879.namprd02.prod.outlook.com (2603:10b6:300:108::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Tue, 4 Aug 2020 14:16:57 +0000 Received: from CY1NAM02FT003.eop-nam02.prod.protection.outlook.com (2603:10b6:903:1f:cafe::e0) by CY4PR01CA0015.outlook.office365.com (2603:10b6:903:1f::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Tue, 4 Aug 2020 14:16:57 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 208.54.98.100) smtp.mailfrom=t-mobile.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=t-mobile.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning t-mobile.com discourages use of 208.54.98.100 as permitted sender) Received: from webmail.t-mobile.com (208.54.98.100) by CY1NAM02FT003.mail.protection.outlook.com (10.152.74.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3239.17 via Frontend Transport; Tue, 4 Aug 2020 14:16:57 +0000 Received: from PRDTWEXCH003E.gsm1900.org (10.94.33.38) by PRDTWEXCH000B.gsm1900.org (10.94.120.17) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 Aug 2020 07:16:53 -0700 Received: from prdtwexch0057.gsm1900.org (10.139.44.122) by PRDTWEXCH003E.gsm1900.org (10.94.33.38) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 4 Aug 2020 07:16:52 -0700 Received: from plsapdm1.corp.sprint.com (144.230.172.36) by prdtwexch0057.gsm1900.org (10.139.44.122) with Microsoft SMTP Server id 15.1.1913.5; Tue, 4 Aug 2020 07:16:51 -0700 Received: from pps.filterd (plsapdm1.corp.sprint.com [127.0.0.1]) by plsapdm1.corp.sprint.com (8.16.0.42/8.16.0.42) with SMTP id 074E7e5N020294; Tue, 4 Aug 2020 09:16:51 -0500 Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2176.outbound.protection.outlook.com [104.47.56.176]) by plsapdm1.corp.sprint.com with ESMTP id 32n61d0uc4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 04 Aug 2020 09:16:51 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UGVmBWwYN/rUhq9EhlRCPpZ2pOmfHKhnVq9tK7MMOadqcSnTucKxSRyccZLSeJYhpeo1aqECKRTMfw30NKYORGtJ2WR+B/dwTN4aKzUFDgnhKWpyr5DtwTuphJqOu4AFkdvlCX6gmkWHgOUXBdlPBAdYlsrMg7yXucIUIFxbdVbATeTPYBbnQT+KOBkbcDAuNu7h1LEboyorRk1PRXJqP7365g6cI6S1c4AhhuhfTP3yxns//OCND45wAwiDyflSmc3DodsggeAtlO3f0bX7z7PFLBQHlMCy1W7wQfBEgFTpstpadBiLOTPXqS/Gd37phxSxyPh484wRJd8yvbAx8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CS+tCCmpIH+EJrpHqA3959YQreDzvEbcIbmswk3koy0=; b=kvjVeHGlPZbGakzTuyWG1GED9i7N1oA4+kYkl6WFTlPQc05G7VjpEK9ltq7bZSBUpAEf07gSwD6YLUmNTxEsB4abLU9Ncu3eO14BM9h31DpQcK5BfXdcNob1d0nmt1PMK6LkXtdOriZ4shxVDP6wgpFGMHot4ZvsO1/OnnT0/h48TNTtj0y3lfoQLTH1691cPqbGcZ2d9L/atlGuRUB0bc3D1VoSymci8Qj+rlkbA0+dpbKaoSgas8mqGedAwJE4TBVQ+0ECrGTrPhqtuZmVKQCAAZkCSKTNeh5nCg8GyU66e/EnumJJK8Tjfu2wsspiIwrSDBf+EShpP4mi03jJ3g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sprint.com; dmarc=pass action=none header.from=sprint.com; dkim=pass header.d=sprint.com; arc=none Received: from DM5PR05MB3289.namprd05.prod.outlook.com (2603:10b6:4:43::22) by DM6PR05MB4795.namprd05.prod.outlook.com (2603:10b6:5:16::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.15; Tue, 4 Aug 2020 14:16:50 +0000 Received: from DM5PR05MB3289.namprd05.prod.outlook.com ([fe80::44b8:b83f:ca1f:a75a]) by DM5PR05MB3289.namprd05.prod.outlook.com ([fe80::44b8:b83f:ca1f:a75a%6]) with mapi id 15.20.3261.015; Tue, 4 Aug 2020 14:16:50 +0000 From: "Gorman, Pierce A [CTO]" To: Chris Wendt , Paul Kyzivat CC: "sipcore@ietf.org" Thread-Topic: [sipcore] draft on rich call data and Call-Info Thread-Index: AQHWZ2ExQtFvv+YumkmWEeP6FPEu6KklKEeAgALXuQCAAAT2gA== Date: Tue, 4 Aug 2020 14:16:50 +0000 Message-ID: References: <87AF4B58-D947-417D-AD26-D2D47EE53338@team.neustar> <05017c3b-55e5-c74a-2730-3ba349e14a3d@alum.mit.edu> <69350136-0C7A-40F2-B833-9218A6F7DE89@chriswendt.net> In-Reply-To: <69350136-0C7A-40F2-B833-9218A6F7DE89@chriswendt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: chriswendt.net; dkim=none (message not signed) header.d=none;chriswendt.net; dmarc=none action=none header.from=sprint.com; x-originating-ip: [136.32.76.110] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d4363bde-635e-4c41-413d-08d838810cfd x-ms-traffictypediagnostic: DM6PR05MB4795:|MWHPR02MB2879:|CY4PR02MB3269: X-Microsoft-Antispam-PRVS: x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: TbpOasaCcAblaiIpkJp4z8HvGQOr0rjrwAjpHT3k74CxYKz3fzWnL3hD8veqimRjlyTjAWRUIyiLzCZx64E1yTOUgX1LCaUJ0N03Rs1YEI6EQ5VIRnRkwmHo0sUoNZdmEFw9eYZVfdKl0knAxTWJOhbtbYniwkSakt0Axtu845RHQUKDE6AYouzQjWRrFwHZHcGaUtwg4iEvHWxLrT76ZijOIONd+kM2aMSqK7+qxYrWDuuJavSUZb8DLE4pCMpZTBp49glhCSVFghbpbHlHFzrcQzwyfVLuDUFLOUSoZcCJULs2iHMBc/7MPxLRG+Pg4jyiCy9DsExsim3UMtL5YEzeL+9+ixWvZTOGyLuu7Hy8Nl68ibJlTL+IYCGFvxzpAWEjnTMw9XpF1gk527jAbg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR05MB3289.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(366004)(136003)(346002)(396003)(8936002)(26005)(5660300002)(7696005)(2906002)(52536014)(55016002)(71200400001)(478600001)(45080400002)(66446008)(86362001)(6506007)(66556008)(66476007)(4326008)(966005)(83380400001)(76116006)(64756008)(53546011)(9686003)(186003)(316002)(33656002)(110136005)(8676002)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ee5FDR5/6y2iQbqbJOKqszZsIBdXhl4f8hmodRJ4nH+4mP88sV4nwW9E7LsPGJC2iDiXDQCFKu/1vANK+3EDICr95AYQECk/IjDkEVTs8QrRZio34BV7VvG452++kUt4rtc2PdPXr4vTX7YX0OPMLqtwwr6xqgnkOVku+jnu5e9PiJ86zJpIRY7B/8EPX3pcTY7ohL30VGlcHhc1qDgxIi7S/CoNSQpIzQDJ30gLeffcPC/vKh1z+WUZ6Ftr5hxEdXcqYDgyqi7fR69/Oqcym29kGnd3zuCOXvRQ95eqF/HdPBrpKrMmnPLmfLkk9NviXMsRR+GMAN5d+sajOReKokWcpHYYrEDkt6HBOCELscQ5kAdH4g/bkxtgm8qvwm8vZb9Lcwz58O4Qns13BGrRr9JN0OVdwnFmS67X9aUem8wB7k/EX76MW9bn2PhFiSso8cSlRyvLqciulLHPFEkQw9rQBW/MjEWshpVmpNNCTBazeAm/Y722bD+XbGlPuKZhh+LtBagrCEI6S44dLgs+SH3t9UJw31B2VrMzIBOTwz9JYc6D6LF/eBK1WikwwNkaHKiftZxcfzNwpY3NFHtFP3Xws/LmgWrqLbb4eobPeVr/HzR/DQdWBioRnRRIT1MKEbebz9HbJObXl9/tgJdPcg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4795 X-EOPAttributedMessage: 1 X-MS-Exchange-Transport-CrossTenantHeadersStripped: CY1NAM02FT003.eop-nam02.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 8bf9110c-49a4-4c68-00f1-08d838810787 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 8ry/363pbXf/hHFiq8RHMyW+mJzE61eUQXJEa/8N7yXwTO1VtQhiJfV3YvViEzeyWOMHHUsrL+eqEB3It3jGeN75dP9Qs7TgDWQZt0ZlfOTg/572swkBW9XKXGm7RsmIFIC97pw8rqYtiYxBOpBnFna769tv3yGgtjLkIm/IAJgZwTiyn8tOkjc9AG41z5eKZj/OImvDmvWnbICoKafUlFQsj8VfS8I4qPp5ogPckWCjBwb92W0uMwJKBGOZ0oZtgJ+6kplJfJpgashhptbO2XvFpozAS9hKeAJQhWBjfhyBzo1V4SJ6cCnDebwcqsHnUs1JNxNundlCBD1MRVQRgHaPi7VX69Hww0aVbpJtcO78jxPfmqqCykv+pRfmSITyv39vkWANXLfGp5zihKygwKPKYMrsBRdL4rV23MeS3o8DtFa1DcSJrWHu7XCcQhI6+Jk5W2ANxKNpvXKCTSK6m0AEiTXm91cezY9F9xktKbw= X-Forefront-Antispam-Report-Untrusted: CIP:208.54.98.100; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:webmail.t-mobile.com; PTR:InfoDomainNonexistent; CAT:NONE; SFTY:; SFS:(4636009)(376002)(39860400002)(136003)(396003)(346002)(46966005)(82740400003)(356005)(82310400002)(81166007)(7696005)(83380400001)(336012)(47076004)(316002)(8676002)(45080400002)(33656002)(110136005)(4326008)(6506007)(478600001)(26005)(70586007)(8936002)(186003)(9686003)(53546011)(5660300002)(966005)(55016002)(86362001)(52536014)(2906002)(70206006); DIR:OUT; SFP:1102; X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR02MB2879 X-CFilter-Loop: Reflected X-DetectorID-Processed: 8c846453-0f50-46b3-95ab-8bbaf7238615 X-MS-Exchange-Transport-CrossTenantHeadersStripped: CY1NAM02FT022.eop-nam02.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: ad02319e-cb57-42d0-17cc-08d838810bd9 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zhQMRJM6w1oPpLTvl5Q/J/ly5KvA92ZegmhR1Emh1fvmNJv7fUcqIRAgVX4mMZqhsyw6P41QyYxsgk5xcI0uyQ1AsIEDjgddZeL5eosneshjLiDqU+6HzOsQUEqe/nEANLpu23pIXXSx4F003fbOovRQ/NzuHy6KTr5pBULWLIq46EbvBuRfAIhnJwY44d0s+04dv8bzHmaiyHlfdKJJByRcJIcYUOZwPCpUpVb36oPQILliZoZzHNWYcNgg8s9rFm6o31s95kfFLp2YczOJvNGzU8nDULEI8CckLqEuPJWjNNGL6OqrOFzutU0ZW55Xyh3g47m+PAV9U58bODXsx2CAzt7kl16zLC+YvdAiUdHrHeENyJQXGhRZmH2etuhtH992yFy0cC4S+HGb+6YnGiSjirW0Ji59fqV2Iyx7ZPtobobjnYtZAzI5eG3nv/cZk9LgM81guOADUH/D3sJCG4YganJQ7woWQ+t/Ssu3Jhs= X-Forefront-Antispam-Report: CIP:18.237.140.177; CTRY:US; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:mail.ds.dlp.protect.symantec.com; PTR:p01b.mail.dlp.protect.symantec.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(136003)(376002)(346002)(46966005)(52536014)(33656002)(45080400002)(5660300002)(36906005)(86362001)(53546011)(26005)(336012)(110136005)(186003)(83380400001)(70206006)(7696005)(70586007)(6506007)(316002)(82310400002)(4326008)(966005)(478600001)(8676002)(9686003)(55016002)(82740400003)(47076004)(2906002)(8936002)(7636003); DIR:OUT; SFP:1102; X-OriginatorOrg: t-mobile.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2020 14:16:59.0726 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d4363bde-635e-4c41-413d-08d838810cfd X-MS-Exchange-CrossTenant-Id: be0f980b-dd99-4b19-bd7b-bc71a09b026c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=be0f980b-dd99-4b19-bd7b-bc71a09b026c; Ip=[18.237.140.177]; Helo=[mail.ds.dlp.protect.symantec.com] X-MS-Exchange-CrossTenant-AuthSource: CY1NAM02FT022.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR02MB3269 Archived-At: X-Mailman-Approved-At: Thu, 06 Aug 2020 06:39:40 -0700 Subject: Re: [sipcore] draft on rich call data and Call-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2020 14:17:03 -0000 KzENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcGNvcmUgPHNpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIENocmlzIFdlbmR0DQpTZW50OiBUdWVzZGF5 LCBBdWd1c3QgNCwgMjAyMCA4OjU5IEFNDQpUbzogUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVt Lm1pdC5lZHU+DQpDYzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBk cmFmdCBvbiByaWNoIGNhbGwgZGF0YSBhbmQgQ2FsbC1JbmZvDQoNCkNBVVRJT046IFRoaXMgZW1h aWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90IGNs aWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNl bmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KDQoNCj4gT24gQXVnIDIsIDIwMjAs IGF0IDI6MzQgUE0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToN Cj4NCj4gT24gNy8zMS8yMCAxOjM2IFBNLCBQZXRlcnNvbiwgSm9uIHdyb3RlOg0KPj4gSGVsbG8s DQo+PiBDaHJpcyBXZW5kdCBhbmQgaGF2ZSBhIGRyYWZ0IHRoYXQgaGFzIHNwbGl0IG9mZiBmcm9t IG91ciB3b3JrIHRvd2FyZCBkZWxpdmVyaW5nIHJpY2ggY2FsbCBkYXRhIChSQ0QpIGluIHRoZSBT VElSIFdHLiBUaGlzIGlzIGZvciBjYXJyeWluZyBkYXRhIGVsZW1lbnRzIGxpa2UgYSBjYWxsZXIg bmFtZSwgYSBqQ2FyZCwgY2FsbCByZWFzb24sIGFuZCBwb3RlbnRpYWxseSByZWxhdGVkIGVsZW1l bnRzIHRoYXQgd2lsbCBiZSByZW5kZXJlZCB0byB0aGUgY2FsbGVkIHBhcnR5IHRvIGhlbHAgdGhl bSBkZWNpZGUgaWYgdGhleSBzaG91bGQgcGljayB1cCB0aGUgcGhvbmUuIFdlIHVsdGltYXRlbHkg ZGVjaWRlZCB0aGF0LCBpbnN0ZWFkIG9mIGRvaW5nIGEgb25lLW9mZiBmb3IgY29udmV5aW5nIFJD RCB3aXRoaW4gdGhlIFBBU1Nwb3JUIG9iamVjdCwgd2Ugc2hvdWxkIGluc3RlYWQgZm9jdXMgb24g aG93IHRoYXQgaW5mb3JtYXRpb24gaXMgYmVzdCByZWxheWVkIGluIGJhc2VsaW5lIFNJUCwgYW5k IGtlZXAgdGhlIFNUSVIgcGFydCBvZiB0aGUgcHJvYmxlbSBjb25maW5lZCB0byBzaWduaW5nIG92 ZXIgdGhvc2UgZmllbGRzIGFzIHRoZXkgYXBwZWFyIGluIFNJUCByZXF1ZXN0cy4NCj4+IFNvIHRo aXMgZHJhZnQgaXMgdGhlIGNvcmUgU0lQIHBhcnQ6DQo+PiBodHRwczovL25hbTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLmNv bSUyRnYzJTJGX19odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LXdl bmR0LXNpcGNvcmUtY2FsbGluZm8tcmNkLTAzX18lM0IhIU4xNEhuQkhGIXFOLVFzWVBxME12V2s3 cmVUS2I5ODRNcnk5MUlOaUVEZklvYzRyUWhLQV9tTXQ5eXNJRzQtWXoyaXRBMCUyNCZhbXA7ZGF0 YT0wMiU3QzAxJTdDcGllcmNlLmdvcm1hbiU0MHNwcmludC5jb20lN0MyZGUxM2VlMDY3Yzc0ODc0 MTY5OTA4ZDgzODdlOGE5OSU3QzRmOGJjMGFjYmQ3ODRiZjViNTVmMWIzMTMwMWQ5YWRmJTdDMCU3 QzAlN0M2MzczMjE0NjM0NDg3OTIyMDEmYW1wO3NkYXRhPW1wOWJYaGowV3FXbzZqRDF2cEVZVmJj U25GYk5ORHlpYUcxODc5bU1RWWclM0QmYW1wO3Jlc2VydmVkPTANCj4+IFdlJ2QgYmUgaW50ZXJl c3RlZCBpbiB0aGUgdGhvdWdodHMgb2YgdGhlIFNJUENPUkUgV0cgYWJvdXQgdGhlIGZ1bmRhbWVu dGFsIGFwcHJvYWNoIGhlcmUsIGFuZCB1bHRpbWF0ZWx5IGlmIHRoZXJlJ3MgaW50ZXJlc3QgaW4g YWRvcHRpbmcgdGhpcyBhcyBhIFdHIGl0ZW0gaGVyZS4NCj4NCj4gVGhpcyBzZWVtcyB0byBiZSBh IGdvb2Qgc3RhcnQuDQo+DQo+IEkgcXVlc3Rpb24gdGhlIGRlY2lzaW9uIHRvIGFkZCB0aGUgImpD YXJkIiBwdXJwb3NlLiBUaGUgZXhpc3RpbmcgImNhcmQiIHB1cnBvc2UgaXMgbm90IGJvdW5kIHRv IGFueSBwYXJ0aWN1bGFyIHJlcHJlc2VudGF0aW9uLiBJdCBtYWtlcyBwZXJmZWN0IHNlbnNlIHRv IHVzZSBhIHB1cnBvc2Ugb2YgImNhcmQiIHdpdGggY29udGVudCB0eXBlIG9mIGFwcGxpY2F0aW9u L3ZjYXJkK2pzb24uDQo+DQo+IFNpbWlsYXJseSwgSSB0aGluayBpdCBuZWVkIGRvIGRpc2N1c3Mg dGhlIG5lZWQgZm9yIHRoZSAiY2FsbC1yZWFzb24iIHBhcmFtZXRlci4gQXMgdGhlIGRyYWZ0IG5v dGVzLCB0aGUgY29udGVudHMgb2YgdGhlIFN1YmplY3QgaGVhZGVyIGNvdWxkIGJlIHVzZWQgZm9y IHRoaXMgcHVycG9zZS4gSSB3b3VsZCBsaWtlIHRvIHNvbWUgc29tZSBmdXJ0aGVyIGluIGludmVz dGlnYXRpb24gb2Ygd2h5IGl0IGlzIHVuc3VpdGFibGUgYmVmb3JlIGdpdmluZyB1cCBvbiBpdC4N Cj4NCj4gVGhlcmUgaXMgYSBsb3Qgb2Ygb3ZlcmxhcCBiZXR3ZWVuIGpDYXJkIHByb3BlcnRpZXMg bWVudGlvbmVkIGluIHNlY3Rpb24gNiBhbmQgb3RoZXIgc2lwIGhlYWRlciBmaWVsZHMgdGhhdCBh cmUgY2FwYWJsZSBvZiBjYXJyeWluZyBzaW1pbGFyIGluZm9ybWF0aW9uLiBBdCB0aGUgbGVhc3Qg SSB0aGluayB0aGVyZSBzaG91bGQgYmUgc29tZSBkaXNjdXNzaW9uIG9mIGhvdyB0aGVzZSBkby9k b24ndCBpbnRlcmFjdCBhbmQgaG93IGEgY2FsbGVyIHNob3VsZCBjaG9vc2Ugd2hpY2ggdG8gdXNl Lg0KDQpWYWxpZCBjb21tZW50cywgaSBndWVzcyBvbmUgcGVyc3BlY3RpdmUgaXMgdGhhdCB3ZSBt YXkgd2FudCB0byBoYXZlIGEgbW9yZSBzcGVjaWZpYyDigJhyY2TigJkgYXBwcm9hY2ggdnMgY29u ZmxpY3RzIHdpdGggZXhpc3RpbmcgdXNhZ2Ugb2Ygb3RoZXIgaGVhZGVycy9wYXJhbWV0ZXJzIGFu ZCBhdm9pZGluZyB0aGUgcG90ZW50aWFsIGNvbmZ1c2lvbiBvZiB3aGF0IGlzIGJlaW5nIHVzZWQg Zm9yIGxlZ2FjeSBwdXJwb3NlcyB2cyB3aGF0IHNob3VsZCBnZW5lcmFsbHkgYmUgc2lnbmVkLiAg QnV0LCBpIGd1ZXNzIHdlIHNvcnQgb2YgYmFja2VkIGludG8gdGhpcywgZmlyc3QgYnVpbGRpbmcg 4oCYcmNk4oCZIFBBU1Nwb3JUIHRoZW4gZGVmaW5pbmcgQ2FsbC1JbmZvLg0KDQpJ4oCZZCBoYXRl IHRvIGhhdmUgYSBjb21wbGV4IG1hcCBvZiB3aGVuIHlvdSBjYW4gYW5kIHdoZW4geW91IGNhbuKA mXQgdXNlIGpDYXJkIGZpZWxkcywgaSBzZWUgdGhhdCBhcyBwb3RlbnRpYWxseSBhIGJpdCBtZXNz eSwgYnV0IGN1cmlvdXMgd2hhdCBvdGhlcnMgdGhpbmsuDQoNCi1DaHJpcw0KDQoNCj4NCj4gICAg ICAgVGhhbmtzLA0KPiAgICAgICBQYXVsDQo+DQo+ICAgICAgIFRoYW5rcywNCj4gICAgICAgUGF1 bA0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vbmFt MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3 dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNpcGNvcmUmYW1wO2RhdGE9MDIlN0Mw MSU3Q3BpZXJjZS5nb3JtYW4lNDBzcHJpbnQuY29tJTdDMmRlMTNlZTA2N2M3NDg3NDE2OTkwOGQ4 Mzg3ZThhOTklN0M0ZjhiYzBhY2JkNzg0YmY1YjU1ZjFiMzEzMDFkOWFkZiU3QzAlN0MwJTdDNjM3 MzIxNDYzNDQ4NzkyMjAxJmFtcDtzZGF0YT1GUm1oUWFVcE9uanV6VFE1eGMxWW1RRzczajNnWkNH biUyQlZKVHlia2ZvUGclM0QmYW1wO3Jlc2VydmVkPTANCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3Jl QGlldGYub3JnDQpodHRwczovL25hbTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZz aXBjb3JlJmFtcDtkYXRhPTAyJTdDMDElN0NwaWVyY2UuZ29ybWFuJTQwc3ByaW50LmNvbSU3QzJk ZTEzZWUwNjdjNzQ4NzQxNjk5MDhkODM4N2U4YTk5JTdDNGY4YmMwYWNiZDc4NGJmNWI1NWYxYjMx MzAxZDlhZGYlN0MwJTdDMCU3QzYzNzMyMTQ2MzQ0ODc5MjIwMSZhbXA7c2RhdGE9RlJtaFFhVXBP bmp1elRRNXhjMVltUUc3M2ozZ1pDR24lMkJWSlR5Ymtmb1BnJTNEJmFtcDtyZXNlcnZlZD0wDQo= From leonid.fainshtein@xorcom.com Thu Aug 6 05:55:50 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7601D3A0B0D for ; Thu, 6 Aug 2020 05:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=xorcom-com.20150623.gappssmtp.com 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 P3COb2LfSTou for ; Thu, 6 Aug 2020 05:55:49 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36CD63A0B0C for ; Thu, 6 Aug 2020 05:55:49 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id c19so6518860wmd.1 for ; Thu, 06 Aug 2020 05:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xorcom-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JR5tNmJSaVemE86YPiVKXrQmefiloIsiLoz/LLzs6E4=; b=C5PgbL6MaXnsUStFQv+qgf6v29Zx9iIi0aVPxt6U00nAIt9wX6soRTQcMG7B6OQzl9 es6z7wSrtESAfQB3LTUS6wjwBkKefLrpmb99gWh8pt6elRESnvwBFnbIzrSJAyrOgxmi RzAWYPN2xkJMOKPGO/3Tgd1eAaUBDwioQzMElyEPBlsX7pGMgfcdl9oZMF5izvtiM63D bJDlh1nTPMXJjrffrHunxlK3Q8N+jiaoB0xcWvKjW++mrzPJoYmn6PDa52Dqbb+iBYsN W8aUqetbpxpKBVJtpX5nNmIzpD907jhTxxdf4jX0ErevRI1NuWLg4SE/PvslxohzGBl/ BTYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JR5tNmJSaVemE86YPiVKXrQmefiloIsiLoz/LLzs6E4=; b=UumnzTiMFwDYselacS6CZbTL0beImloC1DpXPEEMdsl7K+bDIDNWeB4ZV6V+sXM4Ft jAzMz09FjWWtwB1Qa8fgSq21PJ2kXIUnFEVizF41dFWYUOE2ZlEU+EpPqPX6EthJkVc0 7k9Qmq0OREhAblcvqn8rpfvHM3id+mrX1eDjGgRI6clCNLab6d5WGBf8qMal6PvLQAfO eEXlVhOBH4jpjsb/71/H84RiQCuDTnJRHL3kKm07oq5M+Xxe6MuENJoTiT2f2GJjrbrk FL9/0ynTsfXzc8hjGTY/tg13HNCgdBpeL5w8Zt8cfQPeCIhAmGFEDSK79RrZ8V1zYIbR 6yow== X-Gm-Message-State: AOAM532uO831Ur4Y+afys2tMarBxpRyBC7Dys6lzgrvumLMYKrO5UNRT BbXol3UVeXGx/AFyZq7i7z+G6j4dVn5qGVfxEyRZ8nxV/w/7Rw== X-Google-Smtp-Source: ABdhPJzfcry+JthPmkggpUdaV+H3QuRBvCgbMcOwRTsdLATcNywZu2XxfRDQRlG356Y7WLuhaPgkrhoTNcSgZPvPtbw= X-Received: by 2002:a1c:6106:: with SMTP id v6mr7803914wmb.178.1596718547479; Thu, 06 Aug 2020 05:55:47 -0700 (PDT) MIME-Version: 1.0 From: Leonid Fainshtein Date: Thu, 6 Aug 2020 15:55:36 +0300 Message-ID: To: sipcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000d4581605ac3501cf" Archived-At: X-Mailman-Approved-At: Thu, 06 Aug 2020 06:39:40 -0700 Subject: [sipcore] Enabling the wildcard certificates for SIP TLS implementation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 12:57:09 -0000 --000000000000d4581605ac3501cf Content-Type: text/plain; charset="UTF-8" Hi, The "7.2. Comparing SIP Identities" of RFC-5922 prohibits the usage of wildcard certificates. The reasons for this limitation are not clear. The restriction only complicates the multi-home SIP servers configuration and maintenance. I suggest enabling the wildcard certificates for SIP. Best regards, Leonid Fainshtein Xorcom Ltd --000000000000d4581605ac3501cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
The "7.2.=C2=A0 Comparing SIP Identiti= es" of RFC-5922 prohibits=C2=A0the usage of wildcard certificates.
The reasons for this limitation are not clear. The restriction only co= mplicates the multi-home SIP servers configuration and maintenance.=C2=A0
I suggest enabling the wildcard certificates for SIP.

Best regards,
Leonid Fainshtein
Xorcom Ltd
--000000000000d4581605ac3501cf-- From nobody Mon Aug 10 01:03:25 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F107F3A0D01 for ; Mon, 10 Aug 2020 01:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jMVclhTk0rl2 for ; Mon, 10 Aug 2020 01:03:21 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 5D7273A0841 for ; Mon, 10 Aug 2020 01:03:20 -0700 (PDT) Received: from macbook-pro.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 09DAC2172; Mon, 10 Aug 2020 10:03:17 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <5BFABAC0-BCF4-4282-A457-F41BD3D142F2@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_1DC88490-94AD-4444-9DC1-D5A8C6BB28DE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 10 Aug 2020 10:03:16 +0200 In-Reply-To: Cc: Olle E Johansson , sipcore@ietf.org To: Leonid Fainshtein References: X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [sipcore] Enabling the wildcard certificates for SIP TLS implementation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 08:03:24 -0000 --Apple-Mail=_1DC88490-94AD-4444-9DC1-D5A8C6BB28DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 Aug 2020, at 14:55, Leonid Fainshtein = wrote: >=20 > Hi, > The "7.2. Comparing SIP Identities" of RFC-5922 prohibits the usage = of wildcard certificates. > The reasons for this limitation are not clear. The restriction only = complicates the multi-home SIP servers configuration and maintenance.=20 > I suggest enabling the wildcard certificates for SIP. With wide-spread support for TLS SNI and free services like Letsencrypt = I don=E2=80=99t really see a problem with not supporting wildcards. On the other side, I do agree that the argumentation for this limitation = is missing. I remember there was a widespread discussion over multiple working groups about problems with wildcards. Let=E2=80=99s = see if we can dig up something from other RFCs or if someone has a clear argument. /O --Apple-Mail=_1DC88490-94AD-4444-9DC1-D5A8C6BB28DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 6 Aug 2020, at 14:55, Leonid Fainshtein <leonid.fainshtein@xorcom.com> wrote:

Hi,
The "7.2.  = Comparing SIP Identities" of RFC-5922 prohibits the usage of = wildcard certificates.
The reasons for this = limitation are not clear. The restriction only complicates the = multi-home SIP servers configuration and maintenance. 
I= suggest enabling the wildcard certificates for = SIP.

With = wide-spread support for TLS SNI and free services like Letsencrypt I = don=E2=80=99t really see a problem with not supporting = wildcards.

On the other side, I do = agree that the argumentation for this limitation is missing. I remember = there was a widespread discussion
over multiple working groups = about problems with wildcards. Let=E2=80=99s see if we can dig up = something from other RFCs or if someone
has a clear = argument.

/O

= --Apple-Mail=_1DC88490-94AD-4444-9DC1-D5A8C6BB28DE-- From nobody Mon Aug 10 05:51:33 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFB23A1555 for ; Mon, 10 Aug 2020 05:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ccivDXsBsoNq for ; Mon, 10 Aug 2020 05:51:19 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3068B3A155D for ; Mon, 10 Aug 2020 05:51:19 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id k12so7168223otr.1 for ; Mon, 10 Aug 2020 05:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KmacGF6BZc2KhXnar87J4c4OFeojx26oiAFL66mX++Y=; b=p2M9/MJ5EWShqmJjH+15EZWe5MHQ+JgHFuDGobKkEW8vQ7JsJdQshR8Kkm3YkQ8/R1 GrGavJxgdtvmg0q1PfGUe4fuApaUovKzXgGkiurRdNjtMzQR3NbJE8kyPN1/2vooxumM es7/n6HDTP1glU+DAgqPVIBGNcpIwDyH0I/QF+YC496jjOm/PaMA3v+hfgjNmqOlLTyh 19dZ09hIwNvIILswQVItskwQ1+BLXEKQpTR+/WuZL7QE/evpz6PFmXRGlUGxX+lxFauJ Efcnh/9ghqmhoFOrhu/+s7G6gHaustlkA99tsVnVSnCHhsnCgaZn8Mws26TzjtYkmWEr 4RSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KmacGF6BZc2KhXnar87J4c4OFeojx26oiAFL66mX++Y=; b=G+YWVxVSBSv6NyVxEjY1E5RsLQDmNaj/FFTlQUg5+f3Iy/etC0uJKijTCx9da+diwl +87pQCNGZ78h/VIfRIwIMnjARPcyK5ITJ0m3d7OHN58okE621Hxy5PxCMazm74YR/3ub Ob1p/FFT1sHMkurTHDKx2AoG4WiQBXEr+x4QoDniiKtGDIoEsd43lYV/3z/pMimDBbWV FjwjDUXPJ2ziS+zZEcJYNH9G4ouUrdG+H0MrWjA+ZVw02aMbnjb5nzbl7M7WCVk73BWR 2hW7/s3BqH5ZLsUdk9GrZnts8Ap/iDs0J1WCFLo2+tA3LY6HxHNLmqsROX0sXZ85hOvT pB1Q== X-Gm-Message-State: AOAM530pg824TN9m9MKnfnRLVa0cvd2f9Yiwny4HmWiGGYpuj/cryWEX Gnj8lK5gJn8fHKflCK8upwSCgQyfZ98mexkyMORAHdf4 X-Google-Smtp-Source: ABdhPJx/fl8gCFLEZho5kzeSpbS7+lyu8mbQBr0DWZ4g3HIBmMo7QkI0XgXSODfsqI1yb71Yw0EFXn5TKMdmEAfXE2A= X-Received: by 2002:a9d:38f:: with SMTP id f15mr619798otf.74.1597063878242; Mon, 10 Aug 2020 05:51:18 -0700 (PDT) MIME-Version: 1.0 References: <5BFABAC0-BCF4-4282-A457-F41BD3D142F2@edvina.net> In-Reply-To: <5BFABAC0-BCF4-4282-A457-F41BD3D142F2@edvina.net> From: Simon MORLAT Date: Mon, 10 Aug 2020 14:51:07 +0200 Message-ID: To: "Olle E. Johansson" Cc: Leonid Fainshtein , sipcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000257d1b05ac85699f" Archived-At: Subject: Re: [sipcore] Enabling the wildcard certificates for SIP TLS implementation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 12:51:29 -0000 --000000000000257d1b05ac85699f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, This is my first post on an IETF mailing list, I hope I'll make it the right way :-). Just to give a few information about me, I'm the original author of Linphone, a free-software SIP softphone, and now co-owner and manager of Belledonne Communications, the company developing Linphone since 2010. Thanks to Leonid to raise this concern. I must say I always found RFC 5922 really strange with this prohibition of wildcard certificates, with no reason given. Actually, if wildcard certificates are good for https as well as for many internet services, I would expect an argument that explains how SIP is different from all others and why as such, wildcard certificates are bad. Fundamentally, I don't see why sip should be different from http on this aspect. I must admit that in Linphone's SIP implementation we have finally decided, a couple of years ago, not to follow RFC5922 on this point. Because SIP services can comprise multiple nodes and rely on SRV records (which http usually does not), it is very convenient to use wildcard certificates. At this time Letsencrypt wasn't existing yet. I agree that this limitation is now more easy to overcome. Our decision was motivated by: - the convenience of wildcard certificates for SIP services (with multiple SRV balanced hosts) - the absence of any argumentation for this in RFC5922, which is something really odd compared to all RFCs and even drafts I could read. Could it be a mistake ? I hope too someone can give us a clear argument. Otherwise, could it be envisaged to publish some kind of errata or new RFC that changes this requirement ? Best regards, Simon Le lun. 10 ao=C3=BBt 2020 =C3=A0 10:03, Olle E. Johansson = a =C3=A9crit : > > > On 6 Aug 2020, at 14:55, Leonid Fainshtein > wrote: > > Hi, > The "7.2. Comparing SIP Identities" of RFC-5922 prohibits the usage of > wildcard certificates. > The reasons for this limitation are not clear. The restriction only > complicates the multi-home SIP servers configuration and maintenance. > I suggest enabling the wildcard certificates for SIP. > > > With wide-spread support for TLS SNI and free services like Letsencrypt I > don=E2=80=99t really see a problem with not supporting wildcards. > > On the other side, I do agree that the argumentation for this limitation > is missing. I remember there was a widespread discussion > over multiple working groups about problems with wildcards. Let=E2=80=99s= see if > we can dig up something from other RFCs or if someone > has a clear argument. > > /O > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000257d1b05ac85699f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

This is my first post on a= n IETF mailing list, I hope I'll make it the right way :-).
J= ust to=C2=A0give a few information about me, I'm the=C2=A0original auth= or of Linphone, a free-software SIP softphone, and now co-owner and manager= of Belledonne Communications, the company developing Linphone since 2010.<= /div>

Thanks to Leonid to raise this concern. I must say= I always found RFC 5922 really strange with this prohibition of wildcard c= ertificates, with no reason given.
Actually, if wildcard certific= ates are good for https as well as for many internet services, I would expe= ct an argument that explains how SIP is different from all others and why a= s such, wildcard certificates=C2=A0are bad.
Fundamentally, I don&= #39;t see why sip should be different from http on this aspect.
I= must admit that in Linphone's SIP implementation we have finally decid= ed, a couple of years ago, not to follow RFC5922 on this point.
B= ecause SIP services can comprise multiple nodes and rely on SRV records (wh= ich http usually does not), it is very convenient to use wildcard certifica= tes. At this time Letsencrypt wasn't existing=C2=A0yet. I agree that th= is limitation is now more easy to overcome.
Our decision was moti= vated by:
- the convenience of wildcard certificates for SIP serv= ices (with multiple SRV balanced hosts)
- the absence of any argu= mentation for this in RFC5922, which is something really odd compared to al= l RFCs and even drafts I could read. Could it be a mistake ?

=
I hope too someone can give us a clear argument. Otherwise, coul= d it be envisaged to publish some kind of errata or new RFC that changes th= is requirement ?

Best regards,

Simon


Le=C2=A0lun. 10 ao=C3=BBt 2020 =C3=A0=C2=A0= 10:03, Olle E. Johansson <oej@edvina.n= et> a =C3=A9crit=C2=A0:


On 6 Aug 2020, at 14:55, Leonid Fainshtein <leonid.fainshtein@xor= com.com> wrote:

Hi,
The &q= uot;7.2.=C2=A0 Comparing SIP Identities" of RFC-5922 prohibits=C2=A0th= e usage of wildcard certificates.
The reasons for this limitation= are not clear. The restriction only complicates the multi-home SIP servers= configuration and maintenance.=C2=A0
I suggest enabling the wildca= rd certificates for SIP.

With = wide-spread support for TLS SNI and free services like Letsencrypt I don=E2= =80=99t really see a problem with not supporting wildcards.

<= /div>
On the other side, I do agree that the argumentation for this lim= itation is missing. I remember there was a widespread discussion
= over multiple working groups about problems with wildcards. Let=E2=80=99s s= ee if we can dig up something from other RFCs or if someone
has a= clear argument.

/O

_______________= ________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000257d1b05ac85699f-- From nobody Mon Aug 10 08:04:30 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C907D3A163E for ; Mon, 10 Aug 2020 08:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 8x4M-VGFfzd7 for ; Mon, 10 Aug 2020 08:03:46 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 85D1C3A1529 for ; Mon, 10 Aug 2020 08:03:44 -0700 (PDT) Received: from macbook-pro.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id B4CB12172; Mon, 10 Aug 2020 17:03:41 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_39B5E9E2-BBDB-469D-B664-3A81D44FCC26" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Mon, 10 Aug 2020 17:03:41 +0200 In-Reply-To: Cc: Olle E Johansson , sipcore@ietf.org, Leonid Fainshtein To: Simon MORLAT References: <5BFABAC0-BCF4-4282-A457-F41BD3D142F2@edvina.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [sipcore] Enabling the wildcard certificates for SIP TLS implementation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 15:03:51 -0000 --Apple-Mail=_39B5E9E2-BBDB-469D-B664-3A81D44FCC26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Aug 2020, at 14:51, Simon MORLAT wrote: >=20 > Hi everyone, >=20 > This is my first post on an IETF mailing list, I hope I'll make it the = right way :-). Welcome! > Just to give a few information about me, I'm the original author of = Linphone, a free-software SIP softphone, and now co-owner and manager of = Belledonne Communications, the company developing Linphone since 2010. >=20 > Thanks to Leonid to raise this concern. I must say I always found RFC = 5922 really strange with this prohibition of wildcard certificates, with = no reason given. > Actually, if wildcard certificates are good for https as well as for = many internet services, I would expect an argument that explains how SIP = is different from all others and why as such, wildcard certificates are = bad. > Fundamentally, I don't see why sip should be different from http on = this aspect. > I must admit that in Linphone's SIP implementation we have finally = decided, a couple of years ago, not to follow RFC5922 on this point. > Because SIP services can comprise multiple nodes and rely on SRV = records (which http usually does not), it is very convenient to use = wildcard certificates. At this time Letsencrypt wasn't existing yet. I = agree that this limitation is now more easy to overcome. > Our decision was motivated by: > - the convenience of wildcard certificates for SIP services (with = multiple SRV balanced hosts) > - the absence of any argumentation for this in RFC5922, which is = something really odd compared to all RFCs and even drafts I could read. = Could it be a mistake ? >=20 > I hope too someone can give us a clear argument. Otherwise, could it = be envisaged to publish some kind of errata or new RFC that changes this = requirement ? >=20 I found documentation in RFC 6125 from the =E2=80=9CUsing TLS in = applications=E2=80=9D working group. https://tools.ietf.org/html/rfc6125#section-7.2 = Also note the documentation covering SIP in section B.9. While we may do as HTTPS with DNS Subject Alt Names, we can=E2=80=99t do = that with the URI Subject Alt Names that we prefer to use in SIP, but doesn=E2=80=99t have widespread use. Changes are done by publishing a new RFC, not with Errata. That will = open up a whole can of worms, but we need to open it and specify how SIP over TLS should work. Like the "transport=3DTLS=E2=80=9D= stuff and deprecating =E2=80=9CSIPS:=E2=80=9D. I have spoken about this a number of times. Some docs are to be found on = slideshare.net/oej =20 Cheers, /O > Best regards, >=20 > Simon >=20 >=20 > Le lun. 10 ao=C3=BBt 2020 =C3=A0 10:03, Olle E. Johansson = > a =C3=A9crit : >=20 >=20 >> On 6 Aug 2020, at 14:55, Leonid Fainshtein = > = wrote: >>=20 >> Hi, >> The "7.2. Comparing SIP Identities" of RFC-5922 prohibits the usage = of wildcard certificates. >> The reasons for this limitation are not clear. The restriction only = complicates the multi-home SIP servers configuration and maintenance.=20 >> I suggest enabling the wildcard certificates for SIP. >=20 > With wide-spread support for TLS SNI and free services like = Letsencrypt I don=E2=80=99t really see a problem with not supporting = wildcards. >=20 > On the other side, I do agree that the argumentation for this = limitation is missing. I remember there was a widespread discussion > over multiple working groups about problems with wildcards. Let=E2=80=99= s see if we can dig up something from other RFCs or if someone > has a clear argument. >=20 > /O >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_39B5E9E2-BBDB-469D-B664-3A81D44FCC26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10 Aug 2020, at 14:51, Simon MORLAT <simon.morlat@gmail.com> wrote:

Hi everyone,

This is my first post on an IETF mailing list, I hope I'll = make it the right way = :-).
Welcome!

Just to give a few = information about me, I'm the original author of Linphone, a = free-software SIP softphone, and now co-owner and manager of Belledonne = Communications, the company developing Linphone since 2010.

Thanks to Leonid to = raise this concern. I must say I always found RFC 5922 really strange = with this prohibition of wildcard certificates, with no reason = given.
Actually, if wildcard certificates are good = for https as well as for many internet services, I would expect an = argument that explains how SIP is different from all others and why as = such, wildcard certificates are bad.
Fundamentally, I don't see why sip should be different from = http on this aspect.
I must admit that in = Linphone's SIP implementation we have finally decided, a couple of years = ago, not to follow RFC5922 on this point.
Because = SIP services can comprise multiple nodes and rely on SRV records (which = http usually does not), it is very convenient to use wildcard = certificates. At this time Letsencrypt wasn't existing yet. I agree = that this limitation is now more easy to overcome.
Our decision was motivated by:
- the = convenience of wildcard certificates for SIP services (with multiple SRV = balanced hosts)
- the absence of any argumentation = for this in RFC5922, which is something really odd compared to all RFCs = and even drafts I could read. Could it be a mistake ?

I hope too someone can = give us a clear argument. Otherwise, could it be envisaged to publish = some kind of errata or new RFC that changes this requirement ?


I found documentation in RFC 6125 from the = =E2=80=9CUsing TLS in applications=E2=80=9D working group.
<= br class=3D"">
Also note the documentation covering SIP in = section B.9.

While we may do as = HTTPS with DNS Subject Alt Names, we can=E2=80=99t do that with the URI = Subject Alt Names that we prefer to use in SIP,
but doesn=E2=80=99= t have widespread use.

Changes are = done by publishing a new RFC, not with Errata. That will open up a whole = can of worms, but we need to open it
and specify how SIP over = TLS should work. Like the "transport=3DTLS=E2=80=9D stuff and = deprecating =E2=80=9CSIPS:=E2=80=9D.

I= have spoken about this a number of times. Some docs are to be found on = slideshare.net/oej 

Cheers,
/O

Best regards,

Simon


Le lun. 10 ao=C3=BBt 2020 =C3=A0 10:03, = Olle E. Johansson <oej@edvina.net> a =C3=A9crit :

On 6 Aug 2020, at 14:55, Leonid Fainshtein = <leonid.fainshtein@xorcom.com> wrote:

Hi,
The "7.2.  = Comparing SIP Identities" of RFC-5922 prohibits the usage of = wildcard certificates.
The reasons for this = limitation are not clear. The restriction only complicates the = multi-home SIP servers configuration and maintenance. 
I= suggest enabling the wildcard certificates for = SIP.

With wide-spread support for TLS SNI and free services like = Letsencrypt I don=E2=80=99t really see a problem with not supporting = wildcards.

On = the other side, I do agree that the argumentation for this limitation is = missing. I remember there was a widespread discussion
over multiple working groups about problems with wildcards. = Let=E2=80=99s see if we can dig up something from other RFCs or if = someone
has a clear argument.

/O

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_39B5E9E2-BBDB-469D-B664-3A81D44FCC26-- From nobody Mon Aug 10 11:12:43 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD253A0A4A for ; Mon, 10 Aug 2020 11:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com 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 wrxkX2xdliQr for ; Mon, 10 Aug 2020 11:12:37 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F6F3A0A49 for ; Mon, 10 Aug 2020 11:12:37 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id l84so9713818oig.10 for ; Mon, 10 Aug 2020 11:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hV9mOiCWfOBrvEqGRew0p2gn62vChwJPwTffVNpCLug=; b=Jbq4ZTZsKLHnMY7gKEBXn5BRU2H6PM2A9PbftG5nTbzbC3pU2O0yWCStZIdtW8bOvG +GOoV//2dqp1ypdB24N5/032LhoZg3H4epGD7o98QEamuefMWPdDRqY0WWH1+fh5m3I5 WgW5U0pSbP2iIDAei/fGMvJuP5WWVbQAUvLZ3JeXiScUTwSWMq8rk7OuF+OtrtaNvgBU 2KYnJGoC5HU2qYpxqEfketmBB7Fd2HjhOEBR5w20e9Q78ZvUe5cshF+xIkShhXvbvHuM PETwSWdeWihdOL70Bu4efuyTOB22+O3NE6pWOh2yd7dPk/VTWKdBB9ifBpY8kj1yiaC0 4ANA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hV9mOiCWfOBrvEqGRew0p2gn62vChwJPwTffVNpCLug=; b=rLEH/2VBXEouAPJv2jwL9KyCluw7+hp+sAL2/axR0fHW5u47sEqDbE+0PbV62038Gb JhDeq2xmvMeepdRyVBNJTHuGNYv9xDAfh8aQGpwQQn3R5MQlMifcdEs1p6z3elKLJSLT DjZzvv7NgyYNW138ODSSEgAO+x87l1GY/n4XtZLGNP6lkiCjQ/zWtyqjXkfElTDMhXgy C8wmGsij23/cJAm6aYzZYl2hVa5MbhGQNj+BEEuYqKJfSKoEt9cvUoKO6nGtshaZDmh4 POuIyI11K1pNO6ymRyyFiif8YqP+wz7BRK7+47XtlAwx7L1pB0Xz9wF9tY2VotEgBOHE IkCQ== X-Gm-Message-State: AOAM530RVAuHeLa9JYUuwpGUv2qTElOUZ3dThSwIrdaTjUQf3uokv7Ip QD+Sp5DKLlDi5zwp9XuZh9lpbH55QtQ= X-Google-Smtp-Source: ABdhPJwETLhZRwYCYaVhu7LW+mjIq9DwhsjIiFxVwEqP0VkS/aDrX4zTQwPNXOKj+0b2yxer8ksC/w== X-Received: by 2002:aca:a985:: with SMTP id s127mr390381oie.163.1597083156369; Mon, 10 Aug 2020 11:12:36 -0700 (PDT) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com. [209.85.210.43]) by smtp.gmail.com with ESMTPSA id m24sm3795557oof.5.2020.08.10.11.12.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 11:12:35 -0700 (PDT) Received: by mail-ot1-f43.google.com with SMTP id r21so8013692ota.10 for ; Mon, 10 Aug 2020 11:12:35 -0700 (PDT) X-Received: by 2002:a9d:6a88:: with SMTP id l8mr1698271otq.13.1597083154766; Mon, 10 Aug 2020 11:12:34 -0700 (PDT) MIME-Version: 1.0 References: <5BFABAC0-BCF4-4282-A457-F41BD3D142F2@edvina.net> In-Reply-To: From: Roman Shpount Date: Mon, 10 Aug 2020 14:12:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "Olle E. Johansson" Cc: Simon MORLAT , SIPCORE , Leonid Fainshtein Content-Type: multipart/alternative; boundary="0000000000001e033005ac89e63b" Archived-At: Subject: Re: [sipcore] Enabling the wildcard certificates for SIP TLS implementation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 18:12:41 -0000 --0000000000001e033005ac89e63b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson wrote: > I found documentation in RFC 6125 from the =E2=80=9CUsing TLS in applicat= ions=E2=80=9D > working group. > https://tools.ietf.org/html/rfc6125#section-7.2 > This section essentially says why wildcard certificates must not be used and can only be supported for legacy applications. Not supporting wildcard certificates does create a certain degree of pain but given security risks should continue to be avoided. Changes are done by publishing a new RFC, not with Errata. That will open > up a whole can of worms, but we need to open it > and specify how SIP over TLS should work. Like the "transport=3DTLS=E2=80= =9D stuff > and deprecating =E2=80=9CSIPS:=E2=80=9D. > > One thing I've wanted for a long time is an extension which allows to multiplex several DTLS connections over the same protocol/address/port pair. This will allow to replicate all the current SIP over UDP deployment scenarios using a secure protocol. Once this is available, I would participate or author an RFC. Best Regards, _____________ Roman Shpount --0000000000001e033005ac89e63b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Aug 10, 2020 at= 11:04 AM Olle E. Johansson <oej@edvin= a.net> wrote:
=
I found documentation in RFC 6125 from the =E2=80=9CUsing TLS in = applications=E2=80=9D working group.
=C2=A0
This section=C2=A0essentially says why wildcard certific= ates=C2=A0must not be used and can only be supported for legacy application= s. Not supporting wildcard certificates does create a certain degree of pai= n but given security risks should continue to be avoided.

Changes are done by publishing a new RFC, not= with Errata. That will open up a whole can of worms, but we need to open i= t
and specify how SIP over TLS should work. Like the "tr= ansport=3DTLS=E2=80=9D stuff and deprecating =E2=80=9CSIPS:=E2=80=9D.
=


One thing I'= ;ve wanted for a long time is an extension which allows to multiplex severa= l DTLS connections over the same protocol/address/port pair. This will allo= w to replicate all the current SIP over UDP deployment scenarios using a se= cure protocol. Once this is available, I would participate or author=C2=A0a= n RFC.

Best Regards,
_____________
Roman Shpount=C2= =A0
--0000000000001e033005ac89e63b-- From nobody Tue Aug 11 01:44:10 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59213A0E92 for ; Tue, 11 Aug 2020 01:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xQke5JY2yZ97 for ; Tue, 11 Aug 2020 01:44:08 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C653A0E8D for ; Tue, 11 Aug 2020 01:44:08 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id l84so11482913oig.10 for ; Tue, 11 Aug 2020 01:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NPdHi3IjushyGVtr6GDBEQF7ujgA9F/lLv46Idp4Y6E=; b=UaTTOku9faDBpfoSg/kt47MvxyeNY7R2nJ5CNOcwePbyvgsHAuMjNEf8PKQwUIfTjC Qx4/I7HvDf3GoxvNujkcUaE5j4v/80j7JcHKbyzgaMfYq5Ib5giU5iTx0/Etrjb+ZuIA YjW+cm+u34tOjbAHyoD68YtC31ehcCJH9/jOxDEuUi1uXtjWa+ia+Y3+hFhmD107M5Vq tkeJn6M2AedAvbWPTrqPlNVmrVB02YNRRJ6eVhO9ICdx0KrRh34KyrgSnP5gk7yZ40lK 1C2kj7oKFp25/t7dn8eq/RiQXCCK6U/E6SveuAQTRVTpsepYPIxizKR+hpoN9s5XRVJs jIMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NPdHi3IjushyGVtr6GDBEQF7ujgA9F/lLv46Idp4Y6E=; b=BAo+e5OZBeBrQokeHY5kbFGIk5PjctsTh0WvrcAhi8glk+A4iu3L9njEVnCqubr2be Y4S/yjd1pNWV4NMSD1oy62wWhgUbKDCU2kj99nDcoipkwi4VpXf4af4mXZ6LizslVPcE aTyvDdApMuk0Nf6Fs8jaFNMrQOUSxEMk8gD0B+toiZlmEpQ8GAx0LS4UIlVSA86W8CXu 18enf/HpQKWlqJHHeGDWQdVSNggj0iUCJDwokSjNCilTNsiA4csDYHDRYi4Dscijfk0s +iCkA5urU2vYju0CMdpGQb3MR7Gui29L6pYz4vv6KvraKYxmlibF08pDL7LgHsOTEFQ5 nLhA== X-Gm-Message-State: AOAM530Mnyxw7EQRszs2P3QNAn7Kfx7sQWfLoB93cxqqNiAvmLZ/WDiZ OR2mf+UyE4FSKgPQ/L4nFFvXKY08UX82HRcLa/YlX4gg X-Google-Smtp-Source: ABdhPJxkiY3p5LhZVBtIsqy7de+6VlfOiV8dsrycx+2r1sactAQdnVTu2kUg3uqKBLlLSP/5l6oQzhaL2r0T9/aFogc= X-Received: by 2002:aca:1209:: with SMTP id 9mr2694290ois.136.1597135447291; Tue, 11 Aug 2020 01:44:07 -0700 (PDT) MIME-Version: 1.0 References: <5BFABAC0-BCF4-4282-A457-F41BD3D142F2@edvina.net> In-Reply-To: From: Simon MORLAT Date: Tue, 11 Aug 2020 10:43:56 +0200 Message-ID: To: Roman Shpount Cc: "Olle E. Johansson" , SIPCORE , Leonid Fainshtein Content-Type: multipart/alternative; boundary="000000000000fe7e6a05ac961272" Archived-At: Subject: Re: [sipcore] Enabling the wildcard certificates for SIP TLS implementation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 08:44:10 -0000 --000000000000fe7e6a05ac961272 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thank you for all your answers, this is very helpful. I did not know RFC 6125. Based on these considerations, I would say that wildcard certificates will probably disappear for all applications in the next few years. Best regards, Simon Le lun. 10 ao=C3=BBt 2020 =C3=A0 20:12, Roman Shpount a= =C3=A9crit : > > On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson wrote= : > >> I found documentation in RFC 6125 from the =E2=80=9CUsing TLS in applica= tions=E2=80=9D >> working group. >> https://tools.ietf.org/html/rfc6125#section-7.2 >> > > This section essentially says why wildcard certificates must not be used > and can only be supported for legacy applications. Not supporting wildcar= d > certificates does create a certain degree of pain but given security risk= s > should continue to be avoided. > > Changes are done by publishing a new RFC, not with Errata. That will open >> up a whole can of worms, but we need to open it >> and specify how SIP over TLS should work. Like the "transport=3DTLS=E2= =80=9D stuff >> and deprecating =E2=80=9CSIPS:=E2=80=9D. >> >> > One thing I've wanted for a long time is an extension which allows to > multiplex several DTLS connections over the same protocol/address/port > pair. This will allow to replicate all the current SIP over UDP deploymen= t > scenarios using a secure protocol. Once this is available, I would > participate or author an RFC. > > Best Regards, > _____________ > Roman Shpount > --000000000000fe7e6a05ac961272 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for all = your answers, this is very helpful.
I did not know RFC 6125. Base= d on these considerations, I would say that wildcard certificates will prob= ably disappear for all applications in the next few years.

Best regards,

Simon

<= /div>

Le=C2=A0lun. 10 ao=C3=BBt 2020 =C3=A0=C2=A020:12, Roman Shpount <roman@telurix.com> a =C3=A9crit= =C2=A0:

On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson <oej@edvina.net> wrote:<= br>
I found= documentation in RFC 6125 from the =E2=80=9CUsing TLS in applications=E2= =80=9D working group.
=C2=A0
<= div>This section=C2=A0essentially says why wildcard certificates=C2=A0must = not be used and can only be supported for legacy applications. Not supporti= ng wildcard certificates does create a certain degree of pain but given sec= urity risks should continue to be avoided.

Changes are done by publishing a new RFC, not with Erra= ta. That will open up a whole can of worms, but we need to open it
and specify how SIP over TLS should work. Like the "transport=3D= TLS=E2=80=9D stuff and deprecating =E2=80=9CSIPS:=E2=80=9D.

<= /div>

One thing I've wanted= for a long time is an extension which allows to multiplex several DTLS con= nections over the same protocol/address/port pair. This will allow to repli= cate all the current SIP over UDP deployment scenarios using a secure proto= col. Once this is available, I would participate or author=C2=A0an RFC.

Best Regards,
____________= _
Roman Shpount=C2=A0
--000000000000fe7e6a05ac961272-- From nobody Tue Aug 11 02:36:22 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B9E3A0F23 for ; Tue, 11 Aug 2020 02:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vGAPVeVByy39 for ; Tue, 11 Aug 2020 02:36:19 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C205C3A0F1C for ; Tue, 11 Aug 2020 02:36:18 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id f12so10818689wru.13 for ; Tue, 11 Aug 2020 02:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=VHjvMtfa8Alga5sTjxbdi3WM186t9zCsD8rjCokg8V4=; b=DMk1ZAxc/v4qtMOsDWitFzT2vhJINSCQ3lRw+hxKQUupWwEIO1z30kKz3p8ZJ0gPuP yx/Z+600TG6i5C+qY1t97khUw9T2heVIULUcalXgSr50OlynPnwOMm/sRPDi7Lp0IlNs yi3g7gqE3iRWYDwiesNjRIkxKRiaYmkjM2NIbW3VItCivkdI2Pg0iTyXgUpAQlGoJTcG VY7ImGjM0LmuZw7FUThTiOvc1nLaR7XawiWWCLltJWWLgOkfSyPpHR9UxAZhN65g5bDL vVNK3V0JRI+Dh83M8q32c7IxISpGLMH5Fb8WUNP4/k6QYAXe4iA2poHbqWJYoKRUuL9c 7HGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=VHjvMtfa8Alga5sTjxbdi3WM186t9zCsD8rjCokg8V4=; b=aYkEcaZ8wjdALi8cAFJxTcmqdi+smE8doPqn1TFZ09IjwZ5PEck/CQe6/KaHPmLw92 Vl4FhTeNUZHA5eAzLizjg7hdlmWKtLPwLgkcMb4Y8AuJ9rBOm+oh3T3g5VA8hsKIqVJb ByqNrtTotaW0z/1lgnDNKNqgi7Bf8qQtFYmmfaxczoHF/P5c1KC/MgFlNMTUOZ8oWmVi uAJmmUTmNfLjjT6Bon++A5+hrh0Sg2pwGZBU3dyVsEEFqCtYt9FS8vO3wlQv3ZUzAhBg aZyEGz5aCTIvDKbFcXbALOHTdtySIJdfyaxw4JobKSbloEpIVqqgudTjeaxPVzBXAewE IXvA== X-Gm-Message-State: AOAM533HH/o/E2rZr0kVQJGIo+tRKCQRqq2UpgjozKlSoXnFvclnTQtn pxLKLK+QpLOmajyWGDbZYB8= X-Google-Smtp-Source: ABdhPJzr34afWJJsmZIZf1S2bosOWwrIKkNRHSZnYgKP7oq97hzCNgHN/fZ5w20kaxVytsowlkByDg== X-Received: by 2002:adf:90d1:: with SMTP id i75mr27369334wri.278.1597138577164; Tue, 11 Aug 2020 02:36:17 -0700 (PDT) Received: from saturnxs-MacBook-Pro-2.fritz.box (esa.asipto.com. [2a01:4f8:a0:638e::2]) by smtp.googlemail.com with ESMTPSA id n5sm24480257wrx.22.2020.08.11.02.36.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Aug 2020 02:36:16 -0700 (PDT) Reply-To: miconda@gmail.com To: Simon MORLAT , Roman Shpount Cc: SIPCORE , "Olle E. Johansson" , Leonid Fainshtein References: <5BFABAC0-BCF4-4282-A457-F41BD3D142F2@edvina.net> From: Daniel-Constantin Mierla Message-ID: <7164b84b-ade1-7085-7e64-541be8c25085@gmail.com> Date: Tue, 11 Aug 2020 11:36:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B07366B836D0CDCC867FDB8A" Content-Language: en-GB Archived-At: Subject: Re: [sipcore] Enabling the wildcard certificates for SIP TLS implementation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 09:36:21 -0000 This is a multi-part message in MIME format. --------------B07366B836D0CDCC867FDB8A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, maybe it should be split in: 1) trusting the certificate to be used for encryption, but asserting the identity of the peer is done separately. This is the common use case these days and the goal is to ensure the certificate belongs to the entity owning the service by association with the main domain name. E.g., hosted pbx providers with subdomain allocation per customer, like custid.cloudpbx.lab. Identity of peers is ensured by other meanings like shared secret. Here wild card certificates are very useful (with the full left most label being the wildcard), is such case management of certificates with full domains is getting close to impossible on large deployments, not only painful. 2) trusting the certificate also for asserting the identity of the peer, when it needs to match in a 1-to-1 relation. In this case wildcard certificates are not useful, of course, but I rarely have seen it used for this purpose. Cheers, Daniel On 11.08.20 10:43, Simon MORLAT wrote: > Hi, > > Thank you for all your answers, this is very helpful. > I did not know RFC 6125. Based on these considerations, I would say > that wildcard certificates will probably disappear for all > applications in the next few years. > > Best regards, > > Simon > > > Le lun. 10 août 2020 à 20:12, Roman Shpount > a écrit : > > > On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson > wrote: > > I found documentation in RFC 6125 from the “Using TLS in > applications” working group. > https://tools.ietf.org/html/rfc6125#section-7.2 > >   > This section essentially says why wildcard certificates must not > be used and can only be supported for legacy applications. Not > supporting wildcard certificates does create a certain degree of > pain but given security risks should continue to be avoided. > > Changes are done by publishing a new RFC, not with Errata. > That will open up a whole can of worms, but we need to open it > and specify how SIP over TLS should work. Like the > "transport=TLS” stuff and deprecating “SIPS:”. > > > One thing I've wanted for a long time is an extension which allows > to multiplex several DTLS connections over the same > protocol/address/port pair. This will allow to replicate all the > current SIP over UDP deployment scenarios using a secure protocol. > Once this is available, I would participate or author an RFC. > > Best Regards, > _____________ > Roman Shpount  > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda --------------B07366B836D0CDCC867FDB8A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello,

maybe it should be split in:

1) trusting the certificate to be used for encryption, but asserting the identity of the peer is done separately. This is the common use case these days and the goal is to ensure the certificate belongs to the entity owning the service by association with the main domain name. E.g., hosted pbx providers with subdomain allocation per customer, like custid.cloudpbx.lab. Identity of peers is ensured by other meanings like shared secret. Here wild card certificates are very useful (with the full left most label being the wildcard), is such case management of certificates with full domains is getting close to impossible on large deployments, not only painful.

2) trusting the certificate also for asserting the identity of the peer, when it needs to match in a 1-to-1 relation. In this case wildcard certificates are not useful, of course, but I rarely have seen it used for this purpose.

Cheers,
Daniel

On 11.08.20 10:43, Simon MORLAT wrote:
Hi,

Thank you for all your answers, this is very helpful.
I did not know RFC 6125. Based on these considerations, I would say that wildcard certificates will probably disappear for all applications in the next few years.

Best regards,

Simon


Le lun. 10 août 2020 à 20:12, Roman Shpount <roman@telurix.com> a écrit :

On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson <oej@edvina.net> wrote:
I found documentation in RFC 6125 from the “Using TLS in applications” working group.
 
This section essentially says why wildcard certificates must not be used and can only be supported for legacy applications. Not supporting wildcard certificates does create a certain degree of pain but given security risks should continue to be avoided.

Changes are done by publishing a new RFC, not with Errata. That will open up a whole can of worms, but we need to open it
and specify how SIP over TLS should work. Like the "transport=TLS” stuff and deprecating “SIPS:”.


One thing I've wanted for a long time is an extension which allows to multiplex several DTLS connections over the same protocol/address/port pair. This will allow to replicate all the current SIP over UDP deployment scenarios using a secure protocol. Once this is available, I would participate or author an RFC.

Best Regards,
_____________
Roman Shpount 

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
--------------B07366B836D0CDCC867FDB8A-- From nobody Tue Aug 11 05:38:10 2020 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872793A102A for ; Tue, 11 Aug 2020 05:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 dabXYy0otKN6 for ; Tue, 11 Aug 2020 05:38:05 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 3C0DD3A1029 for ; Tue, 11 Aug 2020 05:38:03 -0700 (PDT) Received: from macbook-pro.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id CA70929B6; Tue, 11 Aug 2020 14:37:57 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <1001AACE-ECE2-45EE-AEEF-7812FC240B61@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_7E5CB4EC-8CA2-4B59-9164-377EC5039532" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 11 Aug 2020 14:37:57 +0200 In-Reply-To: <7164b84b-ade1-7085-7e64-541be8c25085@gmail.com> Cc: Simon MORLAT , Roman Shpount , SIPCORE , Leonid Fainshtein To: Daniel-Constantin Mierla References: <5BFABAC0-BCF4-4282-A457-F41BD3D142F2@edvina.net> <7164b84b-ade1-7085-7e64-541be8c25085@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [sipcore] Enabling the wildcard certificates for SIP TLS implementation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 12:38:09 -0000 --Apple-Mail=_7E5CB4EC-8CA2-4B59-9164-377EC5039532 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Aug 2020, at 11:36, Daniel-Constantin Mierla = wrote: >=20 > Hello, >=20 > maybe it should be split in: >=20 > 1) trusting the certificate to be used for encryption, but asserting = the identity of the peer is done separately. This is the common use case = these days and the goal is to ensure the certificate belongs to the = entity owning the service by association with the main domain name. = E.g., hosted pbx providers with subdomain allocation per customer, like = custid.cloudpbx.lab. Identity of peers is ensured by other meanings like = shared secret. Here wild card certificates are very useful (with the = full left most label being the wildcard), is such case management of = certificates with full domains is getting close to impossible on large = deployments, not only painful. >=20 Opportunistic crypto always works. What we=E2=80=99re discussing - at = least I - is some way to set up a call between trusted peers, so you are = right in dividing the use case. In order to get some undefined level of = confidentiality you can just take the public key from any cert presented = without validating, much like most SMTP servers can do today. > 2) trusting the certificate also for asserting the identity of the = peer, when it needs to match in a 1-to-1 relation. In this case wildcard = certificates are not useful, of course, but I rarely have seen it used = for this purpose. >=20 >=20 And it is today a bit undefined what the expected behaviour is. The SIP = RFCs only define validation of SIP server certs with a given SIP URI. = There are a few documents from the UTA group describing expected behaviour when = using DNS SRV but they are not really following the SIP one. And = there=E2=80=99s no documentation whatsoever on client certs, so mutual = auth is very hard to set up if you expect interoperability. I will go through my old documents and presentations. I think I have = tried to sort this mess up into some form of agenda a few years ago. /O :-) > Cheers, > Daniel >=20 > On 11.08.20 10:43, Simon MORLAT wrote: >> Hi, >>=20 >> Thank you for all your answers, this is very helpful. >> I did not know RFC 6125. Based on these considerations, I would say = that wildcard certificates will probably disappear for all applications = in the next few years. >>=20 >> Best regards, >>=20 >> Simon >>=20 >>=20 >> Le lun. 10 ao=C3=BBt 2020 =C3=A0 20:12, Roman Shpount = > a =C3=A9crit : >>=20 >> On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson > wrote: >> I found documentation in RFC 6125 from the =E2=80=9CUsing TLS in = applications=E2=80=9D working group. >> https://tools.ietf.org/html/rfc6125#section-7.2 = >> =20 >> This section essentially says why wildcard certificates must not be = used and can only be supported for legacy applications. Not supporting = wildcard certificates does create a certain degree of pain but given = security risks should continue to be avoided. >>=20 >> Changes are done by publishing a new RFC, not with Errata. That will = open up a whole can of worms, but we need to open it >> and specify how SIP over TLS should work. Like the "transport=3DTLS=E2=80= =9D stuff and deprecating =E2=80=9CSIPS:=E2=80=9D. >>=20 >>=20 >> One thing I've wanted for a long time is an extension which allows to = multiplex several DTLS connections over the same protocol/address/port = pair. This will allow to replicate all the current SIP over UDP = deployment scenarios using a secure protocol. Once this is available, I = would participate or author an RFC. >>=20 >> Best Regards, >> _____________ >> Roman Shpount=20 >>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore = > --=20 > Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- = www.linkedin.com/in/miconda --Apple-Mail=_7E5CB4EC-8CA2-4B59-9164-377EC5039532 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 11 Aug 2020, at 11:36, Daniel-Constantin Mierla <miconda@gmail.com> = wrote:

=20 =20

Hello,

maybe it should = be split in:

1) trusting the certificate to be used for = encryption, but asserting the identity of the peer is done separately. This is the common use case these days and the goal is to ensure the certificate belongs to the entity owning the service by association with the main domain name. E.g., hosted pbx providers with subdomain allocation per customer, like custid.cloudpbx.lab. Identity of peers is ensured by other meanings like shared secret. Here wild card certificates are very useful (with the full left most label being the wildcard), is such case management of certificates with full domains is getting close to impossible on large deployments, not only painful.

Opportunistic crypto always = works. What we=E2=80=99re discussing - at least I - is some way to set = up a call between trusted peers, so you are right
in dividing = the use case. In order to get some undefined level of confidentiality = you can just take the public key from any cert presented = without
validating, much like most SMTP servers can do = today.

2) trusting the certificate also for asserting the = identity of the peer, when it needs to match in a 1-to-1 relation. In this case wildcard certificates are not useful, of course, but I rarely have seen it used for this purpose.


And it is today a bit = undefined what the expected behaviour is. The SIP RFCs only define = validation of SIP server certs with a given SIP URI. There = are
a few documents from the UTA group describing expected = behaviour when using DNS SRV but they are not really following the SIP = one. And there=E2=80=99s no documentation whatsoever on client certs, so = mutual auth is very hard to set up if you expect = interoperability.

I will go through = my old documents and presentations. I think I have tried to sort this = mess up into some form of agenda a few years ago.

/O :-)

Cheers,
Daniel

On 11.08.20 10:43, Simon MORLAT = wrote:
Hi,

Thank you for all your answers, this is very = helpful.
I did not know RFC 6125. Based on these = considerations, I would say that wildcard certificates will probably disappear for all applications in the next few years.

Best regards,

Simon


Le lun. 10 ao=C3=BBt = 2020 =C3=A0 20:12, Roman Shpount <roman@telurix.com> a = =C3=A9crit :

On Mon, Aug 10, 2020 at 11:04 AM Olle E. Johansson <oej@edvina.net> wrote:
I found documentation in RFC 6125 = from the =E2=80=9CUsing TLS in applications=E2=80=9D = working group.
https://tools.ietf.org/html/rfc6125#section-7.2
 
This section essentially says why = wildcard certificates must not be used and can only be = supported for legacy applications. Not supporting wildcard certificates does create a certain degree of pain but given security risks should continue to be = avoided.

Changes are done by publishing a new = RFC, not with Errata. That will open up a whole can of worms, but we need to open it
and specify how SIP over TLS should = work. Like the "transport=3DTLS=E2=80=9D stuff and = deprecating =E2=80=9CSIPS:=E2=80=9D.


One thing I've wanted for a long time is = an extension which allows to multiplex several DTLS connections over the same protocol/address/port pair. This will allow to replicate all the current SIP over UDP deployment scenarios using a secure protocol. Once this is available, I would participate or author an = RFC.

Best Regards,
_____________
Roman Shpount 

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.or=
g/mailman/listinfo/sipcore

--=20
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- =
www.linkedin.com/in/miconda

= --Apple-Mail=_7E5CB4EC-8CA2-4B59-9164-377EC5039532--