[lamps] Distinguished names for self certified TLS client authj

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 14 June 2022 19:58 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CCCC14F740; Tue, 14 Jun 2022 12:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.407
X-Spam-Level:
X-Spam-Status: No, score=-1.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZ5b7_7H0cbh; Tue, 14 Jun 2022 12:58:26 -0700 (PDT)
Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2A6C14F6E5; Tue, 14 Jun 2022 12:58:23 -0700 (PDT)
Received: by mail-yb1-f169.google.com with SMTP id r82so16882081ybc.13; Tue, 14 Jun 2022 12:58:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ocVzbXygtOAItW5qAzfWf2yyN1AVKqV+SFrpWpbo4DA=; b=ba2iBfV1nIFz3zUsY0Y6984iAkpmWw6IfygnFjo+b1+sZLEGw4h17PvTRY5P6ulSrE sO/ZNIldk1mRbyo8PpXm0uC0sympEASziCSnlJmmeVhoqJ8F5BAWpxOFucysP5/f8FTT Knm0iJxuHxYdk5ivfgxzOv+pDbGfMCbw2HE1S5/EufTHTA5JhzZgbUz3hgPP7k6xo4Qb QByLz89U6mI27BHbqj1Sr4ghDnnN8BbJjcc9uPwE/4kENOe9tC6YGSbSwl1d4Klm4e4U ahvAonA6AVpOOmaI4E+RqXDasqxOXQcVd8kNSxrtIyf1OlnJGAN2cDtfXbCOeOrDNYH8 Yn0w==
X-Gm-Message-State: AJIora8c1A8W9BMwkkpGPRS0kBL0dQ2ut8YNa3CvpylZOPRtF1K65W5V lMRkWGWJOSyCsr7d3ZWUGiNnMGxlVisJam+FJ0bwwU9PIffrHg==
X-Google-Smtp-Source: AGRyM1uONv+UiH0U85N1MLM53+Y92N+FVsf/uyRKlDu6WEAcQTsE0t1tlc66OzLYIJrgWamju2wkN6i5kja0cFz6XFQ=
X-Received: by 2002:a05:6902:1202:b0:661:821f:ba94 with SMTP id s2-20020a056902120200b00661821fba94mr6737351ybu.133.1655236702461; Tue, 14 Jun 2022 12:58:22 -0700 (PDT)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 14 Jun 2022 15:58:10 -0400
Message-ID: <CAMm+Lwifpf1DCtFtc-sY_sK2tbW02rON9oyjPzwyoCQ6Hcgfvw@mail.gmail.com>
To: SPASM <SPASM@ietf.org>, tls@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ab682d05e16dd318"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/-JNtU5XdS3UTvEXXhyX8E7AoVEs>
Subject: [lamps] Distinguished names for self certified TLS client authj
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2022 19:58:27 -0000

[Yes, I am aware of the FIDO work and it is a completely different use
case, does not apply to non web applications. TLS Client Auth is an IETF
spec and thus within IETF scope.]

I have an infrastructure that makes private key management really simple
for end users. They can manage private keys across devices without being
aware they are doing it. This technology has obvious applications for
existing public key authentication schemes including EAP, FIDO and TLS
Client Auth.

When looking at TLS client auth it seems to me that it is much closer to
being a viable replacement for some uses of passwords than experience leads
us to believe. In particular, I have maybe 5 accounts I might use a
hardware token to secure but I have several hundred Web accounts that all
use the same password because when it's not my asset and I am not
being paid, I don't use my brain power to remember the password.

So my basic idea here is that Alice connects all her devices to her
personal Mesh and they are automatically provisioned with a device specific
cert that is chained up to one of Alice's personal PKIX CAs. The CA in turn
being (optionally) credentialed under Alice's personal Mesh via an
extension if the goal is to establish that the 'Alice' visiting site A is
the same as the Alice visiting site B. For cases where we want to prevent
linkage, we develop a separate CA per site.

This is not how PKIX is intended to work of course. But the deployed
infrastructure supports PKIX and so that is the framework we have to work
within.


Looking at how TLS Client Auth works as deployed, a server sends a message
back to a client saying 'client certificate required' and a list of
distinguished names of CAs it will accept.

So what I want to know is not 'should I do this', but 'what is the string I
should send when I do'. That is, this is something I am planning to do and
so I am asking what approach is least likely to have unintended effects.

I see a need for two distinguished names:

A) 'Self signed CA speaking to any relying party'
B) 'Self signed CA speaking to a specific relying party'

The server is going to check the certificate chain itself on the other end
of course.


And again, yes, I do fully understand the limitations of transport layer
client auth. That is why I make use of my own authentication layer for Web
Service transactions.