Re: [Rum] RUE client credentials

Brian Rosen <> Tue, 27 August 2019 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDAAB120089 for <>; Tue, 27 Aug 2019 12:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S7-vmxJB9obk for <>; Tue, 27 Aug 2019 12:32:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 579CD120828 for <>; Tue, 27 Aug 2019 12:32:14 -0700 (PDT)
Received: by with SMTP id f10so219662qkg.7 for <>; Tue, 27 Aug 2019 12:32:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7ox1yFl6IDIS7FzxWgPH6tsTYdS56/bA7Ag5QCzOJFY=; b=V8/+f8uM521qbSq84K/QXYKZZ4UQOsRgq9Q+k5IwP/pX3d9OGB4stK3QsBcG/1yNs+ eGxp1m7350e+L9ggnIvaAygI+51KNPEiq6LT5cS89FPQ/N88O+DJT5Mmib4bCdj0Y25v nvWy2aKvtUejQnLpIy2mhb9HZv3O126p4FU2w8D+CjK/jOLMr34kWctcGxhI9J+g9l4J mZkU9wfbaXuJqoE4+5h1cfLqimQsLrI+Evxp4aS8koX/PiMp1EDJG/0QufPA4lOeaW34 Py6ZU5yhkvuIogfYRhST34mYvxJrFH6+yIB8kHxw2T1FskXmvEDiXf+v03m0m1T+h4ln gsqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7ox1yFl6IDIS7FzxWgPH6tsTYdS56/bA7Ag5QCzOJFY=; b=BodHkLyJfjxQeEAIdFeFkF3SfH6jWyo3c0Y+bIw8JTuUIkughK+aT8nFo/NzZLmJpp ehU/rKMs17paz6jPtpeffQHmGk9bEI4utUKoeNK+GofFdgaVufuX/0YYvE9tnfUNJNjT BCK5xJhVDX+/OaoQf3kT0fgFfa5B/0Sg0lxzzewLJ+RPXIXsUeMrLkDrCdOwoT9o7IVV 5+VQAd3ziQchFGRA4PVm9qc1PIA9Y9PTk9y2H1h8JvaaGHbzt7mTWfShIklhVKfAvOgu Ulw1OhPsvkRDVoj6/1BIckapInVPwckhrBFPkNnfEbXsXhfiXrHJ0pxeh3/QJV/ytMXQ 59XA==
X-Gm-Message-State: APjAAAXs7+bVj+yttQDj6hlh/1ynWnvSmhIUDrw3vvlnpW9GME6X+SWK UX3rT8vsmGPLNh30CLMd7IByPg==
X-Google-Smtp-Source: APXvYqwQT5MS1MC4t6UcJiT0zIeRV07as8gmZzqnDx1rpjaH3iDHvMh30V3S3g4BEba2s1Xnpix26g==
X-Received: by 2002:a37:e10f:: with SMTP id c15mr130819qkm.219.1566934333276; Tue, 27 Aug 2019 12:32:13 -0700 (PDT)
Received: from brians-mbp-2369.lan ([]) by with ESMTPSA id 143sm161777qkl.114.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Aug 2019 12:32:12 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Brian Rosen <>
In-Reply-To: <>
Date: Tue, 27 Aug 2019 15:32:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Paul Kyzivat <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Rum] RUE client credentials
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Aug 2019 19:32:17 -0000

Getting back to this, sorry for the delay.

> On Aug 12, 2019, at 3:40 PM, Paul Kyzivat <> wrote:
> On 8/7/19 5:14 PM, Brian Rosen wrote:
>> Working on these comments.  I submitted a new version (-01)
>> I edited the doc to say the client cert is provisioned.  Given that it’s provisioned by the entity that the provides the server, do I need to say anything else about validating the cert?
> I think we need to examine what the goal is here, and whether it is being achieved. I don't think enough is said to decide.
> This client cert mechanism was first added way back when (2015 I think). IIRC, the motivation was because the providers wanted to restrict access to RUE *implementations* that have passed interoperability testing, in order to reduce the problems of dealing with buggy implementations or attackers.
I think you are confusing validating an implementation from authenticating a user.  The notion of mutual auth with a per-device cert is completely separate from some notion of “signing” an implementations code.

We can decide we don’t want the option of having mutual auth.

> The idea was that certs would only be made available to *implementations* (e.g. images) that have been tested. There was no expectation that each user who obtains a rue would need to have it tested.
> But the exact mechanism for binding a cert to a tested implementation was never worked out. I've asked around from time to time and I haven't learned of any way to achieve this.
> Brian's new text pushes this off one level but doesn't solve the problem. The provider's *sip* server can perhaps trust that the rue got the cert from the provider's provisioning server. But the provisioning server still has to decide if this is a trustworthy implementation.
> The Apple store and the Google Play Store solve this problem by being the distributor of apps. The developer has to submit the app, which is then tested/verified by the store and then being assigned credentials. Potentially we could have something list that by having a RUE Store operated by a RUE testing authority. But I don't think anybody is prepared to operate such a thing and it would require the devices receiving these apps to bypass the normal vendor restrictions on installations.
> I don't have a good answer here.
> 	Thanks,
> 	Paul