[therightkey] Proposal for working on PKIX revocation open issues

"Dr. Massimiliano Pala" <massimiliano.pala@gmail.com> Sat, 15 November 2014 01:42 UTC

Return-Path: <massimiliano.pala@gmail.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 95CB21A0275; Fri, 14 Nov 2014 17:42:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_HK_NAME_FM_DR=0.01] 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 KlXskT8ih2wm; Fri, 14 Nov 2014 17:42:26 -0800 (PST)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BAD1A00A9; Fri, 14 Nov 2014 17:42:25 -0800 (PST)
Received: by mail-pd0-f177.google.com with SMTP id v10so17462644pde.8 for <multiple recipients>; Fri, 14 Nov 2014 17:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=3erb4iDu3y8uZPZVQSh7vexbzm1UcQLcMM2PsojJQoE=; b=0e3SvbMhMIC05wXA3cVhTholbZJREAM0BHideJejtyIcgfvfBDpXjdIhyAVo99GmGh ys3eEZaeKV7VeUWs7SZ1duTZsPrTnDqrqwldSu/thBv8fpZFHu3gPfYwaclxSca7LqDz wftldTAZ1CnaxOIiknWAHvha5FfexGx6FT0sBybU2gXVxQ6IpysAjXIh25bqKhUooVkG IZXVuDmgA8kO8O7xg1oIbiaQWCw0oj0nuTN1bj/RHSTQdW56IcCIUnRjkjr0UYg/2P0m ZdS9EpSCeUU99vWM777UWLjdZ9OD6ldtwoSweftEtpVbsQ0+6tnqh5kndrpg6GfEuixR 3H7A==
X-Received: by 10.68.220.39 with SMTP id pt7mr13710515pbc.37.1416015745110; Fri, 14 Nov 2014 17:42:25 -0800 (PST)
Received: from iMassi.local ([172.56.16.52]) by mx.google.com with ESMTPSA id o5sm28703396pdr.50.2014.11.14.17.42.23 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 17:42:24 -0800 (PST)
Message-ID: <5466AF87.2050307@gmail.com>
Date: Fri, 14 Nov 2014 15:42:31 -1000
From: "Dr. Massimiliano Pala" <massimiliano.pala@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: therightkey@ietf.org, "pkix@ietf.org" <pkix@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/F05va3DSo6NjrB46qdA8FiXlBq4
Subject: [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: Sat, 15 Nov 2014 01:42:27 -0000

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

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 - 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 mailing 
list because we thought 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