Return-Path: X-Original-To: openpgp@ietfa.amsl.com Delivered-To: openpgp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8C112008F for ; Fri, 27 Sep 2019 06:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vg44ghTUO4A0 for ; Fri, 27 Sep 2019 06:44:56 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77B0120832 for ; Fri, 27 Sep 2019 06:44:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 92393E2042; Fri, 27 Sep 2019 09:44:49 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 27702-03; Fri, 27 Sep 2019 09:44:46 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id E7665E2040; Fri, 27 Sep 2019 09:44:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1569591886; bh=kIdj+k7a5Br4Fob9ottAn0brfpuls6mSgMWcPQvhpeI=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=IoHu1MlJ84QVbx+r3ryhMI2aQL3QD0hbi35/Edagv0ypKI5bEP9ds36UA4rLJpoA6 x0z/ej6HSA901L+9yWDObBC1sC2HEjW1o09mMgh7NNR5He3c6QOQE2iCzvWRdieHzg kIb5wnoKGmqnquoqM+Ko10vpSMM4vtgsYm/A0iBM= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x8RDicGL008473; Fri, 27 Sep 2019 09:44:38 -0400 From: Derek Atkins To: Justus Winter Cc: Jon Callas , openpgp@ietf.org References: <8994782B-12D6-4B91-BA7A-1BF6BF4E7951@icloud.com> Date: Fri, 27 Sep 2019 09:44:37 -0400 In-Reply-To: (Justus Winter's message of "Thu, 26 Sep 2019 22:15:58 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: Re: [openpgp] Message padding in OpenPGP X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 13:45:02 -0000 Justus Winter writes: > On Wed, Sep 25, 2019 at 4:32 PM Derek Atkins wrote: >> Why not just have multiple literal packets inside the encryption? I.e.: >> >> ENC{ Lit1{realData} | Lit2{pad} } > > Because that is not a well-formed OpenPGP message. Neither is anything else you are currently proposing. If you're going to extend the spec to add a new packet type you might as well extend the spec to allow this, which is easier. And honestly many parsers (at least the parser I wrote in 1995 which AFAIK is still in use by at least one implementation) will actually parse this structure properly. > Cheers, > Justus -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant