Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (

Mike Ounsworth <> Mon, 09 December 2019 01:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 024601200CD for <>; Sun, 8 Dec 2019 17:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 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_HELO_NONE=0.001, 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 XwPpGKbf11-X for <>; Sun, 8 Dec 2019 17:46:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F53912007C for <>; Sun, 8 Dec 2019 17:46:09 -0800 (PST)
IronPort-SDR: it4+DoEqySBJBVZVgYvma0/8YaKrL8Vd0//gbXbgeolMwlGzn5eGhKteSvqxityB90TK/r7eXQ h5NIU4YMWIeg==
X-fn: image001.png
X-IronPort-AV: E=Sophos;i="5.69,293,1571720400"; d="png'150?scan'150,208,217,150";a="63324045"
Received: from (HELO ([]) by with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 08 Dec 2019 19:46:08 -0600
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 8 Dec 2019 19:46:08 -0600
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 8 Dec 2019 19:46:08 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=g7mjd5XpaIAkh2LoB0lVTh0fsktZcjESEOc4q9dGYXfHukkEwe+5th8yg4A3kfq54898DJyXVddvFxw8UxGwq6/u10eCUi4NGsaUctsPluNNuMVMiQIk5wAJq0PKeBy3UMJhCsA5j+yuQTR+rpreEdcPR3WyN1fSTab7zOM3ZHwqlcPuqUoHVmAWBLmHUcbgKTl4xL7Fn18bL6aOoKvI6aB/y1agmIOzrOQzk55H2n38f2ISey72pckZyWP3c2D5qY8uWN87KkH1Vfw2HZHF9KqIJa3hvxwUjUZhBbw0b2e/cnruVmfddHLAbfxpCAFgE3yADve1UBT1WN5hht/isw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KLz0yRLT3tt5NFLyFn0pjWWERq5tjL1IjHelXV51Z0w=; b=Aoa5RngOozypYoGH6mduIAi3zbubvykk7k157Wm3E3OFVy8Yp79beiERVDgqmhyVOLx9OS7aZSd1a1RNvG4VtqaAOtX+y1eoLTs7nYXUf2SjcwT4crDU3GRrjFLYopSztR0AVJhA0b8FW6ULV55eF22b/ynNvtaHt96cjMD1yMR84Vnsj3tCkkfmRrOrTJLbn1jzqHXb/dc9aF8R8H8DvwK5ANNd10nmJUZ78iNYQAxv65IZ2yfBA1Fq/l2Q7L1Wa/oYrnUGv9ItD2X8dZOkLM10EMFowWHLuzNDAvrgE4IugBRqdxsHYIZY7THOVfYWdSYTkgXqexZzyZ/x2yBWpw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KLz0yRLT3tt5NFLyFn0pjWWERq5tjL1IjHelXV51Z0w=; b=PZgN4EzOb1jeSvKzzy8RgP/5+4oXmQ4gHiY2J08n+Q9k6FYzP/jTJgQMCouFtzfdEfWbz7n1vwzsnvAdrnvb6aU4OpZVL914aMqb+R7hXsjOeiCchqaDG6BWXC2pDN7CwBy+fa81Gio6a48sOUIZC3UkbcxBvQeKb7jI5ORL6t8=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.14; Mon, 9 Dec 2019 01:46:07 +0000
Received: from ([fe80::6525:fc5b:ffbb:acd]) by ([fe80::6525:fc5b:ffbb:acd%3]) with mapi id 15.20.2516.018; Mon, 9 Dec 2019 01:46:07 +0000
From: Mike Ounsworth <>
To: Eric Rescorla <>, "Dr. Pala" <>
CC: IETF SecDispatch <>, Stephen Farrell <>
Thread-Topic: [EXTERNAL]Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (
Thread-Index: AQHVnyMsoa9rw3Ho8k+R4BlhE/oAB6eTRrIAgABhhwCAAAHuAIAVC4WQ
Date: Mon, 9 Dec 2019 01:46:06 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 95f2860b-a826-4525-0bf9-08d77c498f08
x-ms-traffictypediagnostic: MN2PR11MB4445:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02462830BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(39840400004)(136003)(376002)(199004)(189003)(51444003)(4326008)(2906002)(102836004)(8936002)(26005)(8676002)(9686003)(76176011)(54896002)(74316002)(33656002)(6506007)(229853002)(5660300002)(186003)(71200400001)(71190400001)(790700001)(53546011)(81166006)(81156014)(66446008)(64756008)(110136005)(7696005)(316002)(66476007)(54906003)(66574012)(99286004)(76116006)(52536014)(66946007)(66616009)(86362001)(66556008)(478600001)(55016002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR11MB4445;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: WF3K8/Omo1NsmPtt9bEFI37R2Qp/nXbBnV1wjOPvPIOMmhd3Ki+lg4WMc+bx6zlP4DuFNW8n/qlf21u2Bn8FkxMILCzzGJ4CX7J3mErbcFPbLfH+8yrt58hYvbeu7BGiNFzWNHZ6hnGPDcFNCFsn5xyBVLzJn+iYDsGqVPBGZQ3b3+dMuuk0aOX+ItCszC7UBQn70ji3yJYo34PXal2jpFT0m+J4Ey7izZ/cHMcT3squtn0Wi/7V0UYwgdg2kODUcT5TLgUh5jsP/etPuOuCL6L0dMpa0ddHEW2iZSjdOatd4k6t8XcJodwp0mVb4ZM84rP6g8F+ZbMYX3CW7p1n2LE/3BD1BtdLI/g00udzv7euYFFoXX7IPYkwa8JiugAmw5mRJbh/Y7yWEsWlxi8G4hNpZH1MYRf+W+xhb+iR0ZqZUA7b5rkevOJhf6sjP8kVNtOckrw1PcPqvry7ncPhXYjrFTaxw4sT94+3ci4WE/2PzPWxVh0IIULlvyBEC6yb
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_004_MN2PR11MB3710195708AAA808B3D08EC29B580MN2PR11MB3710namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 95f2860b-a826-4525-0bf9-08d77c498f08
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2019 01:46:06.7562 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NOz8ZugNKPS189RgRflqN0BPkNtLAj05VELvzWkqQBt7XcbqDnDVIsT8Bk7o1LUhxQleQSTe3ammxOuPiyx9xjiD0jtNnps3yBS6R/lcO29XbfVPGfNaxbLx7/eu9T7f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4445
Archived-At: <>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Clarification Question for the Comment from Eric Rescorla (
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Dec 2019 01:46:13 -0000

Hi Ekr, Max, Stephen,

We tried to design the proposed CompositeCrypto solution to be as generic and general as possible. During design, we wanted something that would work “generically well” across all ASN.1-based use-cases: PKIX (X.509, CRL, CMP, CMS S/MIME), OCSP , PKCS#?, PIV smart cards, code-signing, etc.

As Max said, it’s certainly possibly to design a more elegant solution by tailoring it to one use-case (for example by considering mechanisms available in a negotiated protocol). However, as companies who implement general-purpose Certificate Authorities, we’re looking for a more one-size-fits-most solution.

If WebPKI and CA/B Forum wants to take more time -- possibly even waiting out this problem – I hope that doesn’t preclude a push for a more immediate solution.

As for “why now”: Max has spoken at length about DOCSIS cable modems who want to begin deploying multi-algorithm-capable devices, like now. There are also other closed PKI environments (think heterogenous corporate PKIs providing certs for email, physical building access, Windows smart-card login, etc) where the customer-demanded timelines for classical+PQ solutions are too short to wait for each problem domain to standardize an optimized multi-alg cert standard (plus think of the headache if we fracture into dozens of different cert formats!).

As you say Ekr, maybe the solution is to use hash-based until we’re ready to migrate wholesale to a single NIST-crowned algorithm, but this is not the opinion that I’m hearing from the community around the NIST PQC, nor from my customers who want greater agility, not more restrictions. Hence this generic and flexible CompositeCrypto draft.

TL;DR: CompositeCrypto may not be the forever solution for all use-cases, but it would give us something we can start using soon as a transition mechanism, that we have confidence will be relatively problem-free across the breadth of PKI problem spaces.

- - -
Mike Ounsworth

From: Secdispatch <> On Behalf Of Eric Rescorla
Sent: Wednesday, November 20, 2019 1:29 AM
To: Dr. Pala <>
Cc: IETF SecDispatch <>rg>; Stephen Farrell <>
Subject: [EXTERNAL]Re: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
Hi Max,

I'm not presently taking a position on whether this work should proceed in a general matter; I haven't thought it through enough to have an opinion.

What I was trying to say in the meeting is that I don't think this is probably to be of much use in the WebPKI at this time.


On Tue, Nov 19, 2019 at 11:22 PM Dr. Pala <<>> wrote:

Hi Stephen, all,

I just want to add a quick consideration here. We work with hardware that is deployed at the customer's homes, offices, etc. When planning for our innovation to hit the networks, we need to plan years in advance - this is not something we deal with in universities, but, I assure you, it requires a lot more planning than you might be used to.

I do disagree with the fact that what we are doing doesn't really help that much. The proposed approach does provide a solution that, although it might not be optimized, it works.

Other solutions might come afterwards that provide (probably more complex) optimized paths (maybe TLS 2.0 will be quite different because its design will cover the new design requirements). Another possibility is that application specific would define their own code points: the "CompositCrypto" algorithm OID will allow to combine any algorithms. Applications can then define their own code-points that they accept by simply defining the appropriate OID for the algorithm identifer. For example, when and if TLS, for example, would like to define its own combination of algorithms, a set of specific code-points can be defined for that.

Coming back to delaying the work - I think it is wrong and I would like to understand why you think it is a good idea.

  *   We have the interest of an industry sector
  *   Plus, there has been support on the MLs for not delaying the work any further
  *   Plus, this work is presented by a committed set of Companies that have real interest in using this technology to protect the PKIs that secure the internet connectivity for hundreds of millions of users.
  *   Plus, the problem has been already addressed in other institutions (ITU-T) - thus indicating that IETF is falling behind on this topic.
  *   Plus, we are in contact with NIST to possibly collaborate on real-world deployment of QRC by using Composite Crypto.

I think that blocking or stalling this work within the IETF does not make any sense. If there are other competing/compelling proposals, please let's talk about that and find a common solution we standardize. I personally do not think that "Sometimes waiting is a little better" is a valid argument.

If you have technical reasons as to why this work shall not proceed, please let us know, we want to deploy the best solution possible.


On 11/20/19 9:33 AM, Stephen Farrell wrote:

On 19/11/2019 21:48, Eric Rescorla wrote:

But until we are prepared to do that, then defining the

protocol syntax doesn't really help that much.


Sometimes waiting a bit is better:-)

Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]