Re: [lamps] Revocation Request Format?

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 02 March 2018 20:17 UTC

Return-Path: <hallam@gmail.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 B2914126C25 for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 12:17:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BeYjH_YKiDJ6 for <spasm@ietfa.amsl.com>; Fri, 2 Mar 2018 12:17:05 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CC7124217 for <SPASM@ietf.org>; Fri, 2 Mar 2018 12:17:04 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id g97so9813133otg.13 for <SPASM@ietf.org>; Fri, 02 Mar 2018 12:17:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mzFTtGVRVpELyzeBmvBGoDX+v1AGEIh3A6wZhepaRDg=; b=hZAj0BGvTBuuEfKW2U3JsnNH/6yMQEip4iOKyQDcpq6+S5Ems9SwL0fzJzW3P9plzD 3wWqxOfWTVFHI1lAYrR0r6czbexxGbhsM4LcJbjnEii1YcLu57ayuGw1nGbaEk9oMpky dLI8ZSaQNNOfSIe+yFDdFZhc3M0Nu+ydAx13vUx/+fIZ2CPkx2KqfUDxriWIplsNuhp/ z7r7otd3tANc4LmkjnDexWorDM16UJM6l4XVQrpj7FT8f7UbeZn6Ir/BXeh4JJ9L7Gu4 i2Gv1bE6sZkDRZiofVbvHc+chOgPx4rfxTcNWE79IQb9JxjUiw8UY3EPvi8REnjR7yKP LKgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mzFTtGVRVpELyzeBmvBGoDX+v1AGEIh3A6wZhepaRDg=; b=ScT/XwnnJnB4VoaZiV/xa1SIi7IYYsfuRz/BR99DAytknOHlmZRjZ9lGo32kGitZ44 IONPS7ReULgmGkfdNczPBIKDMjtG+/CRW3WnAhRe5OUrcnoAt6nYWbWk9dy02o2C2P40 zXYQkSLkyvpOVrxjFslBYC64r/hpxvV2+d3AwvSCu/1v/db7ut1HMCoHrL3SPQho+9p8 ZqqTblUcCF3OQcyTEd3VDviBfxjVAKJQDvC+cRb+i/A0Y6H0vwpIb+/MyV8GPtEFRQ7Y krQc1zJ2VUU4BEzmGs0Al5d9+eNzG87ZMX8vTl9xL9aXSoXeiuQkWNkSnKGN4lgF9eR/ m92Q==
X-Gm-Message-State: AElRT7HvzsVXiY4lMAVtZ1PDdvqz7S2QbHXt5qudUusRGwikI6/jjB9n dmh3VsWVq6VSCmkozhbYE26Q3oS7+fzkogD9oV8=
X-Google-Smtp-Source: AG47ELsTzrn0R55MNpoHGdl1CXK40BwqH4HrtacTWwwdBjgUtfQLMp98t7P+E3V+sxVY7d/4FVHIhIDUHbmKlFelqQA=
X-Received: by 10.157.65.140 with SMTP id p12mr4660301ote.167.1520021823957; Fri, 02 Mar 2018 12:17:03 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.5.5 with HTTP; Fri, 2 Mar 2018 12:17:03 -0800 (PST)
In-Reply-To: <CAK6vND8p55yNVoXO6_eJs1ooodVBAFZovJ84ou6uj_4qHt5DGA@mail.gmail.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>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 2 Mar 2018 15:17:03 -0500
X-Google-Sender-Auth: 57t0OQ0j8UzfSk0HOmKYgBPN7J8
Message-ID: <CAMm+LwjKKqaG+OjSw3KaSvwymy6mvvyEDx1sMp2EGqXqvPSdjA@mail.gmail.com>
To: Peter Bowen <pzbowen@gmail.com>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>, SPASM <SPASM@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1c1ce2de3115056673a8e8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/BCBqafPIOZUQfaCwiehK6v_NCfE>
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 20:17:07 -0000

If it is a signing key, just sign a CRL for the certificate. Now that is
not quite the same as revoking the key but certs are the only things PKIX
makes status assertions about.

Do we have to support self-revocation of certs with only encryption only
keys? Probably not.

Since a very common reason for having to revoke a cert is that the private
key is lost entirely any revocation format cannot be the only way to
request revocation. So I don't see the relevance of the robot attack.


Standards are all about taking choices that don't matter except that a
choice is made. If we choose to recognize CRL suicide notes as the one
mechanism that must be supported, that is one mechanism that can be added
to PKI toolkits that don't already have it. And yes, there is at least one
widely used toolkit that allows certificates and CRLs to be parsed but not
generated.



On Fri, Mar 2, 2018 at 3:03 PM, Peter Bowen <pzbowen@gmail.com> wrote:

> On Fri, Mar 2, 2018 at 8:08 AM, Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
> > 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)
>
> There is also a documented (albeit not in RFCs) format for a generic
> signed public key with challenge:
> https://www.w3.org/TR/html51/sec-forms.html#the-keygen-element
>
> PublicKeyAndChallenge ::= SEQUENCE {
>   spki SubjectPublicKeyInfo,
>   challenge IA5STRING
> }
>
> SignedPublicKeyAndChallenge ::= SEQUENCE {
>   publicKeyAndChallenge PublicKeyAndChallenge,
>   signatureAlgorithm AlgorithmIdentifier,
>   signature BIT STRING
> }
>
> The challenge is an arbitrary length IA5STRING, so it could easily
> include nonce or other challenge data to prove key control.
>
> Thanks,
> Peter
>