Re: [lamps] [art] Artart last call review of draft-ietf-lamps-e2e-mail-guidance-14
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Thu, 22 February 2024 16:45 UTC
Return-Path: <dkg@fifthhorseman.net>
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 AE8A0C15108D; Thu, 22 Feb 2024 08:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.313
X-Spam-Level:
X-Spam-Status: No, score=-1.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b="VKguBS+m"; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b="2NDgxe6f"
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 TeO8c_0Mcb0J; Thu, 22 Feb 2024 08:45:12 -0800 (PST)
Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 66A81C15154D; Thu, 22 Feb 2024 08:45:11 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1708620309; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=gJrRkDAcra0MpKK10I7xIlcvsTNORDcZT2T0eSgb8ok=; b=VKguBS+m/WuDVRNn0gNpFm4mY1jQp+/eGmWkfq13X6wT2CbWhdBBYbNE0Bwz9u0A+0RAz uP8pDwWl5KuSSNgCw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1708620309; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=gJrRkDAcra0MpKK10I7xIlcvsTNORDcZT2T0eSgb8ok=; b=2NDgxe6fsLBwUiFjWXkzlW0KMc+KLJvJ2fNu2afhjixXClsmC46z8qOcXrPbms50ZGwaa sMJkkR7t/QC3fVOwtmdZnY8D6sdlStUdAxHxTeW75NvK5KG7B6PMpa+Go/TdUMDYsQb4vp7 e1yC/w0XxYz8ZwJ/qY22K9ASiXvxeeP+YjzsVsDwN/mWSKeYYSSmzJE1EFZxgYds96XGzQa 3JnFeObNimuSvCMXT9v/1DJhg/JwzpG7HJqCHaaoWKWMgPKJ0yalT1ZOIuYW/8Wsr0qAUCp HSCb1YmARYVtY/u1IwmtH/SoStHKwqv2ojfVvNDjF0htm0aIWta20HzDWNQg==
Received: from fifthhorseman.net (AMERICAN-CI.ear2.NewYork6.Level3.net [4.59.214.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 56BF2F9D8; Thu, 22 Feb 2024 11:45:08 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 46C8720591; Thu, 22 Feb 2024 11:45:05 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Steffen Nurpmeso <steffen@sdaoden.eu>, Alexey Melnikov <alexey.melnikov@isode.com>
Cc: art@ietf.org, draft-ietf-lamps-e2e-mail-guidance.all@ietf.org, last-call@ietf.org, spasm@ietf.org, Steffen Nurpmeso <steffen@sdaoden.eu>
In-Reply-To: <20240221234336.D0kH-sLw@steffen%sdaoden.eu>
References: <170853514591.36140.8781659777953563140@ietfa.amsl.com> <cc9f4cb9-8a20-45a0-ab03-752b7c4b0ab7@isode.com> <20240221234336.D0kH-sLw@steffen%sdaoden.eu>
Autocrypt: addr=Daniel Kahn Gillmor; prefer-encrypt=mutual; keydata= xjMEZXEJyxYJKwYBBAHaRw8BAQdA5BpbW0bpl5qCng/RiqwhQINrplDMSS5JsO/YO+5Zi7HCi QQfFgoAMQWCZadnIAUJBdtHCwMLCQcDFQoIApsBAh4BFiEE1HcEDHDCFWpcKYVJu36RAUlea/ cACgkQu36RAUlea/edDQD+M2QjnoEyu/TjI+gRXBpXQ5jCsnnp9FdYhaSSUW/vZ8kBAJByWlj A9aMfVaVrmvgcYw7jzJz+gmZspBRB++5LZ20NzRc8ZGtnQGZpZnRoaG9yc2VtYW4ubmV0PsLA EQQTFgoAeQMLCQdHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnEu/CS CeyWwC6j4ihJr2u/z6delsF1pvYW3ufgf1L538DFQoIApsBAh4BFiEE1HcEDHDCFWpcKYVJu3 6RAUlea/cFAmWnX5AFCQXZ8EUACgkQu36RAUlea/cjVwD+ONjdHM74rAa6EEiiqaPjlptiaZx CVqFYXnib6EbZARkBAPnnR8pW8vCBnDXHKu65jNqwF3aH761NaOqqMFfppg8GzjMEZXEJyxYJ KwYBBAHaRw8BAQdAjX25Fq2Q9IUFeHy6yByIQPBnFOedFliuEiCIUzJsENDCwMUEGBYKAS1HF AAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnwqKWsw56uoWVLIFcs7ZecJ gwpsSNevWCzbviKQ8yRLUCmwK+oAQZFgoAbwWCZXEJywkQdy0WHjXNS4FHFAAAAAAAHgAgc2F sdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnEIJSOxuw2y/UJmg5M3BLpN0JYjODZpXiEVFu 1byARzMWIQR0vATEPYYIS+hnLAZ3LRYeNc1LgQAAsH8BAKg1C5LK/D7pSkXCD+jfTSP+CqM58 iHLjh4vKhpOKsTJAQCHldtEjxJ1ksPTFgG9HihHH7qc6/wvvLw77ETMpwlrAxYhBNR3BAxwwh VqXCmFSbt+kQFJXmv3BQJlp1+rBQkCF4lgAAoJELt+kQFJXmv3ydsA/2roQZ2Jm/7iUrg/2C5 ClWA/xbvPC31LyMkGGH2/rq8tAP9BgqLuCPnNTVPqeX9+9qqMmaFq7wmvjq5I+yycAw9CDc44 BGVxCcsSCisGAQQBl1UBBQEBB0BZMsRrRaaeFSYMF1ZdfRmVgBriDUIr99eDQ085BK14DgMBC AfCwAYEGBYKAG5HFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnsazAWX tEHUPmSTmcRZAIsAsNiO8k0hdjsfRlRVipgJgCmwwWIQTUdwQMcMIValwphUm7fpEBSV5r9wU CZadfqwUJAheJYAAKCRC7fpEBSV5r90AjAPwLgY1iKiFJEj32SVD5f721929l79VxQB5FlQss x1n5kQEA6Uct2tPvbB6T7p5KG3Gl+tbi7oJAuxFmpkpW5/N2Owg=
Date: Thu, 22 Feb 2024 11:45:04 -0500
Message-ID: <87plwosb1r.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/cCSfW2ClnERmCe0LEVRZZlPZbMs>
Subject: Re: [lamps] [art] Artart last call review of draft-ietf-lamps-e2e-mail-guidance-14
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: Thu, 22 Feb 2024 16:45:16 -0000
Hi Steffen-- On Thu 2024-02-22 00:43:36 +0100, Steffen Nurpmeso wrote: > user SHOULD have both a signing-capable certificate and an > encryption-capable certificate (and the corresponding secret > keys) > > is something that causes a headache for me. It may be a headache, but it sounds like that's due to your tooling for X.509 and secret key management, which has poor usability. One of the critical observations in this draft is that the tooling needs better usability if we expect normal users to adopt. That said, no normal e-mail user should ever come near the OpenSSL interface, either the cli or the C interface. The MUA needs to handle these operations for the user in a reasonable fashion. > Anyhow, there is no distinction in between a "signing capable" and > an "encryption capable" key. The keyUsage and extendedKeyUsage flags in X.509 certificates clearly distinguish between signing and encryption use cases. Using the same underlying cryptographic object for both protocols without a proof that the protocols cannot interact runs the risk of cross-protocol vulnerability. The cryptographic objects in question are cheap. There is no shortage there, and there should be no harm in producing two of them rather than one of them. If the process of getting a corresponding X.509 from an authority is too cumbersome to handle two at a time, that is a flaw in the process with the CA. No reasonable CA should want their subscriber to rely on the same cryptographic object in two distinct cryptographic schemes; that simply puts the certificate that they have issued at risk of abuse. > Ie, i do not understand > > 8.2.3.1. Shipping Certificates in S/MIME Messages > > either, because i would not even know how to avoid including the > certificate that any receiver can then use to send encrypted email > back to me. The guidance in the draft is intended for MUA implementers, not for end users. End users are not expected to select which certificate to include. If the MUA implementer cannot control which certificates are included in the CMS object due to limitatins of their chosen CMS toolkit, that is a flaw in the CMS toolkit. > Btw i have sympathy for full key management and master keys and > dedicated subkeys. However a nice TLS+DNSSEC secure DNS TXT entry > with an ED25519 or so certificate (ie: *impossible* with OpenSSL), > with an identifier (or, in DKIM terms: selector) i can bake into > the certificate in order to be able to rotate, i find even better. > Ie, if compromised, create a new one. No CRLS, no OCSP, simply > a X509-baked-in selector and a DNS record. It sounds to me like you're asking for some sort of DANE authentication record. The most straightforward approach for that would be SMIMEA (RFC 8162), which is referenced in the draft. > Btw i have yet to see ACME for S/MIME in real life. Does this > exist? Are you talking about RFC 8823? That certainly exists, and there are software packages that implement it (e.g. https://acme.castle.cloud/). Or, are you asking whether any major CA offers it? I haven't done a full survey, so i'm not sure. Maybe some CA operator wants to weigh in on this? Certainly an enterprise running their own CA could offer it in a pretty straightforward way. > I was thrilled by your efforts to bake this into a standard, but now > the IETF really kills business models, does it. ??? > That is: i see no dedicated subkeys or anything. An X.509 certificate does not have "subkeys". You need a distinct X.509 certificate for each cryptographic public key operation: one for verifying signatures, and another for encrypting data. They should be over different underlying public keys, but have the same identity information. Regards, --dkg
- Re: [lamps] [art] Artart last call review of draf… Alexey Melnikov
- [lamps] Artart last call review of draft-ietf-lam… Bron Gondwana via Datatracker
- Re: [lamps] [art] Artart last call review of draf… Steffen Nurpmeso
- Re: [lamps] Artart last call review of draft-ietf… Daniel Kahn Gillmor
- Re: [lamps] [art] Artart last call review of draf… Daniel Kahn Gillmor
- Re: [lamps] [art] Artart last call review of draf… Bron Gondwana
- Re: [lamps] [Last-Call] Artart last call review o… Bron Gondwana
- Re: [lamps] [art] Artart last call review of draf… Daniel Kahn Gillmor