Re: [lamps] Revocation Request Format?

Tim Hollebeek <tim.hollebeek@digicert.com> Fri, 02 March 2018 23:57 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 E0ECA124B0A for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 15:57:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] 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 DJQZgmzI9sBE for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 15:57:07 -0800 (PST)
Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.12]) (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 5E8311242EA for <SPASM@ietf.org>; Fri, 2 Mar 2018 15:57:07 -0800 (PST)
Received: from [216.82.249.212] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-12.bemta-12.messagelabs.com id 86/8C-09148-2D4E99A5; Fri, 02 Mar 2018 23:57:06 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA2WTfUhTbxTH99x7t93U2W1anoZGrf6olUurH4y iVzAkCIqKYEl1pzd3aZu2O2NCZE2SNCNXznRW68VerSzRqFaQlkXai1pZWWFzRtrwlz+0X1li 3bs7e6F/Dp/nfM85zzkP5yFxZbFcRTJ2G2O10Ca1LIx4rD2RGN/SVaZPqHXM1Tn7ypFuf8dhp DvSlroIT26u/IQlV1QMYsm5Xi+xAtdLWYshw75RarzkPi3PdO1F9tuDq3Yg/05UgMJIgvqIwc vGfEw4KCkXBo2FLaFDB4JhVxtegEaRMioB2m7ewwSOptZA1ZkHQcYpFRy48x0JHEXNBG/nBVy MSYBdz2ukBYjkeS5U9ugFN0FNAYd3gBBYQaWA2/NaJrCSKkHQcCdJ4FHUSmhtLwyWR9Q4+Nx4 PnRVDLR3eYIMVDT4WppkIo+FHv+wVIxPgcP99SH/RMj9fyjEcdDq2ROcGKgaDOpKj4cKaaHW2 YtEXg61gX6ZGJSPQW11LyEKGiipHAwFbYYHl0/JRTZBmdNPiAndGOx7czMkxEL7t7dyURiQwp OrdzFxzjQoPjfS32ME/n6iCGncv43n5nNwyoOg6Po1zB18pzFwv6yLEIP08O+Xp1KRNVDh+C4 XeTqcOhbARZ4GA0WviL/986D0a51M5ElQvMcXyv0HAg3/oaMo/ByayjHWrYw1fvYcrcHKphtt Zpo1xScmztKaGY6j0xkTbeC0qRnmasRvYo5Egq6ipmPr6tF4ElOPVbzzlemVkYaMtGwjzRk3W LNMDFePYklSDYpwfmOVY6xMOmPfxJr4dR6RgYxQRytYPy8ruEzazLHpotSIksiag+/zcHLI18 Pbmk7B3graF92BPFxJWDIsjCpGUS4kU0KyMcvys/TIZ2lFcaooBZJIJMqITMZqZm1/6h9QDIn UUYo6oUoEa7H97OAD3xzGNyfvLRWas9G/JNUOtDi8aEr5l0Ld/NRlWYEZToezaum4KyXNJ9d+ Ks95+ix/9cSq1oa+QyuwPPaip8NlyN7WN9Olcbxb2lxdGqmPoHd2N3UeiPVu16XZcyZdOk7tz l0y+q3e9OLIw76zvpM6Y0XPhAlJprTsZZFxN3SXF65v1iVNHq4qOB82FJbifrTl+gI1wRnpRA 1u5egf9s6NricEAAA=
X-Env-Sender: tim.hollebeek@digicert.com
X-Msg-Ref: server-8.tower-219.messagelabs.com!1520035025!183874591!1
X-Originating-IP: [207.46.163.49]
X-StarScan-Received:
X-StarScan-Version: 9.4.45; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22747 invoked from network); 2 Mar 2018 23:57:05 -0000
Received: from mail-cys01nam02lp0049.outbound.protection.outlook.com (HELO NAM02-CY1-obe.outbound.protection.outlook.com) (207.46.163.49) by server-8.tower-219.messagelabs.com with AES256-SHA256 encrypted SMTP; 2 Mar 2018 23:57: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=rexNqhry3sHgYF4DnSvpiepqngC4Gc7Na70a7UbLIQY=; b=eVWnjn06amW6XlUx7vMB5HEQ9kK64tQgkfJvDd349ZWUjn+kPTBp+sK5saf3YDT1VRlZXwgk2xe1js4bYXywcPoX9HcszzvIUprIbD2NlgdwDg5//kQ8qYpzoWqWXQpqYyvkFxw/XMDFCfyRoAhXwqGlbx8PxHlpeJ+2DZwBaA8=
Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1630.namprd14.prod.outlook.com (10.171.146.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Fri, 2 Mar 2018 23:57:02 +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; Fri, 2 Mar 2018 23:57:02 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>, Phillip Hallam-Baker <phill@hallambaker.com>
CC: SPASM <SPASM@ietf.org>
Thread-Topic: [lamps] Revocation Request Format?
Thread-Index: AQHTsjInSyN45zGu70muhef4KLLyqaO9HOwAgACCEUA=
Date: Fri, 2 Mar 2018 23:57:02 +0000
Message-ID: <MWHPR14MB13763060DE4A23D49EE017BC83C50@MWHPR14MB1376.namprd14.prod.outlook.com>
References: <CAMm+LwjAP78hNL9Yaxqaf4K9RHYGk4M8ayJjCWt=F3_VN28cFQ@mail.gmail.com> <CAErg=HEK0aJm+Xb06px=vmfpyESetdRpe2x=q+Wca=9J8nErmw@mail.gmail.com>
In-Reply-To: <CAErg=HEK0aJm+Xb06px=vmfpyESetdRpe2x=q+Wca=9J8nErmw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [12.130.122.8]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR14MB1630; 7:BsB9H8uSLvAgm5FWArvxqgJsLsyOG4sbAz1J8NIojZ62e19XNVcjiwM31dDM/UvoiolacubLQiNZX6UuockmjcvXVcSBDkNrGW3OEfpsESgJr+c+lP/U/RBlraXZPnonZl/54XvzPg4YKCuaTyb0aYcZsrexOAAGovESC2bDxjYImfMsskIi/7vZvzx9eleSceeylQIoluKCGbfwzdXizH+a2k+pdAotSu1pci3eyWsZDWxhcExmH4yRq/wci5hM
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: fe656451-6a3b-43f1-3941-08d580994b2c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603307)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1630;
x-ms-traffictypediagnostic: MWHPR14MB1630:
x-microsoft-antispam-prvs: <MWHPR14MB1630C4FDA5F5A87F9A892A4783C50@MWHPR14MB1630.namprd14.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(100405760836317)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231220)(944501244)(52105095)(10201501046)(93006095)(93001095)(6041288)(2016111802025)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6043046)(6072148)(201708071742011); SRVR:MWHPR14MB1630; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1630;
x-forefront-prvs: 05991796DF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(366004)(346002)(39380400002)(376002)(189003)(199004)(7736002)(74316002)(5660300001)(5250100002)(33656002)(55016002)(105586002)(6306002)(99936001)(54896002)(106356001)(53936002)(478600001)(14454004)(966005)(236005)(9686003)(68736007)(606006)(3660700001)(110136005)(6436002)(6246003)(3280700002)(81156014)(59450400001)(6506007)(53546011)(316002)(2906002)(81166006)(66066001)(2900100001)(3846002)(6116002)(790700001)(8936002)(97736004)(25786009)(99286004)(4326008)(2950100002)(86362001)(229853002)(76176011)(8676002)(102836004)(26005)(186003)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1630; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 44ZhhVQ7UpndTGT8vT9jnAJqqg5S7go0txZLILZdQYwy6V59MrJ/lLbuVG+EzwR2697vMlsOSa9SvkG7mVL4OvsTYy7P2/4ofmjNHnp7m0yrdF2dqnLKw04jJk17ElGVagwCsqk8sdymVkB8DFPtFRNX+JLegXDIGYt2btTgOrY=
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_039E_01D3B247.749E7440"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fe656451-6a3b-43f1-3941-08d580994b2c
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2018 23:57:02.0771 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1630
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/RCFgSZQMMSGflYBgWQuJBlSNOB8>
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: Fri, 02 Mar 2018 23:57:10 -0000

One thing I would consider doing if I found myself in this situation is to take a fresh, signed OCSP response along with some text like REVOKE THIS CERTIFICATE and sign it with the private key for the certificate in question.

 

Haven’t done a full security analysis of the pros/cons but I thought I’d throw it out there.  It has some nice information about exactly which certificate and exactly when I made the request, and that it was made by someone with access to the private key.

 

It seems like a better idea than abusing a CSR for an unintended purpose.  Abusing signed messages for purposes they weren’t designed for usually ends badly.

 

-Tim

 

From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Ryan Sleevi
Sent: Friday, March 2, 2018 9:08 AM
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: SPASM <SPASM@ietf.org>
Subject: Re: [lamps] Revocation Request Format?

 

It seems signing a new CSR has been a common practice as proof of possession.

 

There's one segment of users that want to have a time-constrained request (that is, incorporating a challenge/response), while another would prefer that you can generate the 'request to revoke' at the same time you request the cert, so that you can use this token for situations such as loss of private key (but not loss of revocation token)

 

It doesn't seem like there needs to be a bespoke format here, considering that the industry is still working through its use cases, and any signed data is sufficient.

 

Further, it may do harm to try and standardize that. Consider the ROBOT attack ( https://robotattack.org/ ), which presented a signing oracle with TLS private keys. Prematurely constraining revocation requests to a particular format might otherwise preclude reasonable demonstration of private key compromise.

 

So I don't think there's anything for LAMPS to do here - we have ample available technology (running code that already works) and we have not yet ascertained industry needs in any meaningful way (no rough consensus for something new)

 

On Fri, Mar 2, 2018 at 9:24 AM, Phillip Hallam-Baker <phill@hallambaker.com <mailto:phill@hallambaker.com> > wrote:

Do we have a PKIX revocation request format?

 

I am asking because of a detail in the Trustico situation in which a file of 23K private keys was emailed to a CA to request revocation.

 

At the point, the circumstances of that situation are not clear. But I can see a scenario in which it is entirely plausible that a CA reseller would have access to large numbers of TLS private keys and that is when they are either hosting or managing the Web sites.

 

The management interfaces that allow Web sites to be wheeled around a data center have become very sophisticated of late with virtualization and much of that infrastructure is 'secret sauce'.

 

What might appear to be a five racks of 100 separate machines is likely visible in the management console as one single entity.


_______________________________________________
Spasm mailing list
Spasm@ietf.org <mailto:Spasm@ietf.org> 
https://www.ietf.org/mailman/listinfo/spasm