Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis

"brian m. carlson" <> Thu, 02 November 2017 00:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EB4C13F816 for <>; Wed, 1 Nov 2017 17:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (3072-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6FQc_0luPEpD for <>; Wed, 1 Nov 2017 17:00:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CA7013942C for <>; Wed, 1 Nov 2017 17:00:54 -0700 (PDT)
Received: from (unknown [IPv6:2001:470:b978:101:254c:7dd1:74c7:cde0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 0094560475; Thu, 2 Nov 2017 00:00:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1509580821; bh=CttYPMXYsBnfnYGp9sY6likILZetH2erKagUQD6HxxM=; h=Date:From:To:Cc:Subject:References:Content-Type: Content-Disposition:In-Reply-To:From:Reply-To:Subject:Date:To:CC: Resent-Date:Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=D4L3ch3OVJ3YVtY8mD/BjOA8/URLE2r7JwtFDCmx0QfZuSU/pH7Qv5sji+IKNDPp3 bcgScU29d3jDbRtxYPjpzK8CeIZlrU/UvhGkZ5bYg+18eeJLyaWzjoZ2F/lsxHBl8l aXTw27n2WgYL7joC1Y77ekiOjBROv/E7+RQNkqMn3hiTwpTblpgIlLFduNV77zZzlC ++P1oXL/xhH1fL8CFHA9SVKtmJYDp0wjgs4A2pTZNNuX1ofu059AVi0eJtM9B8Wc7g RwaXIngZWlDE3TCUJ7qiMyILQwEY/37m6j4drf3wjzoZx5R2+3Cp9NBTPG2fR8aaOI aklsr/e7QpcAIe6bOVFSqzK1zCUvsSWeFDAmzUKB3gtiiSgJZ3LjgrgfK7viP5zhwj E8+QI7BgvjBx+jxItGcc3PsrSrsInPc8irCpr537g/AAc2/Cm9XsYj/3AhR4+Vqvjh HZpyweniuwxfsuiKRBqB7MNME0YCiSr8cS7YXR7LNbdvRi1Ia2A
Date: Thu, 2 Nov 2017 00:00:16 +0000
From: "brian m. carlson" <>
To: Derek Atkins <>
Cc: Ronald Tse <>, "" <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xwiu3tcbhytecxll"
Content-Disposition: inline
In-Reply-To: <>
X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.13.0-1-amd64)
User-Agent: NeoMutt/20170609 (1.8.3)
X-Scanned-By: MIMEDefang 2.79 on
Archived-At: <>
Subject: Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Nov 2017 00:00:57 -0000

On Wed, Nov 01, 2017 at 10:35:59AM -0400, Derek Atkins wrote:
> "brian m. carlson" <> writes:
> > Yes, I would much prefer that we let OCB happen in a separate draft.
> > Then all the patent problems occur in a separate specification that
> > doesn't affect the core OpenPGP.
> I don't think you understand the relationship between the specification
> and IP.  Specifically, whether OCB is in the main spec or a secondard
> spec does not affect any IP/patent "problems".  Put another way,
> IP/patent "problems" occur for anyone who wants to implement OCB,
> regardless of where it is specified.  However having it in the main
> draft makes it easier to implement and audit, as Werner suggested.  The
> more places you have to reference, the more likely you'll make a
> mistake.

No, I completely understand it.  I strongly feel that OCB doesn't belong
in the main draft so we have a simple, complete, unencumbered spec.
Then it's very easy to avoid all the uncertainty (and there is a lot) on
OCB by simply not implementing the additional spec.  People can
implement the entire main RFC without having to even think about
patents, and that's valuable.

Otherwise, people have to end up explaining that yes, we implement the
spec, but no, we don't implement the patented parts, and that the spec
is implementable without the patented parts, and so on and so forth.  I
anticipate that this is a conversation that numerous people, not just
me, are going to have with company lawyers.

I strongly believe that our spec should be unencumbered.  I am still
strongly opposed to OCB because it's patented, but if it lives in a
separate spec, it's easy enough to just say, "Don't implement that RFC."
brian m. carlson / brian with sandals: Houston, Texas, US | My opinion only