Re: [therightkey] Proposal for working on PKIX revocation open issues

Jeremy.Rowley <jeremy.rowley@digicert.com> Mon, 17 November 2014 17:02 UTC

Return-Path: <jeremy.rowley@digicert.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3141A7D80 for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 09:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.895
X-Spam-Level:
X-Spam-Status: No, score=-4.895 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_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 w012efUAYG3c for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 09:02:54 -0800 (PST)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3601A700B for <therightkey@ietf.org>; Mon, 17 Nov 2014 09:02:45 -0800 (PST)
Message-ID: <546A2A34.6020907@digicert.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1416243764; bh=zS8Uc298jEut9Llbvtz5P8RYbXdSTGtBVwmjcotnrKQ=; h=Date:From:To:Subject:References:In-Reply-To; b=LgVuxWxmGyNPWSeDlfHtxgC67eKvaZ1Dfw3LAWeYCDctzyZbi0dvB2HYkSBRZhXEt MvnReS771OXPrIrxIDtilFklEvDbJ+EO8UFzd9mmTLtkIH7n5npSkPFQ4UXXjyRmbA yHIv4hIVQBouGgsXwTb33PRKlczW/JjfeEAVdnKI=
Date: Mon, 17 Nov 2014 10:02:44 -0700
From: "Jeremy.Rowley" <jeremy.rowley@digicert.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: therightkey@ietf.org
References: <5466AF87.2050307@gmail.com> <CABrd9SQkXK99ski74A8EyqHDptBsVs_aN6117Br8NyuPhYAa_Q@mail.gmail.com>
In-Reply-To: <CABrd9SQkXK99ski74A8EyqHDptBsVs_aN6117Br8NyuPhYAa_Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------070203030907050004070409"
X-Originating-IP: [67.137.52.8]
X-ClientProxiedBy: EX1.corp.digicert.com (10.12.0.5) To EX2.corp.digicert.com (10.12.0.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/UpwbLN8Hs5Bg7d5shgxP6rT6RwU
Subject: Re: [therightkey] Proposal for working on PKIX revocation open issues
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 17:02:57 -0000

+1 to using a CT-like structure to also provide revocation information.

On 11/17/2014 8:52 AM, Ben Laurie wrote:
>
>
> On Sat Nov 15 2014 at 1:42:31 AM Dr. Massimiliano Pala 
> <massimiliano.pala@gmail.com <mailto:massimiliano.pala@gmail.com>> wrote:
>
>     Dear PKIX Enthusiasts,
>
>     Although great work has been done in the past... 20 years.. (?) on
>     providing very good protocols in the PKIX work, I think that we all
>     agree that we still have some unresolved issues. In particular, the
>     revocation is still a hot topic (especially for online environments)
>     could use improvement over the current status of things. In
>     particular,
>     by looking at current specifications, some work is needed to address
>     concerns especially in non-web environments.
>
>     For example, current specifications about OCSP stapling do not address
>     the case of client authentication (which is a widespread use case
>     outside the web environment) or, again, defining some new transport
>     protocols for delivering OCSP responses which might reduce operational
>     costs for revocation service providers.
>
>     After proposing the idea to Stephen Farrell and Kathleen Moriarty, we
>     would like to know if there might be interests in participating in
>     updating the status of the current revocation mechanisms for PKIX.
>     This
>     said, the scope of the work I am proposing is very limited.
>     Specifically:
>
>     (a) Defining new transport protocols for revocation information
>     availability (e.g., OCSP over DNS or OCSP over LDAP)
>     (b) (Possibly) defining a more lightweight revocation mechanisms (e.g.
>     Lightweight Revocation Tokens)
>     (c) (Possibly) helping other working groups to revise and update how
>     revocation information are provided (e.g., the client
>     authentication case)
>     (d) (Possibly) introducing privacy consideration when it comes to
>     revocation checking
>
>
> FWIW, we (Google) are interested in doing the same thing for 
> revocation that CT does for certs - i.e. providing a verifiable 
> log/map of revocation status.
>
> Not sure if that fits into your remit above (on the face of it, it 
> does not).
>
>
>     Because of these considerations, I am proposing to start a
>     conversation
>     - for now, Stephen and Kathleen suggested we use (or "abuse") the "The
>     Right Key" mailing list to see if there might be enough interest
>     in the
>     work from implementers to address these issues. I know that we
>     (OpenCA)
>     are interested in implementing these features, and we would like that
>     the work would be standardized.
>
>     At minimal, I would like (a) to happen. This could be achieved in 6
>     months (and we might not even need to meet). (b) and (c) are also
>     desirable in order to provide better support for non-browsers and
>     small
>     devices (AFAIK, some work might be relevant for DICE). (d) is
>     something
>     that we should, I think, all be mindful and at least some
>     considerations
>     should be provided. The scope of the work, however, will be limited to
>     revocation.
>
>     Please, if you are interested and would like to start the discussion,
>     post your opinion on therightkey@ietf.org
>     <mailto:therightkey@ietf.org> - also, please, circulate this
>     proposal to anybody who might be interested in collaborating on
>     this issue.
>
>     Please also note that we did decide not to use the pkix@ietf.org
>     <mailto:pkix@ietf.org> mailing
>     list because we thought therightkey@ietf.org
>     <mailto:therightkey@ietf.org> might provide a more active
>     pool of implementors.
>
>     Looking forward to receive all your inputs and start working on
>     the topics.
>
>     Cheers,
>     Max
>
>
>     _______________________________________________
>     therightkey mailing list
>     therightkey@ietf.org <mailto:therightkey@ietf.org>
>     https://www.ietf.org/mailman/listinfo/therightkey
>
>
>
> _______________________________________________
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey