IETF Logo Mail Archive

Re: [lamps] [EXTERNAL] Re: I-D Action: draft-ietf-lamps-im-keyusage-00.txt

Michael StJohns <msj@nthpermutation.com> Wed, 17 April 2024 20:17 UTC

Return-Path: <msj@nthpermutation.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 44A90C14F5F7 for <spasm@ietfa.amsl.com>; Wed, 17 Apr 2024 13:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 FIMtAnsrd687 for <spasm@ietfa.amsl.com>; Wed, 17 Apr 2024 13:17:26 -0700 (PDT)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 F0B42C14F706 for <spasm@ietf.org>; Wed, 17 Apr 2024 13:17:26 -0700 (PDT)
Received: by mail-qv1-xf2d.google.com with SMTP id 6a1803df08f44-69b6d36b71cso683606d6.3 for <spasm@ietf.org>; Wed, 17 Apr 2024 13:17:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20230601.gappssmtp.com; s=20230601; t=1713385045; x=1713989845; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=dlYO9isfKa+QAdFaZwSlZY1FEDw1o3YJqcNy8Bl/gx8=; b=FqHlV07Ecm0tTxQEcvy59voZGYe98RLEpV+oPQkN7byOZY+jneHlgfCi3poynKE1nI OR/R6IvO/+H+y/Ns9knRYaZWx7L1pB5OG/WemnK209nNR7kfTSEtMEjHTbZ74JwHDhST l745V43mzkfOeCVrtJ6DKtYKgqqjIc0deug8CBmU0aw2LirpB5ZdLGU73eN4I1yQCL9c 7DH481GLB3lajmepbB7tdX6us77//84cSfaReYosG9dcMMBvcqUAWQXJDYMGQjCmEa6o CW1KfJNgeHDiq23Fgm3NJn/yfcobXlGzZDigko1uijhuchwxDtTJZIFHr3RrxPRiGjQs T2AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713385045; x=1713989845; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dlYO9isfKa+QAdFaZwSlZY1FEDw1o3YJqcNy8Bl/gx8=; b=Q9lkFCvwYLIWbfLsq2PnjYIxkINUL1F+LH/R72rNfWx7Dswl7TZGpHEWpLugGDt0ZU Pk2Fw+yqWu/Sdh1CBZaM5bkNwPMQ3+9Q+z6GfcnsttulI8JjwKO2xDIlxeeeenIUA+48 V6EbNxS7JXcz2EtAOUdOCqy/YEl9I1wzAzbNVRG+64xOy1+J61SuuY1gMcz8AJ5whWoL iTeYwIe8hXS5e51TNE48WQTYd2ykQ+0kFVZYIFfI8kT0rpruwll4X9NtsaUpRb2eiPYt G2YmFOtwYdLtET/9ZMF7Rr4IanRtuQ/Gy4XjGYXTyUYTH+iHTUXPJXkiwBCfAVqBN6LM eJLQ==
X-Gm-Message-State: AOJu0Ywqumr0NS0/G8KVmfdtMSM4309vUMoS1esj+W5dxeMXekqF9tWf 6gXsEpi6uZyejxv7my1seawIPZxNo+3T7Dk8P5zfK2/QRFIOLWCQf4xnXrwvB40=
X-Google-Smtp-Source: AGHT+IHIHnlhmqFEY0Q/XG23vUne0NuRoIm8pcg7QvE5lJVn3rE07+QG3Mf9TW3phxi8xcIqq2UDSQ==
X-Received: by 2002:a05:6214:16c3:b0:699:148c:b600 with SMTP id d3-20020a05621416c300b00699148cb600mr531372qvz.22.1713385045233; Wed, 17 Apr 2024 13:17:25 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-31-156-76.washdc.fios.verizon.net. [108.31.156.76]) by smtp.gmail.com with ESMTPSA id i6-20020ad45386000000b0069b4d64ab0bsm8289774qvv.138.2024.04.17.13.17.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Apr 2024 13:17:24 -0700 (PDT)
Message-ID: <7f38a01f-d646-4a5e-b1e5-ff1b85d82d00@nthpermutation.com>
Date: Wed, 17 Apr 2024 16:17:21 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Rohan Mahy <rohan.mahy@gmail.com>, Tim Hollebeek <tim.hollebeek=40digicert.com@dmarc.ietf.org>
Cc: "spasm@ietf.org" <spasm@ietf.org>
References: <171320513468.22285.6899802433610546466@ietfa.amsl.com> <B508131E-0554-471F-94FD-4AA2A0A95346@vigilsec.com> <CAKoiRuYCSwdzwKwSXdyLCNm5Z3DzzzLZzSyDO7DGWHTSeUj-fA@mail.gmail.com> <2E8965D1-F0D8-4947-8A6B-19B822EEFA4C@vigilsec.com> <CH0PR11MB5739FF2B9A378DF7ADFF24E69F082@CH0PR11MB5739.namprd11.prod.outlook.com> <CAKoiRuY5Caq_61+99RQiaRkeKUAou=fiLj+HadajzhwhLKOdAA@mail.gmail.com> <CH0PR11MB5739A5999D59A046D056812C9F0F2@CH0PR11MB5739.namprd11.prod.outlook.com> <CH0PR11MB5739690323861CECECA630AF9F0F2@CH0PR11MB5739.namprd11.prod.outlook.com> <0f7f609b-9283-4f59-bb32-375827d3e7a6@nthpermutation.com> <SN7PR14MB64927E6AB1914083C485E0EA830F2@SN7PR14MB6492.namprd14.prod.outlook.com> <CAKoiRuZeuDOG+Hm97mE2jwJ7w4gXjyvpTj7o3nOykQuufRDv_Q@mail.gmail.com>
From: Michael StJohns <msj@nthpermutation.com>
In-Reply-To: <CAKoiRuZeuDOG+Hm97mE2jwJ7w4gXjyvpTj7o3nOykQuufRDv_Q@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/s4-qF32k4bl3mdywDZ-tboF-WCI>
Subject: Re: [lamps] [EXTERNAL] Re: I-D Action: draft-ietf-lamps-im-keyusage-00.txt
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: This is the mail list for the LAMPS Working Group <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: Wed, 17 Apr 2024 20:17:31 -0000

On 4/17/2024 1:37 PM, Rohan Mahy wrote:
> We clearly don't want someone reusing keys for multiple purposes.

What I believe is meant by this is not using the same key for both Key 
Agreement and Signature.  Or signature and encryption.

IMHO, that's not a statement with the effect of preventing a single 
signature key from being used for TLS and IM.

The former is a crypto properties thing that is good practice, the 
latter is trying to write unenforceable restrictions into a certificate 
and expecting enforceable results.

Later, Mike

v2.23.0 | Report a Bug | By Email