Re: [lamps] Revocation Request Format?

Ryan Sleevi <ryan-ietf@sleevi.com> Sat, 03 March 2018 00:46 UTC

Return-Path: <ryan-ietf@sleevi.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 A1E40126FB3 for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 16:46:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 byQgM3EH14Ga for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 16:45:58 -0800 (PST)
Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324A4126C26 for <SPASM@ietf.org>; Fri, 2 Mar 2018 16:45:58 -0800 (PST)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id B3847A004F1F for <SPASM@ietf.org>; Fri, 2 Mar 2018 16:45:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=49pymlKBHrDPfvemqLHnkxwA27M=; b= DgAZKb6ldHeoZGC31fMG9TCyPGVdmGP5TATWXFbzbqfjDJ7t9eEko9ysSvPgndFc vEcBwZeYky1utgTUajjpOsbjxiPZw1MwOkhsx9DeVxjZSrr8astpY9LMHBh9yI7c Vwx22j9LoU29ULOn7/Tr8ZgRsNST+HoCQbVGcuJrUPc=
Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 7162FA004F1B for <SPASM@ietf.org>; Fri, 2 Mar 2018 16:45:57 -0800 (PST)
Received: by mail-io0-f175.google.com with SMTP id m22so12398623iob.12 for <SPASM@ietf.org>; Fri, 02 Mar 2018 16:45:57 -0800 (PST)
X-Gm-Message-State: AElRT7GTO9tUJ+X2MgPzjIUjjwnIgHGoBX74ZrmTDkH9kmPbFs7WOV0D n4jbElhJ6uNWSuJ7gTMOehV7yahoVW4SpYiCXEA=
X-Google-Smtp-Source: AG47ELvjLM9Zl+y0/ccMG97D9rI/kcVTGuh+isxffq9Z2tMic5ZiDZWFcqtmdlJYBeltVSmLRfrtU3MYcgUEQqrz+Z4=
X-Received: by 10.107.58.86 with SMTP id h83mr8821768ioa.284.1520037956859; Fri, 02 Mar 2018 16:45:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.105.214 with HTTP; Fri, 2 Mar 2018 16:45:55 -0800 (PST)
In-Reply-To: <MWHPR14MB13763060DE4A23D49EE017BC83C50@MWHPR14MB1376.namprd14.prod.outlook.com>
References: <CAMm+LwjAP78hNL9Yaxqaf4K9RHYGk4M8ayJjCWt=F3_VN28cFQ@mail.gmail.com> <CAErg=HEK0aJm+Xb06px=vmfpyESetdRpe2x=q+Wca=9J8nErmw@mail.gmail.com> <MWHPR14MB13763060DE4A23D49EE017BC83C50@MWHPR14MB1376.namprd14.prod.outlook.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Fri, 02 Mar 2018 19:45:55 -0500
X-Gmail-Original-Message-ID: <CAErg=HEPjwf66UaUfnQ8GKaJVT06d1=N0kBMrZfVKHxBcF2xwA@mail.gmail.com>
Message-ID: <CAErg=HEPjwf66UaUfnQ8GKaJVT06d1=N0kBMrZfVKHxBcF2xwA@mail.gmail.com>
To: Tim Hollebeek <tim.hollebeek@digicert.com>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>, Phillip Hallam-Baker <phill@hallambaker.com>, SPASM <SPASM@ietf.org>
Content-Type: multipart/alternative; boundary="001a114ac88476bf150566776a95"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/vJSabJ1UjaSnff-z6oHkEZniax0>
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 00:46:01 -0000

On Fri, Mar 2, 2018 at 6:57 PM, Tim Hollebeek <tim.hollebeek@digicert.com>
wrote:

> 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.
>

Right, and I'm actually arguing against those properties as being
reasonable, for reasons I expand on bleow.


> 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.
>

The key is compromised. It's already ended badly. The format won't change
that if it is compromise, and since only the key holder can produce signed
messages in the first place, if they're signing a message that says their
key is compromised, well, then we know the just self-compromised :)

Perhaps the distinction is whether it's a Subscriber-initiated request or a
Third-Party initiated request.

For a Subscriber initiated request, there's no inherent requirement to
require they demonstrate the private key. It's fundamentally a question
about certificate lifecycle management, and one could just as easily
imagine a 'revoke this cert' button in the subscriber's certificate
management portal. Formats here don't help the subscriber, because the
revocation is part of the lifecycle management, and that overall process is
where you want to see the alignment. For a CA that supports ACME for
lifecycle management, ACME addresses this. However, for a CA that doesn't
use ACME, or a Subscriber who doesn't use ACME, the ACME lifecycle
management is more onerous and detrimental, and out of sync with the rest
of the lifecycle management.

For a third-party initiated request - that is, security researcher or the
like - I don't think more formats is necessarily beneficial. The burden
lies on the CA, not the reporter, regarding the investigation and handling
of this. Properties such as "Was this freshly done" are actively
detrimental, rather than beneficial - if it was compromised in the past,
then that's reasonable grounds for revocation. As for aligning how to
identify the certificate, that benefits the CA, sure, but it doesn't
benefit the reporter. If anything, it adds more burden on the reporter to
now try and shape their proof in a way the CA will accept.

>From a policy point of view, the policies on what an acceptable form of
proof is will vary based on the PKI. For the Web PKI, *any* proof of a
signed message, I would argue, is sufficient proof, so there's no need to
introduce formats for reporting, because any signed message is sufficient,
and, at a minimum, CAs are required to be monitoring that 24/7 with real
people and responding within 24 hours. So, at best, we're talking
optimizing the speed at which a CA responds by offering additional methods
for providing demonstration, but they aren't replacement methods nor will
they be sufficient methods. Nor are they necessarily optimizations - while
it may enable the CA to respond more quickly, it doesn't guarantee they
will - that's a question of policy for that particular PKI, and at least in
the Web PKI, CAs have the flexibility for 24 hours for investigation, 24
hours for revocation, and 24 hours for publication, and the incentive
structure is very much aligned for CAs to take advantage of that full time
precisely because it serves as a risk management method for them.



>
>
> -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> 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
> https://www.ietf.org/mailman/listinfo/spasm
>
>
>