On Thu, Jan 2, 2014 at 1:57 PM, Jacob Appelbaum &= lt;jacob@appelbaum= .net> wrote:

Paul Hoffman:

> On Jan 1, 2014, at 10:22 AM, Jacob Appelbaum <jacob@appelbaum.net>
> wrote:
>
>> I do control the private key for the aforementioned intermediate >> certificate[0] authority. :)
>
> No, you really do not.

=A0

Unless one explicitly distrusts= (all) MD5 signed certificates, pre-loads
our certificate to mark it as untrusted, or a few other things relating
to time constraints - it will probably still work for MITM attacks. Many applications fail to do proper constraint checking.

Anyone who trusts MD5 for signing any form of keying material is v= ulnerable to this type of attack. It does not matter whether there is a CA = involved or not or the number of sub CAs. A variation of the attack could b= e performed on PGP or DNSSEC.

The fix here is to disable MD5 completely in the browse= r or for CAs to not use MD5 in any certificate. The industry has chosen to = do the second since we can't actually recall legacy browsers. However, = Microsoft's recent decision to end of life SHA-1 will have the effect o= f rendering most of the legacy browsers unusable in any case.

> Please don't overstate the results of
> the excellent research that you did; doing so diminishes the
> research.

I'm not overstating anything. I think you don't understand wh= at we
actually did if you think that later, patching things will somehow
magically stop previously successful attacks...

You are confusing people by using a valid attack against the= algorithm to argue against the trust model. PKIX is designed on the assump= tion that the digest algorithm chosen is secure against a second preimage a= ttack.

We have a lot of security issues to deal with right now= and we want to make sure we are paying attention to the ones that matter m= ost. This is really not helping.

--
Website: http://hallambaker.com/

--001a11c33d6eb71f7b04ef02962b-- From leifj@mnt.se Thu Jan 2 13:00:18 2014 Return-Path: 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 DFF201A1F5F for ; Thu, 2 Jan 2014 13:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LszLm55vcdGy for ; Thu, 2 Jan 2014 13:00:16 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id C505A1AC7EF for ; Thu, 2 Jan 2014 13:00:15 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id l4so7643467lbv.35 for ; Thu, 02 Jan 2014 13:00:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=OeztZwRqwXIxeyKF/Z6TxCa1GQZypNy8V9pDCthnh/U=; b=fgtQg0BueIzvI+aJ/bRp+9xco9ROE6ZYoPzmbLBBwTGsO6psQuzb/67UicNf7mi/fl Cbnn26hx5CnZ2ImSGWjRDGP7pwRd6UP3hgmLDqipTttbbF4v9eHOO7zEm0URyjzLUEHw e7D6P5/W7sHCS2nPe/aUpeWv1SwRjOZ5cn0BLHBMwUED+z3Ldp+AcC98X44OWXe5nmVk qH7axZE/taC5ohNi4AhOVtVRPawdqMBkryrmjlHRtkFaSMtkkVt0//qLiurVMd74HiRB Fw1aYXmEQtghlJyLrYVcAeP1JycXa0vrUYjrTeLcPQ6mizeI90oP5IZBmfwUh9HBa/5u HfcQ== X-Gm-Message-State: ALoCoQmH1exkcu5C/MBl2Q6+51pj/aKwAjAMQV7hO40yAt3L/mOb2OIbYeWaxqBzyYY45NN0frH7 X-Received: by 10.152.234.75 with SMTP id uc11mr22354348lac.30.1388696407949; Thu, 02 Jan 2014 13:00:07 -0800 (PST) Received: from [10.0.0.166] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id mq10sm35119041lbb.12.2014.01.02.13.00.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jan 2014 13:00:06 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-8A9055E2-1EFA-442A-B09E-AA2A7AF91B08 Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (11B554a) In-Reply-To: Date: Thu, 2 Jan 2014 22:00:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <22429D73-4EFC-4091-8F5B-BAD38968EA54@taoeffect.com>

<52B88104.9040607@appelbaum.net> <52C2D54F.8000209@comodo.com> <52C45CDC.5020608@appelbaum.net> <96EF8E55-5860-4534-B370-83395C3985D4@vpnc.org> <52C5B67D.4050301@appelbaum.net> To: Phillip Hallam-Baker Cc: "therightkey@ietf.org" , Paul Hoffman , Jacob Appelbaum Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 21:00:19 -0000 --Apple-Mail-8A9055E2-1EFA-442A-B09E-AA2A7AF91B08 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > 2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker : >=20 >=20 >=20 >=20 >> On Thu, Jan 2, 2014 at 1:57 PM, Jacob Appelbaum wro= te: >> Paul Hoffman: >> > On Jan 1, 2014, at 10:22 AM, Jacob Appelbaum >> > wrote: >> > >> >> I do control the private key for the aforementioned intermediate >> >> certificate[0] authority. :) >> > >> > No, you really do not. > =20 >> Unless one explicitly distrusts (all) MD5 signed certificates, pre-loads >> our certificate to mark it as untrusted, or a few other things relating >> to time constraints - it will probably still work for MITM attacks. Many >> applications fail to do proper constraint checking. >=20 > Anyone who trusts MD5 for signing any form of keying material is vulnerabl= e to this type of attack. It does not matter whether there is a CA involved o= r not or the number of sub CAs. A variation of the attack could be performed= on PGP or DNSSEC. >=20 > The fix here is to disable MD5 completely in the browser or for CAs to not= use MD5 in any certificate. The industry has chosen to do the second since w= e can't actually recall legacy browsers. However, Microsoft's recent decisio= n to end of life SHA-1 will have the effect of rendering most of the legacy b= rowsers unusable in any case. >=20 >=20 >=20 >> > Please don't overstate the results of >> > the excellent research that you did; doing so diminishes the >> > research. >>=20 >> I'm not overstating anything. I think you don't understand what we >> actually did if you think that later, patching things will somehow >> magically stop previously successful attacks... >=20 >=20 > You are confusing people by using a valid attack against the algorithm to a= rgue against the trust model. PKIX is designed on the assumption that the di= gest algorithm chosen is secure against a second preimage attack. The fundamental flaw in the pkix trust model is that there is no deployable m= echanism for limiting the impact of such an attack. That realization should inform future design and that bit is certainly on to= pic ;-) >=20 > We have a lot of security issues to deal with right now and we want to mak= e sure we are paying attention to the ones that matter most. This is really n= ot helping. >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --Apple-Mail-8A9055E2-1EFA-442A-B09E-AA2A7AF91B08 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker <hallam@gmail.com>:

On Thu, Jan 2, 2014 at 1:57 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:

Paul Hoffman:

> On Jan 1, 2014, at 10:22 AM, Jacob Appelbaum <jacob@appelbaum.net>
> wrote:
>
>> I do control the private key for the aforementioned intermediate
>> certificate[0] authority. :)
>
> No, you really do not.

Unless one explicitly distrusts (all) MD5 signed certificates, pre-loads
our certificate to mark it as untrusted, or a few other things relating
to time constraints - it will probably still work for MITM attacks. Many
applications fail to do proper constraint checking.

Anyone who trusts MD5 for signing any form of keying material is vulnerable to this type of attack. It does not matter whether there is a CA involved or not or the number of sub CAs. A variation of the attack could be performed on PGP or DNSSEC.

The fix here is to disable MD5 completely in the browser or for CAs to not use MD5 in any certificate. The industry has chosen to do the second since we can't actually recall legacy browsers. However, Microsoft's recent decision to end of life SHA-1 will have the effect of rendering most of the legacy browsers unusable in any case.

> Please don't overstate the results of
> the excellent research that you did; doing so diminishes the
> research.

I'm not overstating anything. I think you don't understand what we
actually did if you think that later, patching things will somehow
magically stop previously successful attacks...

You are confusing people by using a valid attack against the algorithm to argue against the trust model. PKIX is designed on the assumption that the digest algorithm chosen is secure against a second preimage attack.

The fundamental flaw in the pkix trust model is that there is no deployable mechanism for limiting the impact of such an attack.

That realization should inform future design and that bit is certainly on topic ;-)

We have a lot of security issues to deal with right now and we want to make sure we are paying attention to the ones that matter most. This is really not helping.

--
Website: http://hallambaker.com/

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

--Apple-Mail-8A9055E2-1EFA-442A-B09E-AA2A7AF91B08-- From hallam@gmail.com Thu Jan 2 13:58:07 2014 Return-Path: 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 934861AD67C for ; Thu, 2 Jan 2014 13:58:07 -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 kt6pwJiUjijI for ; Thu, 2 Jan 2014 13:58:06 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A35F51AD67A for ; Thu, 2 Jan 2014 13:58:05 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id eh20so7640429lab.19 for ; Thu, 02 Jan 2014 13:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DHHGirYfmt/hPvKA0MGnBzCDOsQ4xgbNJ9QcmK+saGo=; b=tK+m/nE49mnG34C3v78VkfHoHaUJEwDGCqs2jTbJwxeRudUhG1uGUlD8Uztd0iEQ77 9g7oIzX1WKJawI+5Pm75Nf5+tD6N8qhXNBl4NWGSFonudW5ESW9UTuI1g8yhEd8YjuhS GKiiMOp7RDAqQeKCNrPMSRA1i5scQ7XHyD5a8b5w1jDdlxc+USsierfU17xWCH+k+boo GaQZFQkVoTSi6OgXTFdZSQpkMTNVVk9HErkUe9alrcvO2helUCuH2F11JdhshWTtouaO /LVmR/Q4FHbLrGKO3J3vbsxN5lQKb2VBh+6ND3KstdukBDulZSx22rliY11Veq2nEd9i /T5g== MIME-Version: 1.0 X-Received: by 10.112.138.70 with SMTP id qo6mr19140758lbb.34.1388699877820; Thu, 02 Jan 2014 13:57:57 -0800 (PST) Received: by 10.112.37.172 with HTTP; Thu, 2 Jan 2014 13:57:57 -0800 (PST) In-Reply-To: References: <22429D73-4EFC-4091-8F5B-BAD38968EA54@taoeffect.com>

<52B88104.9040607@appelbaum.net> <52C2D54F.8000209@comodo.com> <52C45CDC.5020608@appelbaum.net> <96EF8E55-5860-4534-B370-83395C3985D4@vpnc.org> <52C5B67D.4050301@appelbaum.net>

Date: Thu, 2 Jan 2014 16:57:57 -0500 Message-ID: From: Phillip Hallam-Baker To: Leif Johansson Content-Type: multipart/alternative; boundary=089e0112c02ceacfc104ef03e25f Cc: "therightkey@ietf.org" , Paul Hoffman , Jacob Appelbaum Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 21:58:07 -0000 --089e0112c02ceacfc104ef03e25f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson wrote: > > > 2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker : > > > Please don't overstate the results of >> > the excellent research that you did; doing so diminishes the >> > research. >> >> I'm not overstating anything. I think you don't understand what we >> actually did if you think that later, patching things will somehow >> magically stop previously successful attacks... >> > > You are confusing people by using a valid attack against the algorithm to > argue against the trust model. PKIX is designed on the assumption that the > digest algorithm chosen is secure against a second preimage attack. > > > The fundamental flaw in the pkix trust model is that there is no > deployable mechanism for limiting the impact of such an attack. > > That realization should inform future design and that bit is certainly on > topic ;-) > It is on topic but not limited to PKIX. We have since learned that algorithm agility is not quite the security benefit we once thought as the security of the system is determined by the weakest algorithm you support, not the strongest one you implement. Problem is that I can't see a way to really control this type of attack without a very considerable cost in usability and I think it would constrain other defenses. Anyone using Windows XP in the Enterprise for any purpose other than finding viruses is guilty of security malpractice at this point. It is an obsolete OS that would have been at EOL if lazy sysadmins hadn't begged to keep it. My current solution in my email project is to attempt to require SHA512 for all certificates. But I am not sure that is actually sustainable. -- Website: http://hallambaker.com/ --089e0112c02ceacfc104ef03e25f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson &l= t;leifj@mnt.se> wrote:

2 jan 2014 kl. 2= 1:25 skrev Phillip Hallam-Baker <hallam@gmail.com>:

> Please don't overstate the results of
> the excellent research that you did; doing so diminishes the
> research.

I'm not overstating anything. I think you don't understand wh= at we
actually did if you think that later, patching things will somehow
magically stop previously successful attacks...
=
You are confusing people by using a valid attack against the= algorithm to argue against the trust model. PKIX is designed on the assump= tion that the digest algorithm chosen is secure against a second preimage a= ttack.

The fundamental fl= aw in the pkix trust model is that there is no deployable mechanism for lim= iting the impact of such an attack.

That realizati= on should inform future design and that bit is certainly on topic ;-)

It is on topic but not limited to PK= IX.=A0

We have since learned that algorithm agilit= y is not quite the security benefit we once thought as the security of the = system is determined by the weakest algorithm you support, not the stronges= t one you implement.

Problem is that I can't see a = way to really control this type of attack without a very considerable cost = in usability and I think it would constrain other defenses.

Anyone using Windows XP in the Enterprise for any purpose other = than finding viruses is guilty of security malpractice at this point. It is= an obsolete OS that would have been at EOL if lazy sysadmins hadn't be= gged to keep it.

=A0

My current solution in my email pro= ject is to attempt to require SHA512 for all certificates. But I am not sur= e that is actually sustainable.

--
Website: http://hallambaker.com/

--089e0112c02ceacfc104ef03e25f-- From SChokhani@cygnacom.com Thu Jan 2 14:09:19 2014 Return-Path: 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 53D871ACC88 for ; Thu, 2 Jan 2014 14:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, 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 S2BSa-4ifsS5 for ; Thu, 2 Jan 2014 14:09:17 -0800 (PST) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id D4D6C1AC85E for ; Thu, 2 Jan 2014 14:09:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,593,1384318800"; d="scan'208,217";a="1599364" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 02 Jan 2014 17:09:10 -0500 Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Thu, 2 Jan 2014 17:09:09 -0500 From: Santosh Chokhani To: Phillip Hallam-Baker , Leif Johansson Thread-Topic: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security Thread-Index: AQHPCAXa/8Ioig5tGU25kjFTCjkYTJpx/hOA Date: Thu, 2 Jan 2014 22:09:08 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E8113910E532@scygexch10.cygnacom.com> References: <22429D73-4EFC-4091-8F5B-BAD38968EA54@taoeffect.com>

<52B88104.9040607@appelbaum.net> <52C2D54F.8000209@comodo.com> <52C45CDC.5020608@appelbaum.net> <96EF8E55-5860-4534-B370-83395C3985D4@vpnc.org> <52C5B67D.4050301@appelbaum.net>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.24.81] Content-Type: multipart/alternative; boundary="_000_4262AC0DB9856847A2D00EF817E8113910E532scygexch10cygnaco_" MIME-Version: 1.0 Cc: "therightkey@ietf.org" , Paul Hoffman , Jacob Appelbaum Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 22:09:19 -0000 --_000_4262AC0DB9856847A2D00EF817E8113910E532scygexch10cygnaco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LTANS WG had produced an RFC (RFC 5698) to protect the relying parties from= weak algorithms. If that RFC is implemented on the certificate consuming side, these attacks= will be thwarted. From: therightkey [mailto:therightkey-bounces@ietf.org] On Behalf Of Philli= p Hallam-Baker Sent: Thursday, January 02, 2014 4:58 PM To: Leif Johansson Cc: therightkey@ietf.org; Paul Hoffman; Jacob Appelbaum Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fi= xes HTTPS security On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson > wrote: 2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker >: > Please don't overstate the results of > the excellent research that you did; doing so diminishes the > research. I'm not overstating anything. I think you don't understand what we actually did if you think that later, patching things will somehow magically stop previously successful attacks... You are confusing people by using a valid attack against the algorithm to a= rgue against the trust model. PKIX is designed on the assumption that the d= igest algorithm chosen is secure against a second preimage attack. The fundamental flaw in the pkix trust model is that there is no deployable= mechanism for limiting the impact of such an attack. That realization should inform future design and that bit is certainly on t= opic ;-) It is on topic but not limited to PKIX. We have since learned that algorithm agility is not quite the security bene= fit we once thought as the security of the system is determined by the weak= est algorithm you support, not the strongest one you implement. Problem is that I can't see a way to really control this type of attack wit= hout a very considerable cost in usability and I think it would constrain o= ther defenses. Anyone using Windows XP in the Enterprise for any purpose other than findin= g viruses is guilty of security malpractice at this point. It is an obsolet= e OS that would have been at EOL if lazy sysadmins hadn't begged to keep it= . My current solution in my email project is to attempt to require SHA512 for= all certificates. But I am not sure that is actually sustainable. -- Website: http://hallambaker.com/ --_000_4262AC0DB9856847A2D00EF817E8113910E532scygexch10cygnaco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

LTANS WG had produced an = RFC (RFC 5698) to protect the relying parties from weak algorithms.

<= /p>

If that RFC is implemente= d on the certificate consuming side, these attacks will be thwarted.

<= /p>

From: theright= key [mailto:therightkey-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, January 02, 2014 4:58 PM
To: Leif Johansson
Cc: therightkey@ietf.org; Paul Hoffman; Jacob Appelbaum
Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities= and fixes HTTPS security

On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson <<= a href=3D"mailto:leifj@mnt.se" target=3D"_blank">leifj@mnt.se> wrote= :

2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker <hallam@gmail.com>:

> Please don't ove= rstate the results of
> the excellent research that you did; doing so diminishes the
> research.

I'm not overstating anything. I think you don't unde= rstand what we
actually did if you think that later, patching things will somehow
magically stop previously successful attacks...

You are confusing people by using a valid attack aga= inst the algorithm to argue against the trust model. PKIX is designed on th= e assumption that the digest algorithm chosen is secure against a second pr= eimage attack.

The fundamental flaw in the pkix trust model is that= there is no deployable mechanism for limiting the impact of such an attack= .

That realization should inform future design and tha= t bit is certainly on topic ;-)

It is on topic but not limited to PKIX.

We have since learned that algorithm agility is not = quite the security benefit we once thought as the security of the system is= determined by the weakest algorithm you support, not the strongest one you= implement.

Problem is that I can't see a way to really control = this type of attack without a very considerable cost in usability and I thi= nk it would constrain other defenses.

Anyone using Windows XP in the Enterprise for any pu= rpose other than finding viruses is guilty of security malpractice at this = point. It is an obsolete OS that would have been at EOL if lazy sysadmins h= adn't begged to keep it.

My current solution in my email project is to attemp= t to require SHA512 for all certificates. But I am not sure that is actuall= y sustainable.

--
Website: http://hallambaker.com/

--_000_4262AC0DB9856847A2D00EF817E8113910E532scygexch10cygnaco_-- From leifj@mnt.se Thu Jan 2 14:16:37 2014 Return-Path: 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 4374C1AC7F3 for ; Thu, 2 Jan 2014 14:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LhwG1otb_jKE for ; Thu, 2 Jan 2014 14:16:34 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id 698051AC4C1 for ; Thu, 2 Jan 2014 14:16:34 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id n7so7648051lam.16 for ; Thu, 02 Jan 2014 14:16:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=fgTSgxFxUBMlkUh3Buc6V/CoskPky4HHfKHGiCv3HCk=; b=lslH2SK+Ij9Jmy+UNkTEWfJ1GusEXW62En8zYzdi9pqoW8NU9tF8BhcklMiwcsQe4E PwLDKwEadtF8r/mjCn8kwxPKh9YbOfFibe7Xlj2fXdOHofS0fZ4fL0pybHoJb8Cu/nKK fZTPKbghadlRQQqwqEwdY35j5vIExfyiwCIHkLLTyP4LLN9BQ7njFHb0QH8bRpMuDp3f Y1MtbsblrS5cYO+f3o7UY6UTEXcBdyxy+ypaEx+S1Bx4I6aK+ggR9P82nqIf6bNCbae3 GjxUC3nOzaeXTEL7DvEMoMyTHsR8tlvyBz4HE5WN3H5PJ0dY+El8RBfH0EecWhjAt6Vb h0VQ== X-Gm-Message-State: ALoCoQmpo8NwSrCTuc8FoLlUmq2HWNEXPMsLzIi+vgOmchyn5aMASRfxl8bvofO2olEtURWmsF3s X-Received: by 10.152.244.130 with SMTP id xg2mr35268763lac.4.1388700986715; Thu, 02 Jan 2014 14:16:26 -0800 (PST) Received: from [10.0.0.166] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id sd11sm45328506lab.2.2014.01.02.14.16.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jan 2014 14:16:25 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-A5398DB1-8179-404D-8D98-819960858EEC Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (11B554a) In-Reply-To: Date: Thu, 2 Jan 2014 23:16:27 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <22429D73-4EFC-4091-8F5B-BAD38968EA54@taoeffect.com>

<52B88104.9040607@appelbaum.net> <52C2D54F.8000209@comodo.com> <52C45CDC.5020608@appelbaum.net> <96EF8E55-5860-4534-B370-83395C3985D4@vpnc.org> <52C5B67D.4050301@appelbaum.net>

To: Phillip Hallam-Baker Cc: "therightkey@ietf.org" , Paul Hoffman , Jacob Appelbaum Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 22:16:37 -0000 --Apple-Mail-A5398DB1-8179-404D-8D98-819960858EEC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > 2 jan 2014 kl. 22:57 skrev Phillip Hallam-Baker : >=20 >=20 >=20 >=20 >> On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson wrote: >>=20 >>=20 >> 2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker : >>=20 >>>> > Please don't overstate the results of >>>> > the excellent research that you did; doing so diminishes the >>>> > research. >>>>=20 >>>> I'm not overstating anything. I think you don't understand what we >>>> actually did if you think that later, patching things will somehow >>>> magically stop previously successful attacks... >>>=20 >>>=20 >>> You are confusing people by using a valid attack against the algorithm t= o argue against the trust model. PKIX is designed on the assumption that the= digest algorithm chosen is secure against a second preimage attack. >>=20 >> The fundamental flaw in the pkix trust model is that there is no deployab= le mechanism for limiting the impact of such an attack. >>=20 >> That realization should inform future design and that bit is certainly on= topic ;-) >=20 > It is on topic but not limited to PKIX.=20 >=20 > We have since learned that algorithm agility is not quite the security ben= efit we once thought as the security of the system is determined by the weak= est algorithm you support, not the strongest one you implement. >=20 A trust model based on shorter-time-to-live keys would have limited the impa= ct too. >=20 > Problem is that I can't see a way to really control this type of attack wi= thout a very considerable cost in usability and I think it would constrain o= ther defenses. >=20 > Anyone using Windows XP in the Enterprise for any purpose other than findi= ng viruses is guilty of security malpractice at this point. It is an obsolet= e OS that would have been at EOL if lazy sysadmins hadn't begged to keep it.= > =20 >=20 > My current solution in my email project is to attempt to require SHA512 fo= r all certificates. But I am not sure that is actually sustainable. >=20 > --=20 > Website: http://hallambaker.com/ --Apple-Mail-A5398DB1-8179-404D-8D98-819960858EEC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

2 jan 2014 kl. 22:57 skrev Phillip Hallam-Baker <hallam@gmail.com>:

On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson <leifj@mnt.se> wrote:

2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker <hallam@gmail.com>:

> Please don't overstate the results of
> the excellent research that you did; doing so diminishes the
> research.

I'm not overstating anything. I think you don't understand what we
actually did if you think that later, patching things will somehow
magically stop previously successful attacks...

You are confusing people by using a valid attack against the algorithm to argue against the trust model. PKIX is designed on the assumption that the digest algorithm chosen is secure against a second preimage attack.

The fundamental flaw in the pkix trust model is that there is no deployable mechanism for limiting the impact of such an attack.

That realization should inform future design and that bit is certainly on topic ;-)

It is on topic but not limited to PKIX.

We have since learned that algorithm agility is not quite the security benefit we once thought as the security of the system is determined by the weakest algorithm you support, not the strongest one you implement.

A trust model based on shorter-time-to-live keys would have limited the impact too.

Problem is that I can't see a way to really control this type of attack without a very considerable cost in usability and I think it would constrain other defenses.

Anyone using Windows XP in the Enterprise for any purpose other than finding viruses is guilty of security malpractice at this point. It is an obsolete OS that would have been at EOL if lazy sysadmins hadn't begged to keep it.

My current solution in my email project is to attempt to require SHA512 for all certificates. But I am not sure that is actually sustainable.

--
Website: http://hallambaker.com/

--Apple-Mail-A5398DB1-8179-404D-8D98-819960858EEC-- From paul.hoffman@vpnc.org Thu Jan 2 14:50:49 2014 Return-Path: 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 8296F1ACC88 for ; Thu, 2 Jan 2014 14:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 gzHl5xHwvsEM for ; Thu, 2 Jan 2014 14:50:48 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5F01A8026 for ; Thu, 2 Jan 2014 14:50:48 -0800 (PST) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s02MocKi014717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Jan 2014 15:50:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host sn80.proper.com [75.101.18.80] claimed to be [165.227.249.247] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 $1827$) From: Paul Hoffman In-Reply-To: <52C5B67D.4050301@appelbaum.net> Date: Thu, 2 Jan 2014 14:50:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22429D73-4EFC-4091-8F5B-BAD38968EA54@taoeffect.com>

<52B88104.9040607@appelbaum.net> <52C2D54F.8000209@comodo.com> <52C45CDC.5020608@appelbaum.net> <96EF8E55-5860-4534-B370-83395C3985D4@vpnc.org> <52C5B67D.4050301@appelbaum.net> To: Jacob Appelbaum X-Mailer: Apple Mail (2.1827) Cc: therightkey@ietf.org Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 22:50:49 -0000 On Jan 2, 2014, at 10:57 AM, Jacob Appelbaum = wrote: > I control the private key for the rouge CA that we created. True. However, that rogue CA is not trusted in any root pile, right? You = holding a private key for a trusted CA was, appropriately a big deal. = You holding a private key for an untrusted CA is uninteresting. >> As you certainly know, that attack only >> applied to a very limited number of CAs in the root piles at the >> time. >=20 > I'm not sure where you came to this impression? By counting the number of CAs who used MD5 and had predictable serial = numbers. > There were a few CAs who > were vulnerable, we picked one to perform the research. It worked. = That > work produced a valid signature that we could apply to our second > certificate, which is a sub-CA certificate. Thus, the attack we did = only > applied to a single CA and we did not destroy the private key for the > corresponding certificate. So yes, we most certainly do have the = private > key for that intermediate certificate authority that we created. All true, but no longer relevant. >> I I remember correctly, it applied to zero of them >> approximately six months later. >=20 > Unless one explicitly distrusts (all) MD5 signed certificates, = pre-loads > our certificate to mark it as untrusted, or a few other things = relating > to time constraints - it will probably still work for MITM attacks. It sounds like you are saying that the contents of the issued = certificates don't need to be predictable for the collision to happen. = That would be absurd. Again, please don't overstate the value of your = demonstration. It was a very good thing because it got people to look = and *and fix* the problem. Can you point to a single CA in any of the = common trust stores that both use MD5 and issue certificates with less = than 2^64 bits of unpredictability? > Many > applications fail to do proper constraint checking. Which is just fine. It should be up to the people putting together the = trust pile to do the checking, not the relying parties. > I'm not overstating anything. We disagree. > I think you don't understand what we > actually did if you think that later, patching things will somehow > magically stop previously successful attacks... Ummm, where did I say anything about "patching"? I said that I believed = that there were no more CAs who were vulnerable, and asked you to show = where you thought there was. If you're right, then that's very valuable = information. I don't see any more in the trust piles that I look = through, but I could be missing something. --Paul Hoffman= From leifj@mnt.se Fri Jan 3 04:08:08 2014 Return-Path: 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 825681ADF95 for ; Fri, 3 Jan 2014 04:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7PJyk0dfqthI for ; Fri, 3 Jan 2014 04:08:04 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA451ADF91 for ; Fri, 3 Jan 2014 04:08:03 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id c11so8119600lbj.9 for ; Fri, 03 Jan 2014 04:07:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q/oBWuxJcL03NclLoI55zg1slQUDARfpBcndqZ4/Hhg=; b=C6RIgsD//ji1K3rdTZEf0T145h3Av/VhZiVBm4a3M12+F0d/AWzBS1O4vqY8734uir BO/elFcPgR213GcsE0xaZTvYg4m7Feuv6fHUpksUjabdMOl+5J+6SJswnYvFL89voezJ CsgwX9sEWpf02Az7JHm6M0YiQObEucXuXcYCP+03E4yFsCggsuQOszN3ZzHn/3lWd8y2 PRiX4WTXnWwg9mxlyGQoio1ZRSaSpFFMMj5IkqDp8BjjdRpW2Anx7DNdheDAcDP09FPQ VHLNbANjaxs4o//z2cY1HsbPij0ssIxNsVXYVvSB8d1TvNKxcLQBQRy6oQZL/BfKZKkN vX6w== X-Gm-Message-State: ALoCoQmAujdiA9SlpNoP2S5/1Xk4/qPoHHaH+oB505oBWoVBPBIhCjtvDOQShIZNKNrx3pb6Khsv X-Received: by 10.112.138.70 with SMTP id qo6mr20378777lbb.34.1388750876154; Fri, 03 Jan 2014 04:07:56 -0800 (PST) Received: from [10.0.0.155] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id bl6sm36409319lbb.5.2014.01.03.04.07.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jan 2014 04:07:55 -0800 (PST) Message-ID: <52C6A819.4040509@mnt.se> Date: Fri, 03 Jan 2014 13:07:53 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: therightkey@ietf.org References: <22429D73-4EFC-4091-8F5B-BAD38968EA54@taoeffect.com>

<52B88104.9040607@appelbaum.net> <52C2D54F.8000209@comodo.com> <52C45CDC.5020608@appelbaum.net> <96EF8E55-5860-4534-B370-83395C3985D4@vpnc.org> <52C5B67D.4050301@appelbaum.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 12:08:08 -0000 On 2014-01-02 23:50, Paul Hoffman wrote: > On Jan 2, 2014, at 10:57 AM, Jacob Appelbaum wrote: > >> I control the private key for the rouge CA that we created. > True. However, that rogue CA is not trusted in any root pile, right? You holding a private key for a trusted CA was, appropriately a big deal. You holding a private key for an untrusted CA is uninteresting. > My understanding of what Jakob wrote is that he holds the key for a subordinate CA. Unless the CA that "signed" that subordinate has been removed from trust lists then that subordinate would still be useful, yes. From holz@net.in.tum.de Fri Jan 3 05:24:20 2014 Return-Path: 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 A53E61ADFAF for ; Fri, 3 Jan 2014 05:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 NLsM2IFPZ7fe for ; Fri, 3 Jan 2014 05:24:19 -0800 (PST) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id C97E31ADFA9 for ; Fri, 3 Jan 2014 05:24:18 -0800 (PST) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 8D3A780900; Fri, 3 Jan 2014 14:24:10 +0100 (CET) Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 77B4080844 for ; Fri, 3 Jan 2014 14:24:09 +0100 (CET) Message-ID: <52C6B9F9.7010304@net.in.tum.de> Date: Fri, 03 Jan 2014 14:24:09 +0100 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: therightkey@ietf.org References: <22429D73-4EFC-4091-8F5B-BAD38968EA54@taoeffect.com>

<52B88104.9040607@appelbaum.net> <52C2D54F.8000209@comodo.com> <52C45CDC.5020608@appelbaum.net> <96EF8E55-5860-4534-B370-83395C3985D4@vpnc.org> <52C5B67D.4050301@appelbaum.net> <52C6A819.4040509@mnt.se> In-Reply-To: <52C6A819.4040509@mnt.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.8 at ex6 X-Virus-Status: Clean Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 13:24:20 -0000 Hi, > My understanding of what Jakob wrote is that he holds the key for a > subordinate CA. Unless the CA that "signed" that subordinate has > been removed from trust lists then that subordinate would still be > useful, yes. The subordinate certificate is blacklisted in browsers. Furthermore, Mozilla does not accept any non-root certs with MD5 signatures since mid-2011. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universit�t M�nchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From leifj@mnt.se Fri Jan 3 06:30:10 2014 Return-Path: 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 BAE9E1ADFB9 for ; Fri, 3 Jan 2014 06:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kZeTmmEnSK9p for ; Fri, 3 Jan 2014 06:30:09 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id 937661ADFBD for ; Fri, 3 Jan 2014 06:30:08 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id mc6so8024564lab.26 for ; Fri, 03 Jan 2014 06:30:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SFNfputpIU9tCsHXK2Eqos6d86WoQBAbpcC0j/PR57o=; b=iOlK34LuCqVG406YWSC8YlT4G3ERIIcmkJs/Qg7uQCn+gGMCuw5DMd5kSmPnBl03cV VBX0zd0vFcjF2gA0wdOSxhZxlT7ELsTfysyN0xnUQ70jRPtjBmcOLyVGJ2BMgaJn/luv 05d2yQwZIq7dDzKXagpsLPVdR/Keii6t+WzB5l2w6NUra/4901Et4yhwzFnYZFp5NwTf 5FeKSqKYIE/OwaruvHEbSybRqCnY98UM3L2H3yi9CiV129ouaICYUCIKqO6VlO5Srr+5 LmGHsxgdD8dAv8qs2DNjnEeESG3OktFC33vEmVX6yijAuxKyZvOK+OnEChTYRvh0+572 COOg== X-Gm-Message-State: ALoCoQlNgT/5A5EFiABFAjif6xTIkgvTQULvEXEPGL6Jilj+2szv74h4Yu7CAggfwRDkSrJMJT6r X-Received: by 10.152.4.74 with SMTP id i10mr634873lai.58.1388759400412; Fri, 03 Jan 2014 06:30:00 -0800 (PST) Received: from [10.0.0.155] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id j1sm36619581lbl.10.2014.01.03.06.29.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 Jan 2014 06:29:59 -0800 (PST) Message-ID: <52C6C966.3090606@mnt.se> Date: Fri, 03 Jan 2014 15:29:58 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: therightkey@ietf.org References: <22429D73-4EFC-4091-8F5B-BAD38968EA54@taoeffect.com>

<52B88104.9040607@appelbaum.net> <52C2D54F.8000209@comodo.com> <52C45CDC.5020608@appelbaum.net> <96EF8E55-5860-4534-B370-83395C3985D4@vpnc.org> <52C5B67D.4050301@appelbaum.net> <52C6A819.4040509@mnt.se> <52C6B9F9.7010304@net.in.tum.de> <52C6C966.3090606@mnt.se> In-Reply-To: <52C6C966.3090606@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 15:28:24 -0000 On 03/01/14 14:29, Leif Johansson wrote: > On 2014-01-03 14:24, Ralph Holz wrote: >> Hi, >> >>> My understanding of what Jakob wrote is that he holds the key for a >>> subordinate CA. Unless the CA that "signed" that subordinate has >>> been removed from trust lists then that subordinate would still be >>> useful, yes. >> The subordinate certificate is blacklisted in browsers. Furthermore, >> Mozilla does not accept any non-root certs with MD5 signatures since >> mid-2011. >> >> Ralph > > Assumes you run an updated browser, right? Yes. There's only so much we can do to protect folks who don't update their browsers. It seems very unlikely that MD5 signatures are the biggest threat that they face. > Blacklisting isn't part of the PKIX trust model, but a band-aid used to > fix the lack of deployed/able revocation. So? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From hallam@gmail.com Fri Jan 3 07:57:59 2014 Return-Path: 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 E3F181ADFD7 for ; Fri, 3 Jan 2014 07:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 4jgeLuJNW505 for ; Fri, 3 Jan 2014 07:57:58 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id C32CA1ADED6 for ; Fri, 3 Jan 2014 07:57:57 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id el20so8128390lab.37 for ; Fri, 03 Jan 2014 07:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=AiSGnc9PCMsIefm4B/CK733mUyCe0RhzSMnRA+q2o2o=; b=wiwh5tdhfR/X+ckUb/0KrAtEgQwjfNv9YrIZ23Icco/5kmi9kmYoAGZWYdy63Lksvw /AdrnfhgvQmrIkpIjGi3WW9MhKLIlgtSxUgRau5hft/5zCnrmQMZe1bc0+XX1Imf2ta0 rsl/eBODbqmJlkPrdkbTTDkNTzq56+/okyrm/Bg3cre273HyHHXXmlWwMla/vlVhE30+ d5paNUdU2fNeGzELFsMei8K/7aoEFiIQRZVVjC3mZuGcPsRm489/+cczl4QW73o6gXiL Aw0U08i+rzPA3ehohSCUlD6BsdAsjtB0W7SIaT/ooWKgTqmMKnX6mA0WhAZB1kF+N9Ny ztHg== MIME-Version: 1.0 X-Received: by 10.152.1.197 with SMTP id 5mr37030188lao.0.1388764669718; Fri, 03 Jan 2014 07:57:49 -0800 (PST) Received: by 10.112.37.172 with HTTP; Fri, 3 Jan 2014 07:57:49 -0800 (PST) Date: Fri, 3 Jan 2014 10:57:49 -0500 Message-ID: From: Phillip Hallam-Baker To: Rob Stradling Content-Type: multipart/alternative; boundary=089e0112bfced0b51304ef12f813 Cc: Leif Johansson , "therightkey@ietf.org" Subject: Re: [therightkey] DNSNMC Subject line is stupid X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 15:58:00 -0000 --089e0112bfced0b51304ef12f813 Content-Type: text/plain; charset=ISO-8859-1 Part of my trouble with this thread is that the original proposal was presented in the way it was. It might well be that there is a better way to do PKI than the approach Kohnfelder described in his master's thesis. But I don't think that the person who comes up with it will be describing the existing system as 'deprecated' before a single line of code is deployed. I am currently working on podcasts to describe my new approach to a general audience because getting any PKI deployed depends on buy in from people that are far outside this group and the IETF and even the techie community. We are not going to get change until we have real people appearing in Apple Stores and Microsoft stores asking how they can get usable secure email to protect them from [The russian mafia/ GRU/ Iran/ China/ NSA]. If Google had physical stores in malls, I would include them in that list. But we are not going to get people hassling for deployment until there is a scheme that is really right and not just 'good enough' for a group of highly motivated ideologues like ourselves. Part of the problem with PGP and S/MIME is that people just want it to work so much that they blind themselves to the obvious defects let alone the less obvious ones. The result looks like a Palm Treo, not an iPhone. You could use the Palm to surf the Web and send email and it kinda worked without crashing more than six times a day. But people at Palm never did understand why that was so much of a problem and they never made much of an effort to make the phone really right because web on your phone is so cool it doesn't really need to be perfect... right? When someone is so infatuated by their own idea that they describe it as 'deprecating' the existing system before they have even tried it in the real world then I don't think it is going to get very far. Anyway, I am thinking we should have international cryptography day sometime in early summer. Give some time to get code wrote. --089e0112bfced0b51304ef12f813 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Part of my trouble with this th= read is that the original proposal was presented in the way it was.

It mi= ght well be that there is a better way to do PKI than the approach Kohnfeld= er described in his master's thesis. But I don't think that the per= son who comes up with it will be describing the existing system as 'dep= recated' before a single line of code is deployed.

<= div class=3D"gmail_extra">I am currently working on podcasts to describe my= new approach to a general audience because getting any PKI deployed depend= s on buy in from people that are far outside this group and the IETF and ev= en the techie community.=A0

We are not = going to get change until we have real people appearing in Apple Stores and= Microsoft stores asking how they can get usable secure email to protect th= em from [The russian mafia/ GRU/ Iran/ China/ NSA]. If Google had physical = stores in malls, I would include them in that list.

<= div class=3D"gmail_extra">But we are not going to get people hassling for d= eployment until there is a scheme that is really right and not just 'go= od enough' for a group of highly motivated ideologues like ourselves.

Part of the= problem with PGP and S/MIME is that people just want it to work so much th= at they blind themselves to the obvious defects let alone the less obvious = ones. The result looks like a Palm Treo, not an iPhone. You could use the P= alm to surf the Web and send email and it kinda worked without crashing mor= e than six times a day. But people at Palm never did understand why that wa= s so much of a problem and they never made much of an effort to make the ph= one really right because web on your phone is so cool it doesn't really= need to be perfect... right?

When someon= e is so infatuated by their own idea that they describe it as 'deprecat= ing' the existing system before they have even tried it in the real wor= ld then I don't think it is going to get very far.

<= div class=3D"gmail_extra">Anyway, I am thinking we should have internationa= l cryptography day sometime in early summer. Give some time to get code wro= te.

I'm working getting said code up on = Github ASAP. The holidays and other things slowed me down a bit. It will = be put up under this github group soon (this month, I = expect/hope): https://github.com/okTurtles

--
Please do not email me anything that you are not comfortable also = sharing with the NSA.

On Jan 3, 2014, at 10:57 AM, Phillip Hallam-Baker <hallam@gmail.com> = wrote:

Part of my = trouble with this thread is that the original proposal was presented in = the way it was.

It = might well be that there is a better way to do PKI than the approach = Kohnfelder described in his master's thesis. But I don't think that the = person who comes up with it will be describing the existing system as = 'deprecated' before a single line of code is deployed.

I am = currently working on podcasts to describe my new approach to a general = audience because getting any PKI deployed depends on buy in from people = that are far outside this group and the IETF and even the techie = community.

We are = not going to get change until we have real people appearing in Apple = Stores and Microsoft stores asking how they can get usable secure email = to protect them from [The russian mafia/ GRU/ Iran/ China/ NSA]. If = Google had physical stores in malls, I would include them in that = list.

But we are = not going to get people hassling for deployment until there is a scheme = that is really right and not just 'good enough' for a group of highly = motivated ideologues like ourselves.

Part of = the problem with PGP and S/MIME is that people just want it to work so = much that they blind themselves to the obvious defects let alone the = less obvious ones. The result looks like a Palm Treo, not an iPhone. You = could use the Palm to surf the Web and send email and it kinda worked = without crashing more than six times a day. But people at Palm never did = understand why that was so much of a problem and they never made much of = an effort to make the phone really right because web on your phone is so = cool it doesn't really need to be perfect... right?

When = someone is so infatuated by their own idea that they describe it as = 'deprecating' the existing system before they have even tried it in the = real world then I don't think it is going to get very far.

Anyway, I am = thinking we should have international cryptography day sometime in early = summer. Give some time to get code wrote.

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

= --Apple-Mail=_91B0C499-1D93-4328-97D4-30FB9688A562-- --Apple-Mail=_CB4C78C4-0395-46DB-B584-9D9AB4F2E75A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSx50hAAoJEOxnICvpCVJHuIwP/jZXlGFRvrcKR2N6aVndEsKt R+fpgECHwAqbnhl+Tc8kKFd4PUZpzksTVgyUiUS0ah16UU+q+4GXm+pAvkZ4KZad 6/3Ai8D8C58M2kG4zQLNyqINB48SjbAzQnOM/onY8iON4TJ7EsANNfkBbUKMOAT/ eJ3d82f7cqHHpNcWjqKtz/1e7mPrgDmR+EVBLAUS7+BA1UCsiQQGqXzfGi6to643 25f3yiyPBt9GDW8l+//VSNYvKAOjycjLjzb+/t+1zD01iiXIv7YG1O4F4rH392Xy 3/9LHSuLj48YqqutGGt84NWqxrOKooBOR5Vqf/ewq1ke5APEmuLcv7+7KWDSLdaF kkXgyz60pD1bjvK1DsZqrzPQZKf5+y+AVeFGi8fs/qPVpcx1OBA1W4bd0SYY8LwR ZabWtPxJGcJm4/oYlqosvD9Liq1/KI0SOFTWmlLkW4pqhfDHPUdwEY/WP/zivvJX mRVn6RmsqLu9zwB0FlWkCMNkKBhybwCYhGRtQIHKl605lZAOc5PXhiMQ2Axgs0Iq 6Apm8MjgkV36JXShHVmygAjeNqHBERqz6gbXAri8Aim0KPc1E2Lg2y93CCHO5pJI 63EXCBCq6xvN5i4w0FjB++7nNqZjHcMH4T0XtVMpq4ixDqVjrbK40QQxdVaiPjPS oFai4ePB7955H5MkKYLN =nLGe -----END PGP SIGNATURE----- --Apple-Mail=_CB4C78C4-0395-46DB-B584-9D9AB4F2E75A-- From benl@google.com Tue Jan 7 07:46:33 2014 Return-Path: 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 B69221ADF96 for ; Tue, 7 Jan 2014 07:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 QDIHm04Ok-wI for ; Tue, 7 Jan 2014 07:46:31 -0800 (PST) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2021ADF33 for ; Tue, 7 Jan 2014 07:46:31 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id oz11so241863veb.35 for ; Tue, 07 Jan 2014 07:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OydM/+tV3N0duc3DLRqyVX0Hicmrwakx2gnRCeFoFJU=; b=R2XMOciRiX5p/U58mFdT6jDY3MA6PXCuHa5KPT5EHmb7/sTnCjO4H9oiwyxE17eETz bapwqMufsLDta/PfU3ByddhW0Ik3aMuOKoLyBC7eDzeL+1Xz+8cWn6b40+G3l8+tbYsq grzSHSWIYIYuLQwuUxbQmI2iIDR9ckeElWdTOMESrIqmZj0+RKerzyoXjGSC0Az04iZ8 spLpxtFI3rbTqELGhWzmA1mddzv6nhB4cdUOiwhOpcWDDP7exho/wNHfzWXEIlPA+ICA F9FwCFuKIkiKrf9/mhqA5Xx3hW68BFja+OHeCF5mVPBdQTf6WUOKi6I8ZONMFAyxFb+Q lrWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=OydM/+tV3N0duc3DLRqyVX0Hicmrwakx2gnRCeFoFJU=; b=ZVRez2rOdNVWvPjB0aQsasyrLJMHbKDrEapT9y7O0IXi7j2cMsFeM3UxT2+DlFYAor ART3/qqhrk3+4vQT+GGWsgNAZsBHEqtj/Y/1GuZS7e5H54u1ncIFHP6wj5+nHCINZGyu 2DP09ZgN8+/rwCS6VP1kBnpAgaZRafDw8WxpISG6C4HWfMzez4psT2fyaFSDiSZJnp0E lhNbWH8xUUFye3idcGDC+4lOwMZo3L6O97b9KMu1d4/xK/YVTGC6VLIRhKgckHhRzEzQ x/DdKsonUvRpULFsP8Whmk8WfzgoybBmG+HtOIEVd5YqvjGVJenqsuhCjvFSl5Ca4Dv8 P4Ng== X-Gm-Message-State: ALoCoQk8W7cJLsBqqoT/lWtKQagGedlWkalxJhomsxMfVf6L25BDIkjKayNZ+v8oiweGXi39mq7r6ZF2NfLstCSGYNLWe2RLyqyXFA1dYN0JZLX8ZyBe5yf5VJigpL+WNFr2i6i4IZiaRSjbDa4l6C27/F5qJ4Ij/t5Wulp2RhfShTjHnopPuZw53Zsph7DaoGmISwUEplce MIME-Version: 1.0 X-Received: by 10.58.118.36 with SMTP id kj4mr74832391veb.2.1389109581933; Tue, 07 Jan 2014 07:46:21 -0800 (PST) Received: by 10.52.169.202 with HTTP; Tue, 7 Jan 2014 07:46:21 -0800 (PST) In-Reply-To: References: Date: Tue, 7 Jan 2014 15:46:21 +0000 Message-ID: From: Ben Laurie To: "therightkey@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [therightkey] Fwd: A 2nd Google CT Log is available ("Aviator") X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 15:46:33 -0000 ---------- Forwarded message ---------- From: Al Cutter Date: 7 January 2014 15:31 Subject: A 2nd Google CT Log is available ("Aviator") To: certificate-transparency@googlegroups.com Hi all, we've been running a 2nd test CT log instance ("Aviator") for a little while now and are happy to open it up for you all to use. Like "Pilot", this log is also being periodically pre-loaded with certificates from the public internet. The new log's URL is: http[s]://ct.googleapis.com/aviator (e.g. https://ct.googleapis.com/aviator/ct/v1/get-sth) and its public key is: pub: 04:d7:f4:cc:69:b2:e4:0e:90:a3:8a:ea:5a:70:09: 4f:ef:13:62:d0:8d:49:60:ff:1b:40:50:07:0c:6d: 71:86:da:25:49:8d:65:e1:08:0d:47:34:6b:bd:27: bc:96:21:3e:34:f5:87:76:31:b1:7f:1d:c9:85:3b: 0d:f7:1f:3f:e9 ASN1 OID: prime256v1 -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1/TMabLkDpCjiupacAlP7xNi0I1J YP8bQFAHDG1xhtolSY1l4QgNRzRrvSe8liE+NPWHdjGxfx3JhTsN9x8/6Q== -----END PUBLIC KEY----- giving it a Log ID of: aPaY+B9kgr46jO65KB1M/HFRXWeT1ETRCmesu09P+8Q= We're still planning on turning up a 3rd log, and we'll send details about that as soon as we can. Cheers, Al on behalf of the CT team. -- You received this message because you are subscribed to the Google Groups "certificate-transparency" group. To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transparency+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From stephen.farrell@cs.tcd.ie Tue Jan 7 08:05:18 2014 Return-Path: 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 82CD11ADFDC for ; Tue, 7 Jan 2014 08:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 IUjagfGwRfKj for ; Tue, 7 Jan 2014 08:05:17 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC201ADFDA for ; Tue, 7 Jan 2014 08:05:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 30D18BE55; Tue, 7 Jan 2014 16:05:08 +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 WvndX0NyM2p1; Tue, 7 Jan 2014 16:05:06 +0000 (GMT) Received: from [10.87.48.14] (unknown [86.45.52.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C4D13BE53; Tue, 7 Jan 2014 16:05:06 +0000 (GMT) Message-ID: <52CC25B2.4080201@cs.tcd.ie> Date: Tue, 07 Jan 2014 16:05:06 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ben Laurie , "therightkey@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] Draft charter for a Transparency Working Group X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 16:05:18 -0000 Folks, The deadline for meeting session requests in London is coming up. What I propose to do is to request a placeholder-BoF session for this proposed WG. That doesn't mean there'll be a BoF. It means that if a WG has been formed in time then there'll be a WG session. If WG formation doesn't look to me like its happening (or if the IESG/IAB push back a lot) then I'll cancel the session and there'll be no transparency session in London. The call when that decision is made will be on about Jan 20. So, please get the WG stuff moving along soon now if you want to proceed. Ideally, that'd mean some drafts would exist as well as the draft WG charter, before that call on about Jan 20. But a good charter plus RFC 6962 might be enough. Thanks, S. On 12/11/2013 04:55 PM, Ben Laurie wrote: > Who's in? From benl@google.com Tue Jan 7 08:11:59 2014 Return-Path: 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 725531AE02F for ; Tue, 7 Jan 2014 08:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 wn7-dPA0IOt7 for ; Tue, 7 Jan 2014 08:11:57 -0800 (PST) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 683B61AE024 for ; Tue, 7 Jan 2014 08:11:57 -0800 (PST) Received: by mail-vb0-f53.google.com with SMTP id o19so245475vbm.26 for ; Tue, 07 Jan 2014 08:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1U1vvBKQoHtsg9jrIL1dgFM4TpsjXWD2GStsHAWc6Us=; b=USCo1caio5+JmEus5XIwzd9S7boMY1pBU2VydTI8WGa3QTqk06xzjwwJLV0pLlX4oN jVBuiRvWrIFERroWECq96wv2097/O2479Uu/heLksqPL5YH6dqOyXmTPoPc5uWezcDxR BQyZnftm/wc8iC98FyMXLcrTTqfeymj9lg8nuNyFvGKy3tHs5v0pGkoZPkYwdHkozB6F PUnUau+EV5cfWocKPOEUb6xjlnREu0xUVDynYXHPUuefcEfF6VvGOuhaEeHsyH0S1ymZ tih91oekWLwRulcJzyLUYjP9546k1Anefbqt1I2KqGzg9zSjVrfAy4U0ey9Iyip+sL8C bJmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1U1vvBKQoHtsg9jrIL1dgFM4TpsjXWD2GStsHAWc6Us=; b=RLotroJXnYfgBkd0fnS+Uy9zcZBc3VSDQjTMFrKsE4Q40fglon37SEw//ns45qDU0X KqJF+uw9XbhMyTktPKfP2osjXiFlWFfcXhaJz+ysSWSw009P2CMOLd4jmPOa2GTROBRm Notj5Adqo0S4SXCDmqi5Uk9bsPxqFoGGoM886aWFrCeA3Q26kD6XjbTKKBYuKbrI4EYx ZnCfjgmAdIZjTLJ/LItOokR2oUpMBAiQzpQr+fXWKbF0Xj8OsfXLq96ZJvcYf0S+PWxs 9TR1Zkv+EdeBkU2Gzpp7pfUHt4fVKqQJcM4y8X5qSjeTgM54T/Ya+PX2uBxHXtbH2+7O UeQA== X-Gm-Message-State: ALoCoQlrHufGAMqQw+3BKU2VReF2W18K494V+N1yJsCYHZ5gLXZIHKiD00AHIrE+L9O6GBMS4k2G45uTYXImoaj90ihWPb0S/+F4E5LX7BkAR4tGpehjoZZzdfBVEoxHS+aVPJhTrt8YgLBGybcP4C6Gu4tI/FHbPo6Vf8Q9jyPSXls+cJYMNwrmAlikxCxWkBC0S25lukZJ MIME-Version: 1.0 X-Received: by 10.58.100.65 with SMTP id ew1mr3612584veb.26.1389111108353; Tue, 07 Jan 2014 08:11:48 -0800 (PST) Received: by 10.52.169.202 with HTTP; Tue, 7 Jan 2014 08:11:48 -0800 (PST) In-Reply-To: <52CC25B2.4080201@cs.tcd.ie> References: <52CC25B2.4080201@cs.tcd.ie> Date: Tue, 7 Jan 2014 16:11:48 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Draft charter for a Transparency Working Group X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 16:11:59 -0000 On 7 January 2014 16:05, Stephen Farrell wrote: > > Folks, > > The deadline for meeting session requests in London is coming > up. > > What I propose to do is to request a placeholder-BoF session > for this proposed WG. That doesn't mean there'll be a BoF. > It means that if a WG has been formed in time then there'll > be a WG session. If WG formation doesn't look to me like > its happening (or if the IESG/IAB push back a lot) then I'll > cancel the session and there'll be no transparency session > in London. The call when that decision is made will be on > about Jan 20. > > So, please get the WG stuff moving along soon now if you > want to proceed. Ideally, that'd mean some drafts would > exist as well as the draft WG charter, before that call on > about Jan 20. But a good charter plus RFC 6962 might be > enough. I will post a revised charter to a new thread shortly. I believe it addresses all comments made so far (if it does not, its because I've managed to miss something over the holiday, so apologies in advance). > > Thanks, > S. > > > On 12/11/2013 04:55 PM, Ben Laurie wrote: >> Who's in? From benl@google.com Tue Jan 7 08:14:36 2014 Return-Path: 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 62D101ADFD9 for ; Tue, 7 Jan 2014 08:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 gOKE4hSvnTTe for ; Tue, 7 Jan 2014 08:14:33 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4429B1AE04B for ; Tue, 7 Jan 2014 08:14:33 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id db12so276619veb.22 for ; Tue, 07 Jan 2014 08:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=uS+wH4IHE15Kzkz6pMHV4+v5q6l9z4Mwm/ZNzR/u9O0=; b=ANjo7rD2HL6VO5uVV3saYRcYqoLipixui8Jh5OfLgQB4/rdpD0rOiSOkpGrM/3bbOn T5nUUawtiba8OjTWhw8iMyQWBtj3fuXf0YEzH5sg3LF00BtYUI6oGmrrl0u6bIvuIlt9 z/OPk3GZlb1LMSJLfIBo5mBYJk3OF+lB6DSjLN2LkwkuZONRFIZdQl/I1rQLZKYi8AfL s0p0DQrAFrlt+bUi7B28zCCTddpO63oR1VE2FIiNYFSyrD2Vvmy6TJ1C3CPObNp0q0zT u0nMkzavg+25jbBnWRO8NznRuz/lrRusosZHN5AOmG2NdRmAwcer07do+4xIRjzHXUsC vhWw== 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:content-transfer-encoding; bh=uS+wH4IHE15Kzkz6pMHV4+v5q6l9z4Mwm/ZNzR/u9O0=; b=e6GQP2Ca3kVUR6R+TJlSEc4lnYHoK1j4kc7kxZ8BEYHQ40exNe0VS3fnM53QdF1E2Z b7fMF8wQPatLPe3R0IRhgg7LlvgZ05f7hxV8SrBnfME+k9Z41akc8PKzNIyNpYX+UMul zFszHUV8BFKdSIsmI32lL8XH2in0UcPwdTEu5uq/RLNR/L3gzcwfazWh4SfkiTWHPvHR wNJzkxp73qITcc6E9YQe244iJVaUteWK7UAzJnPs283jJQBmtIhpSyv7Tip8XyEgOWGi skNuEhAGsxGYjBOxPHrDUQCCn6UvDRSV8PvpZ1ioVJkc1taZwysYye/NXBqEq1e9FoVB 5HGA== X-Gm-Message-State: ALoCoQndwTfNQkmMSJyI3Z/KYOeIGG81K9Lcr09Ga9tJxNOJlO6Z0Xo1SjwRC37r3yx+5vFRcrELFOyh9Tr+oON4eMs9UFKCFUTTWtdDwYw42BTKzT9CB7IiB4wot9Xa18zfQpnTY3pG0NpJ4ZL2YLtY4H4a6vAevZGyfTyjysqTXk8qE+7QnwZ530I04daW7N/OF0YHGHIY MIME-Version: 1.0 X-Received: by 10.58.248.198 with SMTP id yo6mr3298246vec.40.1389111264138; Tue, 07 Jan 2014 08:14:24 -0800 (PST) Received: by 10.52.169.202 with HTTP; Tue, 7 Jan 2014 08:14:24 -0800 (PST) Date: Tue, 7 Jan 2014 16:14:24 +0000 Message-ID: From: Ben Laurie To: "therightkey@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [therightkey] Revised Draft Charter for Transparency WG X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 16:14:36 -0000 Problem statement: many Internet protocols require a mapping between some kind of identifier and some kind of key, for example, HTTPS, SMTPS, IPSec, DNSSEC and OpenPGP. These protocols rely on either ad-hoc mappings, or on authorities which attest to the mappings. History shows that neither of these mechanisms is entirely satisfactory. Ad-hoc mappings are difficult to discover and maintain, and authorities make mistakes or are subverted. Cryptographically verifiable logs[1] can help to ameliorate the problems by making it possible to discover and rectify errors before they can cause harm. These logs can also assist with other interesting problems, such as how to assure end users that software they are running is, indeed, the software they intend to run. Work items: Specify a standards-track mechanism to apply verifiable logs to HTTP/TLS (i.e. RFC 6962-bis). Discuss mechanisms and techniques that allow cryptographically verifiable logs to be deployed to improve the security of protocols and software distribution. Where such mechanisms appear sufficiently useful, the WG will re-charter to add relevant new work items. [1] A cryptographically verifiable log is an append-only log of hashes of more-or-less anything that is structured in such a way as to provide efficiently-accessible, cryptographically-supported evidence of correct log behaviour. For example, from RFC 6962: =E2=80=9CThe append-only property of each log i= s technically achieved using Merkle Trees, which can be used to show that any particular version of the log is a superset of any particular previous version. Likewise, Merkle Trees avoid the need to blindly trust logs: if a log attempts to show different things to different people, this can be efficiently detected by comparing tree roots and consistency proofs. Similarly, other misbehaviors of any log (e.g., issuing signed timestamps for certificates they then don't log) can be efficiently detected and proved to the world at large.=E2=80=9D See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.1a= .pdf and http://www.links.org/files/RevocationTransparency.pdf for background. From benl@google.com Tue Jan 7 08:17:29 2014 Return-Path: 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 A99391AE02E for ; Tue, 7 Jan 2014 08:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 X-qohYwXLBVz for ; Tue, 7 Jan 2014 08:17:27 -0800 (PST) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7990C1AE037 for ; Tue, 7 Jan 2014 08:17:27 -0800 (PST) Received: by mail-ve0-f182.google.com with SMTP id jy13so279494veb.41 for ; Tue, 07 Jan 2014 08:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t3de3Bgj1qH8cgHeM+a8avsKxrfCn0fM/gDEQ7Gu69U=; b=dY1s0ljpmd3ulnBi5bcO4OLwqZrD0RlUizzjLOOE1JPXXfl61BWlayqi9b8M87RDvi jrWBWd2EqU1/udsUuLOLSvhRetrY5pYKuZi8BDyx73d8m4WHiJ02SkxRKIlaTThTWXOF +8wLPecKaXfYhHyM6Mv6MwUalO0QMZt+cwqvaKn+LDjSFjJJL2X+g0a2GU3J8lPxqh8C 4RGEdsDYCivJGAGHXb6vG1BrdxPCseKKz8fb+nXkmiTkNujbj6d8W4OLZqb0LkpZPUhg jkI96sYxOT4+o8jThMAfjEjNhvyPJrKNdNjpSmUGALAtS3roMEWUuv21BMEu0tihW+BC ul+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=t3de3Bgj1qH8cgHeM+a8avsKxrfCn0fM/gDEQ7Gu69U=; b=B3+eeFuv41brICVQ3Hf1kJVSZJT/QO3rIHBgsZPJ1JKXTUqWr5/Fjw5c7h4bIoZCnG viriqJ2PQIHd85GHyqXV4DRuyvYcOzvv7kruYz56a+UywRYmDKLBBdfFy+OzwkYHMsbq GADo3gji7FEUcv7V/ku8uIdhAfoAHsb9Ta/agcsipoGDbZV0pvcVsePzmTwgF6MjpAn2 qxRPvxNKGEIs+L28UjG9vvrxxwH80/R0F2xmi2g1jV5QjcPvLao3BaANtsGP9CPZv9um eSH8Tkh5R51sc+GTtMrAZxOqP8vUBMuTZ5KIrGq0PfmAzoDboHgJcJBDGXkHK0HZsY3Z QXuQ== X-Gm-Message-State: ALoCoQlHtDN/ZhzYqsXzeA7I8pq7KaNHWzcclasQ0+c8oONzLltYh8fKoJeGaWDb7kuRAsgZ6OAxR9gFj5yU5n3xIUB7Kqi/DTG7R9e6dzATfBzS6gtoz1UGq7BQN+SrqRhnfeSBibD4HQWnINRpLbl+Nj0cW2A+fhFLwM6E6Q9RiAeUtkGNWOcRf1mV5Ua9SwxguThPgERK MIME-Version: 1.0 X-Received: by 10.52.164.203 with SMTP id ys11mr2746613vdb.37.1389111438305; Tue, 07 Jan 2014 08:17:18 -0800 (PST) Received: by 10.52.169.202 with HTTP; Tue, 7 Jan 2014 08:17:18 -0800 (PST) In-Reply-To: <52CC25B2.4080201@cs.tcd.ie> References: <52CC25B2.4080201@cs.tcd.ie> Date: Tue, 7 Jan 2014 16:17:18 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Draft charter for a Transparency Working Group X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 16:17:29 -0000 On 7 January 2014 16:05, Stephen Farrell wrote: > > Folks, > > The deadline for meeting session requests in London is coming > up. > > What I propose to do is to request a placeholder-BoF session > for this proposed WG. That doesn't mean there'll be a BoF. > It means that if a WG has been formed in time then there'll > be a WG session. If WG formation doesn't look to me like > its happening (or if the IESG/IAB push back a lot) then I'll > cancel the session and there'll be no transparency session > in London. The call when that decision is made will be on > about Jan 20. > > So, please get the WG stuff moving along soon now if you > want to proceed. Ideally, that'd mean some drafts would > exist as well as the draft WG charter, before that call on > about Jan 20. But a good charter plus RFC 6962 might be > enough. Revised charter posted. I am travelling for most of now til Jan 20, so I doubt I'll have a a 6962bis draft, I'm afraid. But we are committed to producing one. There are no other work items currently proposed, hence no other drafts expected (unless someone has an alternate proposal). From stephen.farrell@cs.tcd.ie Tue Jan 7 08:21:46 2014 Return-Path: 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 A69991ADFA0 for ; Tue, 7 Jan 2014 08:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 3_BjZpAZ2wYn for ; Tue, 7 Jan 2014 08:21: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 4EC841ADF72 for ; Tue, 7 Jan 2014 08:21:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 18AA2BE56; Tue, 7 Jan 2014 16:21:36 +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 XKAYZ0v6z0Hj; Tue, 7 Jan 2014 16:21:34 +0000 (GMT) Received: from [10.87.48.14] (unknown [86.45.52.213]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 99492BE55; Tue, 7 Jan 2014 16:21:34 +0000 (GMT) Message-ID: <52CC298E.4050605@cs.tcd.ie> Date: Tue, 07 Jan 2014 16:21:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ben Laurie References: <52CC25B2.4080201@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Draft charter for a Transparency Working Group X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 16:21:46 -0000 On 01/07/2014 04:17 PM, Ben Laurie wrote: > On 7 January 2014 16:05, Stephen Farrell wrote: >> >> Folks, >> >> The deadline for meeting session requests in London is coming >> up. >> >> What I propose to do is to request a placeholder-BoF session >> for this proposed WG. That doesn't mean there'll be a BoF. >> It means that if a WG has been formed in time then there'll >> be a WG session. If WG formation doesn't look to me like >> its happening (or if the IESG/IAB push back a lot) then I'll >> cancel the session and there'll be no transparency session >> in London. The call when that decision is made will be on >> about Jan 20. >> >> So, please get the WG stuff moving along soon now if you >> want to proceed. Ideally, that'd mean some drafts would >> exist as well as the draft WG charter, before that call on >> about Jan 20. But a good charter plus RFC 6962 might be >> enough. > > Revised charter posted. I am travelling for most of now til Jan 20, so > I doubt I'll have a a 6962bis draft, I'm afraid. But we are committed > to producing one. > > There are no other work items currently proposed, hence no other > drafts expected (unless someone has an alternate proposal). Boy that was quick! As far as I can see this proposal does seem to have enough backing to start the WG formation process. What I'll do is kick that off with Ben's revised charter text say at the end of the week, so please comment on the "revised draft charter" thread if you've edits to that to propose. If you're opposed to the formation of such a WG or in favour but haven't previously said so, please do post to that same thread saying why. Thanks, S. > > From paul.hoffman@vpnc.org Tue Jan 7 08:35:30 2014 Return-Path: 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 4939D1ADFA0 for ; Tue, 7 Jan 2014 08:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 fhLCDrtwa6r2 for ; Tue, 7 Jan 2014 08:35:29 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 231D91ADF72 for ; Tue, 7 Jan 2014 08:35:29 -0800 (PST) Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s07GFMuC033297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jan 2014 09:15:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 $1827$) From: Paul Hoffman In-Reply-To: Date: Tue, 7 Jan 2014 08:35:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ben Laurie X-Mailer: Apple Mail (2.1827) Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Revised Draft Charter for Transparency WG X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 16:35:30 -0000 I support the formation of this WG with basically this charter. However, = having footnote in a charter make it harder to read. Having URLs that = are not somewhat guaranteed to be available forever (such as those run = by the IETF) make the charter unstable. A proposed editorial-only = cleanup: Problem statement: Many Internet protocols require a mapping between some kind of = identifier and some kind of key, for example, HTTPS, SMTPS, IPSec, DNSSEC and OpenPGP. These protocols rely on either ad-hoc mappings, or on authorities which = attest to the mappings. History shows that neither of these mechanisms is entirely satisfactory. = Ad-hoc mappings are difficult to discover and maintain, and authorities make mistakes or are = subverted. Cryptographically verifiable logs can help to ameliorate the problems by = making it possible to discover and rectify errors before they can cause harm. A = cryptographically verifiable log is an append-only log of hashes of more-or-less anything that is = structured in such a way as to provide efficiently-accessible, cryptographically-supported = evidence of correct log behaviour. For example, RFC 6962 says: "The append-only property of = each log is technically achieved using Merkle Trees, which can be used to show that = any particular version of the log is a superset of any particular previous version. = Likewise, Merkle Trees avoid the need to blindly trust logs: if a log attempts to show = different things to different people, this can be efficiently detected by comparing tree = roots and consistency proofs. Similarly, other misbehaviors of any log (e.g., issuing signed = timestamps for certificates they then don't log) can be efficiently detected and proved = to the world at large." These logs can also assist with other interesting problems, such as how = to assure end users that software they are running is, indeed, the software they intend to = run. Work items: - Publish an update to RFC 6962 as a standards-track mechanism to apply = verifiable logs to HTTP over TLS. - Discuss mechanisms and techniques that allow cryptographically = verifiable logs to be deployed to improve the security of protocols and software distribution. = Where such mechanisms appear sufficiently useful, the WG will re-charter to add = relevant new work items. From tim.moses@entrust.com Tue Jan 7 08:38:13 2014 Return-Path: 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 AFB211ADFFF for ; Tue, 7 Jan 2014 08:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 9kme7oDO4j_5 for ; Tue, 7 Jan 2014 08:38:11 -0800 (PST) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 816461ADFA0 for ; Tue, 7 Jan 2014 08:38:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,619,1384318800"; d="scan'208";a="1639642" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.224]) by ipedge1.entrust.com with ESMTP; 07 Jan 2014 11:38:00 -0500 Received: from SOTTEXCH11.corp.ad.entrust.com ([fe80::303b:8584:c6f4:be18]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.03.0123.003; Tue, 7 Jan 2014 11:37:59 -0500 From: Tim Moses To: Ben Laurie Thread-Topic: [therightkey] Revised Draft Charter for Transparency WG Thread-Index: AQHPC8Obgf4BDtDBOU6Dw0Co81lEw5p5dh6w Date: Tue, 7 Jan 2014 16:37:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Revised Draft Charter for Transparency WG X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 16:38:13 -0000 Hi Ben. Is it explained somewhere how it would be discovered that a log ha= d issued a time stamp for a certificate that it then did not log? According to my understanding, the time stamp would only be distributed wit= hin a certificate or OCSP response, and (therefore) its existence would not= necessarily be apparent to an auditor. Maybe I missed something. All the best. Tim. > On Jan 7, 2014, at 11:14 AM, "Ben Laurie" wrote: >=20 > Problem statement: many Internet protocols require a mapping between > some kind of identifier and some kind of key, for example, HTTPS, > SMTPS, IPSec, DNSSEC and OpenPGP. >=20 >=20 > These protocols rely on either ad-hoc mappings, or on authorities > which attest to the mappings. >=20 >=20 > History shows that neither of these mechanisms is entirely > satisfactory. Ad-hoc mappings are difficult to discover and maintain, > and authorities make mistakes or are subverted. >=20 >=20 > Cryptographically verifiable logs[1] can help to ameliorate the > problems by making it possible to discover and rectify errors before > they can cause harm. >=20 >=20 > These logs can also assist with other interesting problems, such as > how to assure end users that software they are running is, indeed, the > software they intend to run. >=20 >=20 > Work items: Specify a standards-track mechanism to apply verifiable > logs to HTTP/TLS (i.e. RFC 6962-bis). >=20 >=20 > Discuss mechanisms and techniques that allow cryptographically > verifiable logs to be deployed to improve the security of protocols > and software distribution. Where such mechanisms appear sufficiently > useful, the WG will re-charter to add relevant new work items. >=20 >=20 > [1] A cryptographically verifiable log is an append-only log of hashes > of more-or-less anything that is structured in such a way as to > provide efficiently-accessible, cryptographically-supported evidence > of correct log behaviour. >=20 >=20 > For example, from RFC 6962: =93The append-only property of each log is > technically achieved using Merkle Trees, which can be used to show > that any particular version of the log is a superset of any particular > previous version. Likewise, Merkle Trees avoid the need to blindly > trust logs: if a log attempts to show different things to different > people, this can be efficiently detected by comparing tree roots and > consistency proofs. Similarly, other misbehaviors of any log (e.g., > issuing signed timestamps for certificates they then don't log) can be > efficiently detected and proved to the world at large.=94 >=20 >=20 > See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.= 1a.pdf > and http://www.links.org/files/RevocationTransparency.pdf for > background. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From benl@google.com Tue Jan 7 08:51:52 2014 Return-Path: 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 925C21AE04E for ; Tue, 7 Jan 2014 08:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 ndz7Bs5OnIDw for ; Tue, 7 Jan 2014 08:51:51 -0800 (PST) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id C2AD61AE04D for ; Tue, 7 Jan 2014 08:51:50 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id g10so293275vbg.13 for ; Tue, 07 Jan 2014 08:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zp5FNZHHTupK76tuvls1ruY+7+jtULPpypGwnssQN60=; b=Vg+2WfoDxJtU+8xH7ssjt7/7Ns5Br9MwgL7tNh1w38uPssyo8j5QPEjf6nF4GP9lWi FTL0ZZTZ5Dok5vnP49+eaOsbXsmwd/HQGaRPHQIyhKy4V7N3WG8bwSliLLsYZYgWfWK2 Gbyjp0Z1wDfV1vdkP7Ozqtc1pP1skWk0m01dHSWaXcrXVJUteUKsD3xsQS6mYEhaaGE5 W6ITcZjCu/8KqazwzfPpx/QYQR8yvbQfuTNTQi7KlTzofPIZDAfWVytOZ9KEJIe3yPsf BKLFxixuXv7CvxCX3lbnMkraJA9X0AjxNxeTuXm1UdeG5IzloazEI/d+in1NhzNstL7v 4wXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zp5FNZHHTupK76tuvls1ruY+7+jtULPpypGwnssQN60=; b=BsNI7c6/zi75q/yj5KVyXUZeVcR/qRjsK7rAPETcJ/BlPhdfexFlP9hdfZBHAs0YDF SZnvvyC86xNJz9j4URESavijEVY8zmVwQd+GV2+DLEYWOqwtuYw2vgZ6W/KpiPWRZWKG TocBAh32Il+jIwgrOkvMZylRLZFkKA6DHwtvPhV2aFjdteH3CqtV87PGAlneLAAKYagp Fbb5kqJXHpTC+im1XVWqV0e11pk9oDfqismsUFXafEzVADb6QWp+O9CLiyM988I9KWhL CJUlWeo1YfiDtHu1cAMVc8k3ObmDqK4iDl/tUy6ODUu9Of90243SAU1Ankf8EbBMUcI8 K7EQ== X-Gm-Message-State: ALoCoQlh6gC+IWs8MXwYeIjfN9GQ8dg2V0ofBILMVY/QQ8AnS7bQ16ukwEmIUy90bFLNQSmp2A0hZNWTf3infxnNAEeCb+5jNxdYAitnICx/6sXEsoK1uTSRhCOZ6JCD1USFd7Ubny0Y7HK+74lR9TU3LVebXJCumAermkDUXCaqnlcs5qMg5oloOexV1NYdfEO3yzxY2JRN MIME-Version: 1.0 X-Received: by 10.58.85.133 with SMTP id h5mr9351235vez.4.1389113501553; Tue, 07 Jan 2014 08:51:41 -0800 (PST) Received: by 10.52.169.202 with HTTP; Tue, 7 Jan 2014 08:51:41 -0800 (PST) In-Reply-To: References:

Date: Tue, 7 Jan 2014 16:51:41 +0000 Message-ID: From: Ben Laurie To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Revised Draft Charter for Transparency WG X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 16:51:52 -0000 On 7 January 2014 16:35, Paul Hoffman wrote: > I support the formation of this WG with basically this charter. However, = having footnote in a charter make it harder to read. Having URLs that are n= ot somewhat guaranteed to be available forever (such as those run by the IE= TF) make the charter unstable. A proposed editorial-only cleanup: > > Problem statement: > > Many Internet protocols require a mapping between some kind of identifier= and some kind of > key, for example, HTTPS, SMTPS, IPSec, DNSSEC and OpenPGP. > > These protocols rely on either ad-hoc mappings, or on authorities which a= ttest to the > mappings. > > History shows that neither of these mechanisms is entirely satisfactory. = Ad-hoc mappings are > difficult to discover and maintain, and authorities make mistakes or are = subverted. > > Cryptographically verifiable logs can help to ameliorate the problems by = making it possible > to discover and rectify errors before they can cause harm. A cryptographi= cally verifiable > log is an append-only log of hashes of more-or-less anything that is str= uctured in such a > way as to provide efficiently-accessible, cryptographically-supported evi= dence of correct > log behaviour. For example, RFC 6962 says: "The append-only property of e= ach log is > technically achieved using Merkle Trees, which can be used to show that a= ny particular > version of the log is a superset of any particular previous version. Like= wise, Merkle Trees > avoid the need to blindly trust logs: if a log attempts to show different= things to > different people, this can be efficiently detected by comparing tree root= s and consistency > proofs. Similarly, other misbehaviors of any log (e.g., issuing signed ti= mestamps for > certificates they then don't log) can be efficiently detected and proved = to the world at > large." > > These logs can also assist with other interesting problems, such as how t= o assure end users > that software they are running is, indeed, the software they intend to ru= n. > > Work items: > > - Publish an update to RFC 6962 as a standards-track mechanism to apply v= erifiable logs to > HTTP over TLS. > > - Discuss mechanisms and techniques that allow cryptographically verifiab= le logs to be > deployed to improve the security of protocols and software distribution. = Where such > mechanisms appear sufficiently useful, the WG will re-charter to add rele= vant new work items. OK with me. Thanks. From benl@google.com Tue Jan 7 09:07:59 2014 Return-Path: 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 282F91ADFFF for ; Tue, 7 Jan 2014 09:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 GbSw-kG-ouaU for ; Tue, 7 Jan 2014 09:07:57 -0800 (PST) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 654D31AE006 for ; Tue, 7 Jan 2014 09:07:57 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id 11so304053vbe.24 for ; Tue, 07 Jan 2014 09:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=b6H6ZufNZcqn4/OdzPQnpuApBcyDP3KT81FYwLxZXgs=; b=Ys0CvPB3hTyJRtE6g8/tN5LEiuD8HqVqDylo/TfiVfz6iAFguFP9vunbd/kgwMzb5+ KFW7hZf+FwUtxJBZUvbFZFOf886L7uMBQUEz9uwK4rnGIQK/m9KpJKeBDu9+17oEYAvk j6Z3sMEYFJJSb6FWEYXgcvmvP2kiJv+Mp1bskPs1FBBbKUMx0R8XKmjoqz+JQ3wIRsvv 9P/WFavl3XUUXe0isscBigxhTIcLARGwP962NtInUzvXYaRV6ajuRmCexwQxpzE6N4mv b/+3pV8xMhtyfl1DSVqltlXmSx83ZykRmfNtiAfh40UpQNwTG36LnUO1p9Do7hpswaBT 7S0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b6H6ZufNZcqn4/OdzPQnpuApBcyDP3KT81FYwLxZXgs=; b=XEcOAaZAbwtRRB+STVnifNHSKx2efbqpItCokMJ254eKihmfyrzWgOxuAbYc8pQzPW XLSkz+p3XabH0nwBTXlpjUBXGJWWW7MHdIGnLBBgItoWW9KgUqxinjZyrMWP2Wa5F/QN 3tuyJUJe0ZJdmPgcfAexpKQQ6CQWXKNWlxLjymH3ftG/6YoB/UgL+dipY52dCoprMfl3 xqe/zi9eS+jyaJbbsB4U/T543acFgoBmWGIFzigXa2g1GGhEkc5qodgIwrUUGtPOOXKP acIqXFMmoPc2KbPLHiaKeLfQnz5HyMzXT81JvnflRB3in9zST3VDSwkkigd5UsWXywMO F46Q== X-Gm-Message-State: ALoCoQngO5Gj4OXm8Drr7XyVm3JwtzXOHz0ZzFcEfJUz+ZNDHthuDO3CNZj3Lm+E2pvHrDby+n6WN4LzCmcid/OmlBryDcfyPSGKvaWJuGBMwchT04bsQeaIS4ffgPnJYDz17cQFwItf6uwyiO2IAdwvPDqC7aTrKxy3fLPwRB3OEx551V55dXAE7pB92NygFDBnarxpDtit MIME-Version: 1.0 X-Received: by 10.53.8.1 with SMTP id dg1mr3057852vdd.52.1389114468137; Tue, 07 Jan 2014 09:07:48 -0800 (PST) Received: by 10.52.169.202 with HTTP; Tue, 7 Jan 2014 09:07:48 -0800 (PST) In-Reply-To: References:

Date: Tue, 7 Jan 2014 17:07:48 +0000 Message-ID: From: Ben Laurie To: Tim Moses Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Revised Draft Charter for Transparency WG X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 17:07:59 -0000 On 7 January 2014 16:37, Tim Moses wrote: > Hi Ben. Is it explained somewhere how it would be discovered that a log = had issued a time stamp for a certificate that it then did not log? RFC 6962, Section 5.4 "Auditor". > According to my understanding, the time stamp would only be distributed w= ithin a certificate or OCSP response, and (therefore) its existence would n= ot necessarily be apparent to an auditor. If no-one ever sees the certificate, then whether an SCT was issued or not is unimportant. This is why recipients of certificates need to at least audit the certificates they see. In the RFC "auditor" is a role that may be incorporated in other things. From the RFC: "An auditor might be an integral component of a TLS client". There may be a better way of explaining this. Possibly something to this effect should've been added to 5.2. I've added an issue (https://code.google.com/p/certificate-transparency/issues/d= etail?id=3D25). > Maybe I missed something. > > All the best. Tim. > >> On Jan 7, 2014, at 11:14 AM, "Ben Laurie" wrote: >> >> Problem statement: many Internet protocols require a mapping between >> some kind of identifier and some kind of key, for example, HTTPS, >> SMTPS, IPSec, DNSSEC and OpenPGP. >> >> >> These protocols rely on either ad-hoc mappings, or on authorities >> which attest to the mappings. >> >> >> History shows that neither of these mechanisms is entirely >> satisfactory. Ad-hoc mappings are difficult to discover and maintain, >> and authorities make mistakes or are subverted. >> >> >> Cryptographically verifiable logs[1] can help to ameliorate the >> problems by making it possible to discover and rectify errors before >> they can cause harm. >> >> >> These logs can also assist with other interesting problems, such as >> how to assure end users that software they are running is, indeed, the >> software they intend to run. >> >> >> Work items: Specify a standards-track mechanism to apply verifiable >> logs to HTTP/TLS (i.e. RFC 6962-bis). >> >> >> Discuss mechanisms and techniques that allow cryptographically >> verifiable logs to be deployed to improve the security of protocols >> and software distribution. Where such mechanisms appear sufficiently >> useful, the WG will re-charter to add relevant new work items. >> >> >> [1] A cryptographically verifiable log is an append-only log of hashes >> of more-or-less anything that is structured in such a way as to >> provide efficiently-accessible, cryptographically-supported evidence >> of correct log behaviour. >> >> >> For example, from RFC 6962: =E2=80=9CThe append-only property of each lo= g is >> technically achieved using Merkle Trees, which can be used to show >> that any particular version of the log is a superset of any particular >> previous version. Likewise, Merkle Trees avoid the need to blindly >> trust logs: if a log attempts to show different things to different >> people, this can be efficiently detected by comparing tree roots and >> consistency proofs. Similarly, other misbehaviors of any log (e.g., >> issuing signed timestamps for certificates they then don't log) can be >> efficiently detected and proved to the world at large.=E2=80=9D >> >> >> See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2= .1a.pdf >> and http://www.links.org/files/RevocationTransparency.pdf for >> background. >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey From tim.moses@entrust.com Tue Jan 7 09:27:08 2014 Return-Path: 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 51AE61AE085 for ; Tue, 7 Jan 2014 09:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 VmR55G26nmHJ for ; Tue, 7 Jan 2014 09:27:06 -0800 (PST) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id C4BD11ADF4B for ; Tue, 7 Jan 2014 09:27:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,619,1384318800"; d="scan'208";a="7774271" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP; 07 Jan 2014 12:26:56 -0500 Received: from SOTTEXCH11.corp.ad.entrust.com ([fe80::303b:8584:c6f4:be18]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.03.0123.003; Tue, 7 Jan 2014 12:26:57 -0500 From: Tim Moses To: Ben Laurie Thread-Topic: [therightkey] Revised Draft Charter for Transparency WG Thread-Index: AQHPC8Obgf4BDtDBOU6Dw0Co81lEw5p5dh6wgABcJwD//7GGmg== Date: Tue, 7 Jan 2014 17:26:55 +0000 Message-ID: <6E6E4126-34A4-4633-A253-0996646FF5A5@entrust.com> References:

, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Revised Draft Charter for Transparency WG X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 17:27:08 -0000 Ok. But that's at least one additional round trip, right? Is it more realistic to say that the protocol fails if ALL of the CA and ev= ery timestamp relied upon is untrustworthy? All the best. Tim. > On Jan 7, 2014, at 12:07 PM, "Ben Laurie" wrote: >=20 >> On 7 January 2014 16:37, Tim Moses wrote: >> Hi Ben. Is it explained somewhere how it would be discovered that a log= had issued a time stamp for a certificate that it then did not log? >=20 > RFC 6962, Section 5.4 "Auditor". >=20 >> According to my understanding, the time stamp would only be distributed = within a certificate or OCSP response, and (therefore) its existence would = not necessarily be apparent to an auditor. >=20 > If no-one ever sees the certificate, then whether an SCT was issued or > not is unimportant. This is why recipients of certificates need to at > least audit the certificates they see. >=20 > In the RFC "auditor" is a role that may be incorporated in other > things. From the RFC: "An auditor might be an integral component of a > TLS client". >=20 > There may be a better way of explaining this. >=20 > Possibly something to this effect should've been added to 5.2. I've > added an issue (https://code.google.com/p/certificate-transparency/issues= /detail?id=3D25). >=20 >> Maybe I missed something. >>=20 >> All the best. Tim. >>=20 >>> On Jan 7, 2014, at 11:14 AM, "Ben Laurie" wrote: >>>=20 >>> Problem statement: many Internet protocols require a mapping between >>> some kind of identifier and some kind of key, for example, HTTPS, >>> SMTPS, IPSec, DNSSEC and OpenPGP. >>>=20 >>>=20 >>> These protocols rely on either ad-hoc mappings, or on authorities >>> which attest to the mappings. >>>=20 >>>=20 >>> History shows that neither of these mechanisms is entirely >>> satisfactory. Ad-hoc mappings are difficult to discover and maintain, >>> and authorities make mistakes or are subverted. >>>=20 >>>=20 >>> Cryptographically verifiable logs[1] can help to ameliorate the >>> problems by making it possible to discover and rectify errors before >>> they can cause harm. >>>=20 >>>=20 >>> These logs can also assist with other interesting problems, such as >>> how to assure end users that software they are running is, indeed, the >>> software they intend to run. >>>=20 >>>=20 >>> Work items: Specify a standards-track mechanism to apply verifiable >>> logs to HTTP/TLS (i.e. RFC 6962-bis). >>>=20 >>>=20 >>> Discuss mechanisms and techniques that allow cryptographically >>> verifiable logs to be deployed to improve the security of protocols >>> and software distribution. Where such mechanisms appear sufficiently >>> useful, the WG will re-charter to add relevant new work items. >>>=20 >>>=20 >>> [1] A cryptographically verifiable log is an append-only log of hashes >>> of more-or-less anything that is structured in such a way as to >>> provide efficiently-accessible, cryptographically-supported evidence >>> of correct log behaviour. >>>=20 >>>=20 >>> For example, from RFC 6962: =93The append-only property of each log is >>> technically achieved using Merkle Trees, which can be used to show >>> that any particular version of the log is a superset of any particular >>> previous version. Likewise, Merkle Trees avoid the need to blindly >>> trust logs: if a log attempts to show different things to different >>> people, this can be efficiently detected by comparing tree roots and >>> consistency proofs. Similarly, other misbehaviors of any log (e.g., >>> issuing signed timestamps for certificates they then don't log) can be >>> efficiently detected and proved to the world at large.=94 >>>=20 >>>=20 >>> See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion= 2.1a.pdf >>> and http://www.links.org/files/RevocationTransparency.pdf for >>> background. >>> _______________________________________________ >>> therightkey mailing list >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/listinfo/therightkey From benl@google.com Tue Jan 7 09:40:57 2014 Return-Path: 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 29AC21AE04B for ; Tue, 7 Jan 2014 09:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 M0CEdTAZbaHt for ; Tue, 7 Jan 2014 09:40:54 -0800 (PST) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 64AC21AE075 for ; Tue, 7 Jan 2014 09:40:54 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id w18so345258vbj.37 for ; Tue, 07 Jan 2014 09:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oHw0CLlnacDsitD71ZbDB7bWZmIGcsP4brmV6XiQFW4=; b=hXwvGMlJaKjayW/950NX7EMM7JojQDiZuHkXbASYAp2ZxK6W3DCirR26NTM+H88iRt Sgp7PJCVX/SZ45Q6mjY/JdZFhcwSzPsu9VnaWvzeO1+HAXSNsgwRZwOqGzxwncGQHJFu nU3QttvuQarSggb6uSdcC+0rdsTvsfzE+e0a/M9RE2+t4lV1B4Jjh6np6WyGOaapCfse Y51wFp8oJ2WLbBYB0jQ9+5USKgBWIMJe7x0j9lLj8huYGlqX3EuQPR5PbGFaVZHI+Erq 9N6qRYTiNqmTULwwtnynyc/BRH0nv56AKvbFzSRsjTpDN6biS1xL+JfTGmoNSPjRV1R/ KlvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oHw0CLlnacDsitD71ZbDB7bWZmIGcsP4brmV6XiQFW4=; b=luUmdxAjyg77EYChqAfOrOEFh3lJHsuc53RdC/sAHM6ajoa7/NOrivb2O91VXYMfLq 0jkpKLZtKqPEpnhFw6OONuSTZzBGZqKaRBjV9CN6eEn2fsxM79kYWn30qv1rMR7VxLTY K+PpwGml3x/ibDZbo3NVl1CPgLYTpm1G64Mo7vxt14oFIHt+DrLTG0TgGMhcZ/5MJ4uX IjPjqWwdlhwRv0VuKzNtdPjpHlRXGzr71LRnBEbXt9ZLMkTefa90vcsWc8LgwGf6URmB /6+/7ZffokGE0fKgZAwb+NRWBIDglPq57SnhJcJgTT7bZFynPpDfo1vakSqiJ/3QfQPN /oqQ== X-Gm-Message-State: ALoCoQnQEbrC6elWzgEA7pMpJdGdagpZsWTSG7/iMAqbLxBMkeCan63MoSKGZ7KE3IfQi4HrmCCRNka/5wHPe2nQ/jsBpPjBevFqt5ujrCYb35BFattoUcNpslYEARnL4IcdlXW+Jh2SJSGtdjJ39TVBfaBzOcjjTd1CRTP0E4L0h1YnLmFiHSmYH2FfSr7L9Y+UfQHiMZtk MIME-Version: 1.0 X-Received: by 10.58.118.36 with SMTP id kj4mr75948716veb.2.1389116445212; Tue, 07 Jan 2014 09:40:45 -0800 (PST) Received: by 10.52.169.202 with HTTP; Tue, 7 Jan 2014 09:40:45 -0800 (PST) In-Reply-To: <6E6E4126-34A4-4633-A253-0996646FF5A5@entrust.com> References:

<6E6E4126-34A4-4633-A253-0996646FF5A5@entrust.com> Date: Tue, 7 Jan 2014 17:40:45 +0000 Message-ID: From: Ben Laurie To: Tim Moses Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Revised Draft Charter for Transparency WG X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 17:40:57 -0000 On 7 January 2014 17:26, Tim Moses wrote: > Ok. But that's at least one additional round trip, right? It does not need to be done before accepting the certificate. CT is designed around responsiveness at the cost of finding out bad things happened a little late. But this seems like an acceptable trade-off, since a log still can only misbehave once (or for a short period of time), which makes the cost of doing so very high. > Is it more realistic to say that the protocol fails if ALL of the CA and = every timestamp relied upon is untrustworthy? I'm not sure what you mean by this, but perhaps the above makes it irreleva= nt? > > All the best. Tim. > > >> On Jan 7, 2014, at 12:07 PM, "Ben Laurie" wrote: >> >>> On 7 January 2014 16:37, Tim Moses wrote: >>> Hi Ben. Is it explained somewhere how it would be discovered that a lo= g had issued a time stamp for a certificate that it then did not log? >> >> RFC 6962, Section 5.4 "Auditor". >> >>> According to my understanding, the time stamp would only be distributed= within a certificate or OCSP response, and (therefore) its existence would= not necessarily be apparent to an auditor. >> >> If no-one ever sees the certificate, then whether an SCT was issued or >> not is unimportant. This is why recipients of certificates need to at >> least audit the certificates they see. >> >> In the RFC "auditor" is a role that may be incorporated in other >> things. From the RFC: "An auditor might be an integral component of a >> TLS client". >> >> There may be a better way of explaining this. >> >> Possibly something to this effect should've been added to 5.2. I've >> added an issue (https://code.google.com/p/certificate-transparency/issue= s/detail?id=3D25). >> >>> Maybe I missed something. >>> >>> All the best. Tim. >>> >>>> On Jan 7, 2014, at 11:14 AM, "Ben Laurie" wrote: >>>> >>>> Problem statement: many Internet protocols require a mapping between >>>> some kind of identifier and some kind of key, for example, HTTPS, >>>> SMTPS, IPSec, DNSSEC and OpenPGP. >>>> >>>> >>>> These protocols rely on either ad-hoc mappings, or on authorities >>>> which attest to the mappings. >>>> >>>> >>>> History shows that neither of these mechanisms is entirely >>>> satisfactory. Ad-hoc mappings are difficult to discover and maintain, >>>> and authorities make mistakes or are subverted. >>>> >>>> >>>> Cryptographically verifiable logs[1] can help to ameliorate the >>>> problems by making it possible to discover and rectify errors before >>>> they can cause harm. >>>> >>>> >>>> These logs can also assist with other interesting problems, such as >>>> how to assure end users that software they are running is, indeed, the >>>> software they intend to run. >>>> >>>> >>>> Work items: Specify a standards-track mechanism to apply verifiable >>>> logs to HTTP/TLS (i.e. RFC 6962-bis). >>>> >>>> >>>> Discuss mechanisms and techniques that allow cryptographically >>>> verifiable logs to be deployed to improve the security of protocols >>>> and software distribution. Where such mechanisms appear sufficiently >>>> useful, the WG will re-charter to add relevant new work items. >>>> >>>> >>>> [1] A cryptographically verifiable log is an append-only log of hashes >>>> of more-or-less anything that is structured in such a way as to >>>> provide efficiently-accessible, cryptographically-supported evidence >>>> of correct log behaviour. >>>> >>>> >>>> For example, from RFC 6962: =E2=80=9CThe append-only property of each = log is >>>> technically achieved using Merkle Trees, which can be used to show >>>> that any particular version of the log is a superset of any particular >>>> previous version. Likewise, Merkle Trees avoid the need to blindly >>>> trust logs: if a log attempts to show different things to different >>>> people, this can be efficiently detected by comparing tree roots and >>>> consistency proofs. Similarly, other misbehaviors of any log (e.g., >>>> issuing signed timestamps for certificates they then don't log) can be >>>> efficiently detected and proved to the world at large.=E2=80=9D >>>> >>>> >>>> See RFC 6962, http://www.links.org/files/CertificateTransparencyVersio= n2.1a.pdf >>>> and http://www.links.org/files/RevocationTransparency.pdf for >>>> background. >>>> _______________________________________________ >>>> therightkey mailing list >>>> therightkey@ietf.org >>>> https://www.ietf.org/mailman/listinfo/therightkey From tim.moses@entrust.com Tue Jan 7 10:04:52 2014 Return-Path: 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 0F68D1AE0EE for ; Tue, 7 Jan 2014 10:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 NKyp_t38R7vt for ; Tue, 7 Jan 2014 10:04:50 -0800 (PST) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id CED0F1AE0EA for ; Tue, 7 Jan 2014 10:04:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.95,620,1384318800"; d="scan'208";a="7774704" Received: from unknown (HELO sottexchcas.corp.ad.entrust.com) ([10.4.51.224]) by ipedge2.entrust.com with ESMTP; 07 Jan 2014 13:04:40 -0500 Received: from SOTTEXCH11.corp.ad.entrust.com ([fe80::303b:8584:c6f4:be18]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.03.0123.003; Tue, 7 Jan 2014 13:04:39 -0500 From: Tim Moses To: Ben Laurie Thread-Topic: [therightkey] Revised Draft Charter for Transparency WG Thread-Index: AQHPC8Obgf4BDtDBOU6Dw0Co81lEw5p5dh6wgABcJwD//7GGmoAAV6+A//+y22w= Date: Tue, 7 Jan 2014 18:04:39 +0000 Message-ID: References:

<6E6E4126-34A4-4633-A253-0996646FF5A5@entrust.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Revised Draft Charter for Transparency WG X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 18:04:52 -0000 I see. It seems unfortunate that reliance on one or more time stamps is not= sufficient, but that the client also has to consult the log. All the best. Tim. > On Jan 7, 2014, at 12:40 PM, "Ben Laurie" wrote: >=20 >> On 7 January 2014 17:26, Tim Moses wrote: >> Ok. But that's at least one additional round trip, right? >=20 > It does not need to be done before accepting the certificate. CT is > designed around responsiveness at the cost of finding out bad things > happened a little late. But this seems like an acceptable trade-off, > since a log still can only misbehave once (or for a short period of > time), which makes the cost of doing so very high. >=20 >> Is it more realistic to say that the protocol fails if ALL of the CA and= every timestamp relied upon is untrustworthy? >=20 > I'm not sure what you mean by this, but perhaps the above makes it irrele= vant? >=20 >>=20 >> All the best. Tim. >>=20 >>=20 >>>> On Jan 7, 2014, at 12:07 PM, "Ben Laurie" wrote: >>>>=20 >>>> On 7 January 2014 16:37, Tim Moses wrote: >>>> Hi Ben. Is it explained somewhere how it would be discovered that a l= og had issued a time stamp for a certificate that it then did not log? >>>=20 >>> RFC 6962, Section 5.4 "Auditor". >>>=20 >>>> According to my understanding, the time stamp would only be distribute= d within a certificate or OCSP response, and (therefore) its existence woul= d not necessarily be apparent to an auditor. >>>=20 >>> If no-one ever sees the certificate, then whether an SCT was issued or >>> not is unimportant. This is why recipients of certificates need to at >>> least audit the certificates they see. >>>=20 >>> In the RFC "auditor" is a role that may be incorporated in other >>> things. From the RFC: "An auditor might be an integral component of a >>> TLS client". >>>=20 >>> There may be a better way of explaining this. >>>=20 >>> Possibly something to this effect should've been added to 5.2. I've >>> added an issue (https://code.google.com/p/certificate-transparency/issu= es/detail?id=3D25). >>>=20 >>>> Maybe I missed something. >>>>=20 >>>> All the best. Tim. >>>>=20 >>>>> On Jan 7, 2014, at 11:14 AM, "Ben Laurie" wrote: >>>>>=20 >>>>> Problem statement: many Internet protocols require a mapping between >>>>> some kind of identifier and some kind of key, for example, HTTPS, >>>>> SMTPS, IPSec, DNSSEC and OpenPGP. >>>>>=20 >>>>>=20 >>>>> These protocols rely on either ad-hoc mappings, or on authorities >>>>> which attest to the mappings. >>>>>=20 >>>>>=20 >>>>> History shows that neither of these mechanisms is entirely >>>>> satisfactory. Ad-hoc mappings are difficult to discover and maintain, >>>>> and authorities make mistakes or are subverted. >>>>>=20 >>>>>=20 >>>>> Cryptographically verifiable logs[1] can help to ameliorate the >>>>> problems by making it possible to discover and rectify errors before >>>>> they can cause harm. >>>>>=20 >>>>>=20 >>>>> These logs can also assist with other interesting problems, such as >>>>> how to assure end users that software they are running is, indeed, th= e >>>>> software they intend to run. >>>>>=20 >>>>>=20 >>>>> Work items: Specify a standards-track mechanism to apply verifiable >>>>> logs to HTTP/TLS (i.e. RFC 6962-bis). >>>>>=20 >>>>>=20 >>>>> Discuss mechanisms and techniques that allow cryptographically >>>>> verifiable logs to be deployed to improve the security of protocols >>>>> and software distribution. Where such mechanisms appear sufficiently >>>>> useful, the WG will re-charter to add relevant new work items. >>>>>=20 >>>>>=20 >>>>> [1] A cryptographically verifiable log is an append-only log of hashe= s >>>>> of more-or-less anything that is structured in such a way as to >>>>> provide efficiently-accessible, cryptographically-supported evidence >>>>> of correct log behaviour. >>>>>=20 >>>>>=20 >>>>> For example, from RFC 6962: =93The append-only property of each log i= s >>>>> technically achieved using Merkle Trees, which can be used to show >>>>> that any particular version of the log is a superset of any particula= r >>>>> previous version. Likewise, Merkle Trees avoid the need to blindly >>>>> trust logs: if a log attempts to show different things to different >>>>> people, this can be efficiently detected by comparing tree roots and >>>>> consistency proofs. Similarly, other misbehaviors of any log (e.g., >>>>> issuing signed timestamps for certificates they then don't log) can b= e >>>>> efficiently detected and proved to the world at large.=94 >>>>>=20 >>>>>=20 >>>>> See RFC 6962, http://www.links.org/files/CertificateTransparencyVersi= on2.1a.pdf >>>>> and http://www.links.org/files/RevocationTransparency.pdf for >>>>> background. >>>>> _______________________________________________ >>>>> therightkey mailing list >>>>> therightkey@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/therightkey From benl@google.com Tue Jan 7 10:08:51 2014 Return-Path: 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 EB5C31AE0C6 for ; Tue, 7 Jan 2014 10:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 2utxtLowazJU for ; Tue, 7 Jan 2014 10:08:43 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 119261AE0F3 for ; Tue, 7 Jan 2014 10:08:42 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pa12so410297veb.19 for ; Tue, 07 Jan 2014 10:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5SruhkLVFWrV95a4AVdJH2WpdYjBsWD9f/1gfx4Cnwc=; b=ZT3tPttQ8ZqUIqxLDguGEr8pOKiWFH8s/qzukfg9MGJGwrQkN3UVHPiQ35QqlI5VVn FTaY0r2OpeOJGLdyb4qT/IM2JkMvJaatXbwotTb+58N0ZOFvCo3PFUGUXYGqli/5st1q MJ+anv29p7FKxM0uARqNUKo9+2oVskDbnoiehAKs9okHEnWcl1BOrK7Bgydmarw+8zbN jP1UMyEEJVD1ZH0zlHkia5B7+RbN9spcR8pM4l8AcxL//dcswRM38ciJPEh7ZLQR2c2N mv0bDFVa5V9zMSeO/TnNPEa9DX3K4IO+/dQgtf7RyDuz3Q01sZdl7jh7tEkhqcns8nZk KyVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5SruhkLVFWrV95a4AVdJH2WpdYjBsWD9f/1gfx4Cnwc=; b=a59nLSX9/wJsbhULYulrI2R4HbV4r15c1he4TR16i2l/9b6sMjd+7QL+KvGUoFF5Ai qgcwBleQwTMXr+QJlQU2Arz5vaDDc/Ge2OOi84H6oFjMr4q5/60WiHvWv9VagN4KkVhV XO++JQ/98chlYBQ5vU0YgyrNmjqAcY4nKaEhCoVznyoQ1QaNGHxoHTKViMTwq6dNKVx7 8Oj1G3/qxlcv0bBgbGBGmLig4Pb40Y53xdp+S8D/VuMeuAixzyBrn6WchqYus/YPcGj9 /8PQkFKdRfVfAhrxD2rpvJkhUryIkhrfQAXy7uAgfIyTYBYKSC+aDVPVt8IcGhnhPn86 vB2A== X-Gm-Message-State: ALoCoQlnNd1U9u8V2sSc1OfVBCH7V003F5FZ8sEVs0t7BmcGANKQso028XtgXn80xitPCkf+yM5+imgnlTn0sX46s8ZpE0BWKmLXzZV1BLbXnStUMkW0669CYqFeUHwiNO2RFAl0CiEdHXpZnU5f8pFyvlcl2nzVa6LPxdSyMnLExEsv/pd8UcRpS9zXQnlIKOnQvmTXgZNp MIME-Version: 1.0 X-Received: by 10.52.160.38 with SMTP id xh6mr3608954vdb.39.1389118113901; Tue, 07 Jan 2014 10:08:33 -0800 (PST) Received: by 10.52.169.202 with HTTP; Tue, 7 Jan 2014 10:08:33 -0800 (PST) In-Reply-To: References:

<6E6E4126-34A4-4633-A253-0996646FF5A5@entrust.com>

Date: Tue, 7 Jan 2014 18:08:33 +0000 Message-ID: From: Ben Laurie To: Tim Moses Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Revised Draft Charter for Transparency WG X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 18:08:51 -0000 On 7 January 2014 18:04, Tim Moses wrote: > I see. It seems unfortunate that reliance on one or more time stamps is n= ot sufficient, but that the client also has to consult the log. The client audits the log, which is a different thing. To make a TLS connection, the timestamps are sufficient. > > All the best. Tim. > >> On Jan 7, 2014, at 12:40 PM, "Ben Laurie" wrote: >> >>> On 7 January 2014 17:26, Tim Moses wrote: >>> Ok. But that's at least one additional round trip, right? >> >> It does not need to be done before accepting the certificate. CT is >> designed around responsiveness at the cost of finding out bad things >> happened a little late. But this seems like an acceptable trade-off, >> since a log still can only misbehave once (or for a short period of >> time), which makes the cost of doing so very high. >> >>> Is it more realistic to say that the protocol fails if ALL of the CA an= d every timestamp relied upon is untrustworthy? >> >> I'm not sure what you mean by this, but perhaps the above makes it irrel= evant? >> >>> >>> All the best. Tim. >>> >>> >>>>> On Jan 7, 2014, at 12:07 PM, "Ben Laurie" wrote: >>>>> >>>>> On 7 January 2014 16:37, Tim Moses wrote: >>>>> Hi Ben. Is it explained somewhere how it would be discovered that a = log had issued a time stamp for a certificate that it then did not log? >>>> >>>> RFC 6962, Section 5.4 "Auditor". >>>> >>>>> According to my understanding, the time stamp would only be distribut= ed within a certificate or OCSP response, and (therefore) its existence wou= ld not necessarily be apparent to an auditor. >>>> >>>> If no-one ever sees the certificate, then whether an SCT was issued or >>>> not is unimportant. This is why recipients of certificates need to at >>>> least audit the certificates they see. >>>> >>>> In the RFC "auditor" is a role that may be incorporated in other >>>> things. From the RFC: "An auditor might be an integral component of a >>>> TLS client". >>>> >>>> There may be a better way of explaining this. >>>> >>>> Possibly something to this effect should've been added to 5.2. I've >>>> added an issue (https://code.google.com/p/certificate-transparency/iss= ues/detail?id=3D25). >>>> >>>>> Maybe I missed something. >>>>> >>>>> All the best. Tim. >>>>> >>>>>> On Jan 7, 2014, at 11:14 AM, "Ben Laurie" wrote: >>>>>> >>>>>> Problem statement: many Internet protocols require a mapping between >>>>>> some kind of identifier and some kind of key, for example, HTTPS, >>>>>> SMTPS, IPSec, DNSSEC and OpenPGP. >>>>>> >>>>>> >>>>>> These protocols rely on either ad-hoc mappings, or on authorities >>>>>> which attest to the mappings. >>>>>> >>>>>> >>>>>> History shows that neither of these mechanisms is entirely >>>>>> satisfactory. Ad-hoc mappings are difficult to discover and maintain= , >>>>>> and authorities make mistakes or are subverted. >>>>>> >>>>>> >>>>>> Cryptographically verifiable logs[1] can help to ameliorate the >>>>>> problems by making it possible to discover and rectify errors before >>>>>> they can cause harm. >>>>>> >>>>>> >>>>>> These logs can also assist with other interesting problems, such as >>>>>> how to assure end users that software they are running is, indeed, t= he >>>>>> software they intend to run. >>>>>> >>>>>> >>>>>> Work items: Specify a standards-track mechanism to apply verifiable >>>>>> logs to HTTP/TLS (i.e. RFC 6962-bis). >>>>>> >>>>>> >>>>>> Discuss mechanisms and techniques that allow cryptographically >>>>>> verifiable logs to be deployed to improve the security of protocols >>>>>> and software distribution. Where such mechanisms appear sufficiently >>>>>> useful, the WG will re-charter to add relevant new work items. >>>>>> >>>>>> >>>>>> [1] A cryptographically verifiable log is an append-only log of hash= es >>>>>> of more-or-less anything that is structured in such a way as to >>>>>> provide efficiently-accessible, cryptographically-supported evidence >>>>>> of correct log behaviour. >>>>>> >>>>>> >>>>>> For example, from RFC 6962: =E2=80=9CThe append-only property of eac= h log is >>>>>> technically achieved using Merkle Trees, which can be used to show >>>>>> that any particular version of the log is a superset of any particul= ar >>>>>> previous version. Likewise, Merkle Trees avoid the need to blindly >>>>>> trust logs: if a log attempts to show different things to different >>>>>> people, this can be efficiently detected by comparing tree roots and >>>>>> consistency proofs. Similarly, other misbehaviors of any log (e.g., >>>>>> issuing signed timestamps for certificates they then don't log) can = be >>>>>> efficiently detected and proved to the world at large.=E2=80=9D >>>>>> >>>>>> >>>>>> See RFC 6962, http://www.links.org/files/CertificateTransparencyVers= ion2.1a.pdf >>>>>> and http://www.links.org/files/RevocationTransparency.pdf for >>>>>> background. >>>>>> _______________________________________________ >>>>>> therightkey mailing list >>>>>> therightkey@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/therightkey From benl@google.com Wed Jan 8 10:30:26 2014 Return-Path: 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 9AB461AE066 for ; Wed, 8 Jan 2014 10:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 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, RP_MATCHES_RCVD=-0.538, 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 odfacT4WKt64 for ; Wed, 8 Jan 2014 10:30:24 -0800 (PST) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 642031AE06C for ; Wed, 8 Jan 2014 10:30:24 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id w20so1431770vbb.19 for ; Wed, 08 Jan 2014 10:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=2SWBvBc0aO7Q6dUPm/r4NOGRm+HpZEsEBQ6pfr4WPUc=; b=ENYRwVg41FxFsrKB4Noa//VWAE3V5s2MVrQKyFoEYTMInZEeEje68L2R7+Vq3SKUV9 9MTdw6bYbuqLo62auZuuYGXZtVNKDkCRoPUwJ8KmcLWJka/kGD1t2JqPbL05CSUFDTsO R+sTs3aiVqk9Zn4rqUa0Z4x7ZQCNGiZ1DxAUDq9nOkNfN7AZwIFFISk16PxC5IQUhrHS yEQMxLyYV8Brq/eKS3At8lU5iQfXD1pkpguRbm3xY75asjdl7li8sv6c+uFIWxakQ1z+ a3vVQ7zBfhki30F5EvUdkHynJ+dC2fce8E17E4TzUhuupJ+a3+hZ7h1akaEPyxFaVzBC kzzg== 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:cc :content-type; bh=2SWBvBc0aO7Q6dUPm/r4NOGRm+HpZEsEBQ6pfr4WPUc=; b=ONMfQ8ung0Vg2WKfp1sbBDduj08lzu6CnYnveBLQ5rHpRiCDTboQf1pa87WrX7FRrU aXwK9FFFTnzsRs+Nm7j8KzcX7fBaAl14PaRefSI9vf0sBZFnpvykw2G/+7SRJV1WTJLL 4ffVb+vOAsuwNUqOnJYnOnKVMaakn6NL6SQA18eutIRYFYcozpPEsMtlp1Q+egaomiVI vdeuqrWz71KD3IqzFUw+Avm8n3v7sxpwx2/PZjGaVFCV2co9WZTbuOMdQ54yGUnh0D6q c4cI5zpE6XkYiu8qOm/lPr2DET0CGeabT+r3fyxlXwgWdTiVtKhYEpgrqYh2b5UDezHW Gb1A== X-Gm-Message-State: ALoCoQmIezJ9xmnbWS5w3HzxI/58LH38VyddTnaqZ+BCInJqejC4UUWQ8IE4aGfH+AP9ppzVl/dTC9qWMQeWXEpJalCeMzjsnJoOW/R9Zq9InwqMpgQe+WdjXM6IiEhhqDBv670+gs/Kj0SHaA/FveDBigLByKJ8EVSUQn/arteUNzPWW1LlK/nH4n6JSVEiX74h5dhOeupX MIME-Version: 1.0 X-Received: by 10.58.211.130 with SMTP id nc2mr9953843vec.7.1389205814794; Wed, 08 Jan 2014 10:30:14 -0800 (PST) Received: by 10.52.169.202 with HTTP; Wed, 8 Jan 2014 10:30:14 -0800 (PST) Date: Wed, 8 Jan 2014 18:30:14 +0000 Message-ID: From: Ben Laurie To: Ralph Holz Content-Type: text/plain; charset=UTF-8 Cc: "therightkey@ietf.org" , Seth David Schoen Subject: [therightkey] RA vs CA X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 18:30:26 -0000 On 27 December 2013 10:06, Ralph Holz wrote: > Hi, > > [The EFF's count] > >>> You can't calculate the number of CAs the way the EFF tried to. An >>> intermediate certificate does not equate to a CA. Pretending it does to >>> peddle an alternative PKI scheme calls into question their veracity. >>> >> >> I disagree strongly. I have an intermediate certificate. I am as >> powerful CA as a result. >> Please also see these estimates which are even higher: >> >> https://zakird.com/slides/durumeric-https-imc13.pdf >> >> "Identified 1,832 CA certificates belonging to 683 organizations" >> "311 (45%) of the organizations were provided certificates by >> German National Research and Education Network (DFN) " > > I was there at IMC and spoke with Zakir. He was not aware of the fact > that the private keys to all the intermediate certificates are held by > the central DFN Verein, not the RAs themselves. In the case of DFN, the > intermediate certs only identify the RAs. The RAs do not carry signing > power. What is the function of an RA, then, if not to tell a CA "sign this"? From jeremy.rowley@digicert.com Wed Jan 8 10:34:01 2014 Return-Path: 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 EC5E31AE073 for ; Wed, 8 Jan 2014 10:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.84 X-Spam-Level: X-Spam-Status: No, score=-4.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 WsQxpHkMFdx5 for ; Wed, 8 Jan 2014 10:33:58 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id E0DEF1ADBD7 for ; Wed, 8 Jan 2014 10:33:58 -0800 (PST) Received: from JROWLEYL1 (unknown [67.137.52.8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 7B2628FA055; Wed, 8 Jan 2014 11:33:49 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1389206029; bh=RdkJjnjtZqdJYAMHujGJqMpfJzdSQJD2j7KgU+KhO48=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=Apn7fizKbRZmF/rEjwaEccnoQvy6eDEB09YEbDgfmHEuxX/4fsCgXWeFS6f1g1/Bj rfJE6I+q/uTYZbq7gMCVGWtJY6Zzw1fLb8G0RZJiRd14GniCTyi7Gu+4LxlAIswsjT rh/J9OLsOmFzkDH1P0FML6iLO7MLx3vhnTmlFoko= From: "Jeremy Rowley" To: "'Ben Laurie'" , "'Ralph Holz'" References: In-Reply-To: Date: Wed, 8 Jan 2014 11:33:49 -0700 Message-ID: <011b01cf0ca0$2d258cd0$8770a670$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFuuk0rOt0bp7TcLsgVMFXzk0y/EZs7ywpQ Content-Language: en-us Cc: therightkey@ietf.org, 'Seth David Schoen' Subject: Re: [therightkey] RA vs CA X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 18:34:01 -0000 The role of the RA varies a lot depending on the CA and industry. For example, some CAs use RAs only to collect face to face documentation (similar to a notary). The CA will still do a record check, verify the identity, etc. The existence of an RA does not necessarily mean the CA is signing whatever is put in front of it. The only way to know the scope of the RA function is to ask the CA. Jeremy -----Original Message----- From: therightkey [mailto:therightkey-bounces@ietf.org] On Behalf Of Ben Laurie Sent: Wednesday, January 08, 2014 11:30 AM To: Ralph Holz Cc: therightkey@ietf.org; Seth David Schoen Subject: [therightkey] RA vs CA On 27 December 2013 10:06, Ralph Holz wrote: > Hi, > > [The EFF's count] > >>> You can't calculate the number of CAs the way the EFF tried to. An >>> intermediate certificate does not equate to a CA. Pretending it does >>> to peddle an alternative PKI scheme calls into question their veracity. >>> >> >> I disagree strongly. I have an intermediate certificate. I am as >> powerful CA as a result. >> Please also see these estimates which are even higher: >> >> https://zakird.com/slides/durumeric-https-imc13.pdf >> >> "Identified 1,832 CA certificates belonging to 683 organizations" >> "311 (45%) of the organizations were provided certificates by German >> National Research and Education Network (DFN) " > > I was there at IMC and spoke with Zakir. He was not aware of the fact > that the private keys to all the intermediate certificates are held by > the central DFN Verein, not the RAs themselves. In the case of DFN, > the intermediate certs only identify the RAs. The RAs do not carry > signing power. What is the function of an RA, then, if not to tell a CA "sign this"? _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey From jeremy.rowley@digicert.com Wed Jan 8 10:38:34 2014 Return-Path: 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 AA4061AE0AE for ; Wed, 8 Jan 2014 10:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.84 X-Spam-Level: X-Spam-Status: No, score=-4.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 YpmQt6H3MZIz for ; Wed, 8 Jan 2014 10:38:32 -0800 (PST) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 81F931AE085 for ; Wed, 8 Jan 2014 10:38:32 -0800 (PST) Received: from JROWLEYL1 (unknown [67.137.52.8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 42EA41AE0E2; Wed, 8 Jan 2014 11:38:23 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1389206303; bh=S69G/64c+Qc5AiAt4H3210oAd0eZr2oYzJsIEfAPNb4=; h=From:To:Cc:References:In-Reply-To:Subject:Date; b=PK5wHij5X/+VT3tKhwAPC7kdidhm/g2flCqANcOfiycD5HDVHJsPF/JO2zTgK3Tuv LtF28McBppOb/AGo/xBoIlYRLnuSarAEur2v1P54Z9URrFGBkAGx0nHHiiGmyKQoOj hfkTqgsNOJ156zqaII4j9nfqa/lCivz+j3kgBy1U= From: "Jeremy Rowley" To: "'Ben Laurie'" , "'Ralph Holz'" References: <011b01cf0ca0$2d258cd0$8770a670$@digicert.com> In-Reply-To: <011b01cf0ca0$2d258cd0$8770a670$@digicert.com> Date: Wed, 8 Jan 2014 11:38:23 -0700 Message-ID: <013a01cf0ca0$d0533b50$70f9b1f0$@digicert.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFuuk0rOt0bp7TcLsgVMFXzk0y/EQEmAuz8mzKb7iA= Content-Language: en-us Cc: therightkey@ietf.org, 'Seth David Schoen' Subject: Re: [therightkey] RA vs CA X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 18:38:34 -0000 To add some clarification on why the EFF probably over-counted: We create intermediate certificates all the time for customers, typically for access control or to minimize the potential impact of the intermediate's revocation. However, the intermediate stays within our PKI and is subject to our verification process and control. This doesn't make it a separate issuer. The RA tells us who is authorized to get a certificate off that intermediate, but they don't dictate the validation or issuance process. Again (and unfortunately), the scope of control over an intermediate varies widely depending on the CA. Jeremy -----Original Message----- From: therightkey [mailto:therightkey-bounces@ietf.org] On Behalf Of Jeremy Rowley Sent: Wednesday, January 08, 2014 11:34 AM To: 'Ben Laurie'; 'Ralph Holz' Cc: therightkey@ietf.org; 'Seth David Schoen' Subject: Re: [therightkey] RA vs CA The role of the RA varies a lot depending on the CA and industry. For example, some CAs use RAs only to collect face to face documentation (similar to a notary). The CA will still do a record check, verify the identity, etc. The existence of an RA does not necessarily mean the CA is signing whatever is put in front of it. The only way to know the scope of the RA function is to ask the CA. Jeremy -----Original Message----- From: therightkey [mailto:therightkey-bounces@ietf.org] On Behalf Of Ben Laurie Sent: Wednesday, January 08, 2014 11:30 AM To: Ralph Holz Cc: therightkey@ietf.org; Seth David Schoen Subject: [therightkey] RA vs CA On 27 December 2013 10:06, Ralph Holz wrote: > Hi, > > [The EFF's count] > >>> You can't calculate the number of CAs the way the EFF tried to. An >>> intermediate certificate does not equate to a CA. Pretending it does >>> to peddle an alternative PKI scheme calls into question their veracity. >>> >> >> I disagree strongly. I have an intermediate certificate. I am as >> powerful CA as a result. >> Please also see these estimates which are even higher: >> >> https://zakird.com/slides/durumeric-https-imc13.pdf >> >> "Identified 1,832 CA certificates belonging to 683 organizations" >> "311 (45%) of the organizations were provided certificates by German >> National Research and Education Network (DFN) " > > I was there at IMC and spoke with Zakir. He was not aware of the fact > that the private keys to all the intermediate certificates are held by > the central DFN Verein, not the RAs themselves. In the case of DFN, > the intermediate certs only identify the RAs. The RAs do not carry > signing power. What is the function of an RA, then, if not to tell a CA "sign this"? _______________________________________________ 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 holz@net.in.tum.de Wed Jan 8 10:48:47 2014 Return-Path: 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 DE7DC1AE076 for ; Wed, 8 Jan 2014 10:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 VBNdjZ0CaYgC for ; Wed, 8 Jan 2014 10:48:45 -0800 (PST) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id F13521AE0B6 for ; Wed, 8 Jan 2014 10:48:44 -0800 (PST) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 7F26C80746; Wed, 8 Jan 2014 19:48:33 +0100 (CET) Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 93514806EA; Wed, 8 Jan 2014 19:48:32 +0100 (CET) Message-ID: <52CD9D80.3000604@net.in.tum.de> Date: Wed, 08 Jan 2014 19:48:32 +0100 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: therightkey@ietf.org, benl@google.com References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97.8 at ex6 X-Virus-Status: Clean Subject: Re: [therightkey] RA vs CA X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 18:48:48 -0000 Hi, >> I was there at IMC and spoke with Zakir. He was not aware of the fact >> that the private keys to all the intermediate certificates are held by >> the central DFN Verein, not the RAs themselves. In the case of DFN, the >> intermediate certs only identify the RAs. The RAs do not carry signing >> power. > > What is the function of an RA, then, if not to tell a CA "sign this"? I'll add the following in addition to what Jeremy said: the term RA is used with different meanings by CAs. E.g. during the Comodo incident in 2011 (the one by Comodohacker), it became clear that the RA had access credentials stored that allowed it to trigger certification by the CA. This was really what others might call a reseller or possibly a subordinate CA. In the case of DFN, it is different. The RAs are 1) identifiers in intermediate certs and 2) carry out paperwork. I request a server cert by creating a CSR in DFN's online interface, but I send a paper form to the local RA who will then contact me to verify that I am indeed a TUM employee with control over the server (and in case of S/MIME, see my passport). There does not seem to be an automated trigger from the RA that causes certification; rather it seems to be a delegation of certain duties. The whole thing is specified here: https://www.pki.dfn.de/fileadmin/PKI/Konzept_DFN-PKI.pdf Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From hallam@gmail.com Wed Jan 8 11:29:26 2014 Return-Path: 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 A7E3B1AE114 for ; Wed, 8 Jan 2014 11:29:26 -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 DeXi_Gtt3y59 for ; Wed, 8 Jan 2014 11:29:24 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 21DEC1ADFCB for ; Wed, 8 Jan 2014 11:29:20 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id q8so1617672lbi.36 for ; Wed, 08 Jan 2014 11:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DlDTYMnGxBEL4amb4qd0AEha0vIsZ3eF6WlK+o9G7h8=; b=Z+PCQQZHOIBWimjLGjsRh68cOHL5XNfyCrWpVxzqjBPDMiIyN9WdExtc1FCTxmYA99 uXL5kiUtSoLS5s9v1w3PrdS+wQVn2AVVWL1hh7CnxG7/4TpzDY9Jqjr2o3pqZIJWbaqt NPN2ELObkdxZsDzlF3i4f1UtbkTsJh1pTZ4kkAdYqtwsi1NeXHx+6MMP7A6YG8AByVaO T+vL+CLNynzypiWhpUv389qPm7gVjQRQzUzxhlNibYiciJUl6FoaitL1fziNe39mbCnY W8mtzgDq19f2bPxU+9MwNeBwa3+gv+tC6zMsPFE8uv34veUMScB2V+egnxO1BPe4O5VA 73zg== MIME-Version: 1.0 X-Received: by 10.152.1.197 with SMTP id 5mr50469219lao.0.1389209351092; Wed, 08 Jan 2014 11:29:11 -0800 (PST) Received: by 10.112.37.172 with HTTP; Wed, 8 Jan 2014 11:29:11 -0800 (PST) In-Reply-To: References: Date: Wed, 8 Jan 2014 14:29:11 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=089e0112bfcee400d904ef7a81e1 Cc: Ralph Holz , "therightkey@ietf.org" , Seth David Schoen Subject: Re: [therightkey] RA vs CA X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 19:29:26 -0000 --089e0112bfcee400d904ef7a81e1 Content-Type: text/plain; charset=ISO-8859-1 There is a problem here with the conventional nomenclature. The term CA can mean the legal entity or the machine in control of the private key. As with the original RSA paper that asserted Alice is a Turing machine, this is a problem. The EFF study conflates the term RA with issue under an intermediate certificate, the two are completely separate. There are plenty of examples of an RA that issues directly under the CA root and there are plenty of examples where a CA manages an intermediate root directly. The best definition of the RA function is that the RA is responsible for authorizing issue of certificates. But authorization from the RA is only a necessary condition, it is not necessarily sufficient. In the WebPKI an affiliate or enterprise customer may run an RA, but the CA is now required to perform certain validation functions directly. Since you probably don't want to have the validation taking place in the room with the private key the logical arrangement is again a RA. On Wed, Jan 8, 2014 at 1:30 PM, Ben Laurie wrote: > On 27 December 2013 10:06, Ralph Holz wrote: > > Hi, > > > > [The EFF's count] > > > >>> You can't calculate the number of CAs the way the EFF tried to. An > >>> intermediate certificate does not equate to a CA. Pretending it does to > >>> peddle an alternative PKI scheme calls into question their veracity. > >>> > >> > >> I disagree strongly. I have an intermediate certificate. I am as > >> powerful CA as a result. > >> Please also see these estimates which are even higher: > >> > >> https://zakird.com/slides/durumeric-https-imc13.pdf > >> > >> "Identified 1,832 CA certificates belonging to 683 organizations" > >> "311 (45%) of the organizations were provided certificates by > >> German National Research and Education Network (DFN) " > > > > I was there at IMC and spoke with Zakir. He was not aware of the fact > > that the private keys to all the intermediate certificates are held by > > the central DFN Verein, not the RAs themselves. In the case of DFN, the > > intermediate certs only identify the RAs. The RAs do not carry signing > > power. > > What is the function of an RA, then, if not to tell a CA "sign this"? > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --089e0112bfcee400d904ef7a81e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

There is a problem here with the conventional nomenclature= .

The term CA can mean the legal entity or the machine i= n control of the private key. As with the original RSA paper that asserted = Alice is a Turing machine, this is a problem.

The EFF study conflates the term RA with issue under an= intermediate certificate, the two are completely separate. There are plent= y of examples of an RA that issues directly under the CA root and there are= plenty of examples where a CA manages an intermediate root directly.

The best definition of the RA function i= s that the RA is responsible for authorizing issue of certificates. But aut= horization from the RA is only a necessary condition, it is not necessarily= sufficient.

In the WebPKI an affiliate or enterprise customer may r= un an RA, but the CA is now required to perform certain validation function= s directly. Since you probably don't want to have the validation taking= place in the room with the private key the logical arrangement is again a = RA.

On Wed, Jan 8, 2014 at 1:30 PM, Ben L= aurie <benl@google.com> wrote:

On 27 December 2013 10:06, Ralph Holz <holz@net.in.tum.de> wrote:
> Hi,
>
> [The EFF's count]
>
>>> You can't calculate the number of CAs the way the EFF trie= d to. An
>>> intermediate certificate does not equate to a CA. Pretending i= t does to
>>> peddle an alternative PKI scheme calls into question their ver= acity.
>>>
>>
>> I disagree strongly. I have an intermediate certificate. I am as >> powerful CA as a result.
>> Please also see these estimates which are even higher:
>>
>> https://zakird.com/slides/durumeric-https-imc13.pdf
>>
>> "Identified 1,832 CA certificates =A0belonging to 683 organiz= ations"
>> "311 (45%) of the organizations were provided certificates by=
>> German National Research and Education Network (DFN) "
>
> I was there at IMC and spoke with Zakir. He was not aware of the fact<= br> > that the private keys to all the intermediate certificates are held by=
> the central DFN Verein, not the RAs themselves. In the case of DFN, th= e
> intermediate certs only identify the RAs. The RAs do not carry signing=
> power.

What is the function of an RA, then, if not to tell a CA "sign this&qu= ot;?
_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

--
Website: http://hallambaker.com/

--089e0112bfcee400d904ef7a81e1-- From stephen.farrell@cs.tcd.ie Tue Jan 14 10:03:00 2014 Return-Path: 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 9B4581AE029 for ; Tue, 14 Jan 2014 10:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 2X5EuFmRNiyl for ; Tue, 14 Jan 2014 10:02:58 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 814121ADFB6 for ; Tue, 14 Jan 2014 10:02:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DE043BE3E; Tue, 14 Jan 2014 18:02:46 +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 Mm-7QKVjLAOg; Tue, 14 Jan 2014 18:02:46 +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 B9B3DBE38; Tue, 14 Jan 2014 18:02:46 +0000 (GMT) Message-ID: <52D57BC7.1050905@cs.tcd.ie> Date: Tue, 14 Jan 2014 18:02:47 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Hoffman , Ben Laurie References:

In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Revised Draft Charter for Transparency WG X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: