Re: [lamps] Revocation Request Format?

Tim Hollebeek <tim.hollebeek@digicert.com> Sat, 03 March 2018 04:28 UTC

Return-Path: <tim.hollebeek@digicert.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8353312EAEA for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 20:28:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.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 AKleuRZF9-BG for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 20:28:07 -0800 (PST)
Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69BFE12EABD for <SPASM@ietf.org>; Fri, 2 Mar 2018 20:28:07 -0800 (PST)
Received: from [216.82.251.38] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-16.bemta-12.messagelabs.com id B0/93-11158-6542A9A5; Sat, 03 Mar 2018 04:28:06 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA2WTf0wTZxjH+95drydy7igwHokkWnTZqiAQ3Wr 8Zy4xNiRGt6AmHZk74GyrbSF31XRmEYSMqJDhD4q2CGiGRtSajJTgZE2kG1MQfyFWQIlUwQnM 3zME1NVe3+o0/vPk87zf7/O8z3N5jyHVJ1XJjOCwC6KNt2joGKpvthfS1sx1GzKOVWXp9jyuR brQ0Cil23u7DunqA/m6/b6A6kul3lNxndb/5h5U6a+ceE7oGxsnCX1ZWxu1WmlQmm15hY7vla aJzktE0ekm5LhW/zNZgva50C4Uw1DcIwJaT9VScqLmqgloGQkinNxGsGPAq9qFpjE0lwEB3zl C5gQuB6butSKZSW4j9A2URjzx3EJou+MhsScDfrrhVWI2QKjvcYQpbi5cdG+nZGa5XOjo76Jl VnNDJISat8k8jfsaukdvRjyI+xgmuk4S+K4kGBhuiDBwCRC8eoHGnAijd/9TYn8u1D3zR881c OqfW1F/CvQ0VEQWA85LQFX/nxQW0qFlzwOEeSVcfXqExqadBBx0+lVY0MLD4cEobwKXcyLaqR KBt6qFwsl9Aio916NtZ8G9ivpoKycNZzznEV60AKqP+6PCZQTdrU5qN9K631nQHdZIrgFB2VA v4Y58qTjodA1T2GSAR2fKCcxaaCwNqTDPh6OHx0nMn8G/u29SH54vhQNT7TTmOVBdEYzWLobx jifoEJp+HH0qCeIWQUzLXJyeJ5qNJruVN1vSMjOz0q2CJPFGwcLnSen5hdZmFH6hxQoFOo1e1 GT70UyG0CSyI0GXQT0jr7DgBxMvmdaLmy2C5EezGEYD7I+pboM6ThSMgmOD2RJ+5m9kYGI1Ce xlWWalIt4qmY1Y6kLLmd89wXKS6d3/dzh674yG49lI7Ls/Xk6qKVuhTUhOYn1yMScXmzbb3rZ +8xP1oJTkeBYpFAp1bJEgWs329/UxlMQgTTx7Te4Sa7bZ304wFh6OCA+nenBAHs7O/y8ll6At jQPU3fLEjm+Nk7Sx44/snvW9m7aafdqDn/wSjFm1qN3V3/3rRzUvvYEZXxTXiXbQBJtyDdYls 7/rzJ2XeqPgG2dtaMXh5RNz2Ell6ciCmi71i0VLFpTFO4Ix09cGSpp6l738PKu98sJG36Du0l 8r12W9+upsfvaY0Z7TOaUgDhWnaCjJxGdqSVHiXwP54lYGPwQAAA==
X-Env-Sender: tim.hollebeek@digicert.com
X-Msg-Ref: server-15.tower-163.messagelabs.com!1520051285!153683944!1
X-Originating-IP: [216.32.180.24]
X-StarScan-Received:
X-StarScan-Version: 9.4.45; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 97512 invoked from network); 3 Mar 2018 04:28:05 -0000
Received: from mail-sn1nam02lp0024.outbound.protection.outlook.com (HELO NAM02-SN1-obe.outbound.protection.outlook.com) (216.32.180.24) by server-15.tower-163.messagelabs.com with AES256-SHA256 encrypted SMTP; 3 Mar 2018 04:28:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+bGrAffgVDnc4bE5+0Eiq/H/kfy/LcrG4fQk06lbdxQ=; b=P63p1ekVe1HnR6YC8ZJn6IpWWGFDVHppTdwj9yKMHa3aABL0Nnxt2BFHcngjShgDkVi4sh3/u1cNbSjD+amxTHSLePSipe5uNJiTXV2rtbsRFxXVKeShCKVgnLSHwIfEp7W/KkEKuTaLVqDkSWZvJN3at4d6lR2I9vM5L34H5w0=
Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1261.namprd14.prod.outlook.com (10.173.102.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Sat, 3 Mar 2018 04:28:03 +0000
Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::7929:3f48:4a4f:1e32%18]) with mapi id 15.20.0548.014; Sat, 3 Mar 2018 04:28:03 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
CC: SPASM <SPASM@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>, Peter Bowen <pzbowen@gmail.com>
Thread-Topic: [lamps] Revocation Request Format?
Thread-Index: AQHTsjInSyN45zGu70muhef4KLLyqaO9HOwAgABBwICAAAPKgIAAEXSAgAAHYICAAA1TAIAAYL7g
Date: Sat, 3 Mar 2018 04:28:03 +0000
Message-ID: <MWHPR14MB13762059EAA49E6AD46C1FE183C40@MWHPR14MB1376.namprd14.prod.outlook.com>
References: <CAMm+LwjAP78hNL9Yaxqaf4K9RHYGk4M8ayJjCWt=F3_VN28cFQ@mail.gmail.com> <CAErg=HEK0aJm+Xb06px=vmfpyESetdRpe2x=q+Wca=9J8nErmw@mail.gmail.com> <CAK6vND8p55yNVoXO6_eJs1ooodVBAFZovJ84ou6uj_4qHt5DGA@mail.gmail.com> <CAMm+LwjKKqaG+OjSw3KaSvwymy6mvvyEDx1sMp2EGqXqvPSdjA@mail.gmail.com> <CAErg=HFBWaSV5-mJCBO8fLP3esfnseiqqJ_Fh1x78BW9=P-kUQ@mail.gmail.com> <26f237b9-bbe6-6efe-2a43-394d44e8334c@cs.tcd.ie> <CAErg=HH+B5+DcvPfUixy-3egm3zdhGjMangtAL0wixKE5PVkzw@mail.gmail.com>
In-Reply-To: <CAErg=HH+B5+DcvPfUixy-3egm3zdhGjMangtAL0wixKE5PVkzw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [98.111.253.132]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR14MB1261; 7:ySvwi17ycAdBeuPZRnwh3SprswPzcdw2IWd7Yf9p9mRHO5/pxFWZyvNBX+1w0ePPrcFGENBdTLgwri6QSe/V1LUa9lS0IJM7un+901FHmOXjUiFIG4urIDLqIKNs7SfFed27NpucUPqnLzQ8SjxrvapWQF0qWpTu9IuBa4RCbM4EVRm5jABOgxTFgpUByjKoM25MrUrR+B9iJdhe1k0QEHcTduPzTIUi3osAkgz9id/8jG9C6iqaclntZ2MwYMRT
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 16288334-4e0a-43b2-7494-08d580bf27bf
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1261;
x-ms-traffictypediagnostic: MWHPR14MB1261:
x-microsoft-antispam-prvs: <MWHPR14MB12617B10244ABB9E7DD07A1C83C40@MWHPR14MB1261.namprd14.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(32856632585715)(192374486261705)(85827821059158)(144208319314845)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(3231220)(944501244)(52105095)(10201501046)(3002001)(93006095)(93001095)(6041288)(2016111802025)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6043046)(6072148)(201708071742011); SRVR:MWHPR14MB1261; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1261;
x-forefront-prvs: 0600F93FE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(376002)(39860400002)(39380400002)(199004)(189003)(6436002)(966005)(106356001)(606006)(229853002)(99936001)(5660300001)(478600001)(93886005)(7736002)(3660700001)(33656002)(74316002)(99286004)(59450400001)(53546011)(68736007)(6506007)(81166006)(81156014)(3280700002)(8936002)(8676002)(76176011)(4326008)(25786009)(186003)(102836004)(26005)(105586002)(39060400002)(7696005)(6306002)(9686003)(236005)(54896002)(2906002)(14454004)(55016002)(2950100002)(97736004)(6246003)(5250100002)(86362001)(2900100001)(790700001)(54906003)(53936002)(3846002)(6116002)(110136005)(66066001)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1261; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: LdIpnFDjzwb3uirQcZhsH9f7FTV54D2fBf+XRvrqtmczBrwYXtKni9Fm6BWEmj51XLWyGvJx83YYUZJ2NF0uGQvX2DubU42n80ANzCAebmsGxCxFICUf5uRa4r1Snp669C72Z7CY/MgCwIHKS/n7l08nz8gdUh4K3jmVmhFz4rA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_041F_01D3B26D.572FB4C0"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 16288334-4e0a-43b2-7494-08d580bf27bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2018 04:28:03.5666 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1261
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/ieUhgSf7V7wr-kf8rtI18ubiWRo>
Subject: Re: [lamps] Revocation Request Format?
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Mar 2018 04:28:10 -0000

I agree with Ryan.

 

Some standardized methods of proof of compromise would be useful for typical compromise scenarios (I hope Ryan agrees with that), but you can’t produce an exhaustive list of what’s acceptable.

 

We’re not going to be able to standardize “I have a quantum computer in my back pocket, here’s how I demonstrate that” or “if I wiggle my fingers at the public key like so, the private key appears in an thought bubble above its head”.

 

Security failures happen when assumptions and abstract models break down.  If you can demonstrate that you can violate those assumptions, people have to be prepared to deal with the consequences.

 

-Tim

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Ryan Sleevi
Sent: Friday, March 2, 2018 3:34 PM
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>om>; SPASM <SPASM@ietf.org>rg>; Phillip Hallam-Baker <phill@hallambaker.com>om>; Peter Bowen <pzbowen@gmail.com>
Subject: Re: [lamps] Revocation Request Format?

 

 

 

On Fri, Mar 2, 2018 at 4:45 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie> > wrote:



On 02/03/18 21:19, Ryan Sleevi wrote:
> Because it's a demonstration of compromise. Any attempt to define how that
> demonstration of compromise is proved (which I think is *bad*
> standardization) is to make it more difficult to report or demonstrate
> compromise.

I don't understand the "any" in the above.

Can you clarify?

 

So, there's two scenarios for key compromise that we're considering in the CA space

1) I have the private key (Heartbleed, Trustico, rooted servers, etc)

2) I have a signing oracle (Bleichenbacher, ROBOT, etc)

  a) Note: The signing oracle may be somewhat constrained in message formatting, but still provides an oracle sufficient to count as compromise

  b) Note: The signing oracle may be temporary in nature, so I'd be particularly concerned with systems that require nonces or timestamps, as they would incentivize disclosure to the CA first, rather than to the 'presumed legitimate' keyholder.

 

Further, we have at least several actors to consider demonstration of compromise to:

I) The CA/issuer

II) Those that oversee the trust anchor management that includes the CA

III) The public

 

Because 2) exists, and the constraints re: 2 a), we need ecosystem flexibility for how we demonstrate proof. That is, it will be somewhere along a spectrum, based on what I, II, III find an acceptable demonstration. I might want to require a challenge, but II does not, for example.

 

Thus, because the ecosystem has flexibility, 1) can easily adapt to whatever is needed - because they have the key, they are technically capable of producing any signed message necessary for I, II, III - of which we already have plenty of ways of expressing, whether it be raw signatures, CSRs, SPKACs, whatever your heart desires. There's no need to invent a new format, because we have infinitely flexible formats already available, and because the policy for I, II, and III will be inherently variable anyways.

 

Further, I am deeply concerned for situations in which 1) - or any standardized version of expressing that - is seen as the only form of compromise or the only acceptable form of demonstrating that. This isn't hypothetical - this is a problem that, in acting in the role of a browser trust store maintainer (II), I've had to chase down a number of CAs (I), because they only want to revoke for 1) (... if even that). That's a policy matter, for sure, but it's a policy matter that I fear is or would be amplified.

 

So I think attempts at 1) are somewhere along the line of https://xkcd.com/927/ , where we already have a number of methods.

 

But let's go further, and imagine that let's say we wanted to have an interoperable definition for proof-of-key-compromise, so that you don't see what we see today - where CA Foo revokes a certificate as compromised, and the Subscriber then goes to CA Bar and requests a new certificate - with the same key. It might seem appealing to suggest that an interoperable proof of compromise would facilitate that information sharing, perhaps via some shared transparent ledger. And I totally get that appeal, but that's only addressing 1), and not 2), so we're not really addressing 'compromise' in the broad sense, just 'compromise' in the narrow sense - and we're just adding more work for those who do have the key to adopt whatever the new hotness is, creating ecosystem adoption issues.

 

That's why I think an effort to standardize there is bad, not good, because it counterintuitively fragments the ecosystem, without addressing the general issue, which is in my view is moreso a matter of policy, because of the inherent constraints of 2).