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

Ronald Tse <> Fri, 27 October 2017 10:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 335CC13F411 for <>; Fri, 27 Oct 2017 03:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pLqA6RSt3Iq5 for <>; Fri, 27 Oct 2017 03:12:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CEF713B138 for <>; Fri, 27 Oct 2017 03:12:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-ribose-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6LQqIc5j0l9Ko7PIZav1j8/KwRrWn/DkXZulieaWkpk=; b=fUQfsHUWTyJ0D1NnVqQdrD5HUL6aQUC4KhNRWITzBLdZJSj4VT1yEML8a81GW/SbvGV/R41l+IE2CLqSepjgnrTjZaCx3wKTXgI9SE0L8I8QShAW6oOfL2QyU5DYx7jS9pAfx5OukrYsvJxbzm2eNZT5N/gCY4uyULPD+vkoq+M=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id; Fri, 27 Oct 2017 10:12:51 +0000
Received: from ([fe80::8063:56cb:84b9:41c5]) by ([fe80::8063:56cb:84b9:41c5%14]) with mapi id 15.20.0156.007; Fri, 27 Oct 2017 10:12:51 +0000
From: Ronald Tse <>
To: "" <>
Thread-Topic: [openpgp] Proposal to include AEAD OCB mode to 4880bis
Date: Fri, 27 Oct 2017 10:12:51 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; KL1PR01MB1045; 6:RNfLRCw0hIrgia8muEjIDHnoZ6iFTYmVeWXVJ2BWNHfi0iFNT5jMNPnUDSDMMsk4zBqgKMBgYXJ0htwvXh4tcYi16LxNIPDBI391RiFXTH3OJryBMvtieD+ZFwWUkUyW0W86z2VfEVgJUm7YadkmVjctaykb0YRDDZno2kJt7mbwGQ1jsVhszu03/NvBI7hRlJ0fWmUv0Aw8MapJviaQaBQekT/ZqyLh3LBd4CBlV3TjvBfvr8GtKmNHLuSNxuUyI+I1n3ysIpXnLBGwaTYT6QDsbyYrrZQL4YrlYa8ft1UksNkqIN1nk2kU2S2jGjG9G4OF3LbhAQCxWB7iSS3Mug==; 5:Mlr3tw0Rb40+Ads768PzRSjDt0p1bWMQVUmfUW0e3aTBsvI7+W6KMKNzNCKJMqxecujCbmyYiTZQnihGzx8jl4cIRRy8ELA9Wzgtp3/nmGQnuVEIvky9IfkGe7VZG2ssjJXzcL7j+h/bWlQVzCQcwg==; 24:j/LTA8aoMCuizUxpZJCD4QZgz3aV4WsKEuYd9RnPgk19Y53U17412rjVs9i3j+s/GWIpfaijCjL1f3yTtlLuQKp26jajn75oiOge/s+x1OE=; 7:o3/28RPnweOuYZOCsOj305zwyCzzRvxK2Zi8TwABjVAcYgwQs4ZkR8JYv+3z2kwAIePpcWxGH4NIrcLrZSBlC3YtevtkYUTM6yr3AzylI1btv+F/XHX9GvTEDIOfJUkAKjl9e2THSrmHRl4af4/NWbgc9Bl5lQQGr462Dn42fwnQkoNjHeliCxv2cEEqi2zhb3YX30l6r8KdmKEVR/i6XWd+ioSOtLFM2wLTE8sBfiI=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 678a575f-037f-487b-7675-08d51d234853
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627075)(201702281549075)(2017052603199); SRVR:KL1PR01MB1045;
x-ms-traffictypediagnostic: KL1PR01MB1045:
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3231020)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123562025)(2016111802025)(20161123558100)(20161123560025)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:KL1PR01MB1045; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:KL1PR01MB1045;
x-forefront-prvs: 0473A03F3F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39830400002)(346002)(199003)(51914003)(189002)(24454002)(5640700003)(82746002)(6506006)(25786009)(3280700002)(97736004)(6246003)(86362001)(2501003)(2906002)(3846002)(5250100002)(93886005)(53936002)(102836003)(66066001)(478600001)(99286003)(5660300001)(6512007)(53546010)(83716003)(7736002)(6116002)(236005)(68736007)(3660700001)(6306002)(54896002)(316002)(966005)(33656002)(106356001)(189998001)(105586002)(606006)(6916009)(101416001)(14454004)(2900100001)(6486002)(2351001)(8676002)(50986999)(1730700003)(6436002)(76176999)(81166006)(229853002)(2950100002)(81156014)(8936002)(54356999)(36756003)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:KL1PR01MB1045;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_36023233856C4A6DBAF928037B4DA0F7ribosecom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 678a575f-037f-487b-7675-08d51d234853
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 10:12:51.5877 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1PR01MB1045
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: Fri, 27 Oct 2017 10:12:59 -0000

Thank you Werner for the supporting comment. Seeing the comments I think we all agree that OCB is a great AEAD mode, and the only concern is about its IP.

1. A number of statements have been made regarding IETF standards and patents, but those statements do not necessary reflect today’s reality.

IETF’s IPR page details its stance towards IP and specifically, patents. There does not seem to be no requirement that the standard is “unencumbered”, “free” or “gratis”. The requirement is that licenses must be granted in a non-discriminatory way.

In the IETF’s IPR disclosure listing (, you can find quite a few examples of newly published RFC documents that are clearly covered by issued patents, with no “indemnification” for implementers.

In fact, RFC 8179 clarifies the following for a Standards Track document:
9.  Licensing Requirements to Advance Standards Track IETF Documents

   Section 2.2 of RFC 6410 [RFC6410] states:

      If the technology required to implement the specification requires
      patented or otherwise controlled technology, then the set of
      implementations must demonstrate at least two independent,
      separate and successful uses of the licensing process.

   A key word in this text is "requires".  The mere existence of
   disclosed IPR does not necessarily mean that licenses are actually
   required in order to implement the technology.

For RFC 8179 compliance, there are already 3 licenses issued on Rogaway’s web site, and many others that are not shown there. This means that incorporating OCB in the 4880 document would NOT affect its status as a Standard.

2. There has been some misunderstanding regarding the OCB license coverage.

a. OCB is already shipped in Red Hat and Debian today in the OpenSSL and Botan cryptographic libraries.

b. Linking and distribution of any closed-source software with an open-source software (OCB License 2: as defined by the FSF, including BSD, GPL licenses), is already an accepted, licensed use of OCB.

In all of Brian’s examples, linking or distribution of “any closed-source software shipped on that system or any non-open-source custom-built apps” that utilize an OCB-enabled open-source crypto library, is explicitly allowed by License 2.

3. The misunderstanding that OpenPGP implementers will not implement OCB due to IPR disclosures.

Werner of GnuPG, has already indicated support to OCB on multiple occasions. Our own open-source OpenPGP implementation, RNP, will implement OCB. Anyone that uses popular cryptographic libraries like OpenSSL and Botan can already implement this and is covered by the licenses.

Again, OCB is proposed to be a MAY algorithm, not a MUST or even a SHOULD — if someone doesn't like it, there is no need to prevent others from using it.

Thanks for the comments.



Ronald Tse
Ribose Inc.

On Oct 27, 2017, at 4:46 PM, Peter Gutmann <<>> wrote:

Werner Koch <<>> writes:

rfc2440 and rfc4880 both included IDEA as a SHOULD algorithm despite that
IDEA was patent encumbered.  Also RSA was patent encumbered when 2440 was
published and nevertheless a SHOULD algorithm.

They were there because there wasn't much choice.  PGP 2.0 used IDEA and RSA,
so it had to be kept around for future versions, although it was only a
SHOULD, not a MUST.  With OCB in contrast you're introducing a new patent-
encumbered algorithm for no obvious reason.

If you really want the protection that OCB offers then encrypt-then-MAC is a
totally unencumbered way of doing the same thing.  It's been in S/MIME for

openpgp mailing list<>