From nobody Fri Nov 14 17:42:29 2014
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



From nobody Fri Nov 14 17:47:48 2014
Return-Path: <stephen.farrell@cs.tcd.ie>
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 73B431A00AD for <therightkey@ietfa.amsl.com>; Fri, 14 Nov 2014 17:47:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level: 
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 Y4QAHNx0emUS for <therightkey@ietfa.amsl.com>; Fri, 14 Nov 2014 17:47:45 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 704E51A00A9 for <therightkey@ietf.org>; Fri, 14 Nov 2014 17:47:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BA39DBE49; Sat, 15 Nov 2014 01:47:43 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BQCWMxmymIe; Sat, 15 Nov 2014 01:47:42 +0000 (GMT)
Received: from [10.87.48.4] (unknown [86.42.24.216]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9F3A3BE3E; Sat, 15 Nov 2014 01:47:42 +0000 (GMT)
Message-ID: <5466B0BE.80204@cs.tcd.ie>
Date: Sat, 15 Nov 2014 01:47:42 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Dr. Massimiliano Pala" <massimiliano.pala@gmail.com>,  therightkey@ietf.org
References: <5466AF87.2050307@gmail.com>
In-Reply-To: <5466AF87.2050307@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/S4tXC_HQ1kU_yykAA4_abUgpiDM
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Subject: Re: [therightkey] [pkix] 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:47:47 -0000

Thanks Max,

On 15/11/14 01:42, Dr. Massimiliano Pala wrote:
> 
> 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.

Just to re-iterate: if some good approaches for revocation of X.509
certificates emerge from this discussion that appear likely to get
implemented usefully then Kathleen and I will be happy to try help
form a wg or whatever is needed to develop the work.

Cheers,
S.


From nobody Fri Nov 14 23:55:51 2014
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 53C3B1A1B65; Fri, 14 Nov 2014 23:55:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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] 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 Wpm3N0lkKoyx; Fri, 14 Nov 2014 23:55:45 -0800 (PST)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C591A1B80; Fri, 14 Nov 2014 23:55:45 -0800 (PST)
Received: by mail-pd0-f172.google.com with SMTP id r10so18197682pdi.3 for <multiple recipients>; Fri, 14 Nov 2014 23:55:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4osC7u20cpdYmeVENvXw83XRpF1lnHUjMS4mRkfyDOA=; b=VrPMSit9LBA5CjmmzJFWJgDsMTgBg0UqvjE43KJ+5Bqh9wl/SVurVi4KzcQzemxJjc x5URiQNKwxcn1PZFUBi/RlhneUiGuCmXvGElkJpsrBzTk5u8n2MeppLZwHRTJOK653jX 7e75wvvE0wQ6wS/aFaTvU/CQyy/9BL6byaFJ+jvGtssFkgHjW6utD/Tar5EHbEWnr2O2 Vp294S2yR4XHGZOrbtHlw8HGtmtCsGQa6+1H7eqEsU2SoKPDHfe9XbbWAFqKH+z1rd27 PUlZCILcn0wgAI/EUakE8jZJ6aWds1ZZVfx7CPRRWfeK8XdSJyo0jgneGsrglK2rqF5h pwxg==
X-Received: by 10.68.204.8 with SMTP id ku8mr15389687pbc.103.1416038144488; Fri, 14 Nov 2014 23:55:44 -0800 (PST)
Received: from [100.107.83.90] ([172.56.30.49]) by mx.google.com with ESMTPSA id te2sm29408787pbc.51.2014.11.14.23.55.43 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 23:55:43 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Massimiliano Pala <massimiliano.pala@gmail.com>
X-Mailer: iPhone Mail (12B411)
In-Reply-To: <5466D73B.4000900@gmail.com>
Date: Fri, 14 Nov 2014 23:55:44 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C0EDB94-79FC-4885-B0D8-7169FE5F0610@gmail.com>
References: <5466AF87.2050307@gmail.com> <5466D73B.4000900@gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/V3bQ--zV9DGUNnzS1Wxram0E4uI
Cc: "pkix@ietf.org" <pkix@ietf.org>, "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] [pkix] 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 07:55:48 -0000

Hi Anders,

thanks for the reply. The scope of this proposal was restricted on purpose t=
o see if we gather consensus on a specific area:  revocation, therefore I am=
 limiting my reply to that area to allow the conversation to be focused. May=
be your proposal could be future work for some other pkix-related wg, but it=
 is not in scope with this proposal.

For the HTTP comment, I respectfully disagree. There are many areas where ap=
plications use authentication and confidentiality but do not talk HTTP. Howe=
ver, even if they do, they are not browsers and requirements and their capab=
ilities might be different. However, as I see it, this work will be orthogon=
al to the application protocol.

For the question about client authentication, the only thing that I see miss=
ing today is the possibility, for clients, to present their own revocation i=
nformation (i.e. being able to staple OCSPD responses for the presented cert=
ificate) [RFC 6961 only defines client requests for certificate status]. Thi=
s would provide the server side with the possibility to request/require the c=
lient to provide information about their certificate chains.

I think this might have the positive effects for client-side certificate aut=
hentication and, ultimately, deployment.

Cheers,
Max


> On Nov 14, 2014, at 8:31 PM, Anders Rundgren <anders.rundgren.net@gmail.co=
m> wrote:
>=20
>> On 2014-11-15 02:42, Dr. Massimiliano Pala wrote:
>> Dear PKIX Enthusiasts,
>=20
> Thanx :-)
>=20
> Just for my curiosity, have the OpenCA team implemented EST?
>=20
> If not, I think this highlights the core problem which is adoption of stan=
dards.
> Microsoft, Intel, et. al. spent *hundreds of millions of dollars* on stand=
ardization
> of TPMs only to find that the bulk of the mobile device market (their comp=
etitors...)
> had taken another, more agile path.
>=20
> Since HTTP seems to the lowest common denominator for all networked
> devices, it looks like that you will run into serious adoption issues.
>=20
> I must admit that I don't understand what problem you want to solve
> in the context of *client authentication*.  The client's ability
> to gather revocation information abouts its own keys?  That's hardly
> a problem worth solving.  It sounds like a W3C proposal that I once saw
> which was about introducing an API at the client-side for revoking your
> own certificate(s).
>=20
> As you can see the remains of the PKIX WG still don't want to discuss
> requirements like imposed by "Derived Credentials" which actually is
> a core PKI application that eventually will be used by everybody.
>=20
> Anders
>=20
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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:=

>>=20
>> (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
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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 issu=
e.
>>=20
>> 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.
>>=20
>> Looking forward to receive all your inputs and start working on the topic=
s.
>>=20
>> Cheers,
>> Max
>>=20
>>=20
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>=20


From nobody Sat Nov 15 00:42:10 2014
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 171431A1BC4; Sat, 15 Nov 2014 00:42:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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] 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 YTOgJ5wAz0my; Sat, 15 Nov 2014 00:42:06 -0800 (PST)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3631A19EE; Sat, 15 Nov 2014 00:42:05 -0800 (PST)
Received: by mail-pa0-f41.google.com with SMTP id rd3so4490844pab.14 for <multiple recipients>; Sat, 15 Nov 2014 00:42:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I+hvo9+EwGWiul9XxV3uoftuA8I15I0Mwe5sLddq5ec=; b=rYrPz7Wc6O2Q99GmfyTo+sht2WnB+x69a2DkoQJ4j1hGAkwh0//Ov4TVzgEVbsqvQV bbtqnIl05xT7KHyEX36h9HG2ZDGQAaTHRp270grGwMg4NVowS+pxjnz5BvZekGbxlNWV iTZBUG+hE9LkhohWUJITaXp58dD2sJg9PT7hOXxbsy4PNyoigTJ52+UDf9iSDQOKaEvK bQwojur3oJd9PZ4AWMvBEgbRj+HFGIBQg75FFlCa+BzR+lKvf0NPSOZTh/QrNDEShWla YMfbqFV2G4pufENIq1OjNHM0kJxEjRaudU8ZCeg/KnHTM+pmLzB/97BzoE5ufji79OSk Bf6A==
X-Received: by 10.70.90.11 with SMTP id bs11mr16120172pdb.16.1416040924778; Sat, 15 Nov 2014 00:42:04 -0800 (PST)
Received: from [100.107.83.90] ([172.56.30.49]) by mx.google.com with ESMTPSA id te2sm29529809pbc.51.2014.11.15.00.42.04 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Nov 2014 00:42:04 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Massimiliano Pala <massimiliano.pala@gmail.com>
X-Mailer: iPhone Mail (12B411)
In-Reply-To: <5466E08E.70103@gmail.com>
Date: Sat, 15 Nov 2014 00:42:05 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A674E880-6D09-46F8-B38F-BFCC4B9D1AD1@gmail.com>
References: <5466AF87.2050307@gmail.com> <5466E08E.70103@gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/I_3gG_b9NUvQvbZTW3fgGC6DSp0
Cc: "pkix@ietf.org" <pkix@ietf.org>, therightkey@ietf.org
Subject: Re: [therightkey] [pkix] Client-side OCSP stapling? Re: 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 08:42:08 -0000

Thanks Anders!

Do you have any contacts for people working at that project? We might want t=
o reach out to them as possible implementors and maybe start a conversation w=
ith them about possible requirements ? And eventually let them know about th=
e progresses we might accomplish in the area.

Cheers,
Max

P.S.: Since Stephen and Kathleen asked me to have the conversation on The Ri=
ght Key mailing list (therightkey@ietf.org), please could you send the repli=
es only there? We should not use both therightkey and the pkix MLs :-)


> On Nov 14, 2014, at 9:11 PM, Anders Rundgren <anders.rundgren.net@gmail.co=
m> wrote:
>=20
> Since you want to do something in revocation I would like to
> describe an existing potentially global PKI-using system that
> maybe could be improved.
>=20
> The EU e-passport system needs for crossborder-checking of biometrics
> a pretty elaborate PKI scheme which among many things require
> the parties to expose two public ports on the Internet; one for
> the actual communication using HTTPS[1] and another for publishing
> CRLs using HTTP.  This isn't rocket-science but it still requires
> multiple FW settings and proxies.  If OCSP responses could be
> stapled (TLS client cert auth is used), relying parties would only
> have to open a single inbound port.  Cross-border reliability would
> probably also be improved since the client (sender) wouldn't be able
> to submit any data unless its OCSP is running (the PKIs are unique
> per country).
>=20
> TLS 1.3 and 2.0 are in the workings so the timing is right...
>=20
>=20
> Anders
>=20
> 1] I might add that I believe HTTPS with client certificate auth
> is a very poor choice for cross-border communication when each party
> run their own PKI. Signed messages permit a multi-tier architecture
> and quarantining of not yet trusted messages, greatly simplifying
> operation.  BSI are experts on crypto, but n00bs on IT :-)
>=20
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix


From nobody Sat Nov 15 10:22:50 2014
Return-Path: <paul.hoffman@vpnc.org>
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 37DB41ACD8A; Sat, 15 Nov 2014 10:12:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level: 
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 q-5uJC1ULDFe; Sat, 15 Nov 2014 10:12:49 -0800 (PST)
Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8151ACD37; Sat, 15 Nov 2014 10:12:48 -0800 (PST)
Received: from [10.20.30.90] (142-254-17-6.dsl.dynamic.fusionbroadband.com [142.254.17.6]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sAFICl8k078358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Nov 2014 11:12:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-6.dsl.dynamic.fusionbroadband.com [142.254.17.6] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <5466AF87.2050307@gmail.com>
Date: Sat, 15 Nov 2014 10:12:47 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <4ACAB901-FE45-4E5E-A9E0-8F51E94A2924@vpnc.org>
References: <5466AF87.2050307@gmail.com>
To: "pkix@ietf.org" <pkix@ietf.org>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/uaA6UiCpPuSQwgaacWmytjhBTl8
X-Mailman-Approved-At: Sat, 15 Nov 2014 10:22:45 -0800
Cc: therightkey@ietf.org
Subject: Re: [therightkey] [pkix] 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 18:12:54 -0000

On Nov 14, 2014, at 5:42 PM, Dr. Massimiliano Pala =
<massimiliano.pala@gmail.com> wrote:
> (a) Defining new transport protocols for revocation information =
availability (e.g., OCSP over DNS or OCSP over LDAP)

If you mean "pre-recorded (sometimes called 'stapled') OCSP responses", =
yes, this is useful. Maybe even over HTTP!

> (b) (Possibly) defining a more lightweight revocation mechanisms (e.g. =
Lightweight Revocation Tokens)

Not interested.

> (c) (Possibly) helping other working groups to revise and update how =
revocation information are provided (e.g., the client authentication =
case)

Not interested.

> (d) (Possibly) introducing privacy consideration when it comes to =
revocation checking

Slightly interested.

--Paul Hoffman=


From nobody Sat Nov 15 13:56:58 2014
Return-Path: <hallam@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 722EB1A8879 for <therightkey@ietfa.amsl.com>; Sat, 15 Nov 2014 13:56:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Level: 
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 NdJL7SpFewPH for <therightkey@ietfa.amsl.com>; Sat, 15 Nov 2014 13:56:55 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D816C1A8872 for <therightkey@ietf.org>; Sat, 15 Nov 2014 13:56:54 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id mc6so16849009lab.12 for <therightkey@ietf.org>; Sat, 15 Nov 2014 13:56:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=/0Yvo167k0TccamqEgaRMBBaZ09SjtLC52oSOkdaWLg=; b=on2tSMN2XO+oUyte2TdNnrOPkLhO9UU0+DuLHlAKA867b5N/vkveyD0GITEv5Vcy2P etx0bv5ZpH72IslPgwqBMorzzpKSHJDcM9HluJQ8BkupGijfKO6Zfvev+jfGXJ9pl17s Oyc4PO5C+5ofLNyEt1CDGJUIbZtOmi9FYqlyF2CgRPgAKrT20Es2PgNsIXKm4FyO5lDE jrkvC0VNXiC7kf8uxeiAjafq1VRj/6iv1/B/1We6YNBWnq0BnEtqRrwAQCrzqcKfzYjL BcIJu/quD7OjlTjV7FL8k1ktW9i2YU2ZUXMZpWbbn6UVeG4B7+Y2DcGT12pwchkit/5l E8Kg==
MIME-Version: 1.0
X-Received: by 10.152.2.41 with SMTP id 9mr15572028lar.47.1416088613375; Sat, 15 Nov 2014 13:56:53 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.34.212 with HTTP; Sat, 15 Nov 2014 13:56:53 -0800 (PST)
In-Reply-To: <5466AF87.2050307@gmail.com>
References: <5466AF87.2050307@gmail.com>
Date: Sat, 15 Nov 2014 16:56:53 -0500
X-Google-Sender-Auth: 7oNQC_UpMlUAHkOXSfFcIG6R5zw
Message-ID: <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "therightkey@ietf.org" <therightkey@ietf.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/YHK8JDyRrDGPiYx4rEJQoAHMYGo
Subject: Re: [therightkey] [pkix] 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 21:56:57 -0000

On Fri, Nov 14, 2014 at 8:42 PM, Dr. Massimiliano Pala
<massimiliano.pala@gmail.com> wrote:
> Dear PKIX Enthusiasts,

> 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)

There is already a mechanism for transporting certs over LDAP. I am
pretty sure the folk who do that sort of thing have done the OCSP in
LDAP thing already.

I don't see a future for LDAP as an Internet protocol though. LDAP
introduces a completely gratuitous name infrastructure (X.500) that
adds no value other than to the consultants who can spin a 3 week
consulting gig bikeshedding the DIT with the customer. Nobody has ever
explained an advantage to me of LDAP over HTTP and a well-known
service convention.


OCSP over DNS has the attraction that DNS transport is fast. But
remember that DNS transport is fast because it is absolutely minimal.
Putting more stuff into DNS risks making it slow.

The construction of PRIVATE-DNS attempts to square this circle by
providing a mechanism that allows other protocols to make use of the
DNS channel (if that makes sense) without incorporating them into the
DNS protocol.


> (b) (Possibly) defining a more lightweight revocation mechanisms (e.g.
> Lightweight Revocation Tokens)

The patents on these techniques begin to expire in May 2016. Come back
then. They have not been available on RAND basis let alone RANDZ.

I'm not too interested in them however. S/Key does provide a rapid
means of updating status. Torben Pederssen proposed it as the phone
tick modus, Micali and Kocher proposed schemes that add in Merkle tree
mechanisms. Fast ECC signatures make these moot.


> (c) (Possibly) helping other working groups to revise and update how
> revocation information are provided (e.g., the client authentication case)

CRLs probably work just fine for servers validating private label client certs.


> (d) (Possibly) introducing privacy consideration when it comes to revocation
> checking

Well that is the reason to get away from using straight OCSP. It leaks
information. But stapled OCSP solves that problem.


> 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.

I have a different set of proposals:

1) Stapled OCSP with MUST-STAPLE OID
2) Short lived Certificates
  2a) With the same key
  2b) With different keys
3) CRLs with HBS compression.

Right now we are in the middle of deployment of (1) and doing 2a is
not too hard. But 2b is a LOT better since rotating the keys every 24
hours makes all sorts of attacks a lot harder.

Making 2b work requires quite a bit of prep though. We would have to
completely automate the cert issue process. And we would have to make
it work with pinning etc..

3 is new but we can probably get to convergence on a spec faster than
2b because we haven't tried that problem 4 times already. Much less
room for bikeshedding.


I see 1/2a as stop gap measures and 2b + 3 as the long term approach.

Rather than talk about 'the' revocation problem, I think we should
identify 2 separate revocation problems

Coarse grain: Narrow the vulnerability window from 1-3 years to 48 hours.
Fine grain: Narrow the vulnerability window to 60 mins.

Short lived certs (2b) are the best solution to coarse grain
revocation but it is really hard to get them working well for a window
of less than 48 hours. We would have to define a trusted time protocol
for a start and establish a distribution infrastructure for it.

HBS(3) can be used for both coarse grain as well as 2b at current
certificate issue rates. But it is a compression technique and it only
reduces the size of the problem by several orders of magnitude. If
cert use grows by an order of magnitude we are back in trouble. That
said, combining HBS with short lived certs gives us a path to
achieving fine grain revocation. And that is critical in the longer
term. The criminals do most of their fraud in the first 24 hours after
putting a server live.


Short lived certs have the enormous advantage that the vast majority
of revocations are for administration reasons, at the request of the
cert subject. Revocations for end-entity breach are much rarer. But
the problem is that we don't have an accurate means of distinguishing
between the cases. Our customers don't want to tell us when they have
done something doofus like selling the hard drives with private keys
for a live cert.

Short lived certs have the nice property that many doofus behaviors
time out automatically even if the customer does not catch them. Since
it takes more than 24 hours to sell old hard drives on EBay, the keys
corresponding to short lived certs will have expired by the time the
drives ship.


So to sumarize, here is my roadmap

Now: OCSP Stapling with MUST STAPLE
12 months: CAs begin issuing HBS compressed CRLs in a form that
permits browsers to use them as a basis for constructing 'BigCRL' type
solutions
24 months: Begin issue of 2a short lived certs
36 months: Begin issue of 2b short lived certs

5 years: Begin deprecating long lived certs
10 years: Begin phase out of long lived certs
20 years: Stop issue of long lived certs


Short lived certs with new keys per cert are definitely the way to go
long term. But it will take a long time to eliminate long lived certs
- if that is possible at all. That is fine though, provided we can
make sure that the majority of the growth in certs is of short lived
certs, we will be fine.

I think that is going to happen naturally since short lived certs are
a much better fit for the cloud than long lived ones. If I use a
server for 3 hours, I don't want to rely on the hosting provider
scrubbing the memory before the next customer gets hold of it to
protect my private keys. I want to limit the scope for service
provider defection as well.


The barrier to deployment on 2b is writing a good spec for
provisioning certs. I have a rough sketch of a JSON prototype that
basically just wraps a CSR.


From nobody Sun Nov 16 10:53:12 2014
Return-Path: <trevor.freeman99@icloud.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 4EE911A1A2E for <therightkey@ietfa.amsl.com>; Sun, 16 Nov 2014 10:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 s36zrAdalkk5 for <therightkey@ietfa.amsl.com>; Sun, 16 Nov 2014 10:53:07 -0800 (PST)
Received: from mr11p24im-asmtp001.me.com (mr11p24im-asmtp001.me.com [17.110.78.41]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D811A19E7 for <therightkey@ietf.org>; Sun, 16 Nov 2014 10:53:07 -0800 (PST)
Received: from Den (c-67-183-152-156.hsd1.wa.comcast.net [67.183.152.156]) by mr11p24im-asmtp001.me.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NF500AS1B4H2PC0@mr11p24im-asmtp001.me.com> for therightkey@ietf.org; Sun, 16 Nov 2014 18:53:07 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-16_03:2014-11-15,2014-11-16,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411160171
From: Trevor Freeman <trevor.freeman99@icloud.com>
To: 'Massimiliano Pala' <massimiliano.pala@gmail.com>, therightkey@ietf.org
References: <5466AF87.2050307@gmail.com> <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com>
In-reply-to: <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com>
Date: Sun, 16 Nov 2014 10:53:01 -0800
Message-id: <004501d001ce$8c669c10$a533d430$@icloud.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-index: AQFUCYhQhiaGoOJda7G7bFU0mLLbLQH/JSjNnUuIyuA=
Content-language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/T5LUK9jFGP9Rez-1Wyn2GXyqm8g
Subject: Re: [therightkey] [pkix] 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: Sun, 16 Nov 2014 18:53:10 -0000

Hi Max,

I think we first need a consensus of the unmitigated threats this work would
look to address. That would help assess the technical options. Top of my
list of unmitigated threats would be compromised CA issuing  user
certificates outside of the normal process e.g. attackers use some tool to
sign the certificate direly using the CA key so no log exists of the
issuance.   

For example, if there is consensus on that as a threat to be addressed, OCSP
does not help much in that you want a "known to be good" assertion, not a
"know to be bad" assertion that revocation checking provides. Certificate
reissuance has been long been cited as an alternative to revocation in that
you get a restatement of the goodness which is what you need, but it does
tax the CAs. If you are targeting server validation scenarios, then a Valid
Certificate List which was similar to CRLs but a list of good certificates
could scale much better as Phil points out. Given we know all too well what
does not work well with CRLs, we should be able to avoid the mistakes i.e.
use hashs to identify certificates not issue\serial number, mandate support
for partitions etc., etc.

So what unmitigated threats do you have in mind?

Trevor

-----Original Message-----
From: therightkey [mailto:therightkey-bounces@ietf.org] On Behalf Of Phillip
Hallam-Baker
Sent: Saturday, November 15, 2014 1:57 PM
To: therightkey@ietf.org
Subject: Re: [therightkey] [pkix] Proposal for working on PKIX revocation
open issues

On Fri, Nov 14, 2014 at 8:42 PM, Dr. Massimiliano Pala
<massimiliano.pala@gmail.com> wrote:
> Dear PKIX Enthusiasts,

> 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)

There is already a mechanism for transporting certs over LDAP. I am pretty
sure the folk who do that sort of thing have done the OCSP in LDAP thing
already.

I don't see a future for LDAP as an Internet protocol though. LDAP
introduces a completely gratuitous name infrastructure (X.500) that adds no
value other than to the consultants who can spin a 3 week consulting gig
bikeshedding the DIT with the customer. Nobody has ever explained an
advantage to me of LDAP over HTTP and a well-known service convention.


OCSP over DNS has the attraction that DNS transport is fast. But remember
that DNS transport is fast because it is absolutely minimal.
Putting more stuff into DNS risks making it slow.

The construction of PRIVATE-DNS attempts to square this circle by providing
a mechanism that allows other protocols to make use of the DNS channel (if
that makes sense) without incorporating them into the DNS protocol.


> (b) (Possibly) defining a more lightweight revocation mechanisms (e.g.
> Lightweight Revocation Tokens)

The patents on these techniques begin to expire in May 2016. Come back then.
They have not been available on RAND basis let alone RANDZ.

I'm not too interested in them however. S/Key does provide a rapid means of
updating status. Torben Pederssen proposed it as the phone tick modus,
Micali and Kocher proposed schemes that add in Merkle tree mechanisms. Fast
ECC signatures make these moot.


> (c) (Possibly) helping other working groups to revise and update how 
> revocation information are provided (e.g., the client authentication 
> case)

CRLs probably work just fine for servers validating private label client
certs.


> (d) (Possibly) introducing privacy consideration when it comes to 
> revocation checking

Well that is the reason to get away from using straight OCSP. It leaks
information. But stapled OCSP solves that problem.


> 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.

I have a different set of proposals:

1) Stapled OCSP with MUST-STAPLE OID
2) Short lived Certificates
  2a) With the same key
  2b) With different keys
3) CRLs with HBS compression.

Right now we are in the middle of deployment of (1) and doing 2a is not too
hard. But 2b is a LOT better since rotating the keys every 24 hours makes
all sorts of attacks a lot harder.

Making 2b work requires quite a bit of prep though. We would have to
completely automate the cert issue process. And we would have to make it
work with pinning etc..

3 is new but we can probably get to convergence on a spec faster than 2b
because we haven't tried that problem 4 times already. Much less room for
bikeshedding.


I see 1/2a as stop gap measures and 2b + 3 as the long term approach.

Rather than talk about 'the' revocation problem, I think we should identify
2 separate revocation problems

Coarse grain: Narrow the vulnerability window from 1-3 years to 48 hours.
Fine grain: Narrow the vulnerability window to 60 mins.

Short lived certs (2b) are the best solution to coarse grain revocation but
it is really hard to get them working well for a window of less than 48
hours. We would have to define a trusted time protocol for a start and
establish a distribution infrastructure for it.

HBS(3) can be used for both coarse grain as well as 2b at current
certificate issue rates. But it is a compression technique and it only
reduces the size of the problem by several orders of magnitude. If cert use
grows by an order of magnitude we are back in trouble. That said, combining
HBS with short lived certs gives us a path to achieving fine grain
revocation. And that is critical in the longer term. The criminals do most
of their fraud in the first 24 hours after putting a server live.


Short lived certs have the enormous advantage that the vast majority of
revocations are for administration reasons, at the request of the cert
subject. Revocations for end-entity breach are much rarer. But the problem
is that we don't have an accurate means of distinguishing between the cases.
Our customers don't want to tell us when they have done something doofus
like selling the hard drives with private keys for a live cert.

Short lived certs have the nice property that many doofus behaviors time out
automatically even if the customer does not catch them. Since it takes more
than 24 hours to sell old hard drives on EBay, the keys corresponding to
short lived certs will have expired by the time the drives ship.


So to sumarize, here is my roadmap

Now: OCSP Stapling with MUST STAPLE
12 months: CAs begin issuing HBS compressed CRLs in a form that permits
browsers to use them as a basis for constructing 'BigCRL' type solutions
24 months: Begin issue of 2a short lived certs
36 months: Begin issue of 2b short lived certs

5 years: Begin deprecating long lived certs
10 years: Begin phase out of long lived certs
20 years: Stop issue of long lived certs


Short lived certs with new keys per cert are definitely the way to go long
term. But it will take a long time to eliminate long lived certs
- if that is possible at all. That is fine though, provided we can make sure
that the majority of the growth in certs is of short lived certs, we will be
fine.

I think that is going to happen naturally since short lived certs are a much
better fit for the cloud than long lived ones. If I use a server for 3
hours, I don't want to rely on the hosting provider scrubbing the memory
before the next customer gets hold of it to protect my private keys. I want
to limit the scope for service provider defection as well.


The barrier to deployment on 2b is writing a good spec for provisioning
certs. I have a rough sketch of a JSON prototype that basically just wraps a
CSR.

_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey


From nobody Sun Nov 16 12:30:20 2014
Return-Path: <hallam@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 855651A1AF1 for <therightkey@ietfa.amsl.com>; Sun, 16 Nov 2014 12:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 xONaDyOkLOdA for <therightkey@ietfa.amsl.com>; Sun, 16 Nov 2014 12:30:00 -0800 (PST)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C000E1A1AEB for <therightkey@ietf.org>; Sun, 16 Nov 2014 12:29:59 -0800 (PST)
Received: by mail-la0-f48.google.com with SMTP id s18so3502322lam.35 for <therightkey@ietf.org>; Sun, 16 Nov 2014 12:29:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rGBSmXEksA/ho8nQkSJsSA+cQ0shOJNGdST+fqo6TqY=; b=h3T9Wt83M0BVVRl5Vr52yXZn3Uy4xgEw4nNjSWB51tdA93dV7zOL5Y8WON9e9Vp1qd GOhS7Gs1IN99uxrXEnBjLiDBfjx9R0TLgyiUSw3ppLCLxLmBMPVlTKe3dnOGilXpM/G2 anPeKklSgdxhcRjEkjUMXRwADsTY+6uh+MPVg3nWjahm+o5zUkLEwfNu/nd39DDK3/k0 54yuV6hvoU1+FhkK/weOwO6bmXfh6mneXffpiCryPONP7eJVQEbEX5plg3XU27tgk9pw KYKENVNs6BCn0jR0QcJORA880lOjNxgaty/9soEMwNDW0gYMgodrDjxQz3u5S2QfWvOS QVdw==
MIME-Version: 1.0
X-Received: by 10.152.204.70 with SMTP id kw6mr5240400lac.85.1416169798115; Sun, 16 Nov 2014 12:29:58 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.34.212 with HTTP; Sun, 16 Nov 2014 12:29:58 -0800 (PST)
In-Reply-To: <004501d001ce$8c669c10$a533d430$@icloud.com>
References: <5466AF87.2050307@gmail.com> <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com> <004501d001ce$8c669c10$a533d430$@icloud.com>
Date: Sun, 16 Nov 2014 15:29:58 -0500
X-Google-Sender-Auth: fMveUO-Ty-QFdrlAnQ2qTeu4FKE
Message-ID: <CAMm+LwjWZuKrPQYnjkLJn19nnuBTCzrSn7B+BVfAftCm4jtR=Q@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Trevor Freeman <trevor.freeman99@icloud.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/lLxKw1aOzFXYagR5Hha9nSxTME8
Cc: Massimiliano Pala <massimiliano.pala@gmail.com>, "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] [pkix] 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: Sun, 16 Nov 2014 20:30:01 -0000

On Sun, Nov 16, 2014 at 1:53 PM, Trevor Freeman
<trevor.freeman99@icloud.com> wrote:
> Hi Max,
>
> I think we first need a consensus of the unmitigated threats this work would
> look to address. That would help assess the technical options. Top of my
> list of unmitigated threats would be compromised CA issuing  user
> certificates outside of the normal process e.g. attackers use some tool to
> sign the certificate direly using the CA key so no log exists of the
> issuance.

Seriously?

How often does this happen?

How often does an administrator sell a machine without zeroing the
hard drive where a live key is stored? How often does a corrupt admin
sell a private key? How often does a machine without a TPM with a cert
get rooted?


End entity breach is a daily occurrence.

> For example, if there is consensus on that as a threat to be addressed, OCSP
> does not help much in that you want a "known to be good" assertion, not a
> "know to be bad" assertion that revocation checking provides. Certificate
> reissuance has been long been cited as an alternative to revocation in that
> you get a restatement of the goodness which is what you need, but it does
> tax the CAs. If you are targeting server validation scenarios, then a Valid
> Certificate List which was similar to CRLs but a list of good certificates
> could scale much better as Phil points out. Given we know all too well what
> does not work well with CRLs, we should be able to avoid the mistakes i.e.
> use hashs to identify certificates not issue\serial number, mandate support
> for partitions etc., etc.

I much prefer using hash based mechanisms to issuer/serial. But in a
pinch, I will use hash of the issuer/serial :)


From nobody Mon Nov 17 07:52:54 2014
Return-Path: <benl@google.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 C0AE81A6FEA for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 07:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.972
X-Spam-Level: 
X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 ODhoQKv13FUy for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 07:52:49 -0800 (PST)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F2B1A6FFA for <therightkey@ietf.org>; Mon, 17 Nov 2014 07:52:49 -0800 (PST)
Received: by mail-qg0-f51.google.com with SMTP id l89so853778qgf.38 for <therightkey@ietf.org>; Mon, 17 Nov 2014 07:52:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to :content-type; bh=hWczGDn9geTcKYSQwNSTKEIA5pvNWHJsF0mVkSM9SiM=; b=FsLO1Ko/0TxNjnRh3wvt3x0GImTH3t2rZqzLrBOhnp7NVPW6J34YaFgiqQk5HRYqHb U2NBWIRUkqjjTZdYqVMQR38hgmMZ3cOxlrxuL+ECr8joacpWgU1SsuAap7Sal7a9FQXt nFhxjb3/7aRl292q/PHlFOmX+i09CQ8SFXjtPP2XF9hYo/6N82TEgzIMY95VRdTZvVfm byVrxrKAW8+HR5PJeMO/O7wZpZoildEHivyYh4VJD7Yd/eRqJyLK36bCRUbk3FV40xBF zJpGelednHn4czQjyngKLrGSVoj2pBrm83XuSgJETWSFArt53h4CmL3TwNHB5vO7pagr 4Yww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:content-type; bh=hWczGDn9geTcKYSQwNSTKEIA5pvNWHJsF0mVkSM9SiM=; b=VO4swQPr1Nb0Tlek6Gh2725wg11A6BMD9VdGzi7tw6jVCHT2evRF35Igj9XKQD8zvv ZhXHg/EWjpYrXrhUsyO5EarRy/arPnkpZ+FKo64oCF+0Bpotz2uG8hlpkG/pMUSVDseq grV0734R+IgXthKgAh66j3IPC17hM8V6nm9bPgTgFHRQ+6fWuz5cFyAN9J42+8N51sHL NJHG+QSDP2aGg8MvQxeRQlf+GwvcjPOl5JUNAvo4ddW9jC8efOLKey/JsXcfENIpjZ0f Wi6iHQKgY+iaZnuVBPa6mV8YwgWHEN+vxGG5Sm2eQebov7ekBTKWE7GFAJYJxz2y+Qoa qAbA==
X-Gm-Message-State: ALoCoQnvDRSmCfY1AHYRThLxh10M26LtbPfPSe3spsKtPLslMz2MY48UO1p3uyloUgf7aoE0l9Rc
X-Received: by 10.224.136.194 with SMTP id s2mr7976695qat.82.1416239568632; Mon, 17 Nov 2014 07:52:48 -0800 (PST)
MIME-Version: 1.0
References: <5466AF87.2050307@gmail.com>
From: Ben Laurie <benl@google.com>
Date: Mon, 17 Nov 2014 15:52:48 +0000
Message-ID: <CABrd9SQkXK99ski74A8EyqHDptBsVs_aN6117Br8NyuPhYAa_Q@mail.gmail.com>
To: "Dr. Massimiliano Pala" <massimiliano.pala@gmail.com>, therightkey@ietf.org, "pkix@ietf.org" <pkix@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c2d8e26862ab05080ff842
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/KQ96gT87yNtR_88F8wlNztrEESs
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 15:52:52 -0000

--001a11c2d8e26862ab05080ff842
Content-Type: text/plain; charset=UTF-8

On Sat Nov 15 2014 at 1:42:31 AM Dr. Massimiliano Pala <
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 - 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
>
>
> _______________________________________________
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
>

--001a11c2d8e26862ab05080ff842
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

--001a11c2d8e26862ab05080ff842--


From nobody Mon Nov 17 08:31:11 2014
Return-Path: <nico@cryptonector.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 2F8BD1A6FDE; Mon, 17 Nov 2014 08:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 fJj_cGcUHT6o; Mon, 17 Nov 2014 08:31:08 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 01E591A0123; Mon, 17 Nov 2014 08:31:08 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id B950136007C; Mon, 17 Nov 2014 08:31:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=9ScrUAIAEMfGoTiCDeoF FjKOEOo=; b=y8iSyfQVfHdLhxpBs0JVrXVvsge/4O2aYsa3mnwQ/N0SYB6SvS9/ 5wN4cWenNr9DrYK0bcQWjN4eOlLdDoRZ/LQkD/MYqhJTL2hZVyF1QyvoYMSnD9Sm Ca0Umf3lz3zIkEey3v6itbVvkfr/yxt+qabv+3j4ee0IAzgD1xCl0IM=
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 8830636007B; Mon, 17 Nov 2014 08:31:07 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id ex7so9754916wid.0 for <multiple recipients>; Mon, 17 Nov 2014 08:31:06 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.100.129 with SMTP id ey1mr33340260wib.28.1416241866476;  Mon, 17 Nov 2014 08:31:06 -0800 (PST)
Received: by 10.216.32.135 with HTTP; Mon, 17 Nov 2014 08:31:06 -0800 (PST)
In-Reply-To: <5466AF87.2050307@gmail.com>
References: <5466AF87.2050307@gmail.com>
Date: Mon, 17 Nov 2014 10:31:06 -0600
Message-ID: <CAK3OfOjUbZkFXcvcOKAbKzSznKiJuV+E4++4vP4X5u7z1J6bpQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Dr. Massimiliano Pala" <massimiliano.pala@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/4Ii19o4cn_ga8_gEbghgSVL5ZQU
Cc: "pkix@ietf.org" <pkix@ietf.org>, "therightkey@ietf.org" <therightkey@ietf.org>
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 16:31:09 -0000

On Fri, Nov 14, 2014 at 7:42 PM, Dr. Massimiliano Pala
<massimiliano.pala@gmail.com> wrote:
> (a) Defining new transport protocols for revocation information availability
> (e.g., OCSP over DNS or OCSP over LDAP)

OCSP lacks for various bindings to various transports.  I think
defining more such bindings would be nice.

> (b) (Possibly) defining a more lightweight revocation mechanisms (e.g.
> Lightweight Revocation Tokens)

What would that look like?  I think stapled DANE is about as
light-weight as it's going to get.

> (c) (Possibly) helping other working groups to revise and update how
> revocation information are provided (e.g., the client authentication case)

They can do this themselves.  Assuming TLS 1.3 retains user
authentication with certificates, let the TLS WG add stapled OCSP.

> (d) (Possibly) introducing privacy consideration when it comes to revocation
> checking

If you staple OCSP then the main privacy considerations are:

a) how the end entities' certs and OCSP responses are transported
(e.g., we'd need TLS to have a mode that provides confidentiality to
the client cert, which IIUC is not in the cards for 1.3),

b) how to provide privacy protection for DNS (the elephant in the room).

Anything to be done in TLS belongs squarely in the TLS WG.  I'd love
to see DNS confidentiality, but I think we should get our priorities
straight: opportunistic security, TLS 1.3, CT, DNSSEC/DANE deployment,
...  I confess that my list of priorities is something one could argue
about, and that if we have the energy to do more of these things
concurrently, then we should.

Nico
--


From nobody Mon Nov 17 09:03:00 2014
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

--------------070203030907050004070409
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit

+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


--------------070203030907050004070409
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    +1 to using a CT-like structure to also provide revocation
    information.<br>
    <br>
    <div class="moz-cite-prefix">On 11/17/2014 8:52 AM, Ben Laurie
      wrote:<br>
    </div>
    <blockquote
cite="mid:CABrd9SQkXK99ski74A8EyqHDptBsVs_aN6117Br8NyuPhYAa_Q@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <br>
      <br>
      <div class="gmail_quote">On Sat Nov 15 2014 at 1:42:31 AM Dr.
        Massimiliano Pala &lt;<a moz-do-not-send="true"
          href="mailto:massimiliano.pala@gmail.com">massimiliano.pala@gmail.com</a>&gt;
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear PKIX
          Enthusiasts,<br>
          <br>
          Although great work has been done in the past... 20 years..
          (?) on<br>
          providing very good protocols in the PKIX work, I think that
          we all<br>
          agree that we still have some unresolved issues. In
          particular, the<br>
          revocation is still a hot topic (especially for online
          environments)<br>
          could use improvement over the current status of things. In
          particular,<br>
          by looking at current specifications, some work is needed to
          address<br>
          concerns especially in non-web environments.<br>
          <br>
          For example, current specifications about OCSP stapling do not
          address<br>
          the case of client authentication (which is a widespread use
          case<br>
          outside the web environment) or, again, defining some new
          transport<br>
          protocols for delivering OCSP responses which might reduce
          operational<br>
          costs for revocation service providers.<br>
          <br>
          After proposing the idea to Stephen Farrell and Kathleen
          Moriarty, we<br>
          would like to know if there might be interests in
          participating in<br>
          updating the status of the current revocation mechanisms for
          PKIX. This<br>
          said, the scope of the work I am proposing is very limited.
          Specifically:<br>
          <br>
          (a) Defining new transport protocols for revocation
          information<br>
          availability (e.g., OCSP over DNS or OCSP over LDAP)<br>
          (b) (Possibly) defining a more lightweight revocation
          mechanisms (e.g.<br>
          Lightweight Revocation Tokens)<br>
          (c) (Possibly) helping other working groups to revise and
          update how<br>
          revocation information are provided (e.g., the client
          authentication case)<br>
          (d) (Possibly) introducing privacy consideration when it comes
          to<br>
          revocation checking<br>
        </blockquote>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>Not sure if that fits into your remit above (on the face of
          it, it does not).</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <br>
          Because of these considerations, I am proposing to start a
          conversation<br>
          - for now, Stephen and Kathleen suggested we use (or "abuse")
          the "The<br>
          Right Key" mailing list to see if there might be enough
          interest in the<br>
          work from implementers to address these issues. I know that we
          (OpenCA)<br>
          are interested in implementing these features, and we would
          like that<br>
          the work would be standardized.<br>
          <br>
          At minimal, I would like (a) to happen. This could be achieved
          in 6<br>
          months (and we might not even need to meet). (b) and (c) are
          also<br>
          desirable in order to provide better support for non-browsers
          and small<br>
          devices (AFAIK, some work might be relevant for DICE). (d) is
          something<br>
          that we should, I think, all be mindful and at least some
          considerations<br>
          should be provided. The scope of the work, however, will be
          limited to<br>
          revocation.<br>
          <br>
          Please, if you are interested and would like to start the
          discussion,<br>
          post your opinion on <a moz-do-not-send="true"
            href="mailto:therightkey@ietf.org" target="_blank">therightkey@ietf.org</a>
          - also, please, circulate this<br>
          proposal to anybody who might be interested in collaborating
          on this issue.<br>
          <br>
          Please also note that we did decide not to use the <a
            moz-do-not-send="true" href="mailto:pkix@ietf.org"
            target="_blank">pkix@ietf.org</a> mailing<br>
          list because we thought <a moz-do-not-send="true"
            href="mailto:therightkey@ietf.org" target="_blank">therightkey@ietf.org</a>
          might provide a more active<br>
          pool of implementors.<br>
          <br>
          Looking forward to receive all your inputs and start working
          on the topics.<br>
          <br>
          Cheers,<br>
          Max<br>
          <br>
          <br>
          _______________________________________________<br>
          therightkey mailing list<br>
          <a moz-do-not-send="true" href="mailto:therightkey@ietf.org"
            target="_blank">therightkey@ietf.org</a><br>
          <a moz-do-not-send="true"
            href="https://www.ietf.org/mailman/listinfo/therightkey"
            target="_blank">https://www.ietf.org/mailman/listinfo/therightkey</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
therightkey mailing list
<a class="moz-txt-link-abbreviated" href="mailto:therightkey@ietf.org">therightkey@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/therightkey">https://www.ietf.org/mailman/listinfo/therightkey</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------070203030907050004070409--


From nobody Mon Nov 17 09:07:46 2014
Return-Path: <trevor.freeman99@icloud.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 9043D1A702C for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 09:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 HUXN3Mc63EHc for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 09:07:41 -0800 (PST)
Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C2B1A6FED for <therightkey@ietf.org>; Mon, 17 Nov 2014 09:07:41 -0800 (PST)
Received: from Den (c-67-183-152-156.hsd1.wa.comcast.net [67.183.152.156]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NF700FH00WR5L50@mr11p24im-asmtp002.me.com> for therightkey@ietf.org; Mon, 17 Nov 2014 17:07:41 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-17_02:2014-11-15,2014-11-17,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411170132
From: Trevor Freeman <trevor.freeman99@icloud.com>
To: 'Phillip Hallam-Baker' <phill@hallambaker.com>
References: <5466AF87.2050307@gmail.com> <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com> <004501d001ce$8c669c10$a533d430$@icloud.com> <CAMm+LwjWZuKrPQYnjkLJn19nnuBTCzrSn7B+BVfAftCm4jtR=Q@mail.gmail.com>
In-reply-to: <CAMm+LwjWZuKrPQYnjkLJn19nnuBTCzrSn7B+BVfAftCm4jtR=Q@mail.gmail.com>
Date: Mon, 17 Nov 2014 09:07:33 -0800
Message-id: <007601d00288$fb9d9240$f2d8b6c0$@icloud.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="----=_NextPart_000_0077_01D00245.ED7A5240"
X-Mailer: Microsoft Outlook 14.0
Thread-index: AQFUCYhQhiaGoOJda7G7bFU0mLLbLQH/JSjNAeWTIu4CP5lorJ0r3AMQ
Content-language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/DzU_U4NoHiMoW1yaE-q0BGQAGfk
Cc: 'Massimiliano Pala' <massimiliano.pala@gmail.com>, therightkey@ietf.org
Subject: Re: [therightkey] [pkix] 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:07:44 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0077_01D00245.ED7A5240
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Obviously more that you think otherwise folks would not be working on CTJ

 

-----Original Message-----
From: therightkey [mailto:therightkey-bounces@ietf.org] On Behalf Of Phillip
Hallam-Baker
Sent: Sunday, November 16, 2014 12:30 PM
To: Trevor Freeman
Cc: Massimiliano Pala; therightkey@ietf.org
Subject: Re: [therightkey] [pkix] Proposal for working on PKIX revocation
open issues

 

On Sun, Nov 16, 2014 at 1:53 PM, Trevor Freeman <
<mailto:trevor.freeman99@icloud.com> trevor.freeman99@icloud.com> wrote:

> Hi Max,

> 

> I think we first need a consensus of the unmitigated threats this work 

> would look to address. That would help assess the technical options. 

> Top of my list of unmitigated threats would be compromised CA issuing  

> user certificates outside of the normal process e.g. attackers use 

> some tool to sign the certificate direly using the CA key so no log 

> exists of the issuance.

 

Seriously?

 

How often does this happen?

 

How often does an administrator sell a machine without zeroing the hard
drive where a live key is stored? How often does a corrupt admin sell a
private key? How often does a machine without a TPM with a cert get rooted?

 

 

End entity breach is a daily occurrence.

 

> For example, if there is consensus on that as a threat to be 

> addressed, OCSP does not help much in that you want a "known to be 

> good" assertion, not a "know to be bad" assertion that revocation 

> checking provides. Certificate reissuance has been long been cited as 

> an alternative to revocation in that you get a restatement of the 

> goodness which is what you need, but it does tax the CAs. If you are 

> targeting server validation scenarios, then a Valid Certificate List 

> which was similar to CRLs but a list of good certificates could scale 

> much better as Phil points out. Given we know all too well what does not
work well with CRLs, we should be able to avoid the mistakes i.e.

> use hashs to identify certificates not issue\serial number, mandate 

> support for partitions etc., etc.

 

I much prefer using hash based mechanisms to issuer/serial. But in a pinch,
I will use hash of the issuer/serial :)

 

_______________________________________________

therightkey mailing list

 <mailto:therightkey@ietf.org> therightkey@ietf.org

 <https://www.ietf.org/mailman/listinfo/therightkey>
https://www.ietf.org/mailman/listinfo/therightkey


------=_NextPart_000_0077_01D00245.ED7A5240
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p =
class=3DMsoPlainText>Obviously more that you think otherwise folks would =
not be working on CT<span =
style=3D'font-family:Wingdings'>J</span><o:p></o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText>-----Original Message-----<br>From: therightkey =
[mailto:therightkey-bounces@ietf.org] On Behalf Of Phillip =
Hallam-Baker<br>Sent: Sunday, November 16, 2014 12:30 PM<br>To: Trevor =
Freeman<br>Cc: Massimiliano Pala; therightkey@ietf.org<br>Subject: Re: =
[therightkey] [pkix] Proposal for working on PKIX revocation open =
issues</p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText>On Sun, Nov 16, 2014 at 1:53 PM, Trevor Freeman =
&lt;<a href=3D"mailto:trevor.freeman99@icloud.com"><span =
style=3D'color:windowtext;text-decoration:none'>trevor.freeman99@icloud.c=
om</span></a>&gt; wrote:<o:p></o:p></p><p class=3DMsoPlainText>&gt; Hi =
Max,<o:p></o:p></p><p class=3DMsoPlainText>&gt;<o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText>&gt; I think we first need a consensus of the =
unmitigated threats this work <o:p></o:p></p><p =
class=3DMsoPlainText>&gt; would look to address. That would help assess =
the technical options. <o:p></o:p></p><p class=3DMsoPlainText>&gt; Top =
of my list of unmitigated threats would be compromised CA issuing&nbsp; =
<o:p></o:p></p><p class=3DMsoPlainText>&gt; user certificates outside of =
the normal process e.g. attackers use <o:p></o:p></p><p =
class=3DMsoPlainText>&gt; some tool to sign the certificate direly using =
the CA key so no log <o:p></o:p></p><p class=3DMsoPlainText>&gt; exists =
of the issuance.<o:p></o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText>Seriously?<o:p></o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>How =
often does this happen?<o:p></o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>How =
often does an administrator sell a machine without zeroing the hard =
drive where a live key is stored? How often does a corrupt admin sell a =
private key? How often does a machine without a TPM with a cert get =
rooted?<o:p></o:p></p><p class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>End =
entity breach is a daily occurrence.<o:p></o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>&gt; =
For example, if there is consensus on that as a threat to be =
<o:p></o:p></p><p class=3DMsoPlainText>&gt; addressed, OCSP does not =
help much in that you want a &quot;known to be <o:p></o:p></p><p =
class=3DMsoPlainText>&gt; good&quot; assertion, not a &quot;know to be =
bad&quot; assertion that revocation <o:p></o:p></p><p =
class=3DMsoPlainText>&gt; checking provides. Certificate reissuance has =
been long been cited as <o:p></o:p></p><p class=3DMsoPlainText>&gt; an =
alternative to revocation in that you get a restatement of the =
<o:p></o:p></p><p class=3DMsoPlainText>&gt; goodness which is what you =
need, but it does tax the CAs. If you are <o:p></o:p></p><p =
class=3DMsoPlainText>&gt; targeting server validation scenarios, then a =
Valid Certificate List <o:p></o:p></p><p class=3DMsoPlainText>&gt; which =
was similar to CRLs but a list of good certificates could scale =
<o:p></o:p></p><p class=3DMsoPlainText>&gt; much better as Phil points =
out. Given we know all too well what does not work well with CRLs, we =
should be able to avoid the mistakes i.e.<o:p></o:p></p><p =
class=3DMsoPlainText>&gt; use hashs to identify certificates not =
issue\serial number, mandate <o:p></o:p></p><p class=3DMsoPlainText>&gt; =
support for partitions etc., etc.<o:p></o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p class=3DMsoPlainText>I much =
prefer using hash based mechanisms to issuer/serial. But in a pinch, I =
will use hash of the issuer/serial :)<o:p></o:p></p><p =
class=3DMsoPlainText><o:p>&nbsp;</o:p></p><p =
class=3DMsoPlainText>_______________________________________________<o:p>=
</o:p></p><p class=3DMsoPlainText>therightkey mailing =
list<o:p></o:p></p><p class=3DMsoPlainText><a =
href=3D"mailto:therightkey@ietf.org"><span =
style=3D'color:windowtext;text-decoration:none'>therightkey@ietf.org</spa=
n></a><o:p></o:p></p><p class=3DMsoPlainText><a =
href=3D"https://www.ietf.org/mailman/listinfo/therightkey"><span =
style=3D'color:windowtext;text-decoration:none'>https://www.ietf.org/mail=
man/listinfo/therightkey</span></a><o:p></o:p></p></div></body></html>
------=_NextPart_000_0077_01D00245.ED7A5240--


From nobody Mon Nov 17 09:41:59 2014
Return-Path: <hallam@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 BD7221A6FF9 for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 09:41:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 Fk23ktrO6i0P for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 09:41:55 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98FA61A0278 for <therightkey@ietf.org>; Mon, 17 Nov 2014 09:41:54 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id pn19so1779468lab.26 for <therightkey@ietf.org>; Mon, 17 Nov 2014 09:41:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=d8UPXKtqOc64nSS74npx1q+QBJ/+bl/0b8fx/L0fWzg=; b=Z3nlvaXa+XVUZNg+vDAXaLuYJR38Z7a0MvD327bkzDULtlQNTUvWuoAen7v16UGn/T nIIEC+ps5tlBzBhiGWOuOklknTeqssYJ0/R990a4CKnZBNHr0ZzS9mmY+Ru36oAeWdsv SYCIP9D040zxy5btXGRc5+ovjUH8buQTkg7vHDEmEL8W1PNG70ofuZ/+OLK6myciMSwI 3gRp10cO4wYUnybDI8kHoMpXnV8VaEDlFHJeHx6hM69MWCl/bk+ktzyb3zyAgvapbbyG bYzvy1z5Q41S4hQOhNwPmuFkdlIjG6iR6hn58NMlpMSMfS72aAdQfwAZUcnOpCJtrpXq zRzw==
MIME-Version: 1.0
X-Received: by 10.112.199.40 with SMTP id jh8mr29491111lbc.5.1416246112757; Mon, 17 Nov 2014 09:41:52 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.34.212 with HTTP; Mon, 17 Nov 2014 09:41:52 -0800 (PST)
In-Reply-To: <007601d00288$fb9d9240$f2d8b6c0$@icloud.com>
References: <5466AF87.2050307@gmail.com> <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com> <004501d001ce$8c669c10$a533d430$@icloud.com> <CAMm+LwjWZuKrPQYnjkLJn19nnuBTCzrSn7B+BVfAftCm4jtR=Q@mail.gmail.com> <007601d00288$fb9d9240$f2d8b6c0$@icloud.com>
Date: Mon, 17 Nov 2014 12:41:52 -0500
X-Google-Sender-Auth: 76LScTigUEbj63VXgmOOpJ2-98w
Message-ID: <CAMm+Lwhcw2ep=6BnwCpS+Vn9D9_qW2Sk0_HvuJKsabBtf55QSw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Trevor Freeman <trevor.freeman99@icloud.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/Ejy4NQeydUxAAbswsq3r4lxgGQs
Cc: Massimiliano Pala <massimiliano.pala@gmail.com>, "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] [pkix] 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:41:56 -0000

It is always a mistake to imagine that political outcomes are the
product of rational analysis rather than the respective power
relationships and constraints.

For Google, the risk of consequences due to CA breach are arguably
higher than the consequences of end-entity breach which they have
controlled through shifting liability onto the CAs. But for the
typical Internet user, the risk due to end-entity breach is higher.


I didn't say we shouldn't do CT, what I said is that we have to make
revocation an equal priority.

Checkpointing revocation information in CT makes great sense for all concerned.

Had Harber-Stornetta catenate certificates been available on equitable
terms prior to the expiry of the patent we would probably have done
something like CT years ago. The reason we didn't do revocation before
was that we did not develop a technology that the browser providers
considered acceptable. And then we spend ten years trying to persuade
them that up was down rather than fixing the problem.

Not trying to assign blame here, I should have arrived at this
analysis ten years ago.


On Mon, Nov 17, 2014 at 12:07 PM, Trevor Freeman
<trevor.freeman99@icloud.com> wrote:
> Obviously more that you think otherwise folks would not be working on CTJ
>
>
>
> -----Original Message-----
> From: therightkey [mailto:therightkey-bounces@ietf.org] On Behalf Of Phillip
> Hallam-Baker
> Sent: Sunday, November 16, 2014 12:30 PM
> To: Trevor Freeman
> Cc: Massimiliano Pala; therightkey@ietf.org
> Subject: Re: [therightkey] [pkix] Proposal for working on PKIX revocation
> open issues
>
>
>
> On Sun, Nov 16, 2014 at 1:53 PM, Trevor Freeman
> <trevor.freeman99@icloud.com> wrote:
>
>> Hi Max,
>
>>
>
>> I think we first need a consensus of the unmitigated threats this work
>
>> would look to address. That would help assess the technical options.
>
>> Top of my list of unmitigated threats would be compromised CA issuing
>
>> user certificates outside of the normal process e.g. attackers use
>
>> some tool to sign the certificate direly using the CA key so no log
>
>> exists of the issuance.
>
>
>
> Seriously?
>
>
>
> How often does this happen?
>
>
>
> How often does an administrator sell a machine without zeroing the hard
> drive where a live key is stored? How often does a corrupt admin sell a
> private key? How often does a machine without a TPM with a cert get rooted?
>
>
>
>
>
> End entity breach is a daily occurrence.
>
>
>
>> For example, if there is consensus on that as a threat to be
>
>> addressed, OCSP does not help much in that you want a "known to be
>
>> good" assertion, not a "know to be bad" assertion that revocation
>
>> checking provides. Certificate reissuance has been long been cited as
>
>> an alternative to revocation in that you get a restatement of the
>
>> goodness which is what you need, but it does tax the CAs. If you are
>
>> targeting server validation scenarios, then a Valid Certificate List
>
>> which was similar to CRLs but a list of good certificates could scale
>
>> much better as Phil points out. Given we know all too well what does not
>> work well with CRLs, we should be able to avoid the mistakes i.e.
>
>> use hashs to identify certificates not issue\serial number, mandate
>
>> support for partitions etc., etc.
>
>
>
> I much prefer using hash based mechanisms to issuer/serial. But in a pinch,
> I will use hash of the issuer/serial :)
>
>
>
> _______________________________________________
>
> therightkey mailing list
>
> therightkey@ietf.org
>
> https://www.ietf.org/mailman/listinfo/therightkey


From nobody Mon Nov 17 09:47:46 2014
Return-Path: <nico@cryptonector.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 222331A0302 for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 09:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 yLTh_GGtVQgf for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 09:47:43 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 910F21A026A for <therightkey@ietf.org>; Mon, 17 Nov 2014 09:47:43 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 6E5B2360072 for <therightkey@ietf.org>; Mon, 17 Nov 2014 09:47:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=8xqnKjcIBAkE7mPvS2ym aqKhlxM=; b=pGzKRnB4uBUg0//C3Kl+yEag1gAApfnlI7qCrMkJUkvK74C5WP1I r8K7FNhEUKk2Cv6i9g3qs0FF/YWrqAHVkT0/urFQEsugssQQy4A4mb9KhDFzs+dm Ui6UuPNY/65R3QlQmRk0Qo63h2arG5caXK9mxhpGCnhyoGSEiu3fjaI=
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 44B5936006B for <therightkey@ietf.org>; Mon, 17 Nov 2014 09:47:43 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id n3so2586181wiv.1 for <therightkey@ietf.org>; Mon, 17 Nov 2014 09:47:42 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.2.244 with SMTP id 20mr41319593wjx.4.1416246462198; Mon, 17 Nov 2014 09:47:42 -0800 (PST)
Received: by 10.216.32.135 with HTTP; Mon, 17 Nov 2014 09:47:42 -0800 (PST)
In-Reply-To: <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com>
References: <5466AF87.2050307@gmail.com> <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com>
Date: Mon, 17 Nov 2014 11:47:42 -0600
Message-ID: <CAK3OfOionKNtMRv+bFqY=yN1x+VQNwzraOBF-NSsdnSu6dOA5w@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/qc0hWbL6jtIn-oiyeXNeflo4B9A
Cc: "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] [pkix] 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:47:45 -0000

On Sat, Nov 15, 2014 at 3:56 PM, Phillip Hallam-Baker
<phill@hallambaker.com> wrote:
>> (a) Defining new transport protocols for revocation information availability
>> (e.g., OCSP over DNS or OCSP over LDAP)
>
> There is already a mechanism for transporting certs over LDAP. I am
> pretty sure the folk who do that sort of thing have done the OCSP in
> LDAP thing already.
>
> I don't see a future for LDAP as an Internet protocol though. LDAP

Indeed, but it is an Internet protocol that is widely used in the enterprise.

> introduces a completely gratuitous name infrastructure (X.500) that

Eh?!  It's the same [busted, obnoxious, unworkable, <fill-in-curses>]
naming model as PKIX.  RFC4514 is a great demonstration of what a
disaster X.500 naming is, but don't be fooled by the "LDAP" in the
title: it's as good a demo of X.509's disastrous naming.

> adds no value other than to the consultants who can spin a 3 week
> consulting gig bikeshedding the DIT with the customer. Nobody has ever
> explained an advantage to me of LDAP over HTTP and a well-known
> service convention.

LDAP is hardly my favorite protocol.  Its biggest sin is really not
its fault, but the implementors, who have by and large adopted the
LDAP representation of "objects" as their native representation of the
same, losing a lot of relational power in the process.  The other
problem is that LDAP's is a poor query language.

As for HTTP...  HTTP doesn't do what LDAP does.  One could define a
DAP over HTTP (an "API"), and that'd be a fine thing.

>> (c) (Possibly) helping other working groups to revise and update how
>> revocation information are provided (e.g., the client authentication case)
>
> CRLs probably work just fine for servers validating private label client certs.

Yes.

> I have a different set of proposals:
>
> 1) Stapled OCSP with MUST-STAPLE OID
> 2) Short lived Certificates
>   2a) With the same key
>   2b) With different keys
> 3) CRLs with HBS compression.

+1

Nico
--


From nobody Mon Nov 17 12:44:08 2014
Return-Path: <bascule@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 871CA1A9007 for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 12:44:06 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 z3AC_wMLlb7b for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 12:44:04 -0800 (PST)
Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926DD1A8BC1 for <therightkey@ietf.org>; Mon, 17 Nov 2014 12:44:04 -0800 (PST)
Received: by mail-ob0-f178.google.com with SMTP id gq1so2931346obb.37 for <therightkey@ietf.org>; Mon, 17 Nov 2014 12:44:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=maPSzx0v+fwce834dJZwiVePeNaj1bsKZ9K68gZcZY8=; b=pRaWyo24J8hwMB7KV+8jZ/GkZItjWYoU/NnR+MBDkpZmklhOuzwqAjtWZpUl1BJ84n xrdY59ci4N3F48FiW9RxMqQhD97S+KHKJVJZeBpQiKDNAJ8DluEpB92+BKdpJOwz2qgU uxh7PNL3rbnSChGdabJoFv5bdMNpRW4fKI60TCi3OHEYDF8RpJksy7/9udtv5sdgluPA idI5w0c7+3eGbmsq3If+zTVIubtjPPo+/t6Ulfw+jurCtnUaYgQoSs/A2W87PhxtbGtm eVp0Rg7z9sfs7KU6p5Ft1fMOQvyMevIJUqw7vBEncx7itNElHHzNTVTpDDrcs9/1FzTD YTWg==
X-Received: by 10.202.7.21 with SMTP id 21mr24575638oih.6.1416257043355; Mon, 17 Nov 2014 12:44:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.115.40 with HTTP; Mon, 17 Nov 2014 12:43:43 -0800 (PST)
In-Reply-To: <CAK3OfOionKNtMRv+bFqY=yN1x+VQNwzraOBF-NSsdnSu6dOA5w@mail.gmail.com>
References: <5466AF87.2050307@gmail.com> <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com> <CAK3OfOionKNtMRv+bFqY=yN1x+VQNwzraOBF-NSsdnSu6dOA5w@mail.gmail.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Mon, 17 Nov 2014 12:43:43 -0800
Message-ID: <CAHOTMV+_ASePLyPrvKMW_C8NiNxShY8PQQfZepmuaNQXChoXYw@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=001a113d1046faddd3050814092a
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/pt6Oix283Wz7EveVXJFRi0RD1sQ
Cc: "therightkey@ietf.org" <therightkey@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>
Subject: Re: [therightkey] [pkix] 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 20:44:06 -0000

--001a113d1046faddd3050814092a
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 17, 2014 at 9:47 AM, Nico Williams <nico@cryptonector.com>
wrote:

> As for HTTP...  HTTP doesn't do what LDAP does.  One could define a
> DAP over HTTP (an "API"), and that'd be a fine thing.


Is anyone actually working on that? It's definitely something I'd be
interested in

-- 
Tony Arcieri

--001a113d1046faddd3050814092a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Nov 17, 2014 at 9:47 AM, Nico Williams <span dir=3D"ltr">&lt;<a href=3D=
"mailto:nico@cryptonector.com" target=3D"_blank" onclick=3D"window.open(&#3=
9;https://mail.google.com/mail/?view=3Dcm&amp;tf=3D1&amp;to=3Dnico@cryptone=
ctor.com&amp;cc=3D&amp;bcc=3D&amp;su=3D&amp;body=3D&#39;,&#39;_blank&#39;);=
return false;">nico@cryptonector.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">As for HTTP...=C2=A0 HTTP doesn&#39;t do what LDAP does.=
=C2=A0 One could define a<br>
DAP over HTTP (an &quot;API&quot;), and that&#39;d be a fine thing.</blockq=
uote><div><br></div><div>Is anyone actually working on that? It&#39;s defin=
itely something I&#39;d be interested in=C2=A0</div></div><div><br></div>--=
 <br><div class=3D"gmail_signature">Tony Arcieri<br></div>
</div></div>

--001a113d1046faddd3050814092a--


From nobody Mon Nov 17 13:08:28 2014
Return-Path: <hallam@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 77C471AC3F3 for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 13:08:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 N7bbVsJ1_8jz for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 13:08:12 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869561AC3E1 for <therightkey@ietf.org>; Mon, 17 Nov 2014 13:08:12 -0800 (PST)
Received: by mail-lb0-f171.google.com with SMTP id b6so16710149lbj.16 for <therightkey@ietf.org>; Mon, 17 Nov 2014 13:08:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=W4UtL6X+b6+6wOEpcSb7Qygxx24bU6xNUFMe3Iu/Rbs=; b=tIZCV3EB+R8iFmZv3Pd+ieI2ipYQ+UCov8vKBPAdl/ue/N9Ecs3613VgJVdMSJdgLY ePzo4uPhISLXJ/2iFpv9xwPm22hNPJKu74vPU+PgrTgrPHS5EPqrKZ/89JF1YO0Da3MK i62U3O1Jp5EQs4aMqUA31LTfCrsM54+wkG8k/6Sb9SW0Z3jfCxRZnG0qnKSlHnG4bmY+ T5Tf8Q9zb6Z6JRMq/dkVsb8hm2vlYPMcjuEe/h0vZcsUMak4tYdOh22FQfoUG4oiWW7Z 1lJYkxWMMK4/lNskiw2XkCiBOgufOp9Per7TqQyj+o0w/TdSe5ixAJAcfHsCCSqqWQGp vS6g==
MIME-Version: 1.0
X-Received: by 10.152.87.67 with SMTP id v3mr6477736laz.97.1416258490722; Mon, 17 Nov 2014 13:08:10 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.34.212 with HTTP; Mon, 17 Nov 2014 13:08:10 -0800 (PST)
In-Reply-To: <CAHOTMV+_ASePLyPrvKMW_C8NiNxShY8PQQfZepmuaNQXChoXYw@mail.gmail.com>
References: <5466AF87.2050307@gmail.com> <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com> <CAK3OfOionKNtMRv+bFqY=yN1x+VQNwzraOBF-NSsdnSu6dOA5w@mail.gmail.com> <CAHOTMV+_ASePLyPrvKMW_C8NiNxShY8PQQfZepmuaNQXChoXYw@mail.gmail.com>
Date: Mon, 17 Nov 2014 16:08:10 -0500
X-Google-Sender-Auth: OxFb0_s05D3v9Et1UUrJ0JYgCQU
Message-ID: <CAMm+LwjykpZ5EswC4TUgpgJ+L3Ai=0APx5RzKwTpb6wgwBfVdQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Tony Arcieri <bascule@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/4G6fllJttVB3MB8KxMP2-RwySYw
Cc: Nico Williams <nico@cryptonector.com>, "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] [pkix] 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 21:08:17 -0000

What do you want?

An API that interfaces to the X.500 names or the SubjectAltNames?
Can't see a lot of point in the first but the second makes a lot of
sense. In fact I think we must have several.

Incidentally, the reason I discount LDAP in the Internet is precisely
the fact it is now an enterprise resource. And enterprises are no more
willing to share that with the Internet than their conversations with
their lawyers.



On Mon, Nov 17, 2014 at 3:43 PM, Tony Arcieri <bascule@gmail.com> wrote:
> On Mon, Nov 17, 2014 at 9:47 AM, Nico Williams <nico@cryptonector.com>
> wrote:
>>
>> As for HTTP...  HTTP doesn't do what LDAP does.  One could define a
>> DAP over HTTP (an "API"), and that'd be a fine thing.
>
>
> Is anyone actually working on that? It's definitely something I'd be
> interested in
>
> --
> Tony Arcieri


From nobody Mon Nov 17 13:25:33 2014
Return-Path: <bascule@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 A60D81ACCFA for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 13:25:30 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 z5zYkiC56lPw for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 13:25:28 -0800 (PST)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811131AC41D for <therightkey@ietf.org>; Mon, 17 Nov 2014 13:25:28 -0800 (PST)
Received: by mail-ob0-f180.google.com with SMTP id wp4so4695789obc.11 for <therightkey@ietf.org>; Mon, 17 Nov 2014 13:25:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RuoGO51te7Z+/U0fnee3RQHYgAkSkM3FNvtjht3B/+4=; b=yIVExLkUzoeHVdEf4fWQrp9xS3gi48eskPmEq3zeXxmZIcoBuyNKCIPg/kTyfxMhKu K23bs8U5Pa/GKEr2wz9aTxlQkr3j7Kw9s+fZOQKzuPY1WftIrW/83y2s4iPcDBKWpbJb y/MutV6sRcxErJ1Bu4EbQ/I2FLCW94q1Qjs8bDlPXTm0sycewQb+cUiUl135B/NlPA4R i43NzEnqgmVd773P41fWFhk8c6Hi6/XYvqIwWhk+rwEhtItHRi5VZYuB2R6AhZ15y9Fm qb6feWTs4d2L3GHKWPxEScV8vwYGpyuyN4fdVfSmfAdjb0mVC729p1mHTWFp4QKAvcms rA3Q==
X-Received: by 10.60.150.129 with SMTP id ui1mr9522466oeb.38.1416259527671; Mon, 17 Nov 2014 13:25:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.115.40 with HTTP; Mon, 17 Nov 2014 13:25:07 -0800 (PST)
In-Reply-To: <CAMm+LwjykpZ5EswC4TUgpgJ+L3Ai=0APx5RzKwTpb6wgwBfVdQ@mail.gmail.com>
References: <5466AF87.2050307@gmail.com> <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com> <CAK3OfOionKNtMRv+bFqY=yN1x+VQNwzraOBF-NSsdnSu6dOA5w@mail.gmail.com> <CAHOTMV+_ASePLyPrvKMW_C8NiNxShY8PQQfZepmuaNQXChoXYw@mail.gmail.com> <CAMm+LwjykpZ5EswC4TUgpgJ+L3Ai=0APx5RzKwTpb6wgwBfVdQ@mail.gmail.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Mon, 17 Nov 2014 13:25:07 -0800
Message-ID: <CAHOTMVJGRJ9GJAOR=8RK1okbivJsZ-1QPs6caTMm=QA4Hb1LBg@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Content-Type: multipart/alternative; boundary=047d7b4513d80e86630508149eb7
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/RHzdumqCzfFAvAbU3jqnbj_v0O8
Cc: Nico Williams <nico@cryptonector.com>, "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] [pkix] 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 21:25:30 -0000

--047d7b4513d80e86630508149eb7
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 17, 2014 at 1:08 PM, Phillip Hallam-Baker <phill@hallambaker.com
> wrote:

> What do you want?


An HTTP-powered alternative to LDAP. Preferably ASN.1-free.

-- 
Tony Arcieri

--047d7b4513d80e86630508149eb7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Nov 17, 2014 at 1:08 PM, Phillip Hallam-Baker <span dir=3D"ltr">&lt;<a =
href=3D"mailto:phill@hallambaker.com" target=3D"_blank" onclick=3D"window.o=
pen(&#39;https://mail.google.com/mail/?view=3Dcm&amp;tf=3D1&amp;to=3Dphill@=
hallambaker.com&amp;cc=3D&amp;bcc=3D&amp;su=3D&amp;body=3D&#39;,&#39;_blank=
&#39;);return false;">phill@hallambaker.com</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">What do you want?</blockquote><div><br></div><div>=
An HTTP-powered alternative to LDAP. Preferably ASN.1-free.</div></div><div=
><br></div>-- <br><div class=3D"gmail_signature">Tony Arcieri<br></div>
</div></div>

--047d7b4513d80e86630508149eb7--


From nobody Mon Nov 17 13:52:07 2014
Return-Path: <rob.stradling@comodo.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 15F541ACD1F for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 13:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 VMnTyl_Tf2sy for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 13:52:00 -0800 (PST)
Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC0E1ACD14 for <therightkey@ietf.org>; Mon, 17 Nov 2014 13:52:00 -0800 (PST)
Received: (qmail 18588 invoked by uid 1004); 17 Nov 2014 21:51:58 -0000
Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Lu, 17 nov 2014 21:51:58 +0000
Received: (qmail 29795 invoked by uid 1000); 17 Nov 2014 21:51:58 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 17 Nov 2014 21:51:58 +0000
Message-ID: <546A6DFD.1020306@comodo.com>
Date: Mon, 17 Nov 2014 21:51:57 +0000
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>,  Phillip Hallam-Baker <phill@hallambaker.com>, Ben Laurie <benl@google.com>
References: <5466AF87.2050307@gmail.com><CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com> <CAK3OfOionKNtMRv+bFqY=yN1x+VQNwzraOBF-NSsdnSu6dOA5w@mail.gmail.com>
In-Reply-To: <CAK3OfOionKNtMRv+bFqY=yN1x+VQNwzraOBF-NSsdnSu6dOA5w@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/NAH4OeIFGgk2D3zusG5YuZUsnq4
Cc: "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] [pkix] Proposal for working on PKIX revocationopen 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 21:52:04 -0000

On 17/11/14 17:47, Nico Williams wrote:
> On Sat, Nov 15, 2014 at 3:56 PM, Phillip Hallam-Baker wrote:
<snip>
>> I have a different set of proposals:
>>
>> 1) Stapled OCSP with MUST-STAPLE OID
>> 2) Short lived Certificates
>>    2a) With the same key
>>    2b) With different keys
>> 3) CRLs with HBS compression.
>
> +1

On 17/11/14 15:52, Ben Laurie wrote:
<snip>
> 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.

I'm interested in making revocation checking for the WebPKI actually 
work when it needs to work!  And that means finding a way for browsers 
to be able to hard-fail when revocation status is unobtainable.

TBH, I'm growing weary of OCSP Stapling.  It's still going to be years 
before there's any chance of it being deployed ubiquitously.  And I've 
seen some resistance to having OCSP Stapling enabled by default on the 
server-side.
Must-Staple is selective hard-fail.  It doesn't stop a compromised CA 
from misissuing a cert without Must-Staple for www.domain.com. 
Ultimately, we need browsers to always hard-fail, at which point 
Must-Staple would become redundant.

Short-lived certs are awkward until servers can somehow automate the 
process of requesting and installing new certificates.  And it's a 
problem that browsers don't treat certificate expiration as harshly as 
they treat certificate revocation.

The direction the browsers have been heading in (first Chrome with 
CRLSets, and now Firefox with OneCRL) is for the browser provider to 
construct a curated "global CRL" and push this to users via the 
browser's regular update mechanism.  The biggest problem I've seen with 
these "global CRL" solutions is that they don't cover the majority of 
certs...
...which is why I'm excited about CRLs with HBS compression.  :-)

I'm also excited about Ben's Revocation Transparency proposal.  This 
would be perfect as a trusted source for generating _truly_ "global 
CRLs" with HBS compression.  :-)

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Mon Nov 17 16:17:11 2014
Return-Path: <nico@cryptonector.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 2EEB01ACF24 for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 16:17:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 HEzkn77l2daT for <therightkey@ietfa.amsl.com>; Mon, 17 Nov 2014 16:17:07 -0800 (PST)
Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7201ACFAC for <therightkey@ietf.org>; Mon, 17 Nov 2014 16:17:07 -0800 (PST)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id D4EFA594059; Mon, 17 Nov 2014 16:17:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=QW5roAwrGawQ8L 9Gk3qRmJir84Q=; b=APSQUzxApOrXOZJkm77c0jK5tY+2ojD3TOE8I9wJ7mijqd 4pMyA/JVnoGduVXD39fXJ/JB5syTLKl2ej24aOKiygG+nWqP9l6WFJmkltgtoKC8 G+Lm0pjrwJsYW4LBl/lLcDwo3cgUm5Fp4kboUK9gLO3BPa8HotmadYswJbIqc=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id 7404A594058; Mon, 17 Nov 2014 16:17:06 -0800 (PST)
Date: Mon, 17 Nov 2014 18:17:06 -0600
From: Nico Williams <nico@cryptonector.com>
To: Rob Stradling <rob.stradling@comodo.com>
Message-ID: <20141118001704.GE5476@localhost>
References: <5466AF87.2050307@gmail.com> <CAMm+Lwg30tb+yFxVMG3qJ=_fjVT=ASqUmaf9gH8wpUhUGxgf6A@mail.gmail.com> <CAK3OfOionKNtMRv+bFqY=yN1x+VQNwzraOBF-NSsdnSu6dOA5w@mail.gmail.com> <546A6DFD.1020306@comodo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <546A6DFD.1020306@comodo.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/CWXQ-1EDnVFr0GRaxn7Nw1U_LeA
Cc: "therightkey@ietf.org" <therightkey@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>, Ben Laurie <benl@google.com>
Subject: Re: [therightkey] [pkix] Proposal for working on PKIX revocationopen 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: Tue, 18 Nov 2014 00:17:08 -0000

On Mon, Nov 17, 2014 at 09:51:57PM +0000, Rob Stradling wrote:
> I'm interested in making revocation checking for the WebPKI actually
> work when it needs to work!  And that means finding a way for
> browsers to be able to hard-fail when revocation status is
> unobtainable.
>
> [...]

What you say is true, but what we need here is a time machine.  One that
can travel backwards in time cheaply.  That one is stuck in AUTH48, I
hear, and we might not get it for a while yet.

Deadly embrace problems simply take time to fix.

DANE stands a pretty good chance of helping simplify a lot of things,
which is one reason that I'm a fan.  Right out of the gate DANE is way
ahead of PKIX w.r.t. naming constraints, and that's a huge part of the
battle -- nigh the most important, since the number of CAs that can
impersonate a service becomes: the number of labels in the TLSA RRset
domainname.

DANE can be stapled, and it's rather straightforward to do so too.  Yes,
there are issues, like the DNSSEC RSA 1024 root key, and the lack of
logging of delegations, but we know what they are and they are
tractable.

Nico
-- 


From nobody Thu Nov 20 14:03:15 2014
Return-Path: <rlb@ipv.sx>
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 279441A8798 for <therightkey@ietfa.amsl.com>; Thu, 20 Nov 2014 14:03:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.078
X-Spam-Level: 
X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 pQQqWj1iBOjr for <therightkey@ietfa.amsl.com>; Thu, 20 Nov 2014 14:03:04 -0800 (PST)
Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59F671A884D for <therightkey@ietf.org>; Thu, 20 Nov 2014 14:03:03 -0800 (PST)
Received: by mail-vc0-f170.google.com with SMTP id hy4so1266757vcb.15 for <therightkey@ietf.org>; Thu, 20 Nov 2014 14:03:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=2v3bUWOdPcPy7w/lPIsDe0AzinVw0iJkl5JaFJudbOM=; b=X7M5eMDkibTlUoxmWqp+WKyGOoEzkM7RCVEWMobdfvQmOSv2LHfFTRA9w8icolLqXl /NJmVwrJ2QyIoE7bH3ChA/g9/u59M1g5RvXLByhmudUvkURCslHLS3+4S1A09ikqaB0N UzVFkXxpgnKTfCsnE7uHn8/DIWnznDxbFLYjWQ2X7Lzc13OQLrEfgq6kn3guBUZ7vcmP RrdN7Ar1kk7zHIXdPpCEo8TCAplz+swMNbfP4v2LMRRvO+mD5GMDKOeEs6JqrGJxuyzD WILNr6RwOWRL/oeIU1ui5g6a2Adya+eVAMGRLh0hC93QHdJTdk1qnfj8v2F2kQ/2US+L tdjA==
X-Gm-Message-State: ALoCoQlNBVb2OKEeGGtiIXjby37pc8pGchSPeDXuSonSsD9yOoGwizIrlznjSbgRL6v4rgj3hMKy
MIME-Version: 1.0
X-Received: by 10.220.195.132 with SMTP id ec4mr946311vcb.16.1416520982423; Thu, 20 Nov 2014 14:03:02 -0800 (PST)
Received: by 10.31.149.1 with HTTP; Thu, 20 Nov 2014 14:03:02 -0800 (PST)
Date: Thu, 20 Nov 2014 17:03:02 -0500
Message-ID: <CAL02cgSGLLU2xT03USHFUD2gG-b5n-O9WfJ=iKM9Fwvou=-OnA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "therightkey@ietf.org" <therightkey@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c1ba98f9813f0508517d3d
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/QmcVrgx-qfP6JKquMvxNn3nSHYM
Subject: [therightkey] Proposal: ACME list
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: Thu, 20 Nov 2014 22:03:10 -0000

--001a11c1ba98f9813f0508517d3d
Content-Type: text/plain; charset=UTF-8

As some of you may have heard, some of us have been working on a protocol
to automate certificate management, including things like registration,
enrollment, issuance, and revocation.
<https://github.com/letsencrypt/acme-spec>

There is some similarity to existing CA-proprietary issuance APIs, and to
projects like SSLMate.
<https://sslmate.com/>

Would folks be interested in spinning up an IETF mailing list on this
topic?  It seems like we could probably get this in shape for a BoF in
Dallas.

--Richard

--001a11c1ba98f9813f0508517d3d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>As some of you may have heard, some of us have been w=
orking on a protocol to automate certificate management, including things l=
ike registration, enrollment, issuance, and revocation.<br>&lt;<a href=3D"h=
ttps://github.com/letsencrypt/acme-spec">https://github.com/letsencrypt/acm=
e-spec</a>&gt;<br><br></div>There is some similarity to existing CA-proprie=
tary issuance APIs, and to projects like SSLMate.<br>&lt;<a href=3D"https:/=
/sslmate.com/">https://sslmate.com/</a>&gt;<br><div><br></div><div>Would fo=
lks be interested in spinning up an IETF mailing list on this topic?=C2=A0 =
It seems like we could probably get this in shape for a BoF in Dallas.<br><=
br></div><div>--Richard<br></div></div>

--001a11c1ba98f9813f0508517d3d--


From nobody Thu Nov 20 14:58:48 2014
Return-Path: <hallam@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 7718C1A8707 for <therightkey@ietfa.amsl.com>; Thu, 20 Nov 2014 14:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 S3bYPUCwcd7s for <therightkey@ietfa.amsl.com>; Thu, 20 Nov 2014 14:58:45 -0800 (PST)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F72E1A8701 for <therightkey@ietf.org>; Thu, 20 Nov 2014 14:58:44 -0800 (PST)
Received: by mail-la0-f48.google.com with SMTP id s18so3348354lam.35 for <therightkey@ietf.org>; Thu, 20 Nov 2014 14:58:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Pc7Wl/v3k0YhP8tP5rKURfp7orMaUeiDnzgURzOkavY=; b=Rtctgrlqy1W8fkmRvWUTL/2qQ/hA6y7Ow1c+1GZVP5xTn814xvBEkhUmWIPZXuyhp3 rTx5OZVKNYObdzeHWHxi4k981C+DEkLpc4R6Uoly0jIebEb03zpsO1j6rjY7vsiNmZ/r qnD3a38UUapHKpxrv/hva8U4PEKNWtLHi9E0NcIiu/+GTuid3i6GDNGMj3SfOw92+3M8 09SUcuYSmVtycAiP4oO0N1uUTmreC+YKbwpeUzZM7XQnaj3D5jRs0yp7l7qZFULvwbJ6 Zeffo3jdXHCjYiiYjN0gBzIKVTUPfFYfw+OpkUj+NeXZUqIN3XTo6Pip1EhyRWweEDKK ymZg==
MIME-Version: 1.0
X-Received: by 10.112.93.231 with SMTP id cx7mr679215lbb.89.1416524322868; Thu, 20 Nov 2014 14:58:42 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.34.212 with HTTP; Thu, 20 Nov 2014 14:58:42 -0800 (PST)
In-Reply-To: <CAL02cgSGLLU2xT03USHFUD2gG-b5n-O9WfJ=iKM9Fwvou=-OnA@mail.gmail.com>
References: <CAL02cgSGLLU2xT03USHFUD2gG-b5n-O9WfJ=iKM9Fwvou=-OnA@mail.gmail.com>
Date: Thu, 20 Nov 2014 17:58:42 -0500
X-Google-Sender-Auth: G8hYtnuIhOX-AkbEwmeonFnBV3E
Message-ID: <CAMm+LwjVUfx+SDCLPOA2cTSOLC72f_63EbMNh-Da=O49kjejAA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Richard Barnes <rlb@ipv.sx>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/dic0NEIfGsIrapx-zbBUdpLU6-4
Cc: "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] Proposal: ACME list
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: Thu, 20 Nov 2014 22:58:46 -0000

On Thu, Nov 20, 2014 at 5:03 PM, Richard Barnes <rlb@ipv.sx> wrote:
> As some of you may have heard, some of us have been working on a protocol to
> automate certificate management, including things like registration,
> enrollment, issuance, and revocation.
> <https://github.com/letsencrypt/acme-spec>
>
> There is some similarity to existing CA-proprietary issuance APIs, and to
> projects like SSLMate.
> <https://sslmate.com/>
>
> Would folks be interested in spinning up an IETF mailing list on this topic?
> It seems like we could probably get this in shape for a BoF in Dallas.

There is definitely a need for this to enable use of short liver certs
and to clean up the mess of existing proposals, none of which are
really viable as automated protocols.

I proposed this a while back:

http://tools.ietf.org/html/draft-hallambaker-omnipublish-00


From nobody Fri Nov 21 02:05:33 2014
Return-Path: <stephen.farrell@cs.tcd.ie>
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 9BEED1AD3B6 for <therightkey@ietfa.amsl.com>; Fri, 21 Nov 2014 02:05:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Level: 
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 1EaCBo-_qQJn for <therightkey@ietfa.amsl.com>; Fri, 21 Nov 2014 02:05:12 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8C41AD391 for <therightkey@ietf.org>; Fri, 21 Nov 2014 02:03:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F0A3DBED6; Fri, 21 Nov 2014 10:03:07 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf4Vkb4HLExf; Fri, 21 Nov 2014 10:03:07 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9DCCCBEDD; Fri, 21 Nov 2014 10:03:06 +0000 (GMT)
Message-ID: <546F0DDD.7010503@cs.tcd.ie>
Date: Fri, 21 Nov 2014 10:03:09 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Phillip Hallam-Baker <phill@hallambaker.com>, Richard Barnes <rlb@ipv.sx>
References: <CAL02cgSGLLU2xT03USHFUD2gG-b5n-O9WfJ=iKM9Fwvou=-OnA@mail.gmail.com> <CAMm+LwjVUfx+SDCLPOA2cTSOLC72f_63EbMNh-Da=O49kjejAA@mail.gmail.com>
In-Reply-To: <CAMm+LwjVUfx+SDCLPOA2cTSOLC72f_63EbMNh-Da=O49kjejAA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/m2wtOnTl3zeZ1vSCHMP3hNqRrRU
Cc: "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] Proposal: ACME list
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: Fri, 21 Nov 2014 10:05:27 -0000

On 20/11/14 22:58, Phillip Hallam-Baker wrote:
> On Thu, Nov 20, 2014 at 5:03 PM, Richard Barnes <rlb@ipv.sx> wrote:
>> As some of you may have heard, some of us have been working on a protocol to
>> automate certificate management, including things like registration,
>> enrollment, issuance, and revocation.
>> <https://github.com/letsencrypt/acme-spec>
>>
>> There is some similarity to existing CA-proprietary issuance APIs, and to
>> projects like SSLMate.
>> <https://sslmate.com/>
>>
>> Would folks be interested in spinning up an IETF mailing list on this topic?
>> It seems like we could probably get this in shape for a BoF in Dallas.
> 
> There is definitely a need for this to enable use of short liver certs

Lovely typo! (Or were you only kidneying:-)

> and to clean up the mess of existing proposals, none of which are
> really viable as automated protocols.
> 
> I proposed this a while back:
> 
> http://tools.ietf.org/html/draft-hallambaker-omnipublish-00

Yep, this seems like something we've all been waiting to see
happen, and given that we have credible folks announcing the
accompanying service(s) too, and being willing to run their
protocol through here, I think it's probably a fine plan to
start that list - I'll go ask and get back here once it's
sorted.

Cheers,
S.

> 
> _______________________________________________
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
> 
> 


From nobody Mon Nov 24 10:03:43 2014
Return-Path: <stephen.farrell@cs.tcd.ie>
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 CAA041A87A9 for <therightkey@ietfa.amsl.com>; Mon, 24 Nov 2014 10:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 IN95Hxy2S5Uq for <therightkey@ietfa.amsl.com>; Mon, 24 Nov 2014 10:03:40 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAD41A701E for <therightkey@ietf.org>; Mon, 24 Nov 2014 10:03:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AA71FBDFD; Mon, 24 Nov 2014 18:03:39 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhc-JFOcFODW; Mon, 24 Nov 2014 18:03:33 +0000 (GMT)
Received: from [10.87.48.5] (unknown [86.46.28.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6F623BDF7; Mon, 24 Nov 2014 18:03:33 +0000 (GMT)
Message-ID: <547372F5.6000606@cs.tcd.ie>
Date: Mon, 24 Nov 2014 18:03:33 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Richard Barnes <rlb@ipv.sx>
References: <CAL02cgSGLLU2xT03USHFUD2gG-b5n-O9WfJ=iKM9Fwvou=-OnA@mail.gmail.com> <CAMm+LwjVUfx+SDCLPOA2cTSOLC72f_63EbMNh-Da=O49kjejAA@mail.gmail.com> <546F0DDD.7010503@cs.tcd.ie>
In-Reply-To: <546F0DDD.7010503@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/GB4nThCcphXkZw6RDmfJXWAexqU
Cc: "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] Proposal: ACME list
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, 24 Nov 2014 18:03:42 -0000

Hi Richard,

That's done now. [1]

I assume you'll kick off discussion in a few days

S.

[1] https://www.ietf.org/mailman/listinfo/acme


On 21/11/14 10:03, Stephen Farrell wrote:
> 
> 
> On 20/11/14 22:58, Phillip Hallam-Baker wrote:
>> On Thu, Nov 20, 2014 at 5:03 PM, Richard Barnes <rlb@ipv.sx> wrote:
>>> As some of you may have heard, some of us have been working on a protocol to
>>> automate certificate management, including things like registration,
>>> enrollment, issuance, and revocation.
>>> <https://github.com/letsencrypt/acme-spec>
>>>
>>> There is some similarity to existing CA-proprietary issuance APIs, and to
>>> projects like SSLMate.
>>> <https://sslmate.com/>
>>>
>>> Would folks be interested in spinning up an IETF mailing list on this topic?
>>> It seems like we could probably get this in shape for a BoF in Dallas.
>>
>> There is definitely a need for this to enable use of short liver certs
> 
> Lovely typo! (Or were you only kidneying:-)
> 
>> and to clean up the mess of existing proposals, none of which are
>> really viable as automated protocols.
>>
>> I proposed this a while back:
>>
>> http://tools.ietf.org/html/draft-hallambaker-omnipublish-00
> 
> Yep, this seems like something we've all been waiting to see
> happen, and given that we have credible folks announcing the
> accompanying service(s) too, and being willing to run their
> protocol through here, I think it's probably a fine plan to
> start that list - I'll go ask and get back here once it's
> sorted.
> 
> Cheers,
> S.
> 
>>
>> _______________________________________________
>> therightkey mailing list
>> therightkey@ietf.org
>> https://www.ietf.org/mailman/listinfo/therightkey
>>
>>
> 
> _______________________________________________
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
> 
> 


From nobody Mon Nov 24 11:38:43 2014
Return-Path: <bascule@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 606D91A8948 for <therightkey@ietfa.amsl.com>; Mon, 24 Nov 2014 11:38:30 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 YG_EfLBYUJCb for <therightkey@ietfa.amsl.com>; Mon, 24 Nov 2014 11:38:28 -0800 (PST)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408E51A886A for <therightkey@ietf.org>; Mon, 24 Nov 2014 11:38:28 -0800 (PST)
Received: by mail-ob0-f180.google.com with SMTP id wp4so7740373obc.11 for <therightkey@ietf.org>; Mon, 24 Nov 2014 11:38:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1M5pM+QDHaZwe9sNaLzae3F/ixClHbfokoJY16FYRw8=; b=if+G9tywWv4xmzf53nvfGnRJuYBzLL94+d6R1sPkeCELP0n2pCKqvGr7Vk2/DduHZR LA0WfN6hAFus0j5mpabPoDvCgAPXvCTURCZNW634q11wAiUI3iLeL6to+LmEVdX7QBjH 2yI6QCge6KfyTYAAcHlYh/EyvKOGV+ubJB+l5/HVinYbiOYsYt+NoJz5DIW1Z5oSX340 PWkxvwLHar6Z+ggkZ0STRTSGGZUdXu4nM3VeGjv0HtRV/3CoB6zCklWoNkeb3dLCRPuj dHSTmEtEynizMmt2b4mjOXz8h3UX+teeoPoxHKYHkMuQxx+nWyYML2lbhoH2403J0e/0 ILLg==
X-Received: by 10.182.130.232 with SMTP id oh8mr13753714obb.49.1416857907510;  Mon, 24 Nov 2014 11:38:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.115.40 with HTTP; Mon, 24 Nov 2014 11:38:07 -0800 (PST)
In-Reply-To: <547372F5.6000606@cs.tcd.ie>
References: <CAL02cgSGLLU2xT03USHFUD2gG-b5n-O9WfJ=iKM9Fwvou=-OnA@mail.gmail.com> <CAMm+LwjVUfx+SDCLPOA2cTSOLC72f_63EbMNh-Da=O49kjejAA@mail.gmail.com> <546F0DDD.7010503@cs.tcd.ie> <547372F5.6000606@cs.tcd.ie>
From: Tony Arcieri <bascule@gmail.com>
Date: Mon, 24 Nov 2014 11:38:07 -0800
Message-ID: <CAHOTMVLf-Eh_dn-6CO=ku3i1zEAwssqXOgSBONfdnTBf3HNOog@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=089e013a03c64646a105089ff048
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/oF8rE28tx667BjoMb7WOFyG-2GM
Cc: Richard Barnes <rlb@ipv.sx>, "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] Proposal: ACME list
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, 24 Nov 2014 19:38:30 -0000

--089e013a03c64646a105089ff048
Content-Type: text/plain; charset=UTF-8

I tried to sign up for this, but after entering my name and email on the
signup page and hitting Subscribe, I got a 504 from Cloudflare

On Mon, Nov 24, 2014 at 10:03 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie
> wrote:

>
> Hi Richard,
>
> That's done now. [1]
>
> I assume you'll kick off discussion in a few days
>
> S.
>
> [1] https://www.ietf.org/mailman/listinfo/acme
>
>
> On 21/11/14 10:03, Stephen Farrell wrote:
> >
> >
> > On 20/11/14 22:58, Phillip Hallam-Baker wrote:
> >> On Thu, Nov 20, 2014 at 5:03 PM, Richard Barnes <rlb@ipv.sx> wrote:
> >>> As some of you may have heard, some of us have been working on a
> protocol to
> >>> automate certificate management, including things like registration,
> >>> enrollment, issuance, and revocation.
> >>> <https://github.com/letsencrypt/acme-spec>
> >>>
> >>> There is some similarity to existing CA-proprietary issuance APIs, and
> to
> >>> projects like SSLMate.
> >>> <https://sslmate.com/>
> >>>
> >>> Would folks be interested in spinning up an IETF mailing list on this
> topic?
> >>> It seems like we could probably get this in shape for a BoF in Dallas.
> >>
> >> There is definitely a need for this to enable use of short liver certs
> >
> > Lovely typo! (Or were you only kidneying:-)
> >
> >> and to clean up the mess of existing proposals, none of which are
> >> really viable as automated protocols.
> >>
> >> I proposed this a while back:
> >>
> >> http://tools.ietf.org/html/draft-hallambaker-omnipublish-00
> >
> > Yep, this seems like something we've all been waiting to see
> > happen, and given that we have credible folks announcing the
> > accompanying service(s) too, and being willing to run their
> > protocol through here, I think it's probably a fine plan to
> > start that list - I'll go ask and get back here once it's
> > sorted.
> >
> > Cheers,
> > S.
> >
> >>
> >> _______________________________________________
> >> therightkey mailing list
> >> therightkey@ietf.org
> >> https://www.ietf.org/mailman/listinfo/therightkey
> >>
> >>
> >
> > _______________________________________________
> > therightkey mailing list
> > therightkey@ietf.org
> > https://www.ietf.org/mailman/listinfo/therightkey
> >
> >
>
> _______________________________________________
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
>



-- 
Tony Arcieri

--089e013a03c64646a105089ff048
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I tried to sign up for this, but after entering my name an=
d email on the signup page and hitting Subscribe, I got a 504 from Cloudfla=
re</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, N=
ov 24, 2014 at 10:03 AM, Stephen Farrell <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farrell@cs.tcd.i=
e</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Richard,<br>
<br>
That&#39;s done now. [1]<br>
<br>
I assume you&#39;ll kick off discussion in a few days<br>
<br>
S.<br>
<br>
[1] <a href=3D"https://www.ietf.org/mailman/listinfo/acme" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/acme</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On 21/11/14 10:03, Stephen Farrell wrote:<br>
&gt;<br>
&gt;<br>
&gt; On 20/11/14 22:58, Phillip Hallam-Baker wrote:<br>
&gt;&gt; On Thu, Nov 20, 2014 at 5:03 PM, Richard Barnes &lt;rlb@ipv.sx&gt;=
 wrote:<br>
&gt;&gt;&gt; As some of you may have heard, some of us have been working on=
 a protocol to<br>
&gt;&gt;&gt; automate certificate management, including things like registr=
ation,<br>
&gt;&gt;&gt; enrollment, issuance, and revocation.<br>
&gt;&gt;&gt; &lt;<a href=3D"https://github.com/letsencrypt/acme-spec" targe=
t=3D"_blank">https://github.com/letsencrypt/acme-spec</a>&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; There is some similarity to existing CA-proprietary issuance A=
PIs, and to<br>
&gt;&gt;&gt; projects like SSLMate.<br>
&gt;&gt;&gt; &lt;<a href=3D"https://sslmate.com/" target=3D"_blank">https:/=
/sslmate.com/</a>&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Would folks be interested in spinning up an IETF mailing list =
on this topic?<br>
&gt;&gt;&gt; It seems like we could probably get this in shape for a BoF in=
 Dallas.<br>
&gt;&gt;<br>
&gt;&gt; There is definitely a need for this to enable use of short liver c=
erts<br>
&gt;<br>
&gt; Lovely typo! (Or were you only kidneying:-)<br>
&gt;<br>
&gt;&gt; and to clean up the mess of existing proposals, none of which are<=
br>
&gt;&gt; really viable as automated protocols.<br>
&gt;&gt;<br>
&gt;&gt; I proposed this a while back:<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"http://tools.ietf.org/html/draft-hallambaker-omnipublis=
h-00" target=3D"_blank">http://tools.ietf.org/html/draft-hallambaker-omnipu=
blish-00</a><br>
&gt;<br>
&gt; Yep, this seems like something we&#39;ve all been waiting to see<br>
&gt; happen, and given that we have credible folks announcing the<br>
&gt; accompanying service(s) too, and being willing to run their<br>
&gt; protocol through here, I think it&#39;s probably a fine plan to<br>
&gt; start that list - I&#39;ll go ask and get back here once it&#39;s<br>
&gt; sorted.<br>
&gt;<br>
&gt; Cheers,<br>
&gt; S.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; therightkey mailing list<br>
&gt;&gt; <a href=3D"mailto:therightkey@ietf.org">therightkey@ietf.org</a><b=
r>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/therightkey" targ=
et=3D"_blank">https://www.ietf.org/mailman/listinfo/therightkey</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; therightkey mailing list<br>
&gt; <a href=3D"mailto:therightkey@ietf.org">therightkey@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/therightkey" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/therightkey</a><br>
&gt;<br>
&gt;<br>
<br>
_______________________________________________<br>
therightkey mailing list<br>
<a href=3D"mailto:therightkey@ietf.org">therightkey@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/therightkey" target=3D"_bl=
ank">https://www.ietf.org/mailman/listinfo/therightkey</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature">Tony Arcieri<br></div>
</div>

--089e013a03c64646a105089ff048--