Re: [lamps] Considerations about the need to resume PKIX work

"Dr. Pala" <director@openca.org> Tue, 01 August 2017 17:15 UTC

Return-Path: <director@openca.org>
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 4320C1200F3 for <spasm@ietfa.amsl.com>; Tue, 1 Aug 2017 10:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=ham autolearn_force=no
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 vxFNkojfk-1P for <spasm@ietfa.amsl.com>; Tue, 1 Aug 2017 10:15:14 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 743EA1321B1 for <spasm@ietf.org>; Tue, 1 Aug 2017 10:15:14 -0700 (PDT)
Received: from maxs-mbp.cablelabs.com (host64-111.cablelabs.com [192.160.73.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 2D3EF3740843; Tue, 1 Aug 2017 11:12:10 -0400 (EDT)
To: "Salz, Rich" <rsalz@akamai.com>, "Dang, Quynh (Fed)" <quynh.dang@nist.gov>, Russ Housley <housley@vigilsec.com>
Cc: LAMPS <spasm@ietf.org>
References: <04e73e42-7c5b-912d-cc79-7959a710927e@openca.org> <C9C409F5-778F-4BEF-98B7-10D86996F1F8@vigilsec.com> <CY4PR09MB1464D8F73E5F96E76ED62B6BF3B80@CY4PR09MB1464.namprd09.prod.outlook.com> <0a12992260ec44ebab8cff0426670cc8@usma1ex-dag1mb1.msg.corp.akamai.com>
From: "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Message-ID: <7e290f82-2b2b-44ac-d976-d94064f3d90b@openca.org>
Date: Tue, 01 Aug 2017 09:12:09 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <0a12992260ec44ebab8cff0426670cc8@usma1ex-dag1mb1.msg.corp.akamai.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms060707010801010204020704"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/hVBKAeHJ_36dywiV-KkHV5gkxAw>
Subject: Re: [lamps] Considerations about the need to resume PKIX work
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: Tue, 01 Aug 2017 17:15:16 -0000

Hi Rich, all,

I do really hope we will be able to provide some alternatives that might 
work in different environments - I will try to make more formal 
proposals soon for the charter items and milestones. Depending on which 
direction the WG wants to go, I'd be happy to help with the 
implementation in OpenSSL. We do have some sample code for OCSP over DNS 
for our OCSP responder - it is just demo code (not even close to be 
production ready :D) but it might be used as an example :D

I think few optimizations might be low-hanging fruits (e.g., 
distribution of rev info via DNS, reducing the response size for 
non-revoked entries) and some others might require more creative 
thinking (e.g., cumulative responses for full-chain validation).

These are just examples, and I am curious to know if there are other 
possible proposals on the table...

Cheers,
Max


On 7/31/17 10:27 AM, Salz, Rich wrote:
>
> I am also curious to see what concrete things could be done to improve 
> revocation.  If the answer is “nothing” that’s okay, but if it’s not, 
> I expect OpenSSL will have to write some code J
>
> [...] 

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo