Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients

"Manger, James" <> Fri, 21 April 2017 05:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CC9C124BFA for <>; Thu, 20 Apr 2017 22:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eAMXY56YzNlG for <>; Thu, 20 Apr 2017 22:36:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 548631252BA for <>; Thu, 20 Apr 2017 22:36:45 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.37,228,1488805200"; d="scan'208";a="5468263"
Received: from unknown (HELO ([]) by with ESMTP; 21 Apr 2017 15:36:42 +1000
X-IronPort-AV: E=McAfee;i="5800,7501,8504"; a="350776310"
Received: from ([]) by with ESMTP; 21 Apr 2017 15:36:37 +1000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.3.485.1; Fri, 21 Apr 2017 15:34:01 +1000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 21 Apr 2017 15:34:00 +1000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Fri, 21 Apr 2017 15:34:00 +1000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1K0KXohMZAB38bnd5BzJhscuhVfp/RLlpbAeEk4iGzk=; b=njeRTS07wa8gc5PbXfBe2eE+c3J1AGORFnKZZUiqsQfTmn089o/5AnOP8SsS+qOZ17gD/k2HzCkKr5Q9BK/DPs7FAcaR2aacNeIpNcB0YqyGbqnh1V3SKrjMmt9WapT4BWl9xQTcTSeo3BDzpv5Nwp4ulfP6LirBwJJ9dIaeh/w=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.10; Fri, 21 Apr 2017 05:33:59 +0000
Received: from ([]) by ([]) with mapi id 15.01.1034.018; Fri, 21 Apr 2017 05:33:59 +0000
From: "Manger, James" <>
To: "" <>
Thread-Topic: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients
Thread-Index: AQHSufPijMHl+jcM50+lEDouBjGFMKHPP5Jw
Date: Fri, 21 Apr 2017 05:33:59 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-AU, en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; MEXPR01MB1383; 7:vJvdlozNVjC1phWArXN2ZwYVJW0itv9A6GtkbMtXfGBaQ54ldgmZ0l9S15w4dwaLq6dilOhT/dwtN04vKPgulQMCVgAlhyqioD3v75e+agX1gnghWwh8l0JYL0Un0Co2ppeL0077YBUFzhxflA15HaumKGtvAV5DelNk1UhHwG2KLzfcDroW9sYBuAxJAIZstODtofQi6UuGyeGX9lnbohDeg7hxEOzf+nxHGmGnTAfZDOrMufsVGR7Gw1swU8OLAi9uwnKZawfesdzmyomSSkGkJwF/x4CTJP6TlmRWlGLK5BhqlFn9skgjoOKsCD/UMogkeptBmJoH00aDjmmOoA==
x-ms-office365-filtering-correlation-id: 2f41b710-2c4b-4bcf-cfcb-08d48878032e
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:MEXPR01MB1383;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201703061421075)(201703161042150)(6072148)(6042181); SRVR:MEXPR01MB1383; BCL:0; PCL:0; RULEID:; SRVR:MEXPR01MB1383;
x-forefront-prvs: 02843AA9E0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(1730700003)(8936002)(2501003)(2900100001)(8676002)(122556002)(5660300001)(50986999)(76176999)(6116002)(2906002)(54356999)(102836003)(3280700002)(3846002)(3660700001)(110136004)(38730400002)(189998001)(53936002)(86362001)(7736002)(6506006)(74316002)(6306002)(2351001)(55016002)(305945005)(9686003)(66066001)(33656002)(99286003)(25786009)(7696004)(2950100002)(6916009)(77096006)(229853002)(42882006)(6436002)(6246003)(5640700003); DIR:OUT; SFP:1102; SCL:1; SRVR:MEXPR01MB1383;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 05:33:59.5203 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEXPR01MB1383
Archived-At: <>
Subject: Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Apr 2017 05:36:48 -0000

I support adoption of draft-campbell-oauth-mtls.

Now some comments on the doc:

1. [§2.3] The syntax of tls_client_auth_subject_dn is not specified. Perhaps LDAP's "String Representation of Distinguished Names" [RFC4514]? Perhaps a base64url-encoding of a DER-encoded DN?
It would actually be better to allow any subjectAltName to be specified, instead of a DN.

2. [§2.3] Change the name of tls_client_auth_issuer_dn (maybe tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be too easy to assume this pair refer to the issuer and subject fields of the cert.
PKI chains can be complex so the expected root might not be such a stable concept. For example, the Let's Encrypt CA chains to an ISRG Root and an IdenTrust DST Root [].

3. [§2.3] If a client dynamically registers a "jwks_uri" does this mean the authz server MUST automatically cope when the client updates the key(s) it publishes there?

4. [§3] An access token is bound to a specific client certificate. That is probably ok, but does mean all access tokens die when the client updates their certificate (which could be every 2 months if using Let's Encrypt). This at least warrants a paragraph in the Security Considerations.

5. [§3.1] "exp" and "nbf" values in the example need to be numbers, not strings (drop the quotes).

6. An access token linked to a client TLS cert isn't a bearer token. The spec should really define a new token_type for responses from the token endpoint. That might not necessarily mean we needs a new HTTP authentication scheme as well (it might just hint that "Bearer" wasn't quite the right name).

James Manger