[TLS] TLS specification clarification in case of client authentication: different CA with DN different only in case
devzero2000 <pinto.elia@gmail.com> Mon, 25 September 2017 16:21 UTC
Return-Path: <pinto.elia@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4171344CC for <tls@ietfa.amsl.com>; Mon, 25 Sep 2017 09:21:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 WQ4FwAOjmXPG for <tls@ietfa.amsl.com>; Mon, 25 Sep 2017 09:21:13 -0700 (PDT)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 5DBF61344AE for <tls@ietf.org>; Mon, 25 Sep 2017 09:21:10 -0700 (PDT)
Received: by mail-yw0-x22f.google.com with SMTP id u205so5097278ywa.5 for <tls@ietf.org>; Mon, 25 Sep 2017 09:21:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OoX6mvJ0XAp1lCWJBL1zyldoXbcuDI4TiBNqq2djTtE=; b=VOFt4w1BjFDoIqyOQGBKYrfI4pnYBYSn0kv3/KCLbKjeGvJNPeX3LIfBaukeE9sJfg S+5Fg8sYzCIZ8+RD2dWmP05YrfacXrAMOVXgs+0poXt9Y3oekDpCemtJJwSmkZai19+q prlR0eQgzKV4/bGDzwwWgI/YI2sbWOL2cay6pxwt2cJm6wzeH/ABwpBiYVYDbcDCPhyW awJa2lG6aB7QFTRWB57TAVBchLi/FNha/VOmiH6Vez4NSi9g7HRnZYBE55ijkyamHC9v 7ZZ7QCoJv4vAioPjGd9ZEsDhHRN6IINApI6doR5FV5DqHX6rWUk4Qp2mWMDLAm+SFj+U qOog==
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=OoX6mvJ0XAp1lCWJBL1zyldoXbcuDI4TiBNqq2djTtE=; b=lXGIFgB+FWlVtkek10vblWNDgtvOzdM1eab+VxjlAeoZgirAqclk26MqbJGU0Z0bs6 tHNU5FLURTpyX8xC4rQvIlehTpMPb2W9S8kRhaTYjCi2IV6K0dI6P+MrL80Raf4ZZWqV roLGwhe+OxGrMMnGRQG2ymHWo4LsS0kKlnXeiPs0pvfP6etRWAyySz7J7Dxwr/mTnf4U i5Cejyu735cPa217iTYlliRyDvBPTWzYPZI50pO+nrSC81//a0QapOao2gHhfclSutw2 PhxPUMENWb4rkFasXWv+R6Gyu+eDhSaClEGQtZ2deKbJ2zeilWSFjD4YP8DSCbAwqC3L d9Cw==
X-Gm-Message-State: AHPjjUjFJl+2QItMjLGgFLYKAYxA7kKlpZ/UMNek4FeBsJ1pH5SwIHVo IGCc78sKGC6HY4CRIQmjPfZMsdBAqvj3gkLJEJEzqg==
X-Google-Smtp-Source: AOwi7QBShgZizEgFYVq+jg7lHtt/qUCD92hLWi8Hf6Dw8HcyemLcDVOj9JDkL+K67MrmQP1x6Spuc5E8JdQN13pzb3Q=
X-Received: by 10.129.156.200 with SMTP id t191mr4726882ywg.279.1506356468816; Mon, 25 Sep 2017 09:21:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.234.17 with HTTP; Mon, 25 Sep 2017 09:21:07 -0700 (PDT)
From: devzero2000 <pinto.elia@gmail.com>
Date: Mon, 25 Sep 2017 18:21:07 +0200
Message-ID: <CAH5b-BXvZRYNfn-R6cyO-1judwVYUXktaJtRVFwevUfWD5q8Jg@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0c091a3aa237055a05f2cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/uR57zzdwHJMXKHInarTsCLbKYv0>
Subject: [TLS] TLS specification clarification in case of client authentication: different CA with DN different only in case
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Sep 2017 16:21:15 -0000
Hello everyone >From the tls 1.2 specification, speaking of client authentication, https://tools.ietf.org/html/rfc5246#section-7.4.4 par 7.4.4 (but it is the same for the last tls draft 1.3 par. 4.2.4.) when he says: certificate_authorities A list of the distinguished names [X501] of acceptable certificate_authorities, represented in DER-encoded format. What would be the right behavior if the server has the certificates of two different CAs (different subject key info, public key parameter) but whose subject DN differs only for the case (for example something like this Subject: /C=US/ST=California/L=Mountain View/O=XXX Inc/CN=mail.xxx.com and Subject: /C=US/ST=California/L=mountain View/O=XXX Inc/CN=mail.xxx.com Note the different (M|m)ountain ) 1 - In one case the server could send both DNs to the client, the client could choose the one that signed its certificate, and the server would be able to validate, based on the autority key identier, the client with the right CA. 2 - In another case, instead, the server chooses to send only one of the two DNs, probably the first configured, and if that is not the one that signed the client certificate, the authentication would not continue. I have seen that some TLS implementations follow both of the behaviors described and this creates interoperability issues, i think. It should not be an ambiguous behavior, and it should be clarified. Opinions ? Thanks you very much for the attention Ciao Elia
- [TLS] TLS specification clarification in case of … devzero2000
- Re: [TLS] TLS specification clarification in case… Geoffrey Keating