[OAUTH-WG] Re: Call for adoption - PIKA

Richard Barnes <rlb@ipv.sx> Wed, 18 September 2024 14:31 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB574C14F6FC for <oauth@ietfa.amsl.com>; Wed, 18 Sep 2024 07:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20230601.gappssmtp.com
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 EtX_SX0GPGlL for <oauth@ietfa.amsl.com>; Wed, 18 Sep 2024 07:31:45 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F8FC1388BA for <oauth@ietf.org>; Wed, 18 Sep 2024 07:31:45 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id e9e14a558f8ab-3a09a62e5deso20102905ab.1 for <oauth@ietf.org>; Wed, 18 Sep 2024 07:31:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20230601.gappssmtp.com; s=20230601; t=1726669904; x=1727274704; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fQgDNzoOXNjWgf3/x2EESdNOR+1uGaICWJgI+vTsWzs=; b=ibel6rcAzCfw8ekaLMhX7n8C68xfJf73qOx4/L+kCdQ20K7WV59Itck10O3/6mNsk1 mUIWFqP8x9oIQYJhN2OCr4KQugssQCle7OeLQp/gSSQyoecUNc34OMCu3URFYzbf3/bJ hwbhc5FIzhlqluBKAIldB3COsx7HVAwawHMv5MAvvriQM+khx55zTkrE2C8bxkOPn9Vp 1S+vp8QMjd2szbdORuzdvUHWgGbPT48LS2oy9Ahso6d/rJjbuZ2TIdxyLPZg8iGRJKlx oKZBT9+chEtiHeMfCmHsVHHn2O2gK+v7Dd7GKhSpa1/6BPkmRI1moot3GOOwanF7S983 xFuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726669904; x=1727274704; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fQgDNzoOXNjWgf3/x2EESdNOR+1uGaICWJgI+vTsWzs=; b=AXB5eQkwV1wS4nFL7MzdVWOwaWUgiDCRFPAqqNFhfIX1OiEm15afhw1WLmDhUiBoad QJ9gVNHK/dAoWcJ09PlHZC4iS2WEK12OxnRTAnK58avlaiO8iIRg9B16TOaEYQ6Sw5Od MP+zhmCKBaPe0kjOF9ijWUnVkFJgjLhdwkBeK0zjAHLGQCSou/fYjM1RWTvh9DOun7gU hvnfnTBYZb06Nfuis0dWHI0ePgUxMRvKp0UpDamCqefr+2ReAPUhSBLHkcum5WObCpU/ xSzhGkofYW/3hn15+45FRPnPz04Z69yKtvH14qxPDjHTXHnaucixN9pIym5Mip9WMZPZ VBWQ==
X-Forwarded-Encrypted: i=1; AJvYcCV9dwnrSRqT32Y3728un3i/DkTNmfFn9WdZWEfVszoCAW5MxuoqZ8FNpMKEnLGd4cpqKuXX8A==@ietf.org
X-Gm-Message-State: AOJu0Yx491y81P4alAD7sbE4b+e4/cpp9kExKZa0+T7uwc0fGSvjKQYR Hqbh8nCa65tU2jcn5tDBVmGPYkcXOp8C49xrvZg4ePA+ms9NKZArB3+bXSJqJF6s+xmeYJhqtIZ Ho8XEyW16bLZYvApYqYH6pTeGKY1saGRj+QJ5EH6yGNeY9uZIXX8=
X-Google-Smtp-Source: AGHT+IGWDdazEnsdrD0NINJxf2E2LZIVTMJtR3wSruxknREtqcUFeGVx5kh+6D0YUa+9o1PcwMZQlSjj+cFGRFYejJ4=
X-Received: by 2002:a05:6e02:164f:b0:39b:330b:bb25 with SMTP id e9e14a558f8ab-3a0848f7e52mr217607765ab.12.1726669903713; Wed, 18 Sep 2024 07:31:43 -0700 (PDT)
MIME-Version: 1.0
References: <CADNypP80YnzxOc_NDbFqK0bv=i0Ys1s8hYHwo-PqhUPbAWs4sg@mail.gmail.com> <ff6a0d93-af5d-479f-9ae7-14815364a73e@connect2id.com> <2C5BE4BF-9834-49D4-8E14-19DE69AA97F7@alkaline-solutions.com>
In-Reply-To: <2C5BE4BF-9834-49D4-8E14-19DE69AA97F7@alkaline-solutions.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 18 Sep 2024 10:31:32 -0400
Message-ID: <CAL02cgS4Rx=gN_K88RLucB7bgnxZuikfcf8GvOJOUf6dbjS9GA@mail.gmail.com>
To: David Waite <david=40alkaline-solutions.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000417f14062265aaa5"
Message-ID-Hash: TZ7BVSXRM63SL34UD6FQWTH7MSTCCXNE
X-Message-ID-Hash: TZ7BVSXRM63SL34UD6FQWTH7MSTCCXNE
X-MailFrom: rlb@ipv.sx
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: oauth@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [OAUTH-WG] Re: Call for adoption - PIKA
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/KustkKGtMsFjTaX-HplvQt003_Y>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>

Hi David and Vladimir,

We discussed this in the WG session in Vancouver.  The aim here is
certainly not to just take the certificate on the web server and re-use
it.  Rather, we are re-using the underlying PKI.  As I said in YVR and in
my response to Mike just now, we should have separation between web server
certificates and PIKA-signing certificates.  My view is that a prefix is
sufficient ("_pika.example.com").  We could discuss things like EKUs, but
those will be harder to deploy.

In any case, there are solutions here, so I would propose we adopt the
document and then discuss which solution is best.

--Richard


On Tue, Sep 17, 2024 at 6:29 PM David Waite <david=
40alkaline-solutions.com@dmarc.ietf.org> wrote:

>
>
> On Sep 17, 2024, at 1:58 PM, Vladimir Dzhuvinov <vladimir@connect2id.com>
> wrote:
>
> I frankly don't see how the central premise of PIKA - the reliance on a
> TLS web domain certificate - can be made to work in practice.
>
>
> Reasons: Infrastructure in the real world, mixing of concerns, conflict
> with CA policies and CAB Forum requirements, NIST etc guidance compliance
> issues.
>
> I agree with Vladimir unfortunately.
>
> A certificate is a bundle of restrictions, but the two most critical are
> on subject name and purpose. This reuses a certificate meant to secure
> network traffic with a particular DNS name to one securing arbitrary
> application messages from a particular origin.
>
> This would not only break a lot of organizational security policies (and
> potentially conflict with how they deploy their network infrastructure),
> but ignores CA policy that is baked into the TLS certificate.
>
> -DW
> _______________________________________________
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-leave@ietf.org
>