[openpgp] Re: Fwd: New Version Notification for draft-gallagher-email-invisible-signatures-00.txt

Steffen Nurpmeso <steffen@sdaoden.eu> Wed, 07 May 2025 20:01 UTC

Return-Path: <steffen@sdaoden.eu>
X-Original-To: openpgp@mail2.ietf.org
Delivered-To: openpgp@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 300792617B51 for <openpgp@mail2.ietf.org>; Wed, 7 May 2025 13:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=sdaoden.eu header.b="aPEBVvwP"; dkim=neutral reason="invalid (unsupported algorithm adaed25519-sha256)" header.d=sdaoden.eu header.b="KqI3HoQZ"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z8CqZecb5Yq for <openpgp@mail2.ietf.org>; Wed, 7 May 2025 13:01:22 -0700 (PDT)
Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 4FAB72617B49 for <openpgp@ietf.org>; Wed, 7 May 2025 13:01:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1746648080; x=1747314746; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: author:from:subject:date:to:cc:resent-author:resent-date:resent-from: resent-sender:resent-to:resent-cc:resent-reply-to:resent-message-id: in-reply-to:references:mime-version:content-type: content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=+CwYHl2suUrUn3hNJ0KZaMrHxAchAjgGB7vMjXqzCRE=; b=aPEBVvwPE0FY5Ldy52KfgEe9kUHiknHfdrUm6HJpqlm1GlmHxqXEsLuyVcvoTw2EpZrj1Ej6 1jHu6ojGqRVol8BAdTZ8INM1h0ZUeF1dWKpqvipP+zQ0Rdm8rqiTqyKXcGOyNbDbsvNhJ85eqm s8p14uUiTk8WOO4sFQyFzk9AuvGjed4/J85cfV1QIPdk+aeRhC9aj2/5sfkZu4cVp4babtAM39 PWxOcOSM3aaMoeMyWCAhl0sMhX9Ab/szG7LvbdrVMTwVZTyLnrMknrDsjA3QrzJ+68NYiSWGYk Z8qI6QgHBxhq/6+nLt9GbuXdPoefO5d5QEiEUQF7qncmqzKw==
DKIM-Signature: v=1; a=adaed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1746648080; x=1747314746; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: author:from:subject:date:to:cc:resent-author:resent-date:resent-from: resent-sender:resent-to:resent-cc:resent-reply-to:resent-message-id: in-reply-to:references:mime-version:content-type: content-transfer-encoding:content-disposition:content-id: content-description:message-id:mail-followup-to:openpgp:blahblahblah; bh=+CwYHl2suUrUn3hNJ0KZaMrHxAchAjgGB7vMjXqzCRE=; b=KqI3HoQZ0eG7f5ZEqVsRULHe8MlbxMebzZfhC6+KFmsO2f/zLOpWyX9qiynyOpCv+L+ILhFI SDpm2dePWmt0DA==
Date: Wed, 07 May 2025 22:01:18 +0200
Author: Steffen Nurpmeso <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Andrew Gallagher <andrewg=40andrewg.com@dmarc.ietf.org>
Message-ID: <20250507200118.7B1zRSG5@steffen%sdaoden.eu>
In-Reply-To: <5E01CE52-2B15-48BA-BCEE-4E7FAB7FBD02@andrewg.com>
References: <174626909298.338737.10420965667394729319@dt-datatracker-58d4498dbd-6gzjf> <5E01CE52-2B15-48BA-BCEE-4E7FAB7FBD02@andrewg.com>
Mail-Followup-To: Andrew Gallagher <andrewg=40andrewg.com@dmarc.ietf.org>, IETF OpenPGP WG <openpgp@ietf.org>, OpenPGP-based Email Encryption <openpgp-email@enigmail.net>
User-Agent: s-nail v14.9.25-650-g387a4a6421
OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt
BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs.
Message-ID-Hash: DXDQRBTYDWMIOFBCM7G4OLTQWGADSGDP
X-Message-ID-Hash: DXDQRBTYDWMIOFBCM7G4OLTQWGADSGDP
X-MailFrom: steffen@sdaoden.eu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-openpgp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IETF OpenPGP WG <openpgp@ietf.org>, OpenPGP-based Email Encryption <openpgp-email@enigmail.net>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [openpgp] Re: Fwd: New Version Notification for draft-gallagher-email-invisible-signatures-00.txt
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/6bksqao12x9NPFGQCiks4QGZvJg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>

Andrew Gallagher wrote in
 <5E01CE52-2B15-48BA-BCEE-4E7FAB7FBD02@andrewg.com>:

   This MIME structure MUST NOT be used as part of a Multilayer
   Cryptographic Envelope.  If it is found anywhere but the outside of
   the message it MUST NOT be treated as a Cryptographic Layer.

This is hard to understand.  You mean it is not recursive, or do
you mean that is must be on the outermost layer of the message,
and be the only layer multipart?  No to the latter?
(Later it is then made clear.)

   *  Content-Encoding is used to make the message 7-bit clean

I love this.

   *  If "From " starts a line, at least one letter of it should be
    encoded

Do you really mean "a 7-bit content-transfer-encoding is to be
enforced"?

   FIXME: is all this really necessary in 2025?  What if we said that an
   Invisibly Signed Message that needs 8BITMIME simply can't be
   transmitted across an MTA that doesn't support 8BITMIME?  Or what if
   we decided that it's OK if the signature breaks in that case?

I would say "yes", and if only to deal with bugs.  For example the
MUA i maintain simply passed 8-bit over SMTP regardless of the
above SMTP extension. .. except when S/MIME enforced convertion.
(Ie "could have", it was dependent upon user configuration, but
the default was 8-bit.  And it will support 8BITMIME only with the
next release.)

(I hm "love" Unicode and am practically most often 8-bit in
private (German), but i think the concept of "UTF-8 email" is
bogus -- in sofar as noone really can look at a raw message as it
is on the fly in current times; so many mysterious headers, etc,
the common image etc attachments surely content-encoded, and then
even larger to skip over, etc: any "normal" and "sane" person
needs a utility aka mail reader to deal with emails.  That little
piece of text is alone in its transport 8-bit clean data quest.)

May i ask why the hp="clear" parameter was added?  Isn't it enough
to create the Sig: header?  The "cryptographic payload" begins
directly after the Sig: header.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)