Re: [OAUTH-WG] cert spoofing in mtls & short-lived certs

Leif Johansson <> Tue, 14 November 2017 14:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 390E4124D6C for <>; Tue, 14 Nov 2017 06:54:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 GBA-q4nEuMQg for <>; Tue, 14 Nov 2017 06:54:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F8FC124C27 for <>; Tue, 14 Nov 2017 06:54:47 -0800 (PST)
Received: by with SMTP id c123so7511030pga.11 for <>; Tue, 14 Nov 2017 06:54:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=J9ROcXn7BKdIWlN4m2304jzxaY3+x2IeFl2Euk+xL2A=; b=DgQ9d5BCvhXlJW5q2Qu5hxljA/aRTdhaNrCDTMgSG079LAHTOWD+cn49PFx+onvZB3 iaBRlLnM+FuSm/YgjjCLwSuC577dFsgyz0HBRFt5FvTb936TXnUljXWVE3CSb5tLTp0N rTlEsFLNOTwkax9/IZ298/3DHRREs2un92Ljf1z/Iy2NAzxOagj1GHyY1GPKNR2WVjxT i9Qto5+jzDDuWk5N1iVN0OCdL8FCj3kDYqryQBVarnrVElfI8WxbaI1fivLA5/p4S5Sk Qey1rdKkIhy1XkvxvaHS/8dj/ZmmEvXS2qosT653d+1xoxx13JSTmXRugKQhCTbXe2dT HRdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=J9ROcXn7BKdIWlN4m2304jzxaY3+x2IeFl2Euk+xL2A=; b=cpZkMdyXbd8okGwdgy6gqaZkMPu0rVJoq04G+bmcf4dSIq1s5jy8QQIQo3zFdX9nQf L9iIhDLA7jfj1SMoB+OgBoCdUGYrl51k8KdW0dH0DTmcujwkmXzYAGtu6PC6+0FvWnXl 4yLuXhCojys3NSH/1sk0ao1lUNRpuipUNmXKaObB8DmjyIBKbns2LrGJUaVeU9hcSIAP 36CcXkaZUEEPXRxUOgmC7S5YHA3SWKuk0h1Viijv4OY7Xjm3jq5RTBewnjOBJ+CjF23N hoUdvo4eas9NZ/c8k8FBx5WLzYRA1hrEgE6vVO0piWkFYp7HwSuLfTtIKMlj0N7Yk5RV 5JSw==
X-Gm-Message-State: AJaThX4E2fSAZFCV+JltMoIgvLNW5+t3miqJq668rvYVaBSzWgI52VHD A5lIHPB1UYONMGv3rpXMtj/qR3h8MKo=
X-Google-Smtp-Source: AGs4zMaN41VY0bUeSrzfSdrcy5TaldbgPSsP5cgj5MSiCkN7e6zq2dYO7hhTEpc6crwVmjMavK4gtQ==
X-Received: by with SMTP id g127mr13864498pfc.228.1510671286289; Tue, 14 Nov 2017 06:54:46 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:418a:5b2a:53f5:49b? ([2001:67c:1232:144:418a:5b2a:53f5:49b]) by with ESMTPSA id f6sm30073518pgo.11.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 06:54:45 -0800 (PST)
References: <> <>
From: Leif Johansson <>
Message-ID: <>
Date: Tue, 14 Nov 2017 15:54:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [OAUTH-WG] cert spoofing in mtls & short-lived certs
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: Tue, 14 Nov 2017 14:54:51 -0000

On 2017-11-14 10:27, Brian Campbell wrote:
> The expectation/assumption is that the SubjectDN would be a stable
> identifier through re-issuance of certificates, regardless of whether
> they be short or long term. We've had basically this as a product
> feature for years and use of the SubjectDN as the identifier hasn't been
> an issue. And it's not been raised, that I'm aware of anyway, as a
> concern in the banking use-cases where there will be some central entity
> issuing these certificates to the participants. Not sure if that exactly
> addresses your question but that's how things got the way they are in
> the document.

OK. That satisfies my curiosity.

> If there's some better or additional text you'd like to see for the
> security considerations, please do suggest it.

In addition to what is there I might add something like this:

There is an assumption that the client and server agree on the set
of trust anchors the server uses to create and validate the
certificate chain. Without this assumption the use of a SubjectDN
to identify the client certificate would open the server up to
certificate spoofing attacks.

> On Tue, Nov 14, 2017 at 4:44 PM, Leif Johansson <
> <>> wrote:
>     So I reviewed the security considerations text which basically sais
>     that the server can avoid being spoofed by managing its set of trust
>     anchors. The text is better than nothing.
>     However this lead me to ask another question about the use of
>     SubjectDN as an identifier for the subject in client metadata: don't
>     we expect certificates to be issued as short-term credentials from
>     an STS-like thing?
>     If so the SubjectDN is probably going to change every time the STS
>     gets called (say by including a serial number) and such a SubjectDN
>     probably isn't the best thing to put in client metadata.
>     Would it make sense to make it possible to identify subjects based
>     on (say) SubjectAltName as an alternative for this case?
>     I don't want to hold up the process on this but I'm curious if this
>     has been raised or just overlooked...?
>             Cheers Leif
>     _______________________________________________
>     OAuth mailing list
> <>
>     <>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited.  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./
> _______________________________________________
> OAuth mailing list