Re: [lamps] Revocation Request Format?

Ryan Sleevi <ryan-ietf@sleevi.com> Fri, 02 March 2018 22:33 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 3CBA412D7F1 for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 14:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 4udaHRLGJwj4 for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 14:33:37 -0800 (PST)
Received: from homiemail-a96.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 E6D9D1250B8 for <SPASM@ietf.org>; Fri, 2 Mar 2018 14:33:37 -0800 (PST)
Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id A3EC4C00292B for <SPASM@ietf.org>; Fri, 2 Mar 2018 14:33:37 -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=IdvcSzIUhXTXU6AyhVL2Wp64Fx0=; b= oxR1cWXqxVjFXgmYRnDvMq43MDb+VvlpE1vv7Lsnm+RdnKpF7o1UF5FTmBrldy0U AR7oLRMAmlx8bUz4OmjC5bCY0YgVCt4+txMnbEhTrx/r91ygNypCEjduFYypT1EG QR60xC/E7y1zw1R9Df8KONF0bRn6h7Dt/0SJdKDJYhU=
Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 44CEAC00292A for <SPASM@ietf.org>; Fri, 2 Mar 2018 14:33:37 -0800 (PST)
Received: by mail-it0-f41.google.com with SMTP id e64so3638147ita.5 for <SPASM@ietf.org>; Fri, 02 Mar 2018 14:33:37 -0800 (PST)
X-Gm-Message-State: AElRT7HADOZZ/VnXuPl5piSQYfiMD3rgWwyjBO5hbl8h8OX2zCS/SjrU mv+WUpwOatb/VlU2JqxraBhZmXDoLehq/p1Eh9M=
X-Google-Smtp-Source: AG47ELtGJnfhtey7ZmBfwCq3uzRFzWNaEqrcRHFPy0JE8oWhUdYRvveXDbqABbaccmgl0/R/3m95SOV5ZeXh/Hel2YM=
X-Received: by 10.36.170.6 with SMTP id b6mr4552925itf.148.1520030016659; Fri, 02 Mar 2018 14:33:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.105.214 with HTTP; Fri, 2 Mar 2018 14:33:36 -0800 (PST)
In-Reply-To: <26f237b9-bbe6-6efe-2a43-394d44e8334c@cs.tcd.ie>
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>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Fri, 2 Mar 2018 17:33:36 -0500
X-Gmail-Original-Message-ID: <CAErg=HH+B5+DcvPfUixy-3egm3zdhGjMangtAL0wixKE5PVkzw@mail.gmail.com>
Message-ID: <CAErg=HH+B5+DcvPfUixy-3egm3zdhGjMangtAL0wixKE5PVkzw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>, Phillip Hallam-Baker <phill@hallambaker.com>, SPASM <SPASM@ietf.org>, Peter Bowen <pzbowen@gmail.com>
Content-Type: multipart/alternative; boundary="f403045fae2830e7c00566759132"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/9CLOmjMN3ttN5i9GRG-CbBLNG68>
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 22:33:39 -0000

On Fri, Mar 2, 2018 at 4:45 PM, Stephen Farrell <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).