From benl@google.com Thu Sep 6 07:32:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7E321F8666 for ; Thu, 6 Sep 2012 07:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF0-dI9SRpdw for ; Thu, 6 Sep 2012 07:32:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 706B821F8665 for ; Thu, 6 Sep 2012 07:32:06 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2839630obb.31 for ; Thu, 06 Sep 2012 07:32:06 -0700 (PDT) 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 :x-system-of-record; bh=GUPZgjErcMJDuRZb6BxiUnBASr2jFtC3UZBx4Rhktt0=; b=ddmVUSQoVzr7vHHkWjsgQiRPqdQOdjcx+jhNPbWqPjZNLHVYOQbU5sGsVdUftZBUNt 9dFxCbNjN4R5Hahz+qpILHXLtUB258FClTBzqH+vf3cd3Ds4CgQ2DoEUAyUCclAhFQrg nohufsuP3P2S+C7rZxhHYz5mvBbHMqIUpjAJXcp6E8ySYqDYKfkZXGybKl+USDj9L11k myFWpVLSgmuD9SzllLN/0TMyBMNHZQ/YSPh/1vCezwcgEVTBfkLD8D4tA1HbrHABTbpH 9qw2AoX+CPG+iFdYsenLSVR7oIk2X6NCqTxG/2D/eoeiCo2h5cRjMiosSr2Ioa5xx2SR Nl0Q== X-Google-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 :x-system-of-record:x-gm-message-state; bh=GUPZgjErcMJDuRZb6BxiUnBASr2jFtC3UZBx4Rhktt0=; b=ecd41HgPp84jJu2clfBXelV6d64+LJ7RDd4PF44fYlDdfCodZ7kRe1lwGDE8379HLU tVkY6NK7rsyv5H1bCliDEzOxcn7TRbC2pCxTQuReawuTWdZerYwsrEftV7fzWg+QsmTW 94dDpKfFG4sh30b3FOgswWtcUFMLmZQLkWQyroKFlS+oYTPvDPSfRSiNWm4JG5zB5JZm ci4gSB5iyW9lEwfnx2vrqDZHpXEFHSDIp2lYawa/H9rU9XZu8IUXEb++wUEeMPE+Q7UP 2hKMZELcBkZb6jwlHjz3Smv1CRY9Ju8yZ+RZj1+WThVMRBw3oTkNgTievBTT93g51mLe Eb8w== Received: by 10.182.17.99 with SMTP id n3mr2316696obd.8.1346941925983; Thu, 06 Sep 2012 07:32:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.17.99 with SMTP id n3mr2316686obd.8.1346941925860; Thu, 06 Sep 2012 07:32:05 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Thu, 6 Sep 2012 07:32:05 -0700 (PDT) Date: Thu, 6 Sep 2012 15:32:05 +0100 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkTTDJkq5ndAOUnva/is+Dhy4TMkHK/sm5rvx3j1kuah2TeImAwKEXP8Ef13cYA3IDzczBsLF8var2944AyXz5Bwu6hgLhJSoFgLMoELpoFGqZ55CQbqyPUoBQuQiXuPGPJLQLhiVrXjVcWqfh7AmVhNn/4nsgJ/bvrwL9rKcSzU/Vb4Z2qxbM8LDmzArdJbvtwj/+C Subject: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:32:07 -0000 Would people be interested in starting a WG on Certificate Transparency? If so, how about a BoF in Atlanta? Here's a draft charter... CT IETF WG Draft Charter Objective Specify mechanisms and techniques that allow Internet applications to monitor and verify the issuance of public X.509 certificates such that all public issued certificates are available to applications, and each certificate seen by an application can be efficiently shown to be in the log of issued certificates. Furthermore, it should be possible to cryptographically verify the correct operation of the log. Optionally, do the same for certificate revocations. Problem Statement Currently it is possible for any CA to issue a certificate for any site without any oversight. This has led to some high profile mis-issuance of certificates, such as by DigiNotar, a subsidiary of VASCO Data Security International, in July 2011 (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx). The aim is to make it possible to detect such mis-issuance promptly through the use of a public log of all public issued certificates. Domain owners can then monitor this log and, upon detecting mis-issuance, take appropriate action. This public log must also be able to efficiently demonstrate its own correct operation, rather than introducing yet another party that must be trusted into the equation. Clients should also be able to efficiently verify that certificates they receive have indeed been entered into the public log. For revocations, the aim would be similar: ensure that revocations are as expected, that clients can efficiently obtain the revocation status of a certificate and that the log is operating correctly. Also, in both cases, the solution must be usable by browsers - this means that it cannot add any round trips to page fetches, and that any data transfers that are mandatory are of a reasonable size. From paul@nohats.ca Thu Sep 6 07:34:50 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FF621F866E for ; Thu, 6 Sep 2012 07:34:50 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FGvwKqrx1ec for ; Thu, 6 Sep 2012 07:34:49 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3696B21F865E for ; Thu, 6 Sep 2012 07:34:49 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id BBADB804CD; Thu, 6 Sep 2012 10:33:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AD65580486; Thu, 6 Sep 2012 10:33:59 -0400 (EDT) Date: Thu, 6 Sep 2012 10:33:59 -0400 (EDT) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: therightkey@ietf.org Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:34:50 -0000 On Thu, 6 Sep 2012, Ben Laurie wrote: > Subject: [therightkey] Certificate Transparency Working Group? > > Would people be interested in starting a WG on Certificate > Transparency? If so, how about a BoF in Atlanta? Skeptical, but willing to attend a BoF to be convinced otherwise. Paul From stephen.farrell@cs.tcd.ie Thu Sep 6 07:39:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B9621F8672 for ; Thu, 6 Sep 2012 07:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQMn4DoYKVU4 for ; Thu, 6 Sep 2012 07:39:06 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B05A21F8670 for ; Thu, 6 Sep 2012 07:39:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1F349171486; Thu, 6 Sep 2012 15:39:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346942344; bh=WLffo3rl03Jkdz q8wPrT5ipCfUVMm3f4GKxMqmZFcNM=; b=aMbDm7GcvpWS6sVukpJekLKES/UkEI ZF76c9mty3HMVEmmrPVQ4txQoHgiJLmI4fnTg2Vq4sG9ZYZcLzllCMyf7+ttr1lF Rbm/h+GtzetnN5FU/aEmki1+SQMjvyI0TZ9Sfxhn7OGMrrqT4zPq4EPM+kDg2Nze We7lkdNngti3QeNkcuBhAEXWcfmyPtDAw1SNpFrcNsEa5zf4KFjsNI5WgIwEUKK/ r/8eZrcAH3NpH2ZYcDcyZFc5fJ9BX79SzrIJ8UUSocJVw7BPeLPLnimt9kOTMVgZ Wp/DdAwWMecyB9EN9kbFBVXKfiTlexU9rDcm4sLlnW+CioLFVtY9tcOQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id XpVBXUqkzqg4; Thu, 6 Sep 2012 15:39:04 +0100 (IST) Received: from [10.87.48.9] (unknown [86.44.75.103]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 64D9017147A; Thu, 6 Sep 2012 15:39:04 +0100 (IST) Message-ID: <5048B587.1060702@cs.tcd.ie> Date: Thu, 06 Sep 2012 15:39:03 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Laurie References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:39:07 -0000 Hi all, Just so's you know, Ben and I have been chatting a little about this and Sean and I would be happy to sponsor a BoF on the topic if it looks like it might gain traction and all the other usual things look like they might pan out. The timing for Atlanta is tight though for a formal BoF so if this is of interest (or if you hate it;-) please speak up in the next week. If we don't get sufficient interest for a formal BoF then we can arrange a room for a side-meeting if that's of any use. Cheers, S. On 09/06/2012 03:32 PM, Ben Laurie wrote: > Would people be interested in starting a WG on Certificate > Transparency? If so, how about a BoF in Atlanta? > > Here's a draft charter... > > > CT IETF WG Draft Charter > > Objective > > Specify mechanisms and techniques that allow Internet applications to > monitor and verify the issuance of public X.509 certificates such that > all public issued certificates are available to applications, and each > certificate seen by an application can be efficiently shown to be in > the log of issued certificates. Furthermore, it should be possible to > cryptographically verify the correct operation of the log. > > > Optionally, do the same for certificate revocations. > > Problem Statement > > Currently it is possible for any CA to issue a certificate for any > site without any oversight. This has led to some high profile > mis-issuance of certificates, such as by DigiNotar, a subsidiary of > VASCO Data Security International, in July 2011 > (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx). > > > The aim is to make it possible to detect such mis-issuance promptly > through the use of a public log of all public issued certificates. > Domain owners can then monitor this log and, upon detecting > mis-issuance, take appropriate action. > > > This public log must also be able to efficiently demonstrate its own > correct operation, rather than introducing yet another party that must > be trusted into the equation. > > > Clients should also be able to efficiently verify that certificates > they receive have indeed been entered into the public log. > > > For revocations, the aim would be similar: ensure that revocations are > as expected, that clients can efficiently obtain the revocation status > of a certificate and that the log is operating correctly. > > > Also, in both cases, the solution must be usable by browsers - this > means that it cannot add any round trips to page fetches, and that any > data transfers that are mandatory are of a reasonable size. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > From Scott.Rea@DigiCert.com Thu Sep 6 07:41:16 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A46121F8678 for ; Thu, 6 Sep 2012 07:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo60-3V76+7z for ; Thu, 6 Sep 2012 07:41:15 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 541BC21F8670 for ; Thu, 6 Sep 2012 07:41:15 -0700 (PDT) Received: from [10.211.55.9] (208.64.90.118.static.utbb.net [208.64.90.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id A50201AE125 for ; Thu, 6 Sep 2012 08:41:14 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1346942474; bh=yai/shy201PJx1wGbjRppYtILMtilEa0ofrx2woW5bY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gt0pez5MMkY/kudYUTKpZIAnUnM/TFmfSRpNy4Tz6swY9SYzJHupnupEs05RZJ4Fj bhXqTgHRa8Fb2MhT3BolQJbpUKLc5D+sTerB3dfhJIqjU6KLEs9rlh7NQT1OJZAgXR CTx8Ywmoo23o7d7YOIKB0npnhfrNjc+BDf4K/mYs= Message-ID: <5048B609.6000802@DigiCert.com> Date: Thu, 06 Sep 2012 08:41:13 -0600 From: Scott Rea Organization: DigiCert Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: therightkey@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Sep 2012 07:43:06 -0700 Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:41:16 -0000 I'd be willing to attend a BoF and see where things go... _Scott On 9/6/2012 8:32 AM, Ben Laurie wrote: > Would people be interested in starting a WG on Certificate > Transparency? If so, how about a BoF in Atlanta? > > Here's a draft charter... > > > CT IETF WG Draft Charter > > Objective > > Specify mechanisms and techniques that allow Internet applications to > monitor and verify the issuance of public X.509 certificates such that > all public issued certificates are available to applications, and each > certificate seen by an application can be efficiently shown to be in > the log of issued certificates. Furthermore, it should be possible to > cryptographically verify the correct operation of the log. > > > Optionally, do the same for certificate revocations. > > Problem Statement > > Currently it is possible for any CA to issue a certificate for any > site without any oversight. This has led to some high profile > mis-issuance of certificates, such as by DigiNotar, a subsidiary of > VASCO Data Security International, in July 2011 > (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx). > > > The aim is to make it possible to detect such mis-issuance promptly > through the use of a public log of all public issued certificates. > Domain owners can then monitor this log and, upon detecting > mis-issuance, take appropriate action. > > > This public log must also be able to efficiently demonstrate its own > correct operation, rather than introducing yet another party that must > be trusted into the equation. > > > Clients should also be able to efficiently verify that certificates > they receive have indeed been entered into the public log. > > > For revocations, the aim would be similar: ensure that revocations are > as expected, that clients can efficiently obtain the revocation status > of a certificate and that the log is operating correctly. > > > Also, in both cases, the solution must be usable by browsers - this > means that it cannot add any round trips to page fetches, and that any > data transfers that are mandatory are of a reasonable size. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From Scott@Digicert.com Thu Sep 6 07:43:26 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C546621F84D4 for ; Thu, 6 Sep 2012 07:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHNvyAA6e6iD for ; Thu, 6 Sep 2012 07:43:25 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id D660421F869C for ; Thu, 6 Sep 2012 07:43:24 -0700 (PDT) Received: from [10.211.55.9] (208.64.90.118.static.utbb.net [208.64.90.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id 7E4D21AE123 for ; Thu, 6 Sep 2012 08:43:24 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1346942604; bh=X4hB2gv33tNuZOVKZeV0Z12BDaAm/fu8Kh2sTRSdxy4=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=z7Hgsp5+wEYfODo+09L4ZahmhbicBhCKmf+Em0x5AAnzAeOP+AKDBHDjSdusQAvFp y6PfAxySaJhXhwc0ygHk+YXIIPXXk53n25JOqsRlp1pkcuKHnhFnqK34dhpGHkk5ww FwaOBxsex9BEPdy9OaJKOwEeo3VmxfKl60YOy3Ew= Message-ID: <5048B68B.8050608@Digicert.com> Date: Thu, 06 Sep 2012 08:43:23 -0600 From: Scott Rea User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: therightkey@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:43:26 -0000 I'd be willing to attend a BoF and see where things go... _Scott On 9/6/2012 8:32 AM, Ben Laurie wrote: > Would people be interested in starting a WG on Certificate > Transparency? If so, how about a BoF in Atlanta? > > Here's a draft charter... > > > CT IETF WG Draft Charter > > Objective > > Specify mechanisms and techniques that allow Internet applications to > monitor and verify the issuance of public X.509 certificates such that > all public issued certificates are available to applications, and each > certificate seen by an application can be efficiently shown to be in > the log of issued certificates. Furthermore, it should be possible to > cryptographically verify the correct operation of the log. > > > Optionally, do the same for certificate revocations. > > Problem Statement > > Currently it is possible for any CA to issue a certificate for any > site without any oversight. This has led to some high profile > mis-issuance of certificates, such as by DigiNotar, a subsidiary of > VASCO Data Security International, in July 2011 > (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx). > > > The aim is to make it possible to detect such mis-issuance promptly > through the use of a public log of all public issued certificates. > Domain owners can then monitor this log and, upon detecting > mis-issuance, take appropriate action. > > > This public log must also be able to efficiently demonstrate its own > correct operation, rather than introducing yet another party that must > be trusted into the equation. > > > Clients should also be able to efficiently verify that certificates > they receive have indeed been entered into the public log. > > > For revocations, the aim would be similar: ensure that revocations are > as expected, that clients can efficiently obtain the revocation status > of a certificate and that the log is operating correctly. > > > Also, in both cases, the solution must be usable by browsers - this > means that it cannot add any round trips to page fetches, and that any > data transfers that are mandatory are of a reasonable size. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey -- Scott Rea, CISSP VP GOV/EDU Relations & Sr. PKI Architect DigiCert, Inc. 355 South 520 West Canopy Building II, Suite 200 Lindon, Utah 84042 http://www.digicert.com (800) 896-7973 Em Scott@DigiCert.com Ph#(801) 701-9636 Ce#(801) 874-4114 From ynir@checkpoint.com Thu Sep 6 07:50:04 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626A621F855E for ; Thu, 6 Sep 2012 07:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jtRNrExhs+c for ; Thu, 6 Sep 2012 07:50:03 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E44C621F8568 for ; Thu, 6 Sep 2012 07:50:02 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q86EnwVe026796; Thu, 6 Sep 2012 17:49:58 +0300 X-CheckPoint: {5048B3B1-0-1B221DC2-4FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 6 Sep 2012 17:49:58 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 6 Sep 2012 17:49:58 +0300 From: Yoav Nir To: Ben Laurie Date: Thu, 6 Sep 2012 17:50:01 +0300 Thread-Topic: [therightkey] Certificate Transparency Working Group? Thread-Index: Ac2MPuKTzuaGp6W0QcW9EDAdaetdeQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:50:04 -0000 On Sep 6, 2012, at 5:32 PM, Ben Laurie wrote: > Would people be interested in starting a WG on Certificate > Transparency? Getting interest is the easy part. Getting people to do the work and lockin= g down the deliverables is harder. > If so, how about a BoF in Atlanta? The cut-off date for BoF proposals is 24-Sep. That's 18 days away, but we n= eed people who will commit to more than being in the room. This is one of t= hose subjects (like HTTP authentication) that will get half the security ar= ea regulars into the room. This should not be confused with having a large = group of people willing to work on the same deliverables. > Here's a draft charter... >=20 >=20 > CT IETF WG Draft Charter >=20 > Objective >=20 > Specify mechanisms and techniques that allow Internet applications to > monitor and verify the issuance of public X.509 certificates such that > all public issued certificates are available to applications, and each > certificate seen by an application can be efficiently shown to be in > the log of issued certificates. Furthermore, it should be possible to > cryptographically verify the correct operation of the log. We'll need a good definition of the roles: what is a web application? who k= eeps the log? who can verify the log, etc. > Optionally, do the same for certificate revocations. >=20 > Problem Statement >=20 > Currently it is possible for any CA to issue a certificate for any > site without any oversight. This has led to some high profile > mis-issuance of certificates, such as by DigiNotar, a subsidiary of > VASCO Data Security International, in July 2011 > (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/ne= ws_diginotar_reports_security_incident.aspx). >=20 >=20 > The aim is to make it possible to detect such mis-issuance promptly > through the use of a public log of all public issued certificates. > Domain owners can then monitor this log and, upon detecting > mis-issuance, take appropriate action. >=20 >=20 > This public log must also be able to efficiently demonstrate its own > correct operation, rather than introducing yet another party that must > be trusted into the equation. >=20 >=20 > Clients should also be able to efficiently verify that certificates > they receive have indeed been entered into the public log. >=20 >=20 > For revocations, the aim would be similar: ensure that revocations are > as expected, that clients can efficiently obtain the revocation status > of a certificate and that the log is operating correctly. >=20 >=20 > Also, in both cases, the solution must be usable by browsers - this > means that it cannot add any round trips to page fetches, and that any > data transfers that are mandatory are of a reasonable size. There is some work already being done in this area. One is certificate tran= sparency, and another is the sovereign keys. Maybe there are others. These = should be presented. Yoav From benl@google.com Thu Sep 6 07:53:34 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DB321F86B5 for ; Thu, 6 Sep 2012 07:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCBznUBPhJfp for ; Thu, 6 Sep 2012 07:53:33 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA3C421F868A for ; Thu, 6 Sep 2012 07:53:33 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2893033obb.31 for ; Thu, 06 Sep 2012 07:53:33 -0700 (PDT) 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:x-system-of-record; bh=zxbdIPzbCrD2iJ2QrajzFZnSwYU+oeDpKvv2awaWgOk=; b=PiODf8BVkE2ZJmqsLpJ6+8F+DX0gVhNKpyD0nkkyWbB2gZZfGTkKHlxkilejmKRALT W3VeCMucmkBqoMtTi7RLFjEqEqBNy+ehNPN3UbUeeg/gP9x/BG9psbXfCYqm0aU6QO2o aFDPaNUUrdZ/lEffdHpFGuaZmu9xAPIWwBi/jQeAdh6Y3xf9wCbitCBAy1PJ1W2r+SJS xlr3xTYNovA3iKwZ+Fj1DqS4MaWPMUsGKvPGtJ59qcMFCZCBihYVltvrtk7yXiiVay5b 2MafIj2+QCiD8viQDhi+eC50pem3KaKjOYna9TNAmZw+ry4UzfOJEE0st+9j7OwpaxbM 43/g== X-Google-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:x-system-of-record:x-gm-message-state; bh=zxbdIPzbCrD2iJ2QrajzFZnSwYU+oeDpKvv2awaWgOk=; b=lMAgEXG0zhC4mp0mbynIVuhBqrBXbpRndQGihjWG7hdw5W/Ir+7L1eiRBoXNEvtlFi tWUcYR0t7X7ETTnBJP5+rAruPUX0/YfPIhw2QGjJyjVNJe99tKqaa16v/K/23cLAq7q+ +EFaJImdAIvI9yj+IlX+Gh7+OG6CMC5nva68hPP5LhMRfc9EnBUFYrh5Ad3hC+OmOU96 rIVlQ/9qdHi2x2obGEdU58os6LQpMGDdOgFbgyhPPnfMI8UA9iPcW3dav2NvxfcdsB8A 66HA5p6PJhFf1djAQk5M2PUC25e2h8VWv3ONymfG4VL5zUmqjgEt9+aenFYEKzg+HWgX hWjA== Received: by 10.60.27.10 with SMTP id p10mr2372974oeg.49.1346943213413; Thu, 06 Sep 2012 07:53:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.27.10 with SMTP id p10mr2372962oeg.49.1346943213297; Thu, 06 Sep 2012 07:53:33 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Thu, 6 Sep 2012 07:53:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Sep 2012 15:53:33 +0100 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk9iI47bFdJGedotdjLpOdx/yx924kd3mk8tjYDPn/SJpFma+9iPDEREYT4o04BqwurU3Q1OPcF1mSBqsmq9SvkPizpLBUKm3+na627gTB0z7J9X9ydO8jN2gMtMb8VBBG/bMn023gJbkdLrd7EtfyLVri84XNtzuIlow1ksAsOs0SEQWum+8P92trWcWl3m59sU0+Z Cc: therightkey@ietf.org Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:53:35 -0000 On 6 September 2012 15:33, Paul Wouters wrote: > On Thu, 6 Sep 2012, Ben Laurie wrote: > >> Subject: [therightkey] Certificate Transparency Working Group? >> >> Would people be interested in starting a WG on Certificate >> Transparency? If so, how about a BoF in Atlanta? > > > Skeptical, Curious why? > but willing to attend a BoF to be convinced otherwise. > > Paul From denis.pinkas@bull.net Thu Sep 6 08:07:38 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC8B21F850C for ; Thu, 6 Sep 2012 08:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvW0qCfLqwut for ; Thu, 6 Sep 2012 08:07:37 -0700 (PDT) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0436421F84E6 for ; Thu, 6 Sep 2012 08:07:37 -0700 (PDT) Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id 6AA6D1815B for ; Thu, 6 Sep 2012 17:07:36 +0200 (CEST) MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: X-Disclaimed: 1 From: denis.pinkas@bull.net To: therightkey@ietf.org Message-ID: Date: Thu, 6 Sep 2012 17:07:35 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2FP1 November 29, 2010 X-MIMETrack: Serialize by HTTP Server on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 06/09/2012 17:07:35, Serialize complete at 06/09/2012 17:07:35, Itemize by HTTP Server on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 06/09/2012 17:07:35, Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 06/09/2012 17:07:36, Serialize complete at 06/09/2012 17:07:36 Content-Type: multipart/alternative; boundary="=_alternative 0053179FC1257A71_=" X-Mailman-Approved-At: Thu, 06 Sep 2012 08:08:19 -0700 Subject: [therightkey] Tr : Re: [wpkops] [pkix] Fwd: Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:07:38 -0000 --=_alternative 0053179FC1257A71_= Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Denis, all, Please follow-up on therightkey@ietf.org which is where this will be discussed. Thanks, S. On 09/06/2012 03:55 PM, denis.pinkas@bull.net wrote: > Part of the stated objective (i.e. verify the issuance of public X.509 ce= rtificates)=20 > is currently addressed, within the context of OCSP, in : >=20 > https://datatracker.ietf.org/doc/draft-pinkas-2560bis-certinfo/ >=20 > This draft is being considered within the PKIX WG. >=20 > The second part of the objective (i.e. making all public issued certifica= tes available to applications)=20 > may be dangerous in many situations.=20 >=20 > Denis >=20 > -----pkix-bounces@ietf.org a =E9crit : -----=20 > A : "saag@ietf.org" , "'wpkops@ietf.org'" , pkix > De : Stephen Farrell=20 > Envoy=E9 par : pkix-bounces@ietf.org > Date : 06/09/2012 16:42 > Objet : [pkix] Fwd: [therightkey] Certificate Transparency Working Group? >=20 > Hi all, >=20 > Please see below. Ben Laurie's looking to see if folks are > interested in a BoF on Certificate Transparency for the > IETF meeting in Altanta. >=20 > Sean and I would be fine with that, if there's sufficient > interest etc. >=20 > Please follow up on therightkey@ietf.org if this is a > topic that's of interest to you. >=20 > Thanks, > Stephen. >=20 >=20 > -------- Original Message -------- > Subject: [therightkey] Certificate Transparency Working Group? > Date: Thu, 6 Sep 2012 15:32:05 +0100 > From: Ben Laurie > To: therightkey@ietf.org >=20 > Would people be interested in starting a WG on Certificate > Transparency? If so, how about a BoF in Atlanta? >=20 > Here's a draft charter... >=20 >=20 > CT IETF WG Draft Charter >=20 > Objective >=20 > Specify mechanisms and techniques that allow Internet applications to > monitor and verify the issuance of public X.509 certificates such that > all public issued certificates are available to applications, and each > certificate seen by an application can be efficiently shown to be in > the log of issued certificates. Furthermore, it should be possible to > cryptographically verify the correct operation of the log. >=20 >=20 > Optionally, do the same for certificate revocations. >=20 > Problem Statement >=20 > Currently it is possible for any CA to issue a certificate for any > site without any oversight. This has led to some high profile > mis-issuance of certificates, such as by DigiNotar, a subsidiary of > VASCO Data Security International, in July 2011 > (http://www.vasco.com/company/about=5Fvasco/press=5Froom/news=5Farchive/2= 011/news=5Fdiginotar=5Freports=5Fsecurity=5Fincident.aspx). >=20 >=20 > The aim is to make it possible to detect such mis-issuance promptly > through the use of a public log of all public issued certificates. > Domain owners can then monitor this log and, upon detecting > mis-issuance, take appropriate action. >=20 >=20 > This public log must also be able to efficiently demonstrate its own > correct operation, rather than introducing yet another party that must > be trusted into the equation. >=20 >=20 > Clients should also be able to efficiently verify that certificates > they receive have indeed been entered into the public log. >=20 >=20 > For revocations, the aim would be similar: ensure that revocations are > as expected, that clients can efficiently obtain the revocation status > of a certificate and that the log is operating correctly. >=20 >=20 > Also, in both cases, the solution must be usable by browsers - this > means that it cannot add any round trips to page fetches, and that any > data transfers that are mandatory are of a reasonable size. > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey >=20 >=20 >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix >=20 >=20 >=20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > wpkops mailing list > wpkops@ietf.org > https://www.ietf.org/mailman/listinfo/wpkops >=20 --=_alternative 0053179FC1257A71_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
=0D
Denis, all,=

Please follow-up on therightkey@ietf.org which is where this
wil= l be discussed.

Thanks,
S.

On 09/06/2012 03:55 PM, denis.p= inkas@bull.net wrote:
> Part of the stated objective (i.e. verify the= issuance of public X.509 certificates)
> is currently addressed, wi= thin the context of OCSP, in :
>
> https://datatracker.ietf.o= rg/doc/draft-pinkas-2560bis-certinfo/
>
> This draft is be= ing considered within the PKIX WG.
>
> The second part of the = objective (i.e. making all public issued certificates available to applicat= ions)
> may be dangerous in many situations.
>
> Denis=
>
> -----pkix-bounces@ietf.org a =E9crit : -----
> A := "saag@ietf.org" <saag@ietf.org>, "'wpkops@ietf.org'" <wpkops@ietf= .org>, pkix <pkix@ietf.org>
> De : Stephen Farrell
> = Envoy=E9 par : pkix-bounces@ietf.org
> Date : 06/09/2012 16:42
>= ; Objet : [pkix] Fwd: [therightkey] Certificate Transparency Working Group?=
>
> Hi all,
>
> Please see below. Ben Laurie's l= ooking to see if folks are
> interested in a BoF on Certificate Trans= parency for the
> IETF meeting in Altanta.
>
> Sean and = I would be fine with that, if there's sufficient
> interest etc.
&= gt;
> Please follow up on therightkey@ietf.org if this is a
> = topic that's of interest to you.
>
> Thanks,
> Stephen.<= BR>>
>
> -------- Original Message --------
> Subjec= t: [therightkey] Certificate Transparency Working Group?
> Date: Thu,= 6 Sep 2012 15:32:05 +0100
> From: Ben Laurie <benl@google.com>=
> To: therightkey@ietf.org
>
> Would people be interest= ed in starting a WG on Certificate
> Transparency? If so, how about a= BoF in Atlanta?
>
> Here's a draft charter...
>
>= ;
> CT IETF WG Draft Charter
>
> Objective
>
= > Specify mechanisms and techniques that allow Internet applications to<= BR>> monitor and verify the issuance of public X.509 certificates such t= hat
> all public issued certificates are available to applications, a= nd each
> certificate seen by an application can be efficiently shown= to be in
> the log of issued certificates. Furthermore, it should be= possible to
> cryptographically verify the correct operation of the = log.
>
>
> Optionally, do the same for certificate revo= cations.
>
> Problem Statement
>
> Currently it i= s possible for any CA to issue a certificate for any
> site without a= ny oversight. This has led to some high profile
> mis-issuance of cer= tificates, such as by DigiNotar, a subsidiary of
> VASCO Data Securit= y International, in July 2011
> (http://www.vasco.com/company/about=5Fvasco/p= ress=5Froom/news=5Farchive/2011/news=5Fdiginotar=5Freports=5Fsecurity=5Finc= ident.aspx).
>
>
> The aim is to make it possible t= o detect such mis-issuance promptly
> through the use of a public log= of all public issued certificates.
> Domain owners can then monitor = this log and, upon detecting
> mis-issuance, take appropriate action.=
>
>
> This public log must also be able to efficiently= demonstrate its own
> correct operation, rather than introducing yet= another party that must
> be trusted into the equation.
>
= >
> Clients should also be able to efficiently verify that certif= icates
> they receive have indeed been entered into the public log.>
>
> For revocations, the aim would be similar: ensure = that revocations are
> as expected, that clients can efficiently obta= in the revocation status
> of a certificate and that the log is opera= ting correctly.
>
>
> Also, in both cases, the solution= must be usable by browsers - this
> means that it cannot add any rou= nd trips to page fetches, and that any
> data transfers that are mand= atory are of a reasonable size.
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> therightkey mailing list
> = therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
&g= t;
>
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> pkix mailing list
> pkix@ietf.= org
> https://= www.ietf.org/mailman/listinfo/pkix
>
>
>
> = =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> = wpkops mailing list
> wpkops@ietf.org
> https://www.ietf.org/mailman/listinfo/wpk= ops
>
=0D
 --=_alternative 0053179FC1257A71_=-- From tim.moses@entrust.com Thu Sep 6 08:17:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E58E21F86B4 for ; Thu, 6 Sep 2012 08:17:00 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZPSl9HfcDud for ; Thu, 6 Sep 2012 08:16:59 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id 62DA421F86A8 for ; Thu, 6 Sep 2012 08:16:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,380,1344225600"; d="scan'208";a="6131836" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge1.entrust.com with ESMTP; 06 Sep 2012 11:16:56 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Thu, 6 Sep 2012 11:16:56 -0400 From: Tim Moses To: 'Ben Laurie' Thread-Topic: [therightkey] Certificate Transparency Working Group? Thread-Index: AQHNjDx58kqlytdPxkC/V7LzkfP4ZZd9bC+g Date: Thu, 6 Sep 2012 15:16:55 +0000 Message-ID: <5B68A271B9C97046963CB6A5B8D6F62C3A57E9C0@SOTTEXCH10.corp.ad.entrust.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.160.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:17:00 -0000 Hi Ben. I am supportive of this initiative, and intend to participate. Perhaps a small clarification is warranted. Consider limiting the proposed= solution to "Publicly-Trusted Certificates", which are defined as follows = by CABForum: "A Certificate that is trusted by virtue of the fact that its = corresponding Root Certificate is distributed as a trust anchor in widely-a= vailable application software". All the best. Tim. -----Original Message----- From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] On= Behalf Of Ben Laurie Sent: Thursday, September 06, 2012 10:32 AM To: therightkey@ietf.org Subject: [therightkey] Certificate Transparency Working Group? Would people be interested in starting a WG on Certificate Transparency? If= so, how about a BoF in Atlanta? Here's a draft charter... CT IETF WG Draft Charter Objective Specify mechanisms and techniques that allow Internet applications to monit= or and verify the issuance of public X.509 certificates such that all publi= c issued certificates are available to applications, and each certificate s= een by an application can be efficiently shown to be in the log of issued c= ertificates. Furthermore, it should be possible to cryptographically verify= the correct operation of the log. Optionally, do the same for certificate revocations. Problem Statement Currently it is possible for any CA to issue a certificate for any site wit= hout any oversight. This has led to some high profile mis-issuance of certi= ficates, such as by DigiNotar, a subsidiary of VASCO Data Security Internat= ional, in July 2011 (http://www.vasco.com/company/about_vasco/press_room/ne= ws_archive/2011/news_diginotar_reports_security_incident.aspx). The aim is to make it possible to detect such mis-issuance promptly through= the use of a public log of all public issued certificates. Domain owners can then monitor this log and, upon detecting mis-issuance, t= ake appropriate action. This public log must also be able to efficiently demonstrate its own correc= t operation, rather than introducing yet another party that must be trusted= into the equation. Clients should also be able to efficiently verify that certificates they re= ceive have indeed been entered into the public log. For revocations, the aim would be similar: ensure that revocations are as e= xpected, that clients can efficiently obtain the revocation status of a cer= tificate and that the log is operating correctly. Also, in both cases, the solution must be usable by browsers - this means t= hat it cannot add any round trips to page fetches, and that any data transf= ers that are mandatory are of a reasonable size. _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey From rob.stradling@comodo.com Thu Sep 6 08:19:16 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7227721F86D5 for ; Thu, 6 Sep 2012 08:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bROeQBYU3u5P for ; Thu, 6 Sep 2012 08:19:16 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF5B21F86C9 for ; Thu, 6 Sep 2012 08:19:15 -0700 (PDT) Received: (qmail 1177 invoked from network); 6 Sep 2012 15:19:14 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 6 Sep 2012 15:19:14 -0000 Received: (qmail 7934 invoked by uid 1000); 6 Sep 2012 15:19:13 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 06 Sep 2012 16:19:13 +0100 Message-ID: <5048BEF1.2020403@comodo.com> Date: Thu, 06 Sep 2012 16:19:13 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: therightkey@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Sep 2012 08:19:47 -0700 Cc: denis.pinkas@bull.net Subject: Re: [therightkey] Tr : Re: [wpkops] [pkix] Fwd: Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:19:16 -0000 On 09/06/2012 03:55 PM, denis.pinkas@bull.net wrote: > Part of the stated objective (i.e. verify the issuance of public > X.509 certificates) is currently addressed, within the context of OCSP, in : > > https://datatracker.ietf.org/doc/draft-pinkas-2560bis-certinfo/ > > This draft is being considered within the PKIX WG. Denis, IIUC, your draft allows an OCSP client to ask a CA "Have you issued a certificate with this particular serial number?" That's not the question that users, domain owners and auditors will want to ask of Certificate Transparency. For example, domain owners will want to ask "What certificates have been issued, by any/every CA in the world, for my domain name?" This is clearly out of scope for OCSP. > The second part of the objective (i.e. making all public issued > certificates available to applications) may be dangerous in many situations. Can you give specific examples? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From ietf@hardjono.net Thu Sep 6 10:33:15 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6D721F86C4 for ; Thu, 6 Sep 2012 10:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0e7Ry1ccbqC for ; Thu, 6 Sep 2012 10:33:14 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (unknown [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 701FF21F8685 for ; Thu, 6 Sep 2012 10:33:13 -0700 (PDT) Received: (qmail 10575 invoked by uid 0); 6 Sep 2012 17:33:12 -0000 Received: from unknown (HELO box602.bluehost.com) (70.40.220.102) by oproxy12.bluehost.com with SMTP; 6 Sep 2012 17:33:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardjono.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=HTP9v3Wo2+2sI+T2yu9HWvk5v90yW+cogztToJ5UAKE=; b=KjhJSlDAEnLeB/L/7MO85/yw/xi3rIEunxjjG7XPz85xd0H8jw9lr2NqlbJznUKLabELjJsBvM+7ZT74NxZQbT6VjQKrpJH64d3m6cJD8fBAnmGkdTE/TfnuUkKNtfyv; Received: from [18.111.43.151] (port=51463 helo=WINCE7P9IL9EJ0) by box602.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1T9fx1-0007Ml-W2; Thu, 06 Sep 2012 11:33:12 -0600 From: "Thomas Hardjono" To: "'Ben Laurie'" , References: In-Reply-To: Date: Thu, 6 Sep 2012 13:33:10 -0400 Message-ID: <00e401cd8c55$b05ac560$11105020$@hardjono.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF/7G4KOoXije5kVnukbLzPdTAuH5gY0Dnw Content-Language: en-us X-Identified-User: {3727:box602.bluehost.com:hardjono:hardjono.net} {sentby:smtp auth 18.111.43.151 authed with ietf@hardjono.net} Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:33:15 -0000 Hi Ben, A couple of questions: > The aim is to make it possible to detect such mis-issuance promptly > through the use of a public log of all public issued certificates. (a) Is this a log (repository) of just CA certs only, or does it include every cert on the planet? (b) Does it apply to public CAs only (or can private CA also contribute to this log). > Clients should also be able to efficiently verify that certificates > they receive have indeed been entered into the public log. (c) Will there be legal trust-frameworks to oversee the operations of the contributing CAs as well as the log-operators? (d) Will the end-user (client side) have to pay to access the log? (e) Who are the potential operators of the log(s) & how do they make money? (f) History has shown that server-side certs are rarely ever validated by the client. What's different this time that would make the clients willing to look-up the log. (g) Will the CT-WG define Web APIs for accessing the log? (or will the APIs be non-standard defined by log-operators). ps. anyone remember UDDI? Thanks. /thomas/ > -----Original Message----- > From: therightkey-bounces@ietf.org [mailto:therightkey- > bounces@ietf.org] On Behalf Of Ben Laurie > Sent: Thursday, September 06, 2012 10:32 AM > To: therightkey@ietf.org > Subject: [therightkey] Certificate Transparency Working Group? > > Would people be interested in starting a WG on Certificate > Transparency? If so, how about a BoF in Atlanta? > > Here's a draft charter... > > > CT IETF WG Draft Charter > > Objective > > Specify mechanisms and techniques that allow Internet applications to > monitor and verify the issuance of public X.509 certificates such that > all public issued certificates are available to applications, and each > certificate seen by an application can be efficiently shown to be in > the log of issued certificates. Furthermore, it should be possible to > cryptographically verify the correct operation of the log. > > > Optionally, do the same for certificate revocations. > > Problem Statement > > Currently it is possible for any CA to issue a certificate for any site > without any oversight. This has led to some high profile mis-issuance > of certificates, such as by DigiNotar, a subsidiary of VASCO Data > Security International, in July 2011 > (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011 / > news_diginotar_reports_security_incident.aspx). > > > The aim is to make it possible to detect such mis-issuance promptly > through the use of a public log of all public issued certificates. > Domain owners can then monitor this log and, upon detecting mis- > issuance, take appropriate action. > > > This public log must also be able to efficiently demonstrate its own > correct operation, rather than introducing yet another party that must > be trusted into the equation. > > > Clients should also be able to efficiently verify that certificates > they receive have indeed been entered into the public log. > > > For revocations, the aim would be similar: ensure that revocations are > as expected, that clients can efficiently obtain the revocation status > of a certificate and that the log is operating correctly. > > > Also, in both cases, the solution must be usable by browsers - this > means that it cannot add any round trips to page fetches, and that any > data transfers that are mandatory are of a reasonable size. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From carl@redhoundsoftware.com Thu Sep 6 11:04:51 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433F921F8716 for ; Thu, 6 Sep 2012 11:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSdDL3yqbBx6 for ; Thu, 6 Sep 2012 11:04:50 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0AEF21F8717 for ; Thu, 6 Sep 2012 11:04:50 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1925364vbb.31 for ; Thu, 06 Sep 2012 11:04:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=MZ9rh9wI5G6td2hkoUUgoWJjVHfX7+o3FeKuyQ1+F5A=; b=JB3Ol0kR9MSpCPuiSXb9jan9WVzRl10k76XWPhDOiVgxXmF3BzT9b4BrWgvR1JzsZi 1avPSamjDGwTUrbbGAiOuDneZUE94kirw4qITGA8dUhZOWzJ0iR7bYXRiBbNvtnJWaXl 6te0UDYpEElNNqp07JqjdYNCvbxR/dPN6NsAd7zfH00VOniRiALucwNtQKjOZoexsQOO E+ZHQYJKbzH2IBHw9uavQou3FSBbI4yDyuUPWZiKENwIstbHOzGh8/uFs9xl6XPyTXhD g4R7MgIIq5gKRsft+SIQPsN5iH2ECKDtPgJpdTP/TrIIp5CZ11kBHDjDd+FxJfg20e22 qBtg== Received: by 10.58.13.33 with SMTP id e1mr3659381vec.51.1346954689912; Thu, 06 Sep 2012 11:04:49 -0700 (PDT) Received: from [192.168.2.8] (pool-72-66-83-116.washdc.fios.verizon.net. [72.66.83.116]) by mx.google.com with ESMTPS id q10sm1787367vdj.12.2012.09.06.11.04.44 (version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 11:04:48 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Thu, 06 Sep 2012 14:04:45 -0400 From: Carl Wallace To: Tim Moses , 'Ben Laurie' Message-ID: Thread-Topic: [therightkey] Certificate Transparency Working Group? In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A57E9C0@SOTTEXCH10.corp.ad.entrust.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmHN+zUqic5NzHqd9Fc9cwYtCo4ecWrO+HfP7tF5lIBoBHAcEOQKjGlCIKZr9BxPLOGduMM Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:04:51 -0000 On 9/6/12 11:16 AM, "Tim Moses" wrote: >Hi Ben. I am supportive of this initiative, and intend to participate. > >Perhaps a small clarification is warranted. Consider limiting the >proposed solution to "Publicly-Trusted Certificates", which are defined >as follows by CABForum: "A Certificate that is trusted by virtue of the >fact that its corresponding Root Certificate is distributed as a trust >anchor in widely-available application software". Tim, are you suggesting the mechanisms and techniques produced by a working group should be limited in this way or a service that makes use of those mechanisms and techniques be limited in this way? From benl@google.com Thu Sep 6 11:25:21 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691E721F8745 for ; Thu, 6 Sep 2012 11:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2IGW+47Tw0M for ; Thu, 6 Sep 2012 11:25:20 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8047021F8742 for ; Thu, 6 Sep 2012 11:25:20 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3369604obb.31 for ; Thu, 06 Sep 2012 11:25:20 -0700 (PDT) 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:x-system-of-record; bh=xFGONdsHTMU2GlAQ+Oeg3IZYlgAXyWMt+pD1HnN77dY=; b=ioN+ik5qBpIrl3AfttH6vP9xvV9dt+B2oOzkjYHAsPFIHeKYMoIgJacfKGRgMPV9QN 0hOqZ66dG4AQ1XbtMny7MbY9joVmRqWBcSpcC/qiEX2FsBe+PctaPV+Efm1YBoG3fQzs xoUZXHjo9JmQ9MiwbjkSXrzQzIJOVwZRjr7u3ZiObRV0f5MNLWTr7SioYytnSaMYwghd KeO2sdAZMnYrtyAy93pRGXH9arwYhJIQV88y/FyuO6dYQq6u0nCZFZN40yZwLODGAXaf F8UORhdGmzwcIda+s6aCK4H7Elbj2LYg6Q4aG/n5P4m7vuyC9tpPymqhQIms+rFA43x2 31Pg== X-Google-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:x-system-of-record:x-gm-message-state; bh=xFGONdsHTMU2GlAQ+Oeg3IZYlgAXyWMt+pD1HnN77dY=; b=bI7AVXYiJ+rnK/FSBUSIpnpaeMGNUwuaUizDPZN070LGiCkUTAtO7GcRo/cUkPtmAG iTNyHamu6TnZ9to8LJHUJUVYhq0oNRioGKJMhrHAXKaG8hQwDBQmAGeoEdxwlBsrRqb0 G7MTSEEsoSlYHjVHITqPadlcAlbxWtf0P1Sd7FXlQl84NyA/pDy0BuRwzgPdANsa0xTZ dvma6BjdG8eAyW8tiJG41lWuCnkycaThLn8xYSC7xCIAVdvA0FT/uaFLy4LNBA9s4R5X 2IkstDGZ7QaLybMWdh1gtnC7fn0BQyoPII4qDjjE0Y0YUIMdGRQCg/0smjlYff2IT7oo vddQ== Received: by 10.60.12.8 with SMTP id u8mr3336514oeb.46.1346955920080; Thu, 06 Sep 2012 11:25:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.12.8 with SMTP id u8mr3336350oeb.46.1346955917068; Thu, 06 Sep 2012 11:25:17 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Thu, 6 Sep 2012 11:25:17 -0700 (PDT) In-Reply-To: <00e401cd8c55$b05ac560$11105020$@hardjono.net> References: <00e401cd8c55$b05ac560$11105020$@hardjono.net> Date: Thu, 6 Sep 2012 19:25:17 +0100 Message-ID: From: Ben Laurie To: Thomas Hardjono Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkFu2uKu3LW76WSUAOOPX52hYm06hQp0uhw7D39B+K8x5KJxkkHHx6zurm627HtdiOxvepgRY8ci9r4htVbX/WhNTmgLnq3PLAAD/Lk06gbzc0nkGI6RZEAOWzVxCJnDhG217sfrLtkoyHBa5TT/4PwGc7yNj982n/Tgb4la5qtM50P1K4Jqnok7R2Yv4yGiH1eIXn7 Cc: therightkey@ietf.org Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:25:21 -0000 On 6 September 2012 18:33, Thomas Hardjono wrote: > Hi Ben, > > A couple of questions: > >> The aim is to make it possible to detect such mis-issuance promptly >> through the use of a public log of all public issued certificates. > > (a) Is this a log (repository) of just CA certs only, or does it > include every cert on the planet? Every public cert on the planet. > (b) Does it apply to public CAs only (or can private CA also > contribute to this log). Private CAs can contribute. >> Clients should also be able to efficiently verify that certificates >> they receive have indeed been entered into the public log. > > (c) Will there be legal trust-frameworks to oversee the operations of > the contributing CAs as well as the log-operators? Our proposal does not require trust, so I certainly don't intend to propose legal frameworks. Others may have other ideas, which I look forward to hearing about. > (d) Will the end-user (client side) have to pay to access the log? Not our log. > (e) Who are the potential operators of the log(s) & how do they make > money? It is surprisingly cheap to run a Certificate Transparency log, we believe. So, we hope that there will be sufficient interest in the stability of the 'net to not require a way to make profit from a log. Google intends to run one, in any case. > (f) History has shown that server-side certs are rarely ever validated > by the client. What's different this time that would make the clients > willing to look-up the log. Certificate Transparency does not require lookup. I'd also note that browsers _do_ validate certs. Other clients are less diligent, agreed - this is a different problem which is also worth solving. > (g) Will the CT-WG define Web APIs for accessing the log? (or will the > APIs be non-standard defined by log-operators). I believe that such APIs (I would call them protocols :-) are in scope for the WG. > > > ps. anyone remember UDDI? > > > Thanks. > > /thomas/ > > >> -----Original Message----- >> From: therightkey-bounces@ietf.org [mailto:therightkey- >> bounces@ietf.org] On Behalf Of Ben Laurie >> Sent: Thursday, September 06, 2012 10:32 AM >> To: therightkey@ietf.org >> Subject: [therightkey] Certificate Transparency Working Group? >> >> Would people be interested in starting a WG on Certificate >> Transparency? If so, how about a BoF in Atlanta? >> >> Here's a draft charter... >> >> >> CT IETF WG Draft Charter >> >> Objective >> >> Specify mechanisms and techniques that allow Internet applications > to >> monitor and verify the issuance of public X.509 certificates such > that >> all public issued certificates are available to applications, and > each >> certificate seen by an application can be efficiently shown to be in >> the log of issued certificates. Furthermore, it should be possible > to >> cryptographically verify the correct operation of the log. >> >> >> Optionally, do the same for certificate revocations. >> >> Problem Statement >> >> Currently it is possible for any CA to issue a certificate for any > site >> without any oversight. This has led to some high profile > mis-issuance >> of certificates, such as by DigiNotar, a subsidiary of VASCO Data >> Security International, in July 2011 >> > (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011 > / >> news_diginotar_reports_security_incident.aspx). >> >> >> The aim is to make it possible to detect such mis-issuance promptly >> through the use of a public log of all public issued certificates. >> Domain owners can then monitor this log and, upon detecting mis- >> issuance, take appropriate action. >> >> >> This public log must also be able to efficiently demonstrate its own >> correct operation, rather than introducing yet another party that > must >> be trusted into the equation. >> >> >> Clients should also be able to efficiently verify that certificates >> they receive have indeed been entered into the public log. >> >> >> For revocations, the aim would be similar: ensure that revocations > are >> as expected, that clients can efficiently obtain the revocation > status >> of a certificate and that the log is operating correctly. >> >> >> Also, in both cases, the solution must be usable by browsers - this >> means that it cannot add any round trips to page fetches, and that > any >> data transfers that are mandatory are of a reasonable size. >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > From benl@google.com Thu Sep 6 11:30:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE7221F86CA for ; Thu, 6 Sep 2012 11:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TneGkn8in+8L for ; Thu, 6 Sep 2012 11:30:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B466221F8745 for ; Thu, 6 Sep 2012 11:30:30 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3381425obb.31 for ; Thu, 06 Sep 2012 11:30:30 -0700 (PDT) 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:x-system-of-record; bh=x9Sb/Cax5h9DFtAAqif/IMgcNOJBdpTzKAKKoagLAXM=; b=CT6yz4sZBPHEWMY3UdmrpB6bGnYZZnJFL8BF+X9RM0knLOAAdClsXgqD/lfMwf88BX Z42YLqRcERkMsRrJN52hu0XcEBj/yc6/eOl9P5Fqmpx8R2otJf/S13GH5a5zE6b7yibu HxtvqE+svcgeuFy6eova8W261Xiiw1Ltks9dtCD/XBJvOOJBVXuTp/sKnFTPMn29rkZa F/oHOb4FAKZe5jnWvIotec0m91eRLSno/pcgrw2zcY8jkjJcm73lV3Mcb7p72jwstYlT xXAdB0ezJnHSrdLRGNoxsgX3dWHxSCcVIDGYEjegWR43brmN3WJYRdpocd4K7NEIrfQy NJaQ== X-Google-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:x-system-of-record :x-gm-message-state; bh=x9Sb/Cax5h9DFtAAqif/IMgcNOJBdpTzKAKKoagLAXM=; b=B1I1nuRiD80qfR8zhFKeCTDz8+7MSxDDxS2Te197q3F1ssJVVn/iepbzn/bXW7yP5H rS9YPCVU+iY4L3ceKAB6UuKMSVqeN9EXOQjlcBUCB8R2hoxRD1DKcyVIxC+5TYybGqyR v2IbXzFc4G2GOZZhC2ZsQYTQjIypX1pd39nKeDSGdHJWCprm/AAcuksLujuQkFUjKbtL ydWZ026qo3AFH1X7Ot0tJ52p5RolI9i3YDeuseBCD57v8VOVfsc+GCDkBbh+OA9BIVLe K+EsuYCLkJsK6H4dy+O6/2qnMkLJpReL+4nqM3ovdhoHhNHMOLvU2BNnyrmcycZ5Ty2C pOlA== Received: by 10.182.131.98 with SMTP id ol2mr3303510obb.69.1346956230129; Thu, 06 Sep 2012 11:30:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.131.98 with SMTP id ol2mr3303498obb.69.1346956229975; Thu, 06 Sep 2012 11:30:29 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Thu, 6 Sep 2012 11:30:29 -0700 (PDT) In-Reply-To: <5B68A271B9C97046963CB6A5B8D6F62C3A57E9C0@SOTTEXCH10.corp.ad.entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A57E9C0@SOTTEXCH10.corp.ad.entrust.com> Date: Thu, 6 Sep 2012 19:30:29 +0100 Message-ID: From: Ben Laurie To: Tim Moses Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmuWCJApfeZYSCQZx91aPuXSS21dbNI8P5yfcbCI3c1Tk5EYOuwbGAmhqR+bNdgSR/AujsIAWfHlDSPS3EB+v2AVO9d0rSEJ1zCU9uJC8+g3ifdEB4SuaSkV8swoQ0b/A0rMfzj8ojamH/z56FoHkZjKBioXiN/edaMpSlnx5GCtyWCsx6jJK5+h14rMjLMXi7rGIOg Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:30:32 -0000 On 6 September 2012 16:16, Tim Moses wrote: > Hi Ben. I am supportive of this initiative, and intend to participate. > > Perhaps a small clarification is warranted. Consider limiting the propos= ed solution to "Publicly-Trusted Certificates", which are defined as follow= s by CABForum: "A Certificate that is trusted by virtue of the fact that it= s corresponding Root Certificate is distributed as a trust anchor in widely= -available application software". I don't think we should place a bar to other certificates being logged, but certainly this is the set of certs that should be mandatory. I already said "public" in various places, so I presume you are suggesting I switch that to "publicy-trusted"? > > All the best. Tim. > > -----Original Message----- > From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] = On Behalf Of Ben Laurie > Sent: Thursday, September 06, 2012 10:32 AM > To: therightkey@ietf.org > Subject: [therightkey] Certificate Transparency Working Group? > > Would people be interested in starting a WG on Certificate Transparency? = If so, how about a BoF in Atlanta? > > Here's a draft charter... > > > CT IETF WG Draft Charter > > Objective > > Specify mechanisms and techniques that allow Internet applications to mon= itor and verify the issuance of public X.509 certificates such that all pub= lic issued certificates are available to applications, and each certificate= seen by an application can be efficiently shown to be in the log of issued= certificates. Furthermore, it should be possible to cryptographically veri= fy the correct operation of the log. > > > Optionally, do the same for certificate revocations. > > Problem Statement > > Currently it is possible for any CA to issue a certificate for any site w= ithout any oversight. This has led to some high profile mis-issuance of cer= tificates, such as by DigiNotar, a subsidiary of VASCO Data Security Intern= ational, in July 2011 (http://www.vasco.com/company/about_vasco/press_room/= news_archive/2011/news_diginotar_reports_security_incident.aspx). > > > The aim is to make it possible to detect such mis-issuance promptly throu= gh the use of a public log of all public issued certificates. > Domain owners can then monitor this log and, upon detecting mis-issuance,= take appropriate action. > > > This public log must also be able to efficiently demonstrate its own corr= ect operation, rather than introducing yet another party that must be trust= ed into the equation. > > > Clients should also be able to efficiently verify that certificates they = receive have indeed been entered into the public log. > > > For revocations, the aim would be similar: ensure that revocations are as= expected, that clients can efficiently obtain the revocation status of a c= ertificate and that the log is operating correctly. > > > Also, in both cases, the solution must be usable by browsers - this means= that it cannot add any round trips to page fetches, and that any data tran= sfers that are mandatory are of a reasonable size. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From tim.moses@entrust.com Thu Sep 6 11:41:38 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795AA21F8763 for ; Thu, 6 Sep 2012 11:41:38 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdQcOL+QN5B0 for ; Thu, 6 Sep 2012 11:41:36 -0700 (PDT) Received: from ipedge2.entrust.com (ipedge2.entrust.com [216.191.252.25]) by ietfa.amsl.com (Postfix) with ESMTP id B571221F8754 for ; Thu, 6 Sep 2012 11:41:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,380,1344225600"; d="scan'208";a="1879014" Received: from unknown (HELO sottexchcas1.corp.ad.entrust.com) ([10.4.51.93]) by ipedge2.entrust.com with ESMTP; 06 Sep 2012 14:41:33 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by sottexchcas1.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Thu, 6 Sep 2012 14:41:33 -0400 From: Tim Moses To: Ben Laurie Thread-Topic: [therightkey] Certificate Transparency Working Group? Thread-Index: AQHNjDx58kqlytdPxkC/V7LzkfP4ZZd9bC+ggAB5x4D//8AKzg== Date: Thu, 6 Sep 2012 18:41:32 +0000 Message-ID: <0FF5821F-1FC1-404F-B8CF-89DCC5AA0630@entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A57E9C0@SOTTEXCH10.corp.ad.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:41:38 -0000 Hi Ben. Yes. That's right. But, maybe that's unnecessarily restrictive. I= was trying to come up with a response to Denis' objection. As only a subs= et of all certificates will appear in the log (at the very least during a t= ransitional phase) and a subset of certificate-using software will only acc= ept certificates that do appear in the log, we need a graceful way of linin= g the two subsets up. All the best. Tim. On 2012-09-06, at 2:30 PM, "Ben Laurie" wrote: > On 6 September 2012 16:16, Tim Moses wrote: >> Hi Ben. I am supportive of this initiative, and intend to participate. >>=20 >> Perhaps a small clarification is warranted. Consider limiting the propo= sed solution to "Publicly-Trusted Certificates", which are defined as follo= ws by CABForum: "A Certificate that is trusted by virtue of the fact that i= ts corresponding Root Certificate is distributed as a trust anchor in widel= y-available application software". >=20 > I don't think we should place a bar to other certificates being > logged, but certainly this is the set of certs that should be > mandatory. I already said "public" in various places, so I presume you > are suggesting I switch that to "publicy-trusted"? >=20 >>=20 >> All the best. Tim. >>=20 >> -----Original Message----- >> From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org]= On Behalf Of Ben Laurie >> Sent: Thursday, September 06, 2012 10:32 AM >> To: therightkey@ietf.org >> Subject: [therightkey] Certificate Transparency Working Group? >>=20 >> Would people be interested in starting a WG on Certificate Transparency?= If so, how about a BoF in Atlanta? >>=20 >> Here's a draft charter... >>=20 >>=20 >> CT IETF WG Draft Charter >>=20 >> Objective >>=20 >> Specify mechanisms and techniques that allow Internet applications to mo= nitor and verify the issuance of public X.509 certificates such that all pu= blic issued certificates are available to applications, and each certificat= e seen by an application can be efficiently shown to be in the log of issue= d certificates. Furthermore, it should be possible to cryptographically ver= ify the correct operation of the log. >>=20 >>=20 >> Optionally, do the same for certificate revocations. >>=20 >> Problem Statement >>=20 >> Currently it is possible for any CA to issue a certificate for any site = without any oversight. This has led to some high profile mis-issuance of ce= rtificates, such as by DigiNotar, a subsidiary of VASCO Data Security Inter= national, in July 2011 (http://www.vasco.com/company/about_vasco/press_room= /news_archive/2011/news_diginotar_reports_security_incident.aspx). >>=20 >>=20 >> The aim is to make it possible to detect such mis-issuance promptly thro= ugh the use of a public log of all public issued certificates. >> Domain owners can then monitor this log and, upon detecting mis-issuance= , take appropriate action. >>=20 >>=20 >> This public log must also be able to efficiently demonstrate its own cor= rect operation, rather than introducing yet another party that must be trus= ted into the equation. >>=20 >>=20 >> Clients should also be able to efficiently verify that certificates they= receive have indeed been entered into the public log. >>=20 >>=20 >> For revocations, the aim would be similar: ensure that revocations are a= s expected, that clients can efficiently obtain the revocation status of a = certificate and that the log is operating correctly. >>=20 >>=20 >> Also, in both cases, the solution must be usable by browsers - this mean= s that it cannot add any round trips to page fetches, and that any data tra= nsfers that are mandatory are of a reasonable size. >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey From benl@google.com Thu Sep 6 11:45:53 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CBC21F8763 for ; Thu, 6 Sep 2012 11:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ttlju4AWtCFY for ; Thu, 6 Sep 2012 11:45:53 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3C1321F8751 for ; Thu, 6 Sep 2012 11:45:52 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3420241obb.31 for ; Thu, 06 Sep 2012 11:45:52 -0700 (PDT) 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:x-system-of-record; bh=hug3NHGgea6iIU5w945eJorC+AKbyNgSdeCXLHCJz3s=; b=Ti0RjVN+5EAMXt1+eloOEckw1kJhIYhPLgBuHw3JfRIrYaq5/ElxqYvjQpDSQpRqV9 UxDbym82eQgPBZs/HDIXRlQ4Sc2YStP7KOrdqUtKmGfRo0RRzjvvkGG9+D79tV6R/ymR q/rupmu2ncVVzfNps0wODjUKLqL5X/x+5+6ahN0YQoumpGeYng9QPPcHZVVXdrtFFpgK j3PJqlrdZfkEIuWyVEK1Bt1g31YBYIH4kG8FiEmvrLAyEE8nITDUu5ziJyyl/rbexqTq SHZmYSV6mzAtrV3YgG34BOvQsElgsyPW9IjLjD+LyYobbk8hoFouInjUfkyiLhpP0QXj 7kTQ== X-Google-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:x-system-of-record :x-gm-message-state; bh=hug3NHGgea6iIU5w945eJorC+AKbyNgSdeCXLHCJz3s=; b=BwsZw3oVznQc4c+ycZfHoqKgF2O53S8T8uN160QS07hgBRe1luEf2ZP1iHPDw/20ts hFU4TGNp8GHEfC8bGScC1G3CBJKHjJOAcwILL4Ym8x9LQ/oaGD4DjEcK0kLQlA7tEI5q KpZiZl6vrSI4MPJFvPrGrspeEjornlV6GCURDAl0V0ypEncleGPmeNm05yfzE1aUqgWD rr4+J41foSgKCzWw9jvgxYcHlkgOB41RhKBjMQMVSML1+iV76owwCVkZd1NfH6ih8Plh dCGNZS4334rDiGQIRZrMpLkbrJs+8wg7j64JEe10RkgZRecsjp+O5FZ2LhcQbr+D5Hcq XgFw== Received: by 10.60.8.67 with SMTP id p3mr3440277oea.128.1346957152629; Thu, 06 Sep 2012 11:45:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.8.67 with SMTP id p3mr3440259oea.128.1346957152380; Thu, 06 Sep 2012 11:45:52 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Thu, 6 Sep 2012 11:45:52 -0700 (PDT) In-Reply-To: <0FF5821F-1FC1-404F-B8CF-89DCC5AA0630@entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A57E9C0@SOTTEXCH10.corp.ad.entrust.com> <0FF5821F-1FC1-404F-B8CF-89DCC5AA0630@entrust.com> Date: Thu, 6 Sep 2012 19:45:52 +0100 Message-ID: From: Ben Laurie To: Tim Moses Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnISUfog0HKIAZlDeEDNdLamFtysFbUaZ+6cXVlIGHYxEOSEmusNO5bGKJl/suapkmJJEZ0axFZvopIVK3TS0PIQvJvrHvFyQn6ENXBnm0+TA0WjS5YBaI8xpKbX0TwQpoWIBPqsq3WXt2aDqbnqD7/cDzRC78osiUbxiOZmYb+bBh8MHj/IgxjvSlwtasMYCJTKsEl Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:45:54 -0000 On 6 September 2012 19:41, Tim Moses wrote: > Hi Ben. Yes. That's right. But, maybe that's unnecessarily restrictive.= I was trying to come up with a response to Denis' objection. Perhaps I missed something - I am not sure what Denis' objection was? > As only a subset of all certificates will appear in the log (at the very = least during a transitional phase) and a subset of certificate-using softwa= re will only accept certificates that do appear in the log, we need a grace= ful way of lining the two subsets up. > > All the best. Tim. > > > > On 2012-09-06, at 2:30 PM, "Ben Laurie" wrote: > >> On 6 September 2012 16:16, Tim Moses wrote: >>> Hi Ben. I am supportive of this initiative, and intend to participate. >>> >>> Perhaps a small clarification is warranted. Consider limiting the prop= osed solution to "Publicly-Trusted Certificates", which are defined as foll= ows by CABForum: "A Certificate that is trusted by virtue of the fact that = its corresponding Root Certificate is distributed as a trust anchor in wide= ly-available application software". >> >> I don't think we should place a bar to other certificates being >> logged, but certainly this is the set of certs that should be >> mandatory. I already said "public" in various places, so I presume you >> are suggesting I switch that to "publicy-trusted"? >> >>> >>> All the best. Tim. >>> >>> -----Original Message----- >>> From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org= ] On Behalf Of Ben Laurie >>> Sent: Thursday, September 06, 2012 10:32 AM >>> To: therightkey@ietf.org >>> Subject: [therightkey] Certificate Transparency Working Group? >>> >>> Would people be interested in starting a WG on Certificate Transparency= ? If so, how about a BoF in Atlanta? >>> >>> Here's a draft charter... >>> >>> >>> CT IETF WG Draft Charter >>> >>> Objective >>> >>> Specify mechanisms and techniques that allow Internet applications to m= onitor and verify the issuance of public X.509 certificates such that all p= ublic issued certificates are available to applications, and each certifica= te seen by an application can be efficiently shown to be in the log of issu= ed certificates. Furthermore, it should be possible to cryptographically ve= rify the correct operation of the log. >>> >>> >>> Optionally, do the same for certificate revocations. >>> >>> Problem Statement >>> >>> Currently it is possible for any CA to issue a certificate for any site= without any oversight. This has led to some high profile mis-issuance of c= ertificates, such as by DigiNotar, a subsidiary of VASCO Data Security Inte= rnational, in July 2011 (http://www.vasco.com/company/about_vasco/press_roo= m/news_archive/2011/news_diginotar_reports_security_incident.aspx). >>> >>> >>> The aim is to make it possible to detect such mis-issuance promptly thr= ough the use of a public log of all public issued certificates. >>> Domain owners can then monitor this log and, upon detecting mis-issuanc= e, take appropriate action. >>> >>> >>> This public log must also be able to efficiently demonstrate its own co= rrect operation, rather than introducing yet another party that must be tru= sted into the equation. >>> >>> >>> Clients should also be able to efficiently verify that certificates the= y receive have indeed been entered into the public log. >>> >>> >>> For revocations, the aim would be similar: ensure that revocations are = as expected, that clients can efficiently obtain the revocation status of a= certificate and that the log is operating correctly. >>> >>> >>> Also, in both cases, the solution must be usable by browsers - this mea= ns that it cannot add any round trips to page fetches, and that any data tr= ansfers that are mandatory are of a reasonable size. >>> _______________________________________________ >>> therightkey mailing list >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/listinfo/therightkey From tim.moses@entrust.com Thu Sep 6 11:54:29 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED6721F8745 for ; Thu, 6 Sep 2012 11:54:29 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmGCYxeF4uwH for ; Thu, 6 Sep 2012 11:54:28 -0700 (PDT) Received: from ipedge1.entrust.com (ipedge1.entrust.com [216.191.252.10]) by ietfa.amsl.com (Postfix) with ESMTP id F09F821F8744 for ; Thu, 6 Sep 2012 11:54:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,380,1344225600"; d="scan'208";a="6134767" Received: from unknown (HELO SOTTEXCHCAS2.corp.ad.entrust.com) ([10.4.51.224]) by ipedge1.entrust.com with ESMTP; 06 Sep 2012 14:54:25 -0400 Received: from SOTTEXCH10.corp.ad.entrust.com ([fe80::389b:f45b:7ea1:79b7]) by SOTTEXCHCAS2.corp.ad.entrust.com ([::1]) with mapi id 14.02.0318.001; Thu, 6 Sep 2012 14:54:25 -0400 From: Tim Moses To: Ben Laurie Thread-Topic: [therightkey] Certificate Transparency Working Group? Thread-Index: AQHNjDx58kqlytdPxkC/V7LzkfP4ZZd9bC+ggAB5x4D//8AKzoAAREMA//+/VY4= Date: Thu, 6 Sep 2012 18:54:24 +0000 Message-ID: <03E7FFF5-4AED-4011-9DA2-CA3D1877F56E@entrust.com> References: <5B68A271B9C97046963CB6A5B8D6F62C3A57E9C0@SOTTEXCH10.corp.ad.entrust.com> <0FF5821F-1FC1-404F-B8CF-89DCC5AA0630@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:54:29 -0000 He said ... The second part of the objective (i.e. making all public issued certificat= es available to applications) may be dangerous in many situations. On Sep 6, 2012, at 2:45 PM, "Ben Laurie" wrote: > On 6 September 2012 19:41, Tim Moses wrote: >> Hi Ben. Yes. That's right. But, maybe that's unnecessarily restrictive= . I was trying to come up with a response to Denis' objection. >=20 > Perhaps I missed something - I am not sure what Denis' objection was? >=20 >> As only a subset of all certificates will appear in the log (at the very= least during a transitional phase) and a subset of certificate-using softw= are will only accept certificates that do appear in the log, we need a grac= eful way of lining the two subsets up. >>=20 >> All the best. Tim. >>=20 >>=20 >>=20 >> On 2012-09-06, at 2:30 PM, "Ben Laurie" wrote: >>=20 >>> On 6 September 2012 16:16, Tim Moses wrote: >>>> Hi Ben. I am supportive of this initiative, and intend to participate= . >>>>=20 >>>> Perhaps a small clarification is warranted. Consider limiting the pro= posed solution to "Publicly-Trusted Certificates", which are defined as fol= lows by CABForum: "A Certificate that is trusted by virtue of the fact that= its corresponding Root Certificate is distributed as a trust anchor in wid= ely-available application software". >>>=20 >>> I don't think we should place a bar to other certificates being >>> logged, but certainly this is the set of certs that should be >>> mandatory. I already said "public" in various places, so I presume you >>> are suggesting I switch that to "publicy-trusted"? >>>=20 >>>>=20 >>>> All the best. Tim. >>>>=20 >>>> -----Original Message----- >>>> From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.or= g] On Behalf Of Ben Laurie >>>> Sent: Thursday, September 06, 2012 10:32 AM >>>> To: therightkey@ietf.org >>>> Subject: [therightkey] Certificate Transparency Working Group? >>>>=20 >>>> Would people be interested in starting a WG on Certificate Transparenc= y? If so, how about a BoF in Atlanta? >>>>=20 >>>> Here's a draft charter... >>>>=20 >>>>=20 >>>> CT IETF WG Draft Charter >>>>=20 >>>> Objective >>>>=20 >>>> Specify mechanisms and techniques that allow Internet applications to = monitor and verify the issuance of public X.509 certificates such that all = public issued certificates are available to applications, and each certific= ate seen by an application can be efficiently shown to be in the log of iss= ued certificates. Furthermore, it should be possible to cryptographically v= erify the correct operation of the log. >>>>=20 >>>>=20 >>>> Optionally, do the same for certificate revocations. >>>>=20 >>>> Problem Statement >>>>=20 >>>> Currently it is possible for any CA to issue a certificate for any sit= e without any oversight. This has led to some high profile mis-issuance of = certificates, such as by DigiNotar, a subsidiary of VASCO Data Security Int= ernational, in July 2011 (http://www.vasco.com/company/about_vasco/press_ro= om/news_archive/2011/news_diginotar_reports_security_incident.aspx). >>>>=20 >>>>=20 >>>> The aim is to make it possible to detect such mis-issuance promptly th= rough the use of a public log of all public issued certificates. >>>> Domain owners can then monitor this log and, upon detecting mis-issuan= ce, take appropriate action. >>>>=20 >>>>=20 >>>> This public log must also be able to efficiently demonstrate its own c= orrect operation, rather than introducing yet another party that must be tr= usted into the equation. >>>>=20 >>>>=20 >>>> Clients should also be able to efficiently verify that certificates th= ey receive have indeed been entered into the public log. >>>>=20 >>>>=20 >>>> For revocations, the aim would be similar: ensure that revocations are= as expected, that clients can efficiently obtain the revocation status of = a certificate and that the log is operating correctly. >>>>=20 >>>>=20 >>>> Also, in both cases, the solution must be usable by browsers - this me= ans that it cannot add any round trips to page fetches, and that any data t= ransfers that are mandatory are of a reasonable size. >>>> _______________________________________________ >>>> therightkey mailing list >>>> therightkey@ietf.org >>>> https://www.ietf.org/mailman/listinfo/therightkey From Jeff.Hodges@KingsMountain.com Thu Sep 6 17:09:49 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51FB21F84F8 for ; Thu, 6 Sep 2012 17:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a35BwrtN3ViT for ; Thu, 6 Sep 2012 17:09:49 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 2AFDE21F84F2 for ; Thu, 6 Sep 2012 17:09:49 -0700 (PDT) Received: (qmail 22211 invoked by uid 0); 7 Sep 2012 00:09:47 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 7 Sep 2012 00:09:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=OLNXwEYdb3vTU4isl6o3DMkrOsrDVABUgNYY7+RAmcs=; b=y2hrfcoTf6KlfijXJzbUc0gd3LfOAPASO/Jozo9iBOtL5yyuShrSn8rzoZaoSv3fdDjvXoU95YlcqHCFEpo29WIHodhYRVjDB17gkgFiByZBdCbjHGV2KTyFhy431m7e; Received: from [24.4.122.173] (port=57486 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T9m8p-0005Jz-4r; Thu, 06 Sep 2012 18:09:47 -0600 Message-ID: <50493B49.9020601@KingsMountain.com> Date: Thu, 06 Sep 2012 17:09:45 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Ben Laurie Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: therightkey@ietf.org Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 00:09:49 -0000 I am supportive of this initiative, and intend to participate. In terms of quick comments on draft charter, having pointers to the existing work would be good, e.g.. Certificate Transparency: Spec and Working Code http://www.links.org/?p=1226 http://code.google.com/p/certificate-transparency/source/browse/ Certificate Transparency Version 2 http://www.links.org/?p=1259 http://sump2.links.org/files/CertificateTransparencyVersion2.pdf It looks like upon a quick skim that the I-D source might have kept up with CertificateTransparencyVersion2.pdf.. http://code.google.com/p/certificate-transparency/source/browse/doc/sunlight.xml yes? Having that I-D submitted before 24-Sep would be helpful in terms of getting an actual BoF scheduled (remember I-Ds can be very drafty and rough) HTH =JeffH From rob.stradling@comodo.com Fri Sep 7 02:53:18 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A619721F878E for ; Fri, 7 Sep 2012 02:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtaDlpa6R1Nn for ; Fri, 7 Sep 2012 02:53:17 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3568E21F8786 for ; Fri, 7 Sep 2012 02:53:14 -0700 (PDT) Received: (qmail 2038 invoked from network); 7 Sep 2012 09:53:12 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 7 Sep 2012 09:53:12 -0000 Received: (qmail 14138 invoked by uid 1000); 7 Sep 2012 09:53:11 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 07 Sep 2012 10:53:11 +0100 Message-ID: <5049C407.2070300@comodo.com> Date: Fri, 07 Sep 2012 10:53:11 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Laurie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:53:18 -0000 Hi Ben. There is interest at Comodo. I would like to participate in a CT WG. On 06/09/12 15:32, Ben Laurie wrote: > Would people be interested in starting a WG on Certificate > Transparency? If so, how about a BoF in Atlanta? > > Here's a draft charter... > > > CT IETF WG Draft Charter > > Objective > > Specify mechanisms and techniques that allow Internet applications to > monitor and verify the issuance of public X.509 certificates such that > all public issued certificates are available to applications, and each > certificate seen by an application can be efficiently shown to be in > the log of issued certificates. Furthermore, it should be possible to > cryptographically verify the correct operation of the log. > > > Optionally, do the same for certificate revocations. > > Problem Statement > > Currently it is possible for any CA to issue a certificate for any > site without any oversight. This has led to some high profile > mis-issuance of certificates, such as by DigiNotar, a subsidiary of > VASCO Data Security International, in July 2011 > (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx). > > > The aim is to make it possible to detect such mis-issuance promptly > through the use of a public log of all public issued certificates. > Domain owners can then monitor this log and, upon detecting > mis-issuance, take appropriate action. > > > This public log must also be able to efficiently demonstrate its own > correct operation, rather than introducing yet another party that must > be trusted into the equation. > > > Clients should also be able to efficiently verify that certificates > they receive have indeed been entered into the public log. > > > For revocations, the aim would be similar: ensure that revocations are > as expected, that clients can efficiently obtain the revocation status > of a certificate and that the log is operating correctly. > > > Also, in both cases, the solution must be usable by browsers - this > means that it cannot add any round trips to page fetches, and that any > data transfers that are mandatory are of a reasonable size. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From leifj@mnt.se Fri Sep 7 03:21:37 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFE021E8034 for ; Fri, 7 Sep 2012 03:21:37 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1PIWU9Tg7XT for ; Fri, 7 Sep 2012 03:21:36 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 766E211E808A for ; Fri, 7 Sep 2012 03:21:36 -0700 (PDT) Received: from [109.105.104.195] (dhcp61.se-tug.nordu.net [109.105.104.195] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q87ALUIg002496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Sep 2012 12:21:34 +0200 (CEST) Message-ID: <5049CAAA.7090709@mnt.se> Date: Fri, 07 Sep 2012 12:21:30 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: therightkey@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:21:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/06/2012 04:32 PM, Ben Laurie wrote: > Would people be interested in starting a WG on Certificate > Transparency? If so, how about a BoF in Atlanta? > I'd go to that bof -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBJyqoACgkQ8Jx8FtbMZncEwQCfSE/dlM89D4JBzXUuOZ1MzIls l4UAniQTcoTNvkyja4XtwYYo4mGCzqX+ =M+HE -----END PGP SIGNATURE----- From leifj@mnt.se Fri Sep 7 03:26:09 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EAC21F87CA for ; Fri, 7 Sep 2012 03:26:09 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ekb3rqkcg3h for ; Fri, 7 Sep 2012 03:26:08 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 4A89721F87C9 for ; Fri, 7 Sep 2012 03:26:08 -0700 (PDT) Received: from [109.105.104.195] (dhcp61.se-tug.nordu.net [109.105.104.195] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q87AQ4sQ023216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Sep 2012 12:26:07 +0200 (CEST) Message-ID: <5049CBBC.6050107@mnt.se> Date: Fri, 07 Sep 2012 12:26:04 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: therightkey@ietf.org References: <50493B49.9020601@KingsMountain.com> In-Reply-To: <50493B49.9020601@KingsMountain.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:26:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/07/2012 02:09 AM, =JeffH wrote: > I am supportive of this initiative, and intend to participate. > > In terms of quick comments on draft charter, having pointers to > the existing work would be good, e.g.. The proposed charter doesn't mention any one technique and I'm hoping the intent of a Transparancy WG would be to look at more than the proposal that happens to be called "transparency", yes? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBJy7wACgkQ8Jx8FtbMZnfgMACdFByoecq0LtE/SllTTGzZwhGA imoAoJDPBRW7R1pP/qU4K8SHgvgfbOAL =F43w -----END PGP SIGNATURE----- From SChokhani@cygnacom.com Fri Sep 7 05:02:31 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0801F21F8703 for ; Fri, 7 Sep 2012 05:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WebHq0gjf+wO for ; Fri, 7 Sep 2012 05:02:30 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6D98A21F86EB for ; Fri, 7 Sep 2012 05:02:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,385,1344225600"; d="scan'208,217";a="6141335" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 07 Sep 2012 08:02:30 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 7 Sep 2012 08:02:29 -0400 From: Santosh Chokhani To: "therightkey@ietf.org" Date: Fri, 7 Sep 2012 08:02:29 -0400 Thread-Topic: Certificate Transparency Working Group? Thread-Index: Ac2M7sI8OCnLV18/Q8eQYDrzYMMFGgAAcDEQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AF362EC789scygexch7cygnac_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 07 Sep 2012 05:03:04 -0700 Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:02:31 -0000 --_000_B83745DA469B7847811819C5005244AF362EC789scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ben Laurie, I am posting this at the suggestion of Stephen Ferrell. There is no eviden= ce that he supports or is against my analysis. He just thought this mail l= ist is the appropriate place to make my point.. My basic tenet is that the OCSP certinfo extension being discussed in PKIX = does not protect against RA compromise and may also not protect against CA = compromise since the attacker who compromised the CA may be able to create = an OCSP Responder certificate and either also put bogus OCSP pointer in the= minted certificates or use DNS poisoning on the relying parties. Thus, I think the certificate transparency is worth discussing. Santosh Chokhani CygnaCom Solutions --_000_B83745DA469B7847811819C5005244AF362EC789scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ben Laurie,

 

I am posting this = at the suggestion of Stephen Ferrell.  There is no evidence that he su= pports or is against my analysis.  He just thought this mail list is t= he appropriate place to make my point..

 

My basic tenet is that the OCSP certinf= o extension being discussed in PKIX does not protect against RA compromise = and may also not protect against CA compromise since the attacker who compr= omised the CA may be able to create an OCSP Responder certificate and eithe= r also put bogus OCSP pointer in the minted certificates or use DNS poisoni= ng on the relying parties.

 

Thus, I think the certificate transparency is worth = discussing.

 

 

Santosh Chokhani
Cy= gnaCom Solutions

 

= --_000_B83745DA469B7847811819C5005244AF362EC789scygexch7cygnac_-- From benl@google.com Fri Sep 7 05:51:51 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764C821F8794 for ; Fri, 7 Sep 2012 05:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob8+MMWeVxRh for ; Fri, 7 Sep 2012 05:51:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46DB421F8790 for ; Fri, 7 Sep 2012 05:51:50 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4944562obb.31 for ; Fri, 07 Sep 2012 05:51:49 -0700 (PDT) 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:x-system-of-record; bh=67PtbaRXzFo5MqekrD2aViqYviQuM9pwShKz6jYqwtc=; b=JPPjsjRH1Loe/HB3v+tldezZN5Tkc1OmxkPAe54N5vzR8v8gMbc/T3I2hn/Z7z16yH 9wE0gZW4FW3GZnSx7khFjBtxu3tR9KpksobGADfCJS6yAnz6EBKX6ENChmrNocDutdxQ kT3ofyoeqyTC8ngtbax3qLp38WzIheyE/iG34Ffb4xCDU4Rfc3UHOJSS3hs01urprXKt uX2yEeKkTKVqiH58bNm9unh+ad289qiGf0prfF51NPIQkQ+zIvatCDP17Yiq2gwaC1hB txBhajfr1UlVZo5JiHLuT0HeQFqGYtk5GG0oBKBru/JfwGoDEcawHaXwdq1XoDCT51a2 ONbw== X-Google-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:x-system-of-record:x-gm-message-state; bh=67PtbaRXzFo5MqekrD2aViqYviQuM9pwShKz6jYqwtc=; b=W4gYMBHMe+qfX/VLybjMi68ztJAI5y/ankbHoWoqAkHd4TvjoWYXmDJyBzKXVTbaj/ tGxF8MFTluY6JtoEqRwhjNWxI7XGT3SLpkvKBhFhjZxK62ZuShImVT9cXvKDrSHBkGHH ZQYhI9uX4PREE1aapLMwnwXo+1wZb3CRI4M5xYg4l4lGo6XO5NB8Td5hr3VVemy9t8r6 rC8ib40jhX2DgMbM4ti6QlJ25MdbRpeuwlHxPDgnPj1MmbFgQxKfThE9ADtq/LKq/A/Q Y0P/tzP16fkVbLBKd9kYq++xMblHutuChS22b3saOc/UefQ8iSm4SF64zRootgAeQahR FezA== Received: by 10.60.27.10 with SMTP id p10mr5675494oeg.49.1347022309619; Fri, 07 Sep 2012 05:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.27.10 with SMTP id p10mr5675481oeg.49.1347022309522; Fri, 07 Sep 2012 05:51:49 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Fri, 7 Sep 2012 05:51:49 -0700 (PDT) In-Reply-To: <50493B49.9020601@KingsMountain.com> References: <50493B49.9020601@KingsMountain.com> Date: Fri, 7 Sep 2012 13:51:49 +0100 Message-ID: From: Ben Laurie To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmfAXcFsliYXjX8BZQZ141+17NN9WBFY1JI75tmI3dgKKQYi6fmlWirQ/VJo+nVD3TW+fYifb/hqtv29mhLyMYyHyZOKiAIorK3vIPu51GEdNhJ2ab17E171cbG1ieZBeOUqLlfthDwIPW8pDC+duksQFJUzOwbsLBqKGaFKw8awi62uNe3vYuz56V96s3FOAufIaNx Cc: therightkey@ietf.org Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:51:51 -0000 On 7 September 2012 01:09, =JeffH wrote: > I am supportive of this initiative, and intend to participate. > > In terms of quick comments on draft charter, having pointers to the existing > work would be good, e.g.. > > Certificate Transparency: Spec and Working Code > http://www.links.org/?p=1226 > http://code.google.com/p/certificate-transparency/source/browse/ > > Certificate Transparency Version 2 > http://www.links.org/?p=1259 > http://sump2.links.org/files/CertificateTransparencyVersion2.pdf > > It looks like upon a quick skim that the I-D source might have kept up with > CertificateTransparencyVersion2.pdf.. > > http://code.google.com/p/certificate-transparency/source/browse/doc/sunlight.xml > > yes? Yes - actually consistent with v2.1a, which I just uploaded to www.links.org. > Having that I-D submitted before 24-Sep would be helpful in terms of getting > an actual BoF scheduled (remember I-Ds can be very drafty and rough) Will do - we're going to add some more to it next week so I'll wait for that. > > HTH > > =JeffH > > From benl@google.com Fri Sep 7 06:20:04 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A2921E8051 for ; Fri, 7 Sep 2012 06:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRHHB2BSgv2z for ; Fri, 7 Sep 2012 06:20:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E0F9021E8050 for ; Fri, 7 Sep 2012 06:20:02 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4998116obb.31 for ; Fri, 07 Sep 2012 06:20:02 -0700 (PDT) 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 :x-system-of-record; bh=Fl82Cpc+gYAyEfw19G8HCUsP6qaIRKN70MNXvBHsrWE=; b=auFJQfgFV8H8CxYBX3UJXGskU0RqllD2pWY/QGm8+t7ofqI/fDnjZnG9XPiS2zwWxA gjv5o0VvpaAyw9fpZyXEz/PQ7FOChK7kx69iP9leX33DdTvEUltWAQHA+yQ/Rh/gjloi 4YZNoZKITlbgZpJD+60Kio+nZLdzKIDJctHugywohYzAVgj3+gIh/4WJoqe9MfSoWDPb Hz7LYX1QPvRHnZ3zWHxauwNyRK0TpmeUGrFxGvofD3R9N+0o1q/2LZwccaaZ4CVYI5aY mZUolyXPe/k7+bsEb4Y4Ms1+J65S4RtNWJQz8cBsS37xMkWTSCEgQQFoTwZ2Lajyjeqa 1psA== X-Google-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 :x-system-of-record:x-gm-message-state; bh=Fl82Cpc+gYAyEfw19G8HCUsP6qaIRKN70MNXvBHsrWE=; b=A2qsZtaAnbUjo4p/It9NEIKWLLfvDRwm05ZBZlGJVpIfTzlQOy+HFaVVpRZTXDFHrT Y+08+K4WbSM89rRPrpbsPho260aC6REAM5jU9Z9YfAFAnpSR5C5qM43VWgbP7U4jyJps FDV18nppjjUcAMSuVpHOLfMztcfyXVWHNyI/8Hn37pYkehYON9G8tQU/oiEdQUewiLWB A96n7aoozuFpaX7/88PiBZo4+pGFOSXQeZXcpxyb/hEtm9RD9mCGVMdoCX+ZSYpVTLIt +Sppbpwkz+bMEI0HD6RmHcIPQELSscyF8rBhmcA+d/PGD8QwabtUYAKvWqo0H/BM5opr 4K8w== Received: by 10.60.11.104 with SMTP id p8mr6002781oeb.133.1347024002394; Fri, 07 Sep 2012 06:20:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.11.104 with SMTP id p8mr6002768oeb.133.1347024002281; Fri, 07 Sep 2012 06:20:02 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Fri, 7 Sep 2012 06:20:02 -0700 (PDT) Date: Fri, 7 Sep 2012 14:20:02 +0100 Message-ID: From: Ben Laurie To: sidr@ietf.org, therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmROFd0Q+61P4O5NliXC6haz/Wd3ceMwxAqB/CX+90gBGQDqEk/YTeIpgu9Z0Pq3z9dBoSI1HTzCuaxHeEeB53efIyb7q6Bg/bsSZVrsfq9yaDqzS/8P0AONrlgoL29TwTFZTehKbsQ/+9ngoafgbw/7R6SgIY1Fk3EzRm+8wR0xSuxlqBd7ZrxqsgWaFXbE2DFn+ZT Subject: [therightkey] Certificate Transparency WG X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:20:05 -0000 It has been suggested to me that the SIDR WG might be interested in Certificate Transparency and a possible BoF in Atlanta. Please send followup discussion to therightkey@ietf.org. Here's an (updated) draft charter. CT IETF WG Draft Charter version 2 Objective Specify mechanisms and techniques that allow Internet applications to monitor and verify the issuance of public X.509 certificates such that all issued certificates are available to applications, and each certificate seen by an application can be efficiently shown to be in the log of issued certificates. Furthermore, it should be possible to cryptographically verify the correct operation of the log. Optionally, do the same for certificate revocations. Problem Statement Currently it is possible for any CA to issue a certificate for any purpose without any oversight. This has led to some high profile mis-issuance of web certificates, such as by DigiNotar, a subsidiary of VASCO Data Security International, in July 2011 (http://www.vasco.com/company/about_vasco/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx). The aim is to make it possible to detect such mis-issuance promptly through the use of a public log of all public issued certificates. Domain owners can then monitor this log and, upon detecting mis-issuance, take appropriate action. This public log must also be able to efficiently demonstrate its own correct operation, rather than introducing yet another party that must be trusted into the equation. Clients should also be able to efficiently verify that certificates they receive have indeed been entered into the public log. For revocations, the aim would be similar: ensure that revocations are as expected, that clients can efficiently obtain the revocation status of a certificate and that the log is operating correctly. Also, in both cases, the solution must be usable by browsers - this means that it cannot add any round trips to page fetches, and that any data transfers that are mandatory are of a reasonable size. Existing Work Certificate Transparency v2.1a (http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf) Spec and working code: http://code.google.com/p/certificate-transparency/source/browse/ From hallam@gmail.com Fri Sep 7 07:04:20 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4982C21E805D for ; Fri, 7 Sep 2012 07:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKYB0KgfAwtF for ; Fri, 7 Sep 2012 07:04:19 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 764F321E8051 for ; Fri, 7 Sep 2012 07:04:19 -0700 (PDT) Received: by ggnh4 with SMTP id h4so543023ggn.31 for ; Fri, 07 Sep 2012 07:04:19 -0700 (PDT) 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=Ws8VFtPg/D8MgUAdARPoeucoRQa63dEBd3rgzQjGDuE=; b=XEuF2O4hl9Li3B6mMr+Ee090HKW77527ytQqd+8U8GU4d7nYtrzMmo1EnQ6ojn+X6L zJirZiLqG0aXVwp+PrKQK6JayllmuoBcGFTIFYzHCpvwcvLB9sX9nBvYPOUfcEoe2Mdf uH9ouPGFfSU3Imk3/63GWsf4+kjtf4wAp7SdKgNzu3VFiOFhon6xbMG/G7LW+Z6rEG4+ z97dWrkNmHGkB/0v3OaQLe0mhr8TRQCAYAPkFA3joH24NPRKtqntLKbtVfnmDcv3AQCd dDOfYkqD+kmM8jJNeWvS/IlbAaR9njsU9lrvxawEwPD5pr5Pr1xeYkbGMIyRXwYnbBrN iDZg== MIME-Version: 1.0 Received: by 10.58.137.34 with SMTP id qf2mr8082381veb.9.1347026658778; Fri, 07 Sep 2012 07:04:18 -0700 (PDT) Received: by 10.58.170.103 with HTTP; Fri, 7 Sep 2012 07:04:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 10:04:18 -0400 Message-ID: From: Phillip Hallam-Baker To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:04:20 -0000 I think there are two questions here: 1) Is there industry interest in support for some form of CA transparency? 2) Is the Ben, Adam, Chris et. al. proposal the approach to take? If the answer to the first one is 'no' then there is no point in a BOF because it would be like having a WG to decide what colour to paint the White House, however interested the participants might be in the proceedings they would have no practical effect. The second question is not nearly so important as the first. There has to be some demonstration that the subject area is an IETF problem rather than an IRTF one but discussions on which approach or which approaches to take would seem to me to be exactly the sort of thing that should be considered at the BOF. So the point raised by Denis seems to be an argument for a BOF rather than against one. He is interested in the subject area but is proposing a different approach. Given that the plan is to shut PKIX down in the near future, I don't see how it can address any of the OCSP responder approaches to transparency. In addition to the proposal made by Denis, there is the proposal I made with Rob and other folk have also raised from time to time. It would seem to me that this set of approaches is something that would be better served by addressing them in a new WG rather than trying to squeak them in before PKIX sets up shop. PKIX never had a monopoly on X.509v3 extensions so closing PKIX should not mean the end of development there. Comodo is interested in CA transparency, whether we could support a proposal that requires us to share our customer lists with competitors is a different matter. There might well be a deployment deadlock situation inherent in the protocol, I can well imagine a situation in which all the major CAs are willing to deploy after someone else agrees to go first. Another proposal that probably deserves some consideration is a germ of an idea that Rick Andrews proposed on the CABForum public list (so I will feel free to raise it here). Rick proposed that national CAs issue a statement that they only issue certificates for one country and so all others should be ignored. Now there are many problems with that particular proposal, I don't think that national constraints give a lot of leverage. But it is possible that some form of 'CA root profile' or 'Certificate signing certificate profile' that goes beyond client-enforceable constraints might have value. This gets to a problem I am having on my home network right now. It is very difficult to work out what part of the system is causing the periodic network storms because none of the components on the network provide a description of what 'normal' operation actually is. Every device on my network has the ability to perform a SYN flood attack at periodic intervals. That seems like a very bad idea to me. I think that Transparency is the next big idea in Computer Security. Addressing core PKI first seems like the best approach as it is the point where we get the most leverage. Where my approach differs from Ben's is that he is proposing a scheme (call it Strong Transparency) that allows clients to tell when they are being spoofed and I am more interested in the problem of how to make it possible for any party with the requisite resources to tell when someone might be being spoofed (Weak Transparency). The difference between strong and weak transparency is the resources that we can bring to the task and the outcomes we can accept. Strong transparency is limited to the information on hand at the client processed according to set rules, Weak transparency can engage information from any source whatsoever and apply proprietary analysis. Since the only actions a client can take have a significant impact on the user (warnings, deny access to site), Strong transparency requires a very high degree of confidence in the result. False positives are much less important in Weak transparency as the action taken is most likely to be 'tell a human analyst who makes personal contact with the CA in question'. Another possibility is that we might bridge the gap between the two by using some scheme like Omnibroker that moves the task of establishing network connections out of the client completely. That provides the immediate protection that ST offers while retaining the flexibility advantage of WT. My view is that Weak Transparency is the low hanging fruit here and Strong Transparency is a hard problem. I am willing to spend time on Strong Transparency but only if that does not preclude the Weak Transparency approach. I think we can definitely get some form of WT deployed that justifies the effort involved. Getting WT deployment will help rather than hinder deployment of ST as it will provide the necessary testbed to tell what works and how well it works. Given the reluctance of the browser providers to deploy revocation checking properly, I have a hard time believing that browsers are going to be hard failing on CT irregularities. So I rather suspect that what we will end up with is a WT system plus a distributed catenate certificate notary infrastructure that we don't use for this particular task but is useful for many other tasks. From palmer@google.com Fri Sep 7 08:36:19 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691E321F8757 for ; Fri, 7 Sep 2012 08:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sasmYab7VMM for ; Fri, 7 Sep 2012 08:36:18 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9287D21F8723 for ; Fri, 7 Sep 2012 08:36:18 -0700 (PDT) Received: by wibhi8 with SMTP id hi8so1526130wib.13 for ; Fri, 07 Sep 2012 08:36:17 -0700 (PDT) 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:x-system-of-record; bh=Q2HFGKS5EAlPvxjSdhTbm+S/qq4WNpCTxQd6IvdZ6aM=; b=JrKJFKVH9ouHULWcyMomFTmGhyi2VWaD1TWPNiInEb9eUgBf25yqnnCLEGBJSYMNwC lSEKWkPZKJJAD9LsAsx5+izrZCMrU+lPg3UGYooYKADrcsKcDg3oF1GC9sXdslCj0JoV G4wAboHnEXyok/q2OveDnJa9uPUqY4EiFNoe3J+JLW20Z1qQaMMTpJncqdzCDWFyC+2i HVOtVAacWmAcauk1tQpoUuNCLJOUGubAzN+d7z+vxgpMwK95t1FVuVA3f0o10Z9imAPa i0ohdF75I2+7IBs+1lSphm41UMgjRjnG7bpEP26ufnIEG4zOY5HoeycGzWh7+GXxmim+ BqBA== X-Google-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:x-system-of-record:x-gm-message-state; bh=Q2HFGKS5EAlPvxjSdhTbm+S/qq4WNpCTxQd6IvdZ6aM=; b=YjkaU0hwF2AV0pxKb3zOttC03RwRQavaAEW8omPE2s2Ct4b1rnW+KK+OpkkT9HPD38 DmRNTB9bdGoeNJBYSRm+ak2MZsUxioEU/RgJAsPQDyY1J1eJAfCv7wCf6wJ6Q1QAczuq jIy99MD0PeToKzGrqRbxwq7d45nKYM5qhoIqVKfzSNXWZwUEILr5yAvzpLUhfIy9latL hlZ2CqVuiXE8KVkB02WLUA6M3E/pheryzZ8bl6oiLGdyH6TkwLkwAvJMEFZWuOkSoPXk Ajkn1Bm4pF1eyX0xLAKb0bQrTNCoRz8tFSw9n9/XXLtmktU4vEZJm09JiVUXMLxVSQFT 0QNg== Received: by 10.180.102.136 with SMTP id fo8mr13040522wib.19.1347032177793; Fri, 07 Sep 2012 08:36:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.102.136 with SMTP id fo8mr13040490wib.19.1347032177504; Fri, 07 Sep 2012 08:36:17 -0700 (PDT) Received: by 10.223.66.219 with HTTP; Fri, 7 Sep 2012 08:36:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 08:36:17 -0700 Message-ID: From: Chris Palmer To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkka4Pix/L+8E09mGMMTsGC8dpgIVbtv2aPz4aUULbDCggtiVFbvPJwqHnZqkxyZv6Y4x7mJomi5ADjttSyQjvPBWqHsnezhBtbpNDaK4i7JZOek+WzTY75RstpvkpU2OIo0setmmxyHOkerIkble9iZoYY8AWkAusvAg2bTKC/yFWfpf/HRlUmuttZTe6ZkdHaMAA2 Cc: Santosh Chokhani , "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:36:19 -0000 On Fri, Sep 7, 2012 at 7:04 AM, Phillip Hallam-Baker wrote: > 2) Is the Ben, Adam, Chris et. al. proposal the approach to take? I don't know if you mean me, but if you do, everyone should know that I have not worked on CT. It's Ben Laurie, Adam Langley, and Emilia Kasper. See e.g. http://www.links.org/files/sunlight.html. I am a CT booster, of course. :) From rob.stradling@comodo.com Mon Sep 10 03:32:34 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D8321F85A8 for ; Mon, 10 Sep 2012 03:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRLxKhkU6zlX for ; Mon, 10 Sep 2012 03:32:28 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 49BD421F852A for ; Mon, 10 Sep 2012 03:32:27 -0700 (PDT) Received: (qmail 20455 invoked from network); 10 Sep 2012 10:32:26 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Sep 2012 10:32:26 -0000 Received: (qmail 29461 invoked by uid 1000); 10 Sep 2012 10:32:25 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 10 Sep 2012 11:32:25 +0100 Message-ID: <504DC1B9.50400@comodo.com> Date: Mon, 10 Sep 2012 11:32:25 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Laurie References: <50493B49.9020601@KingsMountain.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org, =JeffH Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 10:32:34 -0000 On 07/09/12 13:51, Ben Laurie wrote: > On 7 September 2012 01:09, =JeffH wrote: >> I am supportive of this initiative, and intend to participate. >> >> In terms of quick comments on draft charter, having pointers to the existing >> work would be good, e.g.. >> >> Certificate Transparency: Spec and Working Code >> http://www.links.org/?p=1226 >> http://code.google.com/p/certificate-transparency/source/browse/ >> >> Certificate Transparency Version 2 >> http://www.links.org/?p=1259 >> http://sump2.links.org/files/CertificateTransparencyVersion2.pdf >> >> It looks like upon a quick skim that the I-D source might have kept up with >> CertificateTransparencyVersion2.pdf.. >> >> http://code.google.com/p/certificate-transparency/source/browse/doc/sunlight.xml >> >> yes? > > Yes - actually consistent with v2.1a, which I just uploaded to www.links.org. Ben, I don't see a link to your v2.1a PDF on www.links.org. I guessed and found it here... http://sump2.links.org/files/CertificateTransparencyVersion2.1a.pdf >> Having that I-D submitted before 24-Sep would be helpful in terms of getting >> an actual BoF scheduled (remember I-Ds can be very drafty and rough) > > Will do - we're going to add some more to it next week so I'll wait for that. > >> >> HTH >> >> =JeffH >> >> > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From stephen.farrell@cs.tcd.ie Mon Sep 10 15:21:54 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78D621F8710 for ; Mon, 10 Sep 2012 15:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbM04wjK4W6i for ; Mon, 10 Sep 2012 15:21:50 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7226D21F870E for ; Mon, 10 Sep 2012 15:21:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B1E62171476; Mon, 10 Sep 2012 23:21:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1347315699; bh=IGROZFXff3gG2dyCxmOITtlr kSrxt8LfomXM1T+iyN0=; b=ODvgAyecIAHAybfjDRbmnV6wdLkNfstXWepkyN3i Zq76lBLNxUR9rYa2y6rXYun6rPmsl9UtlSKWJKJiev7LcNHbDz60TRbllU6AeRP+ fBwd7JVmftprq7W52gHfbNUnKRp59sdJCmEEO0sim+0TzjYVbYDlblSK6h0/yjxW TlkhTOGbkGqcWNpwFvd8AeHHFLre7stG/gfQ2pYneIFnr/V+jfFbTo42XQXm7uXl nlo/PbPfAcymtma1TVfvscvS5Clqqi62STvlJBEoFHfcLVGECR8XAqbOBUoz3ckz uQTZqlZDq2UUVhh6DQWTnwMhyamTDvwFKFjKxV9/TG3jXw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ZH6Ns-MC7HAe; Mon, 10 Sep 2012 23:21:39 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.29.198]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A3CC3171473; Mon, 10 Sep 2012 23:21:38 +0100 (IST) Message-ID: <504E67F2.8020002@cs.tcd.ie> Date: Mon, 10 Sep 2012 23:21:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Laurie X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 22:21:54 -0000 Hiya, If you want a BoF, then you need to do the required dance;-) "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area Directors at UTC 24:00. To request a BOF, please see instructions on Requesting a BOF." [1] Sean and I remain interested in folks' opinions about having this BoF. So far I've seen about a dozen-ish "I'm interested in something here" responses, a good chunk from folks who do good work around the IETF; one negative comment off-list (saying its not baked), and have seen a just a couple of folks say they'd do work. That's not bad, but nowhere near overwhelming either, so more input would be appreciated, preferably on the list. S. [1] https://www.ietf.org/iesg/bof-procedures.html From ynir@checkpoint.com Mon Sep 10 21:22:40 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB4521F84D3 for ; Mon, 10 Sep 2012 21:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O5N4QYIyvw7 for ; Mon, 10 Sep 2012 21:22:40 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6B63C21F84C8 for ; Mon, 10 Sep 2012 21:22:37 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q8B4MW1P013644 for ; Tue, 11 Sep 2012 07:22:35 +0300 X-CheckPoint: {504EBC65-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 11 Sep 2012 07:22:31 +0300 From: Yoav Nir To: "therightkey@ietf.org" Date: Tue, 11 Sep 2012 07:22:30 +0300 Thread-Topic: [therightkey] Transparency BoF - there's a deadline... Thread-Index: Ac2Porduzj2kYySuQji+jPylYd0jeQAMfF1A Message-ID: <006FEB08D9C6444AB014105C9AEB133F017A7FA20710@il-ex01.ad.checkpoint.com> References: <504E67F2.8020002@cs.tcd.ie> In-Reply-To: <504E67F2.8020002@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 04:22:40 -0000 In case I wasn't clear last week, yes, I'm interested, and yes, I'm willing= to review/contribute/edit. I don't think an opinion that the idea is not yet baked should be a bar to = meeting. Meetings are a good forum for baking ideas. Yoav -----Original Message----- From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] On= Behalf Of Stephen Farrell Sent: Tuesday, September 11, 2012 1:22 AM To: Ben Laurie Cc: therightkey@ietf.org Subject: [therightkey] Transparency BoF - there's a deadline... Hiya, If you want a BoF, then you need to do the required dance;-) "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area Directo= rs at UTC 24:00. To request a BOF, please see instructions on Requesting a = BOF." [1] Sean and I remain interested in folks' opinions about having this BoF. So f= ar I've seen about a dozen-ish "I'm interested in something here" responses= , a good chunk from folks who do good work around the IETF; one negative co= mment off-list (saying its not baked), and have seen a just a couple of fol= ks say they'd do work. That's not bad, but nowhere near overwhelming either, so more input would b= e appreciated, preferably on the list. S. [1] https://www.ietf.org/iesg/bof-procedures.html _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey From hallam@gmail.com Tue Sep 11 05:02:52 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEFE21F85F4 for ; Tue, 11 Sep 2012 05:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PkafIrxFzYP for ; Tue, 11 Sep 2012 05:02:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D63F321F846F for ; Tue, 11 Sep 2012 05:02:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so720745obb.31 for ; Tue, 11 Sep 2012 05:02:49 -0700 (PDT) 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=CZrsDqgj73pq+T00iv3uaXo/bjLzfL7gu+ESfpeRS1g=; b=CCUB4XRKzBiFiT/DHg/NHkFshCtH7Pc+uFD8MKc1XZ9ZZc0Nytopr2q0WC549Lzjf4 sKOeB6O7qt5WPcidJIURfd+V7Db/PFlTuUrPDAcNO7hyat8MpyzdqjbTS6KCB5v0xcG2 nDo6AN9muUnPWfVqdebAv4pK3ZbANOCbhfeLdz0SpYu5isEfnu6KIVpr3F2JgAvlbygx 7NxElmCrKWkCEb3Ivr1eR1DSlzJDblwWmJLgTr4gt9uESew6/rsfkaUlftqAHLPcJ03b Pv64YVEjoqoBVXNkPY914hsqUfX5gMj5fP9xEQ6fEmp9FGPVRTIehiMoqJIPKpUmdIXE Zfsw== MIME-Version: 1.0 Received: by 10.60.11.34 with SMTP id n2mr17532028oeb.18.1347364969449; Tue, 11 Sep 2012 05:02:49 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Tue, 11 Sep 2012 05:02:49 -0700 (PDT) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F017A7FA20710@il-ex01.ad.checkpoint.com> References: <504E67F2.8020002@cs.tcd.ie> <006FEB08D9C6444AB014105C9AEB133F017A7FA20710@il-ex01.ad.checkpoint.com> Date: Tue, 11 Sep 2012 08:02:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: multipart/alternative; boundary=e89a8fb206e663090004c96bdab5 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 12:02:52 -0000 --e89a8fb206e663090004c96bdab5 Content-Type: text/plain; charset=ISO-8859-1 I am willing to work on a transparency scheme, edit and review documents. I do have a different approach to the question to the Google scheme, but I think they are both worth doing. On Tue, Sep 11, 2012 at 12:22 AM, Yoav Nir wrote: > In case I wasn't clear last week, yes, I'm interested, and yes, I'm > willing to review/contribute/edit. > > I don't think an opinion that the idea is not yet baked should be a bar to > meeting. Meetings are a good forum for baking ideas. > > Yoav > > -----Original Message----- > From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] > On Behalf Of Stephen Farrell > Sent: Tuesday, September 11, 2012 1:22 AM > To: Ben Laurie > Cc: therightkey@ietf.org > Subject: [therightkey] Transparency BoF - there's a deadline... > > > Hiya, > > If you want a BoF, then you need to do the required dance;-) > > "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area > Directors at UTC 24:00. To request a BOF, please see instructions on > Requesting a BOF." [1] > > Sean and I remain interested in folks' opinions about having this BoF. So > far I've seen about a dozen-ish "I'm interested in something here" > responses, a good chunk from folks who do good work around the IETF; one > negative comment off-list (saying its not baked), and have seen a just a > couple of folks say they'd do work. > > That's not bad, but nowhere near overwhelming either, so more input would > be appreciated, preferably on the list. > > S. > > [1] https://www.ietf.org/iesg/bof-procedures.html > _______________________________________________ > 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 > -- Website: http://hallambaker.com/ --e89a8fb206e663090004c96bdab5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am willing to work on a transparency scheme, edit and review documents.
I do have a different approach to the question to the Goo= gle scheme, but I think they are both worth doing.


On Tue, Sep 11, 2012 at 12:22 AM, Yoav Nir <y= nir@checkpoint.com> wrote:
In case I wasn't clear last week, yes, I'm interested, and yes, I&#= 39;m willing to review/contribute/edit.

I don't think an opinion that the idea is not yet baked should be a bar= to meeting. Meetings are a good forum for baking ideas.

Yoav

-----Original Message-----
From: therightkey-bounces@i= etf.org [mailto:therigh= tkey-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Tuesday, September 11, 2012 1:22 AM
To: Ben Laurie
Cc: therightkey@ietf.org
Subject: [therightkey] Transparency BoF - there's a deadline...


Hiya,

If you want a BoF, then you need to do the required dance;-)

"2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area Di= rectors at UTC 24:00. To request a BOF, please see instructions on Requesti= ng a BOF." [1]

Sean and I remain interested in folks' opinions about having this BoF. = So far I've seen about a dozen-ish "I'm interested in somethin= g here" responses, a good chunk from folks who do good work around the= IETF; one negative comment off-list (saying its not baked), and have seen = a just a couple of folks say they'd do work.

That's not bad, but nowhere near overwhelming either, so more input wou= ld be appreciated, preferably on the list.

S.

[1] https://www.ietf.org/iesg/bof-procedures.html
_______________________________________________
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



--
= Website: http://hallambaker.com/
--e89a8fb206e663090004c96bdab5-- From benl@google.com Tue Sep 11 08:15:28 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649D821F8810 for ; Tue, 11 Sep 2012 08:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNOumNUianun for ; Tue, 11 Sep 2012 08:15:27 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA20421F87FF for ; Tue, 11 Sep 2012 08:15:27 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1087612obb.31 for ; Tue, 11 Sep 2012 08:15:27 -0700 (PDT) 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 :x-system-of-record; bh=RzHSFWfL1uO0zr9/bLOAIg0AFrKnKrNE9JEVqa4Vsyk=; b=Rh3n1cpLEY5lmSKvaZxPVIR9O9y5g2eryiV2gJSBf54iJYjMo136uFiPNckdj/IATZ thE3ltAkQkpGxoOoihE85Jo11VrqrEL683WcnUCu1VvbURVFUWgsL2utTl4SJBJkPww/ fR7R4ZHwgKUH9WGRpbJg529daBpiWdmXBaCr70cNrqWo1UtuNC5bQxCPm3SB9NKO3LvY JgZhy7rVpPqygcHBvyey8V8RntTd5IeouspOavY0kdFiSYsgPkBeOeYFquBFqWBxli8c eMi4PX5BVcxHZSw4EZDJIXXOonaNM1uYbl8XZGdVPFC5SltFkGcYeAftqKTE7q5hYTPR t3Rg== X-Google-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 :x-system-of-record:x-gm-message-state; bh=RzHSFWfL1uO0zr9/bLOAIg0AFrKnKrNE9JEVqa4Vsyk=; b=KFfEillrNAYZucYFtcV0DvcDW2ZJMCLQX6KnFv+SsrMDXxywNy7mIXvRCUTNHBab/R NnJ+4lLVgfREKKxjBwzQ2AU0h0FqgFNLXEiCR9rIXUMGMu1Pc4F20EIeWCjRNYw3KNIR QhvU6yEeGMueo3aPSMR8S3RVX7m7rTWsdaE9BpnU2QLqtSouceWj/6bzyHA7e9AWWeJ7 dSgNlr1MzRhWj76Cd+mzg0XXE+N2zbe90s79otdDWGk/OontdglCKg+ufDX5aX5ivkoV P5fJ5Ql8oO4UCdLz/I9KHnGB0ZS4GU/yupLuhdaCa/s/8rFpbkP1GZKO2UUxzIveE5Xn aNUA== Received: by 10.182.182.71 with SMTP id ec7mr18832387obc.22.1347376527216; Tue, 11 Sep 2012 08:15:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.182.71 with SMTP id ec7mr18832374obc.22.1347376527105; Tue, 11 Sep 2012 08:15:27 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Tue, 11 Sep 2012 08:15:27 -0700 (PDT) Date: Tue, 11 Sep 2012 16:15:27 +0100 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkZ7ofR/i5fC1ZP92/bx2YlrXHbKqwMXEzN0+3bdlx362HfMVEfSV5zCZsGtnbFK39Zc2oCOBuPr0fR7REph3x/wr9T86V/ZCLKpAb0K7xhYgYmx8DmwChce/fmConUL6mCRUm5QMoWXCHnAjgw7wkf3g3fAl1ze8GnUOojoAk0XumTXN5sLEqJWccZCKnsvYytB5OB Subject: [therightkey] Revocation Transparency X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 15:15:28 -0000 Emilia Kasper and I came up with a mechanism for providing revocation transparency. We currently have no plans to implement it, but the mechanism is interesting. Blog post here: http://www.links.org/?p=1272 Paper here: http://sump2.links.org/files/RevocationTransparency.pdf. From stephen.farrell@cs.tcd.ie Tue Sep 11 09:11:56 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DF121F86B2 for ; Tue, 11 Sep 2012 09:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA8FkajbvQ5V for ; Tue, 11 Sep 2012 09:11:55 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1F70E21F86F9 for ; Tue, 11 Sep 2012 09:11:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 08B65171476; Tue, 11 Sep 2012 17:11:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1347379890; bh=CsKHnYId1Je7g9 n7fWiRWeXM5zQ8HIAw+XV7tZGfdM4=; b=MR//oXtjaAH8VRYbOlI1HTAlNB4qVV uqRy3zQsViMu4Xx2bsykXNuMQNRs8iwIF4yOn45EAKBmuqfNJ535at5nxXIl87Ka Dr9qAIdIlFwKYUHJ/bWv+vIyqQ8ay99JdOIVzUbSHAKGrl8QQljWr24FkLUbL+2B d8k1sadfKRdTnWkz8iaGW2+jQACDaZnb/on+LK2bMDE6uT+rMDu08LVAAPr0VoA8 /FC8MZoy+G4CmIxy9bZPF/GH3mK0yW0xn5cIo2nlFvTBPDwi5WhgvqzIVIi7KrYg GmwRK3Hb7tVnLp8UpA9IVwHi+n94bn9rXlq36QagKEiF2ygPGIatOI2Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id HXGURfsiOuBl; Tue, 11 Sep 2012 17:11:30 +0100 (IST) Received: from [IPv6:2001:770:10:203:91d4:f91e:fb11:787a] (unknown [IPv6:2001:770:10:203:91d4:f91e:fb11:787a]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 613A017147C; Tue, 11 Sep 2012 17:11:30 +0100 (IST) Message-ID: <504F62B2.1040900@cs.tcd.ie> Date: Tue, 11 Sep 2012 17:11:30 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <504E67F2.8020002@cs.tcd.ie> In-Reply-To: <504E67F2.8020002@cs.tcd.ie> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ben Laurie Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 16:11:56 -0000 And the deadline's been met early:-) Thanks Ben. I've put up some info on the BoF wiki. [1] Note: this means that this BoF will be considered for scheduling. It does not yet mean that it is approved. That decision happens on Sep 24th. If folks can post Internet-Drafts describing their scheme(s) before the 24th then that's all to the good - it shows people are willing to make the effort and buy into the IETF's processes which can help a lot. If there are other non security area WGs that this ought not collide with, please let me know. (It won't collide with any other BoF or area meeting unless we slip up in scheduling so no need to tell me about those.) We can sort out other details (e.g. remote access) after the BoF approval call on the 24th. We have a BoF chair volunteer who'll be able to help start organising agenda slots etc after the BoF approval call. More on that after the 24th. Thanks, S. [1] http://trac.tools.ietf.org/bof/trac/wiki/WikiStart On 09/10/2012 11:21 PM, Stephen Farrell wrote: > > Hiya, > > If you want a BoF, then you need to do the required dance;-) > > "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area > Directors at UTC 24:00. To request a BOF, please see instructions on > Requesting a BOF." [1] > > Sean and I remain interested in folks' opinions about having this > BoF. So far I've seen about a dozen-ish "I'm interested in > something here" responses, a good chunk from folks who do good > work around the IETF; one negative comment off-list (saying its > not baked), and have seen a just a couple of folks say they'd > do work. > > That's not bad, but nowhere near overwhelming either, so more > input would be appreciated, preferably on the list. > > S. > > [1] https://www.ietf.org/iesg/bof-procedures.html > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > From jon@callas.org Tue Sep 11 17:14:58 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DC321F84CD for ; Tue, 11 Sep 2012 17:14:58 -0700 (PDT) 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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkV9lfy--ML5 for ; Tue, 11 Sep 2012 17:14:57 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8B96121F84C9 for ; Tue, 11 Sep 2012 17:14:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id D1EFA1011F0B; Tue, 11 Sep 2012 17:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOpsUHsO+RVb; Tue, 11 Sep 2012 17:14:55 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 097631011EFD; Tue, 11 Sep 2012 17:14:46 -0700 (PDT) Received: from [10.0.23.29] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Tue, 11 Sep 2012 17:14:55 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 11 Sep 2012 17:14:55 -0700 Mime-Version: 1.0 (Apple Message framework v1278) From: Jon Callas In-Reply-To: <504E67F2.8020002@cs.tcd.ie> Date: Tue, 11 Sep 2012 17:14:46 -0700 Message-Id: <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> References: <504E67F2.8020002@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" , Ben Laurie , Jon Callas Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 00:14:58 -0000 On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote: >=20 > Hiya, >=20 > If you want a BoF, then you need to do the required dance;-) >=20 > "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area > Directors at UTC 24:00. To request a BOF, please see instructions on > Requesting a BOF." [1] >=20 > Sean and I remain interested in folks' opinions about having this > BoF. So far I've seen about a dozen-ish "I'm interested in > something here" responses, a good chunk from folks who do good > work around the IETF; one negative comment off-list (saying its > not baked), and have seen a just a couple of folks say they'd > do work. >=20 > That's not bad, but nowhere near overwhelming either, so more > input would be appreciated, preferably on the list. Stephen, I am very supportive of the BoF. Certificate Transparency addresses a real problem that no other public = key infrastructure tweaks do. It permits any party to survey the = landscape of public certificates and do meaningful security analysis. It = is also a modest protocol that doesn't interfere with existing = operations. Many of us doubt the public web certificate infrastructure runs without = someone cheating. We take as an article of faith that someone somewhere = is issuing bogus certificates for whatever nefarious purpose. Usually = that is some vague surveillance, if not outright espionage. (For what = it's worth, I subscribe to that faith.) CT has the value that CAs, relying parties, end users, and interested = third parties can look at the landscape of certificates and catch = inconsistencies. It allows us put some actual faith into trust. It = allows us to see what is going on in a system that we all use. We need = CT. It would be good to have it develop under the aegis of the IETF. Jon From hallam@gmail.com Tue Sep 11 18:37:41 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BAA21E8043 for ; Tue, 11 Sep 2012 18:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InwfgvLwFuDp for ; Tue, 11 Sep 2012 18:37:41 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D817A21E8037 for ; Tue, 11 Sep 2012 18:37:40 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2023902obb.31 for ; Tue, 11 Sep 2012 18:37:40 -0700 (PDT) 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=3jdLyNXn2TcXA5Eszg8yLH3YH/WT2HxqV6opeYVDKNA=; b=ZbxdozFo+JsKeiHXh4QpErh4Ef6ts+w7jvPbIicC4EUUAsnvFRIUnljrGs0cahmecc 30WF29ni0HuMoB0V0iArIJCBW7ibX9lYYt7kYi20c4dpXNXjIHP3c9K8InGVWgWH19Lu ASyI255hQtE+dDVwG5a/aT++s7r79U7VcuyDmPwERk1lQbaLMe8JJJ2vJw395baCs1K+ H7HpaEUEOhK9WELHRDYXB3sYYwJKQxKlmINjD02xHN7AbjyvF788Ev2WrYaSOCkCUVIP ixW9p/twtNcI4kCoPOQ+5qbpJYxJ8k+93gzKfrJDAJoEXCNyMtvIGxq8PPFi59zXsWqP rp0A== MIME-Version: 1.0 Received: by 10.182.152.36 with SMTP id uv4mr20213917obb.81.1347413860269; Tue, 11 Sep 2012 18:37:40 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Tue, 11 Sep 2012 18:37:40 -0700 (PDT) In-Reply-To: <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Tue, 11 Sep 2012 21:37:40 -0400 Message-ID: From: Phillip Hallam-Baker To: Jon Callas Content-Type: multipart/alternative; boundary=f46d044472f381bea404c9773ccf Cc: "therightkey@ietf.org" , Ben Laurie , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 01:37:41 -0000 --f46d044472f381bea404c9773ccf Content-Type: text/plain; charset=ISO-8859-1 Thinking through some baby steps here. Perhaps one of the first steps might be to apply transparency to intermediate certs since those are the ones that have the highest risk associated? In particular I really hope that there is nobody out there issuing intercept certs on public roots. On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas wrote: > > On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote: > > > > > Hiya, > > > > If you want a BoF, then you need to do the required dance;-) > > > > "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area > > Directors at UTC 24:00. To request a BOF, please see instructions on > > Requesting a BOF." [1] > > > > Sean and I remain interested in folks' opinions about having this > > BoF. So far I've seen about a dozen-ish "I'm interested in > > something here" responses, a good chunk from folks who do good > > work around the IETF; one negative comment off-list (saying its > > not baked), and have seen a just a couple of folks say they'd > > do work. > > > > That's not bad, but nowhere near overwhelming either, so more > > input would be appreciated, preferably on the list. > > Stephen, > > I am very supportive of the BoF. > > Certificate Transparency addresses a real problem that no other public key > infrastructure tweaks do. It permits any party to survey the landscape of > public certificates and do meaningful security analysis. It is also a > modest protocol that doesn't interfere with existing operations. > > Many of us doubt the public web certificate infrastructure runs without > someone cheating. We take as an article of faith that someone somewhere is > issuing bogus certificates for whatever nefarious purpose. Usually that is > some vague surveillance, if not outright espionage. (For what it's worth, I > subscribe to that faith.) > > CT has the value that CAs, relying parties, end users, and interested > third parties can look at the landscape of certificates and catch > inconsistencies. It allows us put some actual faith into trust. It allows > us to see what is going on in a system that we all use. We need CT. It > would be good to have it develop under the aegis of the IETF. > > Jon > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --f46d044472f381bea404c9773ccf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thinking through some baby steps here. Perhaps one of the first steps might= be to apply transparency to intermediate certs since those are the ones th= at have the highest risk associated?

In particular I rea= lly hope that there is nobody out there issuing intercept certs on public r= oots.



On Tue, S= ep 11, 2012 at 8:14 PM, Jon Callas <jon@callas.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote:

>
> Hiya,
>
> If you want a BoF, then you need to do the required dance;-)
>
> "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Ar= ea
> Directors at UTC 24:00. To request a BOF, please see instructions on > Requesting a BOF." [1]
>
> Sean and I remain interested in folks' opinions about having this<= br> > BoF. So far I've seen about a dozen-ish "I'm interested i= n
> something here" responses, a good chunk from folks who do good > work around the IETF; one negative comment off-list (saying its
> not baked), and have seen a just a couple of folks say they'd
> do work.
>
> That's not bad, but nowhere near overwhelming either, so more
> input would be appreciated, preferably on the list.

Stephen,

I am very supportive of the BoF.

Certificate Transparency addresses a real problem that no other public key = infrastructure tweaks do. It permits any party to survey the landscape of p= ublic certificates and do meaningful security analysis. It is also a modest= protocol that doesn't interfere with existing operations.

Many of us doubt the public web certificate infrastructure runs without som= eone cheating. We take as an article of faith that someone somewhere is iss= uing bogus certificates for whatever nefarious purpose. Usually that is som= e vague surveillance, if not outright espionage. (For what it's worth, = I subscribe to that faith.)

CT has the value that CAs, relying parties, end users, and interested third= parties can look at the landscape of certificates and catch inconsistencie= s. It allows us put some actual faith into trust. It allows us to see what = is going on in a system that we all use. We need CT. It would be good to ha= ve it develop under the aegis of the IETF.

=A0 =A0 =A0 =A0 Jon

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



--
= Website: http://hallambaker.com/
--f46d044472f381bea404c9773ccf-- From benl@google.com Wed Sep 12 06:45:42 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CE121F85A3 for ; Wed, 12 Sep 2012 06:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDtQ8AgxIdTx for ; Wed, 12 Sep 2012 06:45:41 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E41B521F8582 for ; Wed, 12 Sep 2012 06:45:40 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2943340obb.31 for ; Wed, 12 Sep 2012 06:45:40 -0700 (PDT) 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:x-system-of-record; bh=PxMUrRZsRQsw8uRUvhq6qoKqgBRSyaYs46tFB5LlOBI=; b=PwgeRMMoHlPb/pxsZ3gOCSISxBdGQG6k0cHy8qyArvn9E/cTNI2+k8S0Ft3rx6cKt5 168nMyLyiOtf3qTuw9Gm8HS3N0LztbbZmNfLbzkB9IkzF46d18Ur/4MyxWBdaruQOQyj JD4f6E3pahDrDnD8ZX16qBlMvU/Sezr1qBrsIZkGb/lfSDcK+415CiNJ9K1LgbuLAW5F RPh6c2xykmi0frsNKJ2RQJ3fPEHq3vlX+y/2Tx6ecROl8zKfNavakE+izdpDaIg7nX7e z8eLVdbu/j2tdpsqIiMYrOurpjaSGn8gxMHbXDIw0Whm5Iu9HJj3wRER6cZiKZjAWpZb s9mg== X-Google-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:x-system-of-record:x-gm-message-state; bh=PxMUrRZsRQsw8uRUvhq6qoKqgBRSyaYs46tFB5LlOBI=; b=XVFDZpO1jLiBfXY6j8yrMQw/Xws7jLkVBVag9PCm8MEF7lLwMJxdXnLpPYFPNRk5dw quwHKbK7pvlMmDU8nnfCnDVjudjD/OfasWwi/Y37QAjoR+yqXiiF6G00iq9u9CbeiP3t 0M9dx9Y03zDdg/UFWeYLeFrBXoU9qftNScKrGm3Hr4KG6ZRZhzaQqeI1fmXmY1mNi2qD S16x7m0rXE5JywRvdHAnsgahWodXRfJ+H1gvXnWk5JCSUl3+Et/tYjF7i88Tw7I92Ou5 zDlWL/+uofnZtxt6LykPNifMZK2He6q1Rw6MH8/DBXfkLTYZbTw+mEFUBVt2Ej4LXGtC 9xEw== Received: by 10.60.27.10 with SMTP id p10mr22122287oeg.49.1347457540515; Wed, 12 Sep 2012 06:45:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.27.10 with SMTP id p10mr22122277oeg.49.1347457540420; Wed, 12 Sep 2012 06:45:40 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Wed, 12 Sep 2012 06:45:40 -0700 (PDT) In-Reply-To: <20120912132434.20539.5223.idtracker@ietfa.amsl.com> References: <20120912132434.20539.5223.idtracker@ietfa.amsl.com> Date: Wed, 12 Sep 2012 14:45:40 +0100 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkdAYwSOCskcWXlZcvYhtGRRx9QqRIBP9A1amHRUtnHpIGhXU/mOJTDBYFp6kFqQYcP++HpCm6DmfcA6nU6yECFVvT2/RJp5v57XvkEB1WjoqoE+Q5jNqSsbMmrpZfwjHQ7MRuOZmlUvLuDlTpLA3UkI4M/stoeosBMqOxPMiYMNBeM0Xwez7QV1NvZpabAufefyNoO Subject: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-00.txt X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:45:42 -0000 ---------- Forwarded message ---------- From: Date: 12 September 2012 14:24 Subject: New Version Notification for draft-laurie-pki-sunlight-00.txt To: benl@google.com Cc: ekasper@google.com, agl@google.com A new version of I-D, draft-laurie-pki-sunlight-00.txt has been successfully submitted by Ben Laurie and posted to the IETF repository. Filename: draft-laurie-pki-sunlight Revision: 00 Title: Certificate Transparency Creation date: 2012-09-12 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-laurie-pki-sunlight-00.txt Status: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight Htmlized: http://tools.ietf.org/html/draft-laurie-pki-sunlight-00 Abstract: The aim of Certificate Transparency is to have every public end- entity TLS certificate issued by a known Certificate Authority recorded in one or more certificate logs. In order to detect mis- issuance of certificates, all logs are publicly auditable. In particular, domain owners will be able to monitor logs for certificates issued on their own domain. In order to protect clients from unlogged mis-issued certificates, logs sign all recorded certificates, and clients can choose not to trust certificates that are not accompanied by an appropriate log signature. For privacy and performance reasons log signatures are embedded in the TLS handshake via the TLS authorization extension [RFC5878], or in the certificate itself via an X.509v3 certificate extension [RFC5280]. In order to ensure a globally consistent view of the log, logs also provide a global signature over the entire log. Any inconsistency of logs can be detected through cross-checks on the global signature. Logs are only expected to certify that they have seen a certificate and thus, we do not specify any revocation mechanism for log signatures in this document. Logs will be append-only, and log signatures will be valid indefinitely. The IETF Secretariat From benl@google.com Wed Sep 12 07:22:26 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A6321F859F for ; Wed, 12 Sep 2012 07:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lFGfOSNwqQQ for ; Wed, 12 Sep 2012 07:22:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB7C321F85A4 for ; Wed, 12 Sep 2012 07:22:24 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3018494obb.31 for ; Wed, 12 Sep 2012 07:22:24 -0700 (PDT) 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:x-system-of-record; bh=a5vvtQxxUGW9030vUm5r5ZswhXEoqr8CixOc/GQtsTg=; b=Eq/znFHmt7tbC1rLeJGYmVQOQelWjVQEe/9gbmBoNo6Sm7UkjiaD0Nv/HVIe6yTxO2 siBE14galL+mLy6XXSbIex6GbwJv0A1hBXP/nQQITFy6dDmcpHmHeT2TnvDtVJ8wAGBS 9/prrybqU5XlFtkoAw1lE5EUORrjlCkyyamX8brRgsJHlZvobXfmVp50IwSXxFp0AF3F siqzXCjzCATmF+P7GhD5oWIGEF5fl5nY83WQIJYnl3b/1AvH3BIigKlyQySm4cgeWTGr nqtJ3hDp/4A1vusYVQJdZmWofumQbAXleVOkUiu0erIAsdRkh6QPPgpMYvanQ834T4xZ 6qGA== X-Google-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:x-system-of-record:x-gm-message-state; bh=a5vvtQxxUGW9030vUm5r5ZswhXEoqr8CixOc/GQtsTg=; b=ZBzt83SdTbBcCKp04bfVTj6x/j9PlLlkYLPpekhuKskt53xkRh8prWNiuhoU/qGsXW zQA+TL2TUYIsgUut/lMJ1c2QjClVDo7GQ1a716v9wV1D+l3t1L7awYjJvBiCQney4Toj ZYLExKFLgOtHyFRHX8AVwtwxmEzyroUYMbxcTKM9ThOLKLmpuxWVbLv2KESiQgLIbAQf xv+S5uuQXKaOKhbhJaJ2MfHa16fXAoP3zC6KNizf8FEWnBrTF0LbUdJAY3dKfZENXjGX eEIuO0Og0nD8Wn+ssTvGHwtnErdlFzzKWDLtSgpjRHAecnYKQFGp+mEWAHLBhWvi9+0U y07g== Received: by 10.182.131.98 with SMTP id ol2mr22491059obb.69.1347459744371; Wed, 12 Sep 2012 07:22:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.131.98 with SMTP id ol2mr22491035obb.69.1347459744255; Wed, 12 Sep 2012 07:22:24 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Wed, 12 Sep 2012 07:22:24 -0700 (PDT) In-Reply-To: References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Wed, 12 Sep 2012 15:22:24 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkctGbXFYIS2j9AnNHY+lWsH4TMKvZzQUcpgohwWUdQl2WeKKLLzCbXGYph+j5MKwF6BUOq2IRpu5hJEIP/3ozU7oeGlDcu7OijbH5V363KvaqPgOJtR4steJnmSFYXdxNTYXzBM4MnZSLyS8wjp5K5EphWHaPHSBE9tbduC3bdtd+Np7fVVy7mGLMBRWn/KSXFzzes Cc: "therightkey@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:22:26 -0000 On 12 September 2012 02:37, Phillip Hallam-Baker wrote: > Thinking through some baby steps here. Perhaps one of the first steps might > be to apply transparency to intermediate certs since those are the ones that > have the highest risk associated? You'd have to either re-issue them all, or upgrade all the servers using certs chained from them... > In particular I really hope that there is nobody out there issuing intercept > certs on public roots. > > > > On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas wrote: >> >> >> On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote: >> >> > >> > Hiya, >> > >> > If you want a BoF, then you need to do the required dance;-) >> > >> > "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area >> > Directors at UTC 24:00. To request a BOF, please see instructions on >> > Requesting a BOF." [1] >> > >> > Sean and I remain interested in folks' opinions about having this >> > BoF. So far I've seen about a dozen-ish "I'm interested in >> > something here" responses, a good chunk from folks who do good >> > work around the IETF; one negative comment off-list (saying its >> > not baked), and have seen a just a couple of folks say they'd >> > do work. >> > >> > That's not bad, but nowhere near overwhelming either, so more >> > input would be appreciated, preferably on the list. >> >> Stephen, >> >> I am very supportive of the BoF. >> >> Certificate Transparency addresses a real problem that no other public key >> infrastructure tweaks do. It permits any party to survey the landscape of >> public certificates and do meaningful security analysis. It is also a modest >> protocol that doesn't interfere with existing operations. >> >> Many of us doubt the public web certificate infrastructure runs without >> someone cheating. We take as an article of faith that someone somewhere is >> issuing bogus certificates for whatever nefarious purpose. Usually that is >> some vague surveillance, if not outright espionage. (For what it's worth, I >> subscribe to that faith.) >> >> CT has the value that CAs, relying parties, end users, and interested >> third parties can look at the landscape of certificates and catch >> inconsistencies. It allows us put some actual faith into trust. It allows us >> to see what is going on in a system that we all use. We need CT. It would be >> good to have it develop under the aegis of the IETF. >> >> Jon >> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > > > > > -- > Website: http://hallambaker.com/ > From benl@google.com Wed Sep 12 07:30:14 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710E221F8539 for ; Wed, 12 Sep 2012 07:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHLvtzj6qMMj for ; Wed, 12 Sep 2012 07:30:13 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F75621F8504 for ; Wed, 12 Sep 2012 07:30:13 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3034408obb.31 for ; Wed, 12 Sep 2012 07:30:13 -0700 (PDT) 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:x-system-of-record; bh=DW7uDjPhFooNLPHqdmPIlBFaITv+4AsGsWVZ/8wfEMY=; b=d3YSsri27Jm8Ld3Z9B60XaOhgOafbEvfTPiZllgkPn47QMrdhdxgO7N1/P3jemtBWo 1Y+BA7lJEcbnU9Yy557r+LfCYjx6PbvnZURKkLi1pmKzOkx/ykH6vthJCci7E7JlMeGi vw1xw6ToTXvySs/bqkGcyer56d+8AFa6UGa9kDfAkwuWb0hFUOFgz0YPr8+T1l1IwuJU bu8tRBO7s1bcg5DHIJRYiOfIYBXGhDoe0+F5Bwyb93lMsRAsrU/qVUtfYw/j47fURoK/ 2pdAiVRCcebr4ARmj2mRnY1mgrflPFOd1ryontQ+xabwlvYvEnSPYYHpXzvXN1tBPZYR k4BA== X-Google-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:x-system-of-record:x-gm-message-state; bh=DW7uDjPhFooNLPHqdmPIlBFaITv+4AsGsWVZ/8wfEMY=; b=iXEQnzR727sApJaISymrnk4xjRvxrXxq7ZwYTcYwybfsAeRJgue7+nJfEbuIzMUtAF L3HNT2PAoWbsKggkvKW3lYBfoOIOydJhbE8W8MHmEzZq4YKhaBRZcmPpbZyXhKJfpaFK 6FN9SgA3djlNdd49O+TCkPFvj+bsnXNUllDE9z7LBdip/8uPucRvghWIX5whImAXC/p6 7+VAa9sPWm5+AvNBmx8BCy/C6KHXqS6ZM9hUKz58zGuZp4nusp30levNAQV06G99YDKQ yA6wpxH7rfELf/24eLp3ygwAjKgUYObVYQ3dYOdhIFEu+nG385DT0S+LZDK2ejIGwvEv K7+Q== Received: by 10.60.29.134 with SMTP id k6mr22372696oeh.5.1347460213312; Wed, 12 Sep 2012 07:30:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.29.134 with SMTP id k6mr22372671oeh.5.1347460213112; Wed, 12 Sep 2012 07:30:13 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Wed, 12 Sep 2012 07:30:13 -0700 (PDT) In-Reply-To: References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Wed, 12 Sep 2012 15:30:13 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkhtmX7JU4D/IjlZc+SZSs83T6Mm6R6u/DDP8r4Vm51Tek7KuC4zcSKRanUxT6i0Mghzln3YMq6Y1tOLfRMBtgk1C9fri3mX6/wptF8xy0HUWcUwvPPxOxnDkUz35Qgcrx9e0rlHq9g5g+Ewlnf8XgwfqdfFldplz67pyxRjz8rIMReXeZyBUSPRmcjTLcMqv7iFLsS Cc: "therightkey@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:30:14 -0000 On 12 September 2012 02:37, Phillip Hallam-Baker wrote: > Thinking through some baby steps here. Perhaps one of the first steps might > be to apply transparency to intermediate certs since those are the ones that > have the highest risk associated? > > In particular I really hope that there is nobody out there issuing intercept > certs on public roots. What do you mean by an "intercept cert"? > > > > On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas wrote: >> >> >> On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote: >> >> > >> > Hiya, >> > >> > If you want a BoF, then you need to do the required dance;-) >> > >> > "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area >> > Directors at UTC 24:00. To request a BOF, please see instructions on >> > Requesting a BOF." [1] >> > >> > Sean and I remain interested in folks' opinions about having this >> > BoF. So far I've seen about a dozen-ish "I'm interested in >> > something here" responses, a good chunk from folks who do good >> > work around the IETF; one negative comment off-list (saying its >> > not baked), and have seen a just a couple of folks say they'd >> > do work. >> > >> > That's not bad, but nowhere near overwhelming either, so more >> > input would be appreciated, preferably on the list. >> >> Stephen, >> >> I am very supportive of the BoF. >> >> Certificate Transparency addresses a real problem that no other public key >> infrastructure tweaks do. It permits any party to survey the landscape of >> public certificates and do meaningful security analysis. It is also a modest >> protocol that doesn't interfere with existing operations. >> >> Many of us doubt the public web certificate infrastructure runs without >> someone cheating. We take as an article of faith that someone somewhere is >> issuing bogus certificates for whatever nefarious purpose. Usually that is >> some vague surveillance, if not outright espionage. (For what it's worth, I >> subscribe to that faith.) >> >> CT has the value that CAs, relying parties, end users, and interested >> third parties can look at the landscape of certificates and catch >> inconsistencies. It allows us put some actual faith into trust. It allows us >> to see what is going on in a system that we all use. We need CT. It would be >> good to have it develop under the aegis of the IETF. >> >> Jon >> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > > > > > -- > Website: http://hallambaker.com/ > From hallam@gmail.com Wed Sep 12 07:33:40 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA9821F8526 for ; Wed, 12 Sep 2012 07:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g17CtPh+7RnV for ; Wed, 12 Sep 2012 07:33:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 767F121F84F5 for ; Wed, 12 Sep 2012 07:33:39 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3041448obb.31 for ; Wed, 12 Sep 2012 07:33:39 -0700 (PDT) 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=wUqSH6ABhz67NR+EMneZxQ2jpfKCLMrp0uk4Z2bYxRo=; b=EEVH2qBnwkg91xuoQ36Gq2rFPy492QZZgnMABaHFA0av9RzOZCPYOIlPYnyZAIyZIQ f4t5QNK9b23MJITHUq+VW14vXL/bW7kmkxfg74UN38u/rgifYt1fRG6tATBPNB2gDYPB RqyhrrzcEBdCphqQDNAI1geV17Z6vvW+o/6jtvKR1EgJT/wdBgwiNWg2kMDGDW+fuett f2SkoXArkwGun3t4Tf+m9TW9dVGDWpGI8+z2jqZUeJBCBkevg7IgsRt4sMhAKhZk88rN NSGqW1vOBheW+SrgombPGkKn0ZPLdEZVyQwq1R/BV4et4Bet0nFhP6iwEYBvJOmvPxcS M82Q== MIME-Version: 1.0 Received: by 10.182.174.100 with SMTP id br4mr22569979obc.62.1347460419111; Wed, 12 Sep 2012 07:33:39 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Wed, 12 Sep 2012 07:33:39 -0700 (PDT) In-Reply-To: References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Wed, 12 Sep 2012 10:33:39 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8f647b1da14be804c982130b Cc: "therightkey@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:33:40 -0000 --e89a8f647b1da14be804c982130b Content-Type: text/plain; charset=ISO-8859-1 Issuing a cert on a public root for the purpose of enabling transparent intercept of SSL on a Bluecoat like device. Anyone doing so would be in direct contravention of the Mozilla requirements (and probably everyone else) of course. On Wed, Sep 12, 2012 at 10:30 AM, Ben Laurie wrote: > On 12 September 2012 02:37, Phillip Hallam-Baker wrote: > > Thinking through some baby steps here. Perhaps one of the first steps > might > > be to apply transparency to intermediate certs since those are the ones > that > > have the highest risk associated? > > > > In particular I really hope that there is nobody out there issuing > intercept > > certs on public roots. > > What do you mean by an "intercept cert"? > > > > > > > > > On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas wrote: > >> > >> > >> On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote: > >> > >> > > >> > Hiya, > >> > > >> > If you want a BoF, then you need to do the required dance;-) > >> > > >> > "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area > >> > Directors at UTC 24:00. To request a BOF, please see instructions on > >> > Requesting a BOF." [1] > >> > > >> > Sean and I remain interested in folks' opinions about having this > >> > BoF. So far I've seen about a dozen-ish "I'm interested in > >> > something here" responses, a good chunk from folks who do good > >> > work around the IETF; one negative comment off-list (saying its > >> > not baked), and have seen a just a couple of folks say they'd > >> > do work. > >> > > >> > That's not bad, but nowhere near overwhelming either, so more > >> > input would be appreciated, preferably on the list. > >> > >> Stephen, > >> > >> I am very supportive of the BoF. > >> > >> Certificate Transparency addresses a real problem that no other public > key > >> infrastructure tweaks do. It permits any party to survey the landscape > of > >> public certificates and do meaningful security analysis. It is also a > modest > >> protocol that doesn't interfere with existing operations. > >> > >> Many of us doubt the public web certificate infrastructure runs without > >> someone cheating. We take as an article of faith that someone somewhere > is > >> issuing bogus certificates for whatever nefarious purpose. Usually that > is > >> some vague surveillance, if not outright espionage. (For what it's > worth, I > >> subscribe to that faith.) > >> > >> CT has the value that CAs, relying parties, end users, and interested > >> third parties can look at the landscape of certificates and catch > >> inconsistencies. It allows us put some actual faith into trust. It > allows us > >> to see what is going on in a system that we all use. We need CT. It > would be > >> good to have it develop under the aegis of the IETF. > >> > >> Jon > >> > >> _______________________________________________ > >> therightkey mailing list > >> therightkey@ietf.org > >> https://www.ietf.org/mailman/listinfo/therightkey > > > > > > > > > > -- > > Website: http://hallambaker.com/ > > > -- Website: http://hallambaker.com/ --e89a8f647b1da14be804c982130b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Issuing a cert on a public root for the purpose of enabling transparent int= ercept of SSL on a Bluecoat like device.

Anyone doing so= would be in direct contravention of the Mozilla requirements (and probably= everyone else) of course.


On Wed, Sep 12, 2012 at 10:30 AM, B= en Laurie <benl@google.com> wrote:
On 12 September 2012 02:37, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> Thinking through some baby steps here. Perhaps= one of the first steps might
> be to apply transparency to intermediate certs since those are the one= s that
> have the highest risk associated?
>
> In particular I really hope that there is nobody out there issuing int= ercept
> certs on public roots.

What do you mean by an "intercept cert"?

>
>
>
> On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas <jon@callas.org> wrote:
>>
>>
>> On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote:
>>
>> >
>> > Hiya,
>> >
>> > If you want a BoF, then you need to do the required dance;-)<= br> >> >
>> > "2012-09-24 (Monday): Cutoff date for BOF proposal reque= sts to Area
>> > Directors at UTC 24:00. To request a BOF, please see instruct= ions on
>> > Requesting a BOF." [1]
>> >
>> > Sean and I remain interested in folks' opinions about hav= ing this
>> > BoF. So far I've seen about a dozen-ish "I'm int= erested in
>> > something here" responses, a good chunk from folks who d= o good
>> > work around the IETF; one negative comment off-list (saying i= ts
>> > not baked), and have seen a just a couple of folks say they&#= 39;d
>> > do work.
>> >
>> > That's not bad, but nowhere near overwhelming either, so = more
>> > input would be appreciated, preferably on the list.
>>
>> Stephen,
>>
>> I am very supportive of the BoF.
>>
>> Certificate Transparency addresses a real problem that no other pu= blic key
>> infrastructure tweaks do. It permits any party to survey the lands= cape of
>> public certificates and do meaningful security analysis. It is als= o a modest
>> protocol that doesn't interfere with existing operations.
>>
>> Many of us doubt the public web certificate infrastructure runs wi= thout
>> someone cheating. We take as an article of faith that someone some= where is
>> issuing bogus certificates for whatever nefarious purpose. Usually= that is
>> some vague surveillance, if not outright espionage. (For what it&#= 39;s worth, I
>> subscribe to that faith.)
>>
>> CT has the value that CAs, relying parties, end users, and interes= ted
>> third parties can look at the landscape of certificates and catch<= br> >> inconsistencies. It allows us put some actual faith into trust. It= allows us
>> to see what is going on in a system that we all use. We need CT. I= t would be
>> good to have it develop under the aegis of the IETF.
>>
>> =A0 =A0 =A0 =A0 Jon
>>
>> _______________________________________________
>> therightkey mailing list
>> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey
>
>
>
>
> --
> Website: http://= hallambaker.com/
>



--
= Website: http://hallambaker.com/
--e89a8f647b1da14be804c982130b-- From benl@google.com Wed Sep 12 07:34:53 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEF021F8530 for ; Wed, 12 Sep 2012 07:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HEUjcVKUZdm for ; Wed, 12 Sep 2012 07:34:53 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 03B0121F84F5 for ; Wed, 12 Sep 2012 07:34:52 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3043952obb.31 for ; Wed, 12 Sep 2012 07:34:52 -0700 (PDT) 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:x-system-of-record; bh=fuIHWZnP43bztiai4IA838G/jWg49p9W0aHVvqCoaSI=; b=Gt0wRc8HUtEN+tDY20nktjOTutUy4AM1DE6EIvzmdu63mXegYk8K4PgHKpfcHPzEox INUNC82RBPWV5p5vVutR7jyk66vEWwuwgUqtS03eoVMvZFAydEdD3/agvoBfuMPFjCIg mPlQoF+OW/isnM6qJJD4g84CKx1R+iQ6/8lbm5Qstv0HyxRDgIXUIBXVZ6eHaqgWlgKI 1Lo9c5j/2yuW5iFRDWjJAbmX7HVcn8q9VupLPsxo8PX1sYgY1jCfQYuxshnHqedgcHm6 1Mure31Z6kPtbm4AVhgz7FxEQWlEkZiEWDCWi5WKm62J2YuUsppruQ0rMn0QNFezy+i0 fsrA== X-Google-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:x-system-of-record:x-gm-message-state; bh=fuIHWZnP43bztiai4IA838G/jWg49p9W0aHVvqCoaSI=; b=WsdWpiBmIaqI68EDRhN/1YSh2u4O/SwaWKX0z+/8zXlsAv2rXEoOJz9urkVLOf+kqc M94izf3va9AHvyNaWYo7D8ZAbXyewT5BA3Yt0kqbWYfH+1C98SSZMe8v4fa8O8pKa+F7 kopZc2eFEcJePwVqdd5e4ISR4m7fdLugDwIEuA3oWVOIwic/Z1TWHrBBSkUs4rzg+Gt/ Xq9xCjph6rwXS+7SpX0UFvoacjqjyITE2KhOrvJKdUmO5aDo6NaiB/Xvd5vdHhDPRP0V hc3bUzgYioLmMassfTjbto0oez1PXu+D/7iN3VQJZHCUVaPtA+yv0O0Kp5VtJo4FZFoI vrcA== Received: by 10.182.17.99 with SMTP id n3mr22615391obd.8.1347460492678; Wed, 12 Sep 2012 07:34:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.17.99 with SMTP id n3mr22615366obd.8.1347460492476; Wed, 12 Sep 2012 07:34:52 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Wed, 12 Sep 2012 07:34:52 -0700 (PDT) In-Reply-To: References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Wed, 12 Sep 2012 15:34:52 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmhgp0rZYoT9Onb0g4O+u2OZ5/3C0r2EApBepKcXNHDJcu24aB3l87lT49Lhx/VmLk9eyUoIvt7xHmO0KLiZsL7+2XBqIjN/EOA+Sog6MN0Yo6db30ODtuZBEW3o4gwc2M5xnaI8YNrox/Cbx3cHZ441RyaX4fBfnVcoj9mVe/+ueO88Rd+Y1BLFNQ7gtfOIQWLwxgX Cc: "therightkey@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:34:53 -0000 On 12 September 2012 15:33, Phillip Hallam-Baker wrote: > Issuing a cert on a public root for the purpose of enabling transparent > intercept of SSL on a Bluecoat like device. OK. So how would one tell what the purpose was? For example: http://cdp.disney.com/ From hallam@gmail.com Wed Sep 12 07:35:05 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8009E21F8618 for ; Wed, 12 Sep 2012 07:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+Aj5jtNHpK9 for ; Wed, 12 Sep 2012 07:35:04 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A65D721F84F5 for ; Wed, 12 Sep 2012 07:35:04 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wc20so3043952obb.31 for ; Wed, 12 Sep 2012 07:35:04 -0700 (PDT) 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=5rpNfWdy1Nehk3HR7PZZFWMJSm53d/zFi5ILkZLDJ8Y=; b=gGuCL6d/JMftKYX4RLJAqZ34liQ/DfeDcvXBJN4zQq+sE0umrls5rXZmX2XKP8NJLc xa1T1vV3kVRzZe5+oh9IhJ8bIh1cBhZq0gva7B7i6zEufj4Hw3OhxDDIgxUHVkNdtEgT hfeQf9X5OxHvPwm68KJSEj9l6SnbXlOrRbImctezEBYEOIWK/+23+BtliUnOfNZ7w0Pz QolX7oVsKhvA8cmsfNnbvg6HWtp0Xs7QnWLIYrz0c5RSUn1t5LM4fzoOtp8gpQav5VG3 5J2UFexn1z12wRG4rPFI+Ssbxqh7xQ9dn87mZOssA1XuUk7OiLHSbJSMF1SyrmLeQYPf wTyQ== MIME-Version: 1.0 Received: by 10.182.152.97 with SMTP id ux1mr23016334obb.13.1347460504518; Wed, 12 Sep 2012 07:35:04 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Wed, 12 Sep 2012 07:35:04 -0700 (PDT) In-Reply-To: References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Wed, 12 Sep 2012 10:35:04 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=f46d04462c0ab882a104c9821868 Cc: "therightkey@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:35:05 -0000 --f46d04462c0ab882a104c9821868 Content-Type: text/plain; charset=ISO-8859-1 I don't see why that would be the case. The requirement could be applied to new certs going forward. Or the proofs could be embedded in OCSP tokens rather than the certs themselves. On Wed, Sep 12, 2012 at 10:22 AM, Ben Laurie wrote: > On 12 September 2012 02:37, Phillip Hallam-Baker wrote: > > Thinking through some baby steps here. Perhaps one of the first steps > might > > be to apply transparency to intermediate certs since those are the ones > that > > have the highest risk associated? > > You'd have to either re-issue them all, or upgrade all the servers > using certs chained from them... > > > In particular I really hope that there is nobody out there issuing > intercept > > certs on public roots. > > > > > > > > On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas wrote: > >> > >> > >> On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote: > >> > >> > > >> > Hiya, > >> > > >> > If you want a BoF, then you need to do the required dance;-) > >> > > >> > "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area > >> > Directors at UTC 24:00. To request a BOF, please see instructions on > >> > Requesting a BOF." [1] > >> > > >> > Sean and I remain interested in folks' opinions about having this > >> > BoF. So far I've seen about a dozen-ish "I'm interested in > >> > something here" responses, a good chunk from folks who do good > >> > work around the IETF; one negative comment off-list (saying its > >> > not baked), and have seen a just a couple of folks say they'd > >> > do work. > >> > > >> > That's not bad, but nowhere near overwhelming either, so more > >> > input would be appreciated, preferably on the list. > >> > >> Stephen, > >> > >> I am very supportive of the BoF. > >> > >> Certificate Transparency addresses a real problem that no other public > key > >> infrastructure tweaks do. It permits any party to survey the landscape > of > >> public certificates and do meaningful security analysis. It is also a > modest > >> protocol that doesn't interfere with existing operations. > >> > >> Many of us doubt the public web certificate infrastructure runs without > >> someone cheating. We take as an article of faith that someone somewhere > is > >> issuing bogus certificates for whatever nefarious purpose. Usually that > is > >> some vague surveillance, if not outright espionage. (For what it's > worth, I > >> subscribe to that faith.) > >> > >> CT has the value that CAs, relying parties, end users, and interested > >> third parties can look at the landscape of certificates and catch > >> inconsistencies. It allows us put some actual faith into trust. It > allows us > >> to see what is going on in a system that we all use. We need CT. It > would be > >> good to have it develop under the aegis of the IETF. > >> > >> Jon > >> > >> _______________________________________________ > >> therightkey mailing list > >> therightkey@ietf.org > >> https://www.ietf.org/mailman/listinfo/therightkey > > > > > > > > > > -- > > Website: http://hallambaker.com/ > > > -- Website: http://hallambaker.com/ --f46d04462c0ab882a104c9821868 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't see why that would be the case. The requirement could be applie= d to new certs going forward. Or the proofs could be embedded in OCSP token= s rather than the certs themselves.

On W= ed, Sep 12, 2012 at 10:22 AM, Ben Laurie <benl@google.com> wro= te:
On 12 September 2012 02:37= , Phillip Hallam-Baker <hallam@gmail= .com> wrote:
> Thinking through some baby steps here. Perhaps one of the first steps = might
> be to apply transparency to intermediate certs since those are the one= s that
> have the highest risk associated?

You'd have to either re-issue them all, or upgrade all the server= s
using certs chained from them...

> In particular I really hope that there is nobody out there issuing int= ercept
> certs on public roots.
>
>
>
> On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas <jon@callas.org> wrote:
>>
>>
>> On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote:
>>
>> >
>> > Hiya,
>> >
>> > If you want a BoF, then you need to do the required dance;-)<= br> >> >
>> > "2012-09-24 (Monday): Cutoff date for BOF proposal reque= sts to Area
>> > Directors at UTC 24:00. To request a BOF, please see instruct= ions on
>> > Requesting a BOF." [1]
>> >
>> > Sean and I remain interested in folks' opinions about hav= ing this
>> > BoF. So far I've seen about a dozen-ish "I'm int= erested in
>> > something here" responses, a good chunk from folks who d= o good
>> > work around the IETF; one negative comment off-list (saying i= ts
>> > not baked), and have seen a just a couple of folks say they&#= 39;d
>> > do work.
>> >
>> > That's not bad, but nowhere near overwhelming either, so = more
>> > input would be appreciated, preferably on the list.
>>
>> Stephen,
>>
>> I am very supportive of the BoF.
>>
>> Certificate Transparency addresses a real problem that no other pu= blic key
>> infrastructure tweaks do. It permits any party to survey the lands= cape of
>> public certificates and do meaningful security analysis. It is als= o a modest
>> protocol that doesn't interfere with existing operations.
>>
>> Many of us doubt the public web certificate infrastructure runs wi= thout
>> someone cheating. We take as an article of faith that someone some= where is
>> issuing bogus certificates for whatever nefarious purpose. Usually= that is
>> some vague surveillance, if not outright espionage. (For what it&#= 39;s worth, I
>> subscribe to that faith.)
>>
>> CT has the value that CAs, relying parties, end users, and interes= ted
>> third parties can look at the landscape of certificates and catch<= br> >> inconsistencies. It allows us put some actual faith into trust. It= allows us
>> to see what is going on in a system that we all use. We need CT. I= t would be
>> good to have it develop under the aegis of the IETF.
>>
>> =A0 =A0 =A0 =A0 Jon
>>
>> _______________________________________________
>> therightkey mailing list
>> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey
>
>
>
>
> --
> Website: http://= hallambaker.com/
>



--
= Website: http://hallambaker.com/
--f46d04462c0ab882a104c9821868-- From benl@google.com Wed Sep 12 07:37:30 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0143D21F84AE for ; Wed, 12 Sep 2012 07:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVBDUpUaBm4F for ; Wed, 12 Sep 2012 07:37:29 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05F4C21F8499 for ; Wed, 12 Sep 2012 07:37:28 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3049201obb.31 for ; Wed, 12 Sep 2012 07:37:28 -0700 (PDT) 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:x-system-of-record; bh=6eRDIe6ZZZG+V5Lz7TkUcomoIDLcrdxoN6d8OykhU5I=; b=XBbw2oinPJ7h+oGXP/ot1rRmUUaGVRaD5+UngPSMB7w2AZmLrKMCdvhsR4FpPyhIbm 97uChXnqRMxtwBDzKnjYVih1JG8e7hwJ3Mh0oHGB9lD6AAQCa7EsfyR2wfs+iXDMm5Ot 59oF2FN/bb+pDCT+xyAK9jncxQVi0+AzFZUOTvsNJLroVUfLkrGDYkP/DIHkwrHCxq0n fzbx1uT6BdYB2Og3BXDXbGpo2DTkpnXTlSea31zriSvWvvzDVY7qEIZoz1ZKzQmMHVhv CE7a+w2E/y4AIWkScV3FXwhG5wprxz9IE21WNQE5xCFi83kP41trAD1fxFUmzC61GRSV EYjQ== X-Google-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:x-system-of-record:x-gm-message-state; bh=6eRDIe6ZZZG+V5Lz7TkUcomoIDLcrdxoN6d8OykhU5I=; b=BblXYHzyI7zCs6fYOC7/jPpLuzzsCtsdronLvsvEYWo5bxjYsOG0TpoSjAW/THPzwk wcPfeIEkgMOQpAacNY+v7zvLeEFlDoUyn4+njgjEiIJFLtbHurhZDw7ozWOaV4BUzbAR XhKcQsMX8KvjuoEKQpg+cLN6GxTYwL/eS3PYSTs5r5kMOElGNtarsIXQi+qPwWO4Xq00 EBFYjwuAvrJ75HBJD7W/CuffK/m9SW+e0DjNbDsisdFBpSOyEGxErOFtnav7tyP292XE ZaPtVXjyNmEHukeu/tAPTu4UJro/Qbsq63sL43+s/2+r0RqlmifpmK6JRW7sj3Szzfev D+1A== Received: by 10.60.12.8 with SMTP id u8mr22722442oeb.46.1347460648647; Wed, 12 Sep 2012 07:37:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.12.8 with SMTP id u8mr22722421oeb.46.1347460648519; Wed, 12 Sep 2012 07:37:28 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Wed, 12 Sep 2012 07:37:28 -0700 (PDT) In-Reply-To: References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Wed, 12 Sep 2012 15:37:28 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQldsyz6ixqsCKiZ30bCC1+uQqrt5CCugpWxOpjAF56T/yu5Lm2wJ74DLA/TTAQpL2FOqI0n8j7Malq8ScNATEDSI9u9bD54tNFNu2aySc0SXtR6+gElcg40NujoFZw2d3wa4IzPtBabgYxyjNeiLUkMdbVPCwRoNqQDnLi1PjULgGBZNlqPU9oq4Mmf1fxG3T27DAuE Cc: "therightkey@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:37:30 -0000 On 12 September 2012 15:35, Phillip Hallam-Baker wrote: > I don't see why that would be the case. The requirement could be applied to > new certs going forward. Or the proofs could be embedded in OCSP tokens > rather than the certs themselves. I think I've said before that I would welcome a move to embedding in OCSP. Presumably they'd have to be stapled... > > On Wed, Sep 12, 2012 at 10:22 AM, Ben Laurie wrote: >> >> On 12 September 2012 02:37, Phillip Hallam-Baker wrote: >> > Thinking through some baby steps here. Perhaps one of the first steps >> > might >> > be to apply transparency to intermediate certs since those are the ones >> > that >> > have the highest risk associated? >> >> You'd have to either re-issue them all, or upgrade all the servers >> using certs chained from them... >> >> > In particular I really hope that there is nobody out there issuing >> > intercept >> > certs on public roots. >> > >> > >> > >> > On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas wrote: >> >> >> >> >> >> On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote: >> >> >> >> > >> >> > Hiya, >> >> > >> >> > If you want a BoF, then you need to do the required dance;-) >> >> > >> >> > "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area >> >> > Directors at UTC 24:00. To request a BOF, please see instructions on >> >> > Requesting a BOF." [1] >> >> > >> >> > Sean and I remain interested in folks' opinions about having this >> >> > BoF. So far I've seen about a dozen-ish "I'm interested in >> >> > something here" responses, a good chunk from folks who do good >> >> > work around the IETF; one negative comment off-list (saying its >> >> > not baked), and have seen a just a couple of folks say they'd >> >> > do work. >> >> > >> >> > That's not bad, but nowhere near overwhelming either, so more >> >> > input would be appreciated, preferably on the list. >> >> >> >> Stephen, >> >> >> >> I am very supportive of the BoF. >> >> >> >> Certificate Transparency addresses a real problem that no other public >> >> key >> >> infrastructure tweaks do. It permits any party to survey the landscape >> >> of >> >> public certificates and do meaningful security analysis. It is also a >> >> modest >> >> protocol that doesn't interfere with existing operations. >> >> >> >> Many of us doubt the public web certificate infrastructure runs without >> >> someone cheating. We take as an article of faith that someone somewhere >> >> is >> >> issuing bogus certificates for whatever nefarious purpose. Usually that >> >> is >> >> some vague surveillance, if not outright espionage. (For what it's >> >> worth, I >> >> subscribe to that faith.) >> >> >> >> CT has the value that CAs, relying parties, end users, and interested >> >> third parties can look at the landscape of certificates and catch >> >> inconsistencies. It allows us put some actual faith into trust. It >> >> allows us >> >> to see what is going on in a system that we all use. We need CT. It >> >> would be >> >> good to have it develop under the aegis of the IETF. >> >> >> >> Jon >> >> >> >> _______________________________________________ >> >> therightkey mailing list >> >> therightkey@ietf.org >> >> https://www.ietf.org/mailman/listinfo/therightkey >> > >> > >> > >> > >> > -- >> > Website: http://hallambaker.com/ >> > > > > > > -- > Website: http://hallambaker.com/ > From hallam@gmail.com Wed Sep 12 07:37:40 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FDE21F8499 for ; Wed, 12 Sep 2012 07:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCZf+RKx4obh for ; Wed, 12 Sep 2012 07:37:39 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5A221F854F for ; Wed, 12 Sep 2012 07:37:39 -0700 (PDT) Received: by oagk14 with SMTP id k14so1158624oag.31 for ; Wed, 12 Sep 2012 07:37:39 -0700 (PDT) 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=FYJIb4YCrSktLbej+yQ/zrsA48p5uDZk/yXaRwgjZNQ=; b=X9hFO7Qp1nsePtjkPASET+JcKLli4wq2tlkm1/thzpPs7XAde72XAbW0M5dWhdm1nj yLOAQ6alulEuVYlLW0/vfsNIaIpScXptCcGxoXyi0/PxA5iFrqoF3G5PqzBnqUoBgnt9 mbDcmCgVJgj0MYG9YjkgM74oO/EvqasHhZNOyx0UT4EL1IAvtirk+zfnBEbZpaAGrn24 kl7vZDUMWZhoSAv4YJpQZ2dqpZENfi5N0gbEiRlg1tRJhdTRRUCUUMOYTspCYE47DUb4 vnntrcu3aV1s9DEnz4f/UQ6GGLXVaxZTdyY9YP0794OL+iyHQh3gQPPhcNO0tKJZpl12 aPHg== MIME-Version: 1.0 Received: by 10.60.11.34 with SMTP id n2mr22704606oeb.18.1347460659075; Wed, 12 Sep 2012 07:37:39 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Wed, 12 Sep 2012 07:37:39 -0700 (PDT) In-Reply-To: References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Wed, 12 Sep 2012 10:37:39 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8fb206e6eeda8b04c982217c Cc: "therightkey@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:37:40 -0000 --e89a8fb206e6eeda8b04c982217c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 12, 2012 at 10:34 AM, Ben Laurie wrote: > On 12 September 2012 15:33, Phillip Hallam-Baker wrote: > > Issuing a cert on a public root for the purpose of enabling transparent > > intercept of SSL on a Bluecoat like device. > > OK. So how would one tell what the purpose was? > > For example: http://cdp.disney.com/ > I don't think you can and I don't think you need to. Transparency is pretty robust. If people have a good explanation for the reason they are doing something then it isn't an intercept cert. If they don't have an explanation then it is a problem even if the specific problem isn't intercept. -- Website: http://hallambaker.com/ --e89a8fb206e6eeda8b04c982217c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 12, 2012 at 10:34 AM, Ben Laurie <benl@google.com> wrote:
On 12 September 2012 15:33, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> Issuing a cert on a public root for the purpose of enabling transparen= t
> intercept of SSL on a Bluecoat like device.

OK. So how would one tell what the purpose was?

For example: http://cd= p.disney.com/

I don't think you can and I don't think you = need to.

Transparency is pretty robust. If people have a= good explanation for the reason they are doing something then it isn't= an intercept cert. If they don't have an explanation then it is a prob= lem even if the specific problem isn't intercept.

--
Website: http://h= allambaker.com/

--e89a8fb206e6eeda8b04c982217c-- From benl@google.com Wed Sep 12 07:38:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E9321F859B for ; Wed, 12 Sep 2012 07:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65dLEN4B9X45 for ; Wed, 12 Sep 2012 07:38:32 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B38C21F8594 for ; Wed, 12 Sep 2012 07:38:32 -0700 (PDT) Received: by oagk14 with SMTP id k14so1159401oag.31 for ; Wed, 12 Sep 2012 07:38:31 -0700 (PDT) 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:x-system-of-record; bh=nYHdC9NuQ3o/EQl2K5h1WO0EEP5R9r5zS1ECyymHB00=; b=V85/Z/IYYJa5AqvfdnpdFMM0V8Bl29YBXMwfqDLKIzmDIsitiZZSAIAQrDkaAugYqj LzBnnHiVB3D+FTLw7nLk2xdHEo9At+myofI9SKJ6s1RgS0EHy2/P2ZKHGen0nrLJMcBg qGs6wn9Lg0jFd/WlUW+gjqvjEb+RqdvsWPNVfMUQ/Etpfv5S4FaNNrxsEmmXE4C97wr9 oXbHAv67t6VbkklpuDLei0awoExfxjXsKYXzJGS3DxPmt83mwdWXNxSAa+1c+NBguDdi evPj0eehpIotCieAM7sY88y1bzTCTmH0icA1G6PJ6SJybg1qptz6MPCtf/5lK2DR+J1X c/Bw== X-Google-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:x-system-of-record:x-gm-message-state; bh=nYHdC9NuQ3o/EQl2K5h1WO0EEP5R9r5zS1ECyymHB00=; b=oa8vtiKuBhYX/n9GTN/eO4fyp0nsU+h0VvIOeoH/qoy0J66gjAi7+iEDuhPjYuOJTU 4dac8Vfd9Tc/ZRJGP+z7J95PRix3Pwtnn5Wr0WDuqL4Irojxjp4tbRFl/aVY7C3mexz9 t768RVf5b/JgL0d8lV0VndrNgRe7XtNgkVZqmDsZJ9CuP0R+LKDKxEiwIUxhBtkmaEq/ Ydkg+Owr8MGZkeXM/9Um5WiF0s926LvMPr0zbdsu9LRzkPL5WQMPmINocZx41Bij0OpE 3Iz2/mIZK85Ff2XFIuRZaHG0n1zV3pj4CaCv5t0vgMggJTdLiIhH5iCRphh8YQ3hT2xh +WFQ== Received: by 10.60.27.10 with SMTP id p10mr22422317oeg.49.1347460711776; Wed, 12 Sep 2012 07:38:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.27.10 with SMTP id p10mr22422300oeg.49.1347460711671; Wed, 12 Sep 2012 07:38:31 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Wed, 12 Sep 2012 07:38:31 -0700 (PDT) In-Reply-To: References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Wed, 12 Sep 2012 15:38:31 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQklaMEmVi7BKhAiw4HO7mxlcVEO99YAvo6VevpzDoPYvEf6af1UUFMVOR8EnHQDckR/58XM5Su/OZ9BLLMHvsXc3jxvGSdmVs62dAdN6DxAvW5Axn4nlmV+r8QyxJIQqINoOLnwGlp9tgV8RUVUjkXvVN9wMctmftPXTLzi0KT2BooTp+eowGQyoPuHXxKWkMhwUyXa Cc: "therightkey@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:38:32 -0000 On 12 September 2012 15:37, Phillip Hallam-Baker wrote: > On Wed, Sep 12, 2012 at 10:34 AM, Ben Laurie wrote: >> >> On 12 September 2012 15:33, Phillip Hallam-Baker wrote: >> > Issuing a cert on a public root for the purpose of enabling transparent >> > intercept of SSL on a Bluecoat like device. >> >> OK. So how would one tell what the purpose was? >> >> For example: http://cdp.disney.com/ > > > I don't think you can and I don't think you need to. > > Transparency is pretty robust. If people have a good explanation for the > reason they are doing something then it isn't an intercept cert. If they > don't have an explanation then it is a problem even if the specific problem > isn't intercept. I'd say name constraints were the right mechanism, not a plausible explanation :-) From hallam@gmail.com Wed Sep 12 07:38:41 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCD021F860E for ; Wed, 12 Sep 2012 07:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pck1QEk54Wc for ; Wed, 12 Sep 2012 07:38:40 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B021F21F857D for ; Wed, 12 Sep 2012 07:38:40 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3051620obb.31 for ; Wed, 12 Sep 2012 07:38:40 -0700 (PDT) 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=Tl3sch+ZyshaMYx8otdcUTwr6voGDsptM8r4PkUUHm8=; b=kpQwGss83wtUUXgR6kb4XeQ6d+H+rZEBh4C1FQmIxgtvf6939Sru+wEJijXjHW0VmG 1UYKND4gu0scd99WFOwZwCQmR8a1nDXCBlDh/PsCdSkCwlOC8az9WM4fy3CYw2zvjCbG T8/L4QIhsv9wGbrcITgPdvNxpvKYWxYujG2+KjSNC/9k3zrpixXXYxIsqnhCERgQSRZf 4KZUMdtt3J4b8+lMeCnQxKyXIE/Zom90OOZ8FZXIo2LD/69ixCpXC99uN2/J00kCKBho dTpVV7Zca5wBoMkF9VF3o2tpMyEOIlvzAui5+N2IsWRWcvGC4xFmDZ0MJ38AkLPsGJLp IHQQ== MIME-Version: 1.0 Received: by 10.60.170.229 with SMTP id ap5mr22638565oec.101.1347460720346; Wed, 12 Sep 2012 07:38:40 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Wed, 12 Sep 2012 07:38:40 -0700 (PDT) In-Reply-To: References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Wed, 12 Sep 2012 10:38:40 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=bcaec54b4ac095c7a004c9822590 Cc: "therightkey@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:38:41 -0000 --bcaec54b4ac095c7a004c9822590 Content-Type: text/plain; charset=ISO-8859-1 Or we can use something like Omnibroker. There are lots of ways to boil this bunny. On Wed, Sep 12, 2012 at 10:37 AM, Ben Laurie wrote: > On 12 September 2012 15:35, Phillip Hallam-Baker wrote: > > I don't see why that would be the case. The requirement could be applied > to > > new certs going forward. Or the proofs could be embedded in OCSP tokens > > rather than the certs themselves. > > I think I've said before that I would welcome a move to embedding in > OCSP. Presumably they'd have to be stapled... > > > > > On Wed, Sep 12, 2012 at 10:22 AM, Ben Laurie wrote: > >> > >> On 12 September 2012 02:37, Phillip Hallam-Baker > wrote: > >> > Thinking through some baby steps here. Perhaps one of the first steps > >> > might > >> > be to apply transparency to intermediate certs since those are the > ones > >> > that > >> > have the highest risk associated? > >> > >> You'd have to either re-issue them all, or upgrade all the servers > >> using certs chained from them... > >> > >> > In particular I really hope that there is nobody out there issuing > >> > intercept > >> > certs on public roots. > >> > > >> > > >> > > >> > On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas wrote: > >> >> > >> >> > >> >> On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote: > >> >> > >> >> > > >> >> > Hiya, > >> >> > > >> >> > If you want a BoF, then you need to do the required dance;-) > >> >> > > >> >> > "2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area > >> >> > Directors at UTC 24:00. To request a BOF, please see instructions > on > >> >> > Requesting a BOF." [1] > >> >> > > >> >> > Sean and I remain interested in folks' opinions about having this > >> >> > BoF. So far I've seen about a dozen-ish "I'm interested in > >> >> > something here" responses, a good chunk from folks who do good > >> >> > work around the IETF; one negative comment off-list (saying its > >> >> > not baked), and have seen a just a couple of folks say they'd > >> >> > do work. > >> >> > > >> >> > That's not bad, but nowhere near overwhelming either, so more > >> >> > input would be appreciated, preferably on the list. > >> >> > >> >> Stephen, > >> >> > >> >> I am very supportive of the BoF. > >> >> > >> >> Certificate Transparency addresses a real problem that no other > public > >> >> key > >> >> infrastructure tweaks do. It permits any party to survey the > landscape > >> >> of > >> >> public certificates and do meaningful security analysis. It is also a > >> >> modest > >> >> protocol that doesn't interfere with existing operations. > >> >> > >> >> Many of us doubt the public web certificate infrastructure runs > without > >> >> someone cheating. We take as an article of faith that someone > somewhere > >> >> is > >> >> issuing bogus certificates for whatever nefarious purpose. Usually > that > >> >> is > >> >> some vague surveillance, if not outright espionage. (For what it's > >> >> worth, I > >> >> subscribe to that faith.) > >> >> > >> >> CT has the value that CAs, relying parties, end users, and interested > >> >> third parties can look at the landscape of certificates and catch > >> >> inconsistencies. It allows us put some actual faith into trust. It > >> >> allows us > >> >> to see what is going on in a system that we all use. We need CT. It > >> >> would be > >> >> good to have it develop under the aegis of the IETF. > >> >> > >> >> Jon > >> >> > >> >> _______________________________________________ > >> >> therightkey mailing list > >> >> therightkey@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/therightkey > >> > > >> > > >> > > >> > > >> > -- > >> > Website: http://hallambaker.com/ > >> > > > > > > > > > > > -- > > Website: http://hallambaker.com/ > > > -- Website: http://hallambaker.com/ --bcaec54b4ac095c7a004c9822590 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Or we can use something like Omnibroker.

There are lots = of ways to boil this bunny.

On Wed, = Sep 12, 2012 at 10:37 AM, Ben Laurie <benl@google.com> wrote:<= br>
On 12 September 2012 15:35= , Phillip Hallam-Baker <hallam@gmail= .com> wrote:
> I don't see why that would be the case. The requirement could be a= pplied to
> new certs going forward. Or the proofs could be embedded in OCSP token= s
> rather than the certs themselves.

I think I've said before that I would welcome a move to embedding= in
OCSP. Presumably they'd have to be stapled...

>
> On Wed, Sep 12, 2012 at 10:22 AM, Ben Laurie <benl@google.com> wrote:
>>
>> On 12 September 2012 02:37, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>> > Thinking through some baby steps here. Perhaps one of the fir= st steps
>> > might
>> > be to apply transparency to intermediate certs since those ar= e the ones
>> > that
>> > have the highest risk associated?
>>
>> You'd have to either re-issue them all, or upgrade all the ser= vers
>> using certs chained from them...
>>
>> > In particular I really hope that there is nobody out there is= suing
>> > intercept
>> > certs on public roots.
>> >
>> >
>> >
>> > On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas <jon@callas.org> wrote:
>> >>
>> >>
>> >> On Sep 10, 2012, at 3:21 PM, Stephen Farrell wrote:
>> >>
>> >> >
>> >> > Hiya,
>> >> >
>> >> > If you want a BoF, then you need to do the required = dance;-)
>> >> >
>> >> > "2012-09-24 (Monday): Cutoff date for BOF propo= sal requests to Area
>> >> > Directors at UTC 24:00. To request a BOF, please see= instructions on
>> >> > Requesting a BOF." [1]
>> >> >
>> >> > Sean and I remain interested in folks' opinions = about having this
>> >> > BoF. So far I've seen about a dozen-ish "I&= #39;m interested in
>> >> > something here" responses, a good chunk from fo= lks who do good
>> >> > work around the IETF; one negative comment off-list = (saying its
>> >> > not baked), and have seen a just a couple of folks s= ay they'd
>> >> > do work.
>> >> >
>> >> > That's not bad, but nowhere near overwhelming ei= ther, so more
>> >> > input would be appreciated, preferably on the list.<= br> >> >>
>> >> Stephen,
>> >>
>> >> I am very supportive of the BoF.
>> >>
>> >> Certificate Transparency addresses a real problem that no= other public
>> >> key
>> >> infrastructure tweaks do. It permits any party to survey = the landscape
>> >> of
>> >> public certificates and do meaningful security analysis. = It is also a
>> >> modest
>> >> protocol that doesn't interfere with existing operati= ons.
>> >>
>> >> Many of us doubt the public web certificate infrastructur= e runs without
>> >> someone cheating. We take as an article of faith that som= eone somewhere
>> >> is
>> >> issuing bogus certificates for whatever nefarious purpose= . Usually that
>> >> is
>> >> some vague surveillance, if not outright espionage. (For = what it's
>> >> worth, I
>> >> subscribe to that faith.)
>> >>
>> >> CT has the value that CAs, relying parties, end users, an= d interested
>> >> third parties can look at the landscape of certificates a= nd catch
>> >> inconsistencies. It allows us put some actual faith into = trust. It
>> >> allows us
>> >> to see what is going on in a system that we all use. We n= eed CT. It
>> >> would be
>> >> good to have it develop under the aegis of the IETF.
>> >>
>> >> =A0 =A0 =A0 =A0 Jon
>> >>
>> >> _______________________________________________
>> >> therightkey mailing list
>> >> therightkey@ietf.= org
>> >> https://www.ietf.org/mailman/listinfo/therightkey
>> >
>> >
>> >
>> >
>> > --
>> > Website: http://hallambaker.com/
>> >
>
>
>
>
> --
> Website: http://= hallambaker.com/
>



--
= Website: http://hallambaker.com/
--bcaec54b4ac095c7a004c9822590-- From hallam@gmail.com Wed Sep 12 07:39:38 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC6A21F8604 for ; Wed, 12 Sep 2012 07:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BqD3u7Z5Qur for ; Wed, 12 Sep 2012 07:39:38 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 850A721F857D for ; Wed, 12 Sep 2012 07:39:37 -0700 (PDT) Received: by oagk14 with SMTP id k14so1160433oag.31 for ; Wed, 12 Sep 2012 07:39:37 -0700 (PDT) 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=a5rfKD55bvM/a8xiMyTlUtrvTsvZDg+T/vble6GYxWk=; b=F9FZI8+MnYoznvqCGWTykF54RWiqfr6w0Nwj6eUchWtPaxdIi5dO7MB2YqXswhCJPS 8oNHaQypFr6GdBGs4P2NTh8D8s7vN2zQPfMeBhQ5sgmd7DAgNAxsjw4z5xbM+BppR6g9 2N4PRgb5xj928FY4jBuuI9q7r9KvMXHOAe43IwgpqTtOldi7Ohgi7mtKc7H71DiiNRvA XiOE17Vqh++TC0i9F3K/zZTBcXIxr+Lu73pVOA8PyhHc8p6vbuj4fA7Kf4fo/mdgphYw D0ApXYA0Y6jxWdTy7sijo+68Fild+jEk4JXLsxusqXf8bS9xQMjzYzE4VZh4qNcoe23E j1oA== MIME-Version: 1.0 Received: by 10.60.25.129 with SMTP id c1mr6223392oeg.36.1347460777208; Wed, 12 Sep 2012 07:39:37 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Wed, 12 Sep 2012 07:39:37 -0700 (PDT) In-Reply-To: References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Wed, 12 Sep 2012 10:39:37 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8ff1c6cef96a8b04c98228a9 Cc: "therightkey@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:39:38 -0000 --e89a8ff1c6cef96a8b04c98228a9 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 12, 2012 at 10:38 AM, Ben Laurie wrote: > On 12 September 2012 15:37, Phillip Hallam-Baker wrote: > > On Wed, Sep 12, 2012 at 10:34 AM, Ben Laurie wrote: > >> > >> On 12 September 2012 15:33, Phillip Hallam-Baker > wrote: > >> > Issuing a cert on a public root for the purpose of enabling > transparent > >> > intercept of SSL on a Bluecoat like device. > >> > >> OK. So how would one tell what the purpose was? > >> > >> For example: http://cdp.disney.com/ > > > > > > I don't think you can and I don't think you need to. > > > > Transparency is pretty robust. If people have a good explanation for the > > reason they are doing something then it isn't an intercept cert. If they > > don't have an explanation then it is a problem even if the specific > problem > > isn't intercept. > > I'd say name constraints were the right mechanism, not a plausible > explanation :-) > Which is what got me thinking about doing it there first, we want to do NC there so it makes sense to start there. -- Website: http://hallambaker.com/ --e89a8ff1c6cef96a8b04c98228a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Sep 12, 2012 at 10:38 AM, Ben La= urie <benl@google.com> wrote:
On 12 September 2012 15:37, Phillip= Hallam-Baker <hallam@gmail.com&= gt; wrote:
> On Wed, Sep 12, 2012 at 10:34 AM, Ben Laurie <benl@google.com> wrote:
>>
>> On 12 September 2012 15:33, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>> > Issuing a cert on a public root for the purpose of enabling t= ransparent
>> > intercept of SSL on a Bluecoat like device.
>>
>> OK. So how would one tell what the purpose was?
>>
>> For example: = http://cdp.disney.com/
>
>
> I don't think you can and I don't think you need to.
>
> Transparency is pretty robust. If people have a good explanation for t= he
> reason they are doing something then it isn't an intercept cert. I= f they
> don't have an explanation then it is a problem even if the specifi= c problem
> isn't intercept.

I'd say name constraints were the right mechanism, not a pl= ausible
explanation :-)

Which is what got me thinking about doing it there f= irst, we want to do NC there so it makes sense to start there.


-= -
Website: http://hallambaker.com/<= /a>

--e89a8ff1c6cef96a8b04c98228a9-- From hallam@gmail.com Wed Sep 12 07:40:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C06521F861B for ; Wed, 12 Sep 2012 07:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU9TQnIBAt29 for ; Wed, 12 Sep 2012 07:40:24 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C54321F860E for ; Wed, 12 Sep 2012 07:40:24 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3055158obb.31 for ; Wed, 12 Sep 2012 07:40:24 -0700 (PDT) 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=i3Z2lj0FBSENtoCyuFqNNdQOhUm4iTFyTIRqHWa/XHk=; b=tz/L9+xGKaEwCHsKMxULRtNE2xHQr8KKkLtO4EMQuBmZVAgzuAtI5aekwyu5dwIUzd 7J3bsqLDrOgKI21YgjdVgHTRASHFEg7eY0JPomrwmrt8xgrDvaIFH+0+dVVFW0jTYWhT szJ82dQZF0+txKM+AFDvv/IO5mc+UQjubgBdxO7OMJnKRFwBgCLPLqMPm5+82AZ83GS8 ZhdJu5n4qc+SrXjJtwmoG3fTXrSEbFgqgWq1QKTT/Pys8JwYSQn/rVAvrg1iM6GFoffg ohMBZJbVAy8+SANGsmODIygsfLhrMh737txZIVRd+18w1v9Ds5PRZHVviLH0HxjHI0+I /MHg== MIME-Version: 1.0 Received: by 10.60.5.194 with SMTP id u2mr22413108oeu.24.1347460824173; Wed, 12 Sep 2012 07:40:24 -0700 (PDT) Received: by 10.76.80.10 with HTTP; Wed, 12 Sep 2012 07:40:24 -0700 (PDT) In-Reply-To: References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> Date: Wed, 12 Sep 2012 10:40:24 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8ff2509ec60c5004c9822b62 Cc: "therightkey@ietf.org" , Jon Callas , Stephen Farrell Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:40:25 -0000 --e89a8ff2509ec60c5004c9822b62 Content-Type: text/plain; charset=ISO-8859-1 Perhaps we need both a BOF and a Bar BOF on this. On Wed, Sep 12, 2012 at 10:39 AM, Phillip Hallam-Baker wrote: > > > On Wed, Sep 12, 2012 at 10:38 AM, Ben Laurie wrote: > >> On 12 September 2012 15:37, Phillip Hallam-Baker >> wrote: >> > On Wed, Sep 12, 2012 at 10:34 AM, Ben Laurie wrote: >> >> >> >> On 12 September 2012 15:33, Phillip Hallam-Baker >> wrote: >> >> > Issuing a cert on a public root for the purpose of enabling >> transparent >> >> > intercept of SSL on a Bluecoat like device. >> >> >> >> OK. So how would one tell what the purpose was? >> >> >> >> For example: http://cdp.disney.com/ >> > >> > >> > I don't think you can and I don't think you need to. >> > >> > Transparency is pretty robust. If people have a good explanation for the >> > reason they are doing something then it isn't an intercept cert. If they >> > don't have an explanation then it is a problem even if the specific >> problem >> > isn't intercept. >> >> I'd say name constraints were the right mechanism, not a plausible >> explanation :-) >> > > Which is what got me thinking about doing it there first, we want to do NC > there so it makes sense to start there. > > > -- > Website: http://hallambaker.com/ > > -- Website: http://hallambaker.com/ --e89a8ff2509ec60c5004c9822b62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps we need both a BOF and a Bar BOF on this.


On Wed, Sep 12, 2012 at 10:39 AM, Phillip Hallam-Baker <halla= m@gmail.com> wrote:

=
On Wed, Sep 12, 2012 at 10:38 AM, Ben Laurie= <benl@google.com> wrote:
On 12 September 2012 15:37, Phillip Hallam-Baker <hallam@gmail.com> wrote: > On Wed, Sep 12, 2012 at 10:34 AM, Ben Laurie <benl@google.com> wrote:
>>
>> On 12 September 2012 15:33, Phillip Hallam-Baker <hallam@gmail.com> wrote: >> > Issuing a cert on a public root for the purpose of enabling t= ransparent
>> > intercept of SSL on a Bluecoat like device.
>>
>> OK. So how would one tell what the purpose was?
>>
>> For example: = http://cdp.disney.com/
>
>
> I don't think you can and I don't think you need to.
>
> Transparency is pretty robust. If people have a good explanation for t= he
> reason they are doing something then it isn't an intercept cert. I= f they
> don't have an explanation then it is a problem even if the specifi= c problem
> isn't intercept.

I'd say name constraints were the right mechanism, not a pl= ausible
explanation :-)

Which is what got me thinking about doin= g it there first, we want to do NC there so it makes sense to start there.<= span class=3D"HOEnZb">


--
Website: <= a href=3D"http://hallambaker.com/" target=3D"_blank">http://hallambaker.com= /




-- Website: http://hallambaker.com/<= br>
--e89a8ff2509ec60c5004c9822b62-- From stephen.farrell@cs.tcd.ie Wed Sep 12 07:53:33 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C47821F8555 for ; Wed, 12 Sep 2012 07:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.535 X-Spam-Level: X-Spam-Status: No, score=-106.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGEeuZBiP5E7 for ; Wed, 12 Sep 2012 07:53:32 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id B69EB21F854C for ; Wed, 12 Sep 2012 07:53:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C7F0117147A; Wed, 12 Sep 2012 15:53:09 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1347461589; bh=dOZik84H6MwhPy 6n3Dgbg1yMGL01uL3IMGyl530/sQk=; b=bdnzCWG5RSxL30F/VNFjlUuuski45P HKm+T2jJ15tUGn8DnnSys8+17pcCM+lLSN8l6rTu0za6Ufdm/90qhd8JwFdvZA8L ofs1MTZIpvlJaSs1ET0Qbo/34j0c0chuGPU3g+I2DvhtdPQXBVIYn1yB9Tdo9oBF LQrvl4/m4QV9eIVl1freS94bhRGbRULv6eXaz34qJkUGthgvrHqrx4J73xfz9lV6 Lf9YPiPCXHCg8syxfCCYB/Gl4suTKgddoOLgec8n0d33zCr5iJzRSRsVMs45GRF0 ZijngxIlLf8z6gVE/VXRJSN6x2f7qxvham0fkEm6Iquq+OFRLL7QKD/A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ZkvKnwEeZf1z; Wed, 12 Sep 2012 15:53:09 +0100 (IST) Received: from [IPv6:2001:770:10:203:353a:ba33:c76c:87ba] (unknown [IPv6:2001:770:10:203:353a:ba33:c76c:87ba]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3B603171474; Wed, 12 Sep 2012 15:53:09 +0100 (IST) Message-ID: <5050A1D6.4010205@cs.tcd.ie> Date: Wed, 12 Sep 2012 15:53:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <504E67F2.8020002@cs.tcd.ie> <147DF892-AF33-49A9-85C5-6F3F9173B7BF@callas.org> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:53:33 -0000 On 09/12/2012 03:40 PM, Phillip Hallam-Baker wrote: > Perhaps we need both a BOF and a Bar BOF on this. Going straight to the bar after a BoF is a fine plan :-) S. From paul.hoffman@vpnc.org Wed Sep 12 07:55:24 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9FB21F861E for ; Wed, 12 Sep 2012 07:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CCFIVMVPyfX for ; Wed, 12 Sep 2012 07:55:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BFC0821F8602 for ; Wed, 12 Sep 2012 07:55:23 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8CEtMUX080970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 12 Sep 2012 07:55:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Paul Hoffman In-Reply-To: <504F62B2.1040900@cs.tcd.ie> Date: Wed, 12 Sep 2012 07:55:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <504E67F2.8020002@cs.tcd.ie> <504F62B2.1040900@cs.tcd.ie> To: therightkey@ietf.org X-Mailer: Apple Mail (2.1486) Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:55:24 -0000 On Sep 11, 2012, at 9:11 AM, Stephen Farrell = wrote: > We have a BoF chair volunteer who'll be able to > help start organising agenda slots etc after the > BoF approval call. More on that after the 24th. Delurking: that would be me. I didn't want to say anything until I had = caught up on the list, and I still haven't, but then again it's not = urgent because we don't know whether we will even get a slot. More later = when we do. FWIW, I'm the one who proposed 90 minutes instead of the typical 60. My = view is that there should be no more than 30-45 minutes of presentations = followed by lots of mic talk. I will probably enforce a "presentations = must be ready the Monday before the meeting" requirement and will = encourage people to start reading and commenting on them then. The value of mic time is not "I like this and don't like that", but = rather "that one idea on slide 3 makes me think of this other thing that = hasn't been discussed yet". Proclamations of "this is great" and "this = will never work" are more appropriate on the list; proposals of "if you = add this" or "if you change that" are better uses of mic time. The fact that we might meet f2f should have little effect on the current = discussion. --Paul Hoffman= From stephen.farrell@cs.tcd.ie Wed Sep 12 08:23:49 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAE621F8621 for ; Wed, 12 Sep 2012 08:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWMMvSZOEjpQ for ; Wed, 12 Sep 2012 08:23:38 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1B76D21F8613 for ; Wed, 12 Sep 2012 08:23:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 850E5171480; Wed, 12 Sep 2012 16:23:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1347463393; bh=eViORumIxzf4a8 lvPqKqU/XLgVe2Cqks6RulHRgvy/o=; b=ivQorf+QOhuVrNTGYv8fvaEoFekiQw ImWHr3JteFcwGM6ue3W5KIPRoGzcvAsw2Qwmfgo6SrBTxzYPuZrWhtNdKjfnkAOs lmbJztR4MnqFs1YUVwVpSpQ7iMYGF4Lt4uMQQMfG+zmHlod4XAClOlKcmY48A30X sTOgj5XFh4NZc2w8flgw6vbP6kYpnIjegw+ExFJ7ZPGa0Y9Y+MeCv7jjJUPjGTqf cFAmrXiknfQ1xkZ1xzJllmFXPAcKgYKZAJY6RD+LzoR6j45IXtKSom3AfccxiUcw XYiLJcryiqBEWzaQ1u4VtQdEfIq3HcE75LnviFYb5dcPNRMnEf8Rt+Zg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id wyI6Xr5yadR0; Wed, 12 Sep 2012 16:23:13 +0100 (IST) Received: from [IPv6:2001:770:10:203:353a:ba33:c76c:87ba] (unknown [IPv6:2001:770:10:203:353a:ba33:c76c:87ba]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E3C7E17147A; Wed, 12 Sep 2012 16:23:11 +0100 (IST) Message-ID: <5050A8E0.8000806@cs.tcd.ie> Date: Wed, 12 Sep 2012 16:23:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Paul Hoffman References: <504E67F2.8020002@cs.tcd.ie> <504F62B2.1040900@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] Transparency BoF - there's a deadline... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:23:49 -0000 On 09/12/2012 03:55 PM, Paul Hoffman wrote: > On Sep 11, 2012, at 9:11 AM, Stephen Farrell wrote: > >> We have a BoF chair volunteer who'll be able to >> help start organising agenda slots etc after the >> BoF approval call. More on that after the 24th. > > Delurking: that would be me. And thanks Paul for taking it on. > I didn't want to say anything until I had caught up on the list, and I still haven't, but then again it's not urgent because we don't know whether we will even get a slot. More later when we do. > > FWIW, I'm the one who proposed 90 minutes instead of the typical 60. My view is that there should be no more than 30-45 minutes of presentations followed by lots of mic talk. I will probably enforce a "presentations must be ready the Monday before the meeting" requirement and will encourage people to start reading and commenting on them then. > > The value of mic time is not "I like this and don't like that", but rather "that one idea on slide 3 makes me think of this other thing that hasn't been discussed yet". Proclamations of "this is great" and "this will never work" are more appropriate on the list; proposals of "if you add this" or "if you change that" are better uses of mic time. > > The fact that we might meet f2f should have little effect on the current discussion. Right. A number of people have also said "something like this might be good, not sure what" so if those folks can write up Internet-drafts too that'd be great since we could discuss 'em on the list and make better use of f2f time if we get it. S. > > --Paul Hoffman > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > From SChokhani@cygnacom.com Tue Sep 18 07:27:46 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9221F874A for ; Tue, 18 Sep 2012 07:27:45 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjL8jKTTf6V7 for ; Tue, 18 Sep 2012 07:27:45 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id F3DBB21F8744 for ; Tue, 18 Sep 2012 07:27:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,442,1344225600"; d="scan'208";a="1970952" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 18 Sep 2012 10:27:40 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Tue, 18 Sep 2012 10:27:40 -0400 From: Santosh Chokhani To: Ben Laurie , "therightkey@ietf.org" Date: Tue, 18 Sep 2012 10:27:38 -0400 Thread-Topic: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-00.txt Thread-Index: Ac2Q7PIdPuzion6NQZabbbx8v2QjYQEuuVeQ Message-ID: References: <20120912132434.20539.5223.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-00.txt X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 14:27:46 -0000 Ben, One of the things the transparency depends on is the domain owners and audi= tors monitoring the logs. Given the size, if things are not verified, mis-= issued certificates can fall through the cracks. I have some minor suggest= ions that may strengthen the transparency I-D further. You are welcome to = consider some or all of these below: 1. Discuss this dependency explicitly in the Security Considerations Secti= on. 2. Since the SCT extension has the certification path used by the log, dis= cuss that the relying party optionally can match that with their path albei= t the paths could be different in some instances. 3. Include a flag or indication in the SCT extension if the Log has matche= d one of the CAs in the path authoritative for the domain name if the domai= n has registered such a CA using out of band means. (I have not fully thou= ght out what the relying party will do if flag says no, but would think tha= t if the Log knows CAs for a domain and the certificate is not a descendant= of one of the CAs, log will not automatically include the certificate in t= he log) 4. Given the structure of SCT, the determination that a CA speaks for doma= in can be made by Log, Auditor or the relying party if they have a visibili= ty into authorized CAs for the domain. -----Original Message----- From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] On= Behalf Of Ben Laurie Sent: Wednesday, September 12, 2012 9:46 AM To: therightkey@ietf.org Subject: [therightkey] Fwd: New Version Notification for draft-laurie-pki-s= unlight-00.txt ---------- Forwarded message ---------- From: Date: 12 September 2012 14:24 Subject: New Version Notification for draft-laurie-pki-sunlight-00.txt To: benl@google.com Cc: ekasper@google.com, agl@google.com A new version of I-D, draft-laurie-pki-sunlight-00.txt has been successfull= y submitted by Ben Laurie and posted to the IETF repository. Filename: draft-laurie-pki-sunlight Revision: 00 Title: Certificate Transparency Creation date: 2012-09-12 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-laurie-pki-sunlight-00.txt Status: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight Htmlized: http://tools.ietf.org/html/draft-laurie-pki-sunlight-00 Abstract: The aim of Certificate Transparency is to have every public end- entity TLS certificate issued by a known Certificate Authority recorded in one or more certificate logs. In order to detect mis- issuance of certificates, all logs are publicly auditable. In particular, domain owners will be able to monitor logs for certificates issued on their own domain. In order to protect clients from unlogged mis-issued certificates, logs sign all recorded certificates, and clients can choose not to trust certificates that are not accompanied by an appropriate log signature. For privacy and performance reasons log signatures are embedded in the TLS handshake via the TLS authorization extension [RFC5878], or in the certificate itself via an X.509v3 certificate extension [RFC5280]. In order to ensure a globally consistent view of the log, logs also provide a global signature over the entire log. Any inconsistency of logs can be detected through cross-checks on the global signature. Logs are only expected to certify that they have seen a certificate and thus, we do not specify any revocation mechanism for log signatures in this document. Logs will be append-only, and log signatures will be valid indefinitely. The IETF Secretariat _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey From benl@google.com Wed Sep 19 02:55:16 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC50321F872A for ; Wed, 19 Sep 2012 02:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNXvKdJtVFLL for ; Wed, 19 Sep 2012 02:55:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 043DC21F86E1 for ; Wed, 19 Sep 2012 02:55:15 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so939202obb.31 for ; Wed, 19 Sep 2012 02:55:15 -0700 (PDT) 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:x-system-of-record; bh=l6uydKvgvcNCuSdQOFbEikLBLkhtN0mMTt0sHaLPL30=; b=fo14EwLqfztAVd8qdMUo9yc9PypP47YVwQyyuLj6Rjw5ZHNj5rrsB0XL2+9Gd9B428 TP6p6GWsj4XykjjKkdgRGc06mLZxVqXQcgYxQgJslLgJTdg8CfE8BTjBBZdXd/jpYSrl lRKd2kQkTeIUoUBJaRIg3+U6I7USj1Ka7gsZaFZ0VfUT1LXrrfdAChoQrsk+vjvNMyqB nPzl9oMGbtC3IrCxI64yrF7U5Nm+tcO38tjoxxTBZX+zv8c87kPnjfKVWboCZ4mDlZft 3TpwzGxkS+Am0INWI60ZmgYdZ0G3Q47qMYS9dcbmNLb2pIWQxvpq/JHH7sNywbGhZg1f 256w== X-Google-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:x-system-of-record :x-gm-message-state; bh=l6uydKvgvcNCuSdQOFbEikLBLkhtN0mMTt0sHaLPL30=; b=Th2CDXY///nNSZnFfi7G5gbi5JCZ5ezZqRSJaQeYzhwTJnqIyMvt7EvPSOYNOW54md hAzhnTB5euaTdoQkXNHfPTw9W5jmyVV7Ul2pWO+jjPIY7KnCI4rUqUcqyJwCEnFEWpEH IBrMS2dMb42RHRDgRG7peX85RffjsJWcAgrEOJftu4gjXW4WL4CYVeVYPp0Uf5iFs7Kq ZJTEoY0ZaE16paVcLC3FjDLH0EFs6pbKr7O08+V6tH0FUvDNHi1yh+wNVGakiGtw9ND3 z6fxuqXk4gVl6S2cgt9wRhA77avy5RU7kXh7bjObflb+sq3V7XYEumUcThv2BX2P3W2y tEbQ== Received: by 10.60.29.134 with SMTP id k6mr2628260oeh.5.1348048515497; Wed, 19 Sep 2012 02:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.29.134 with SMTP id k6mr2628253oeh.5.1348048515396; Wed, 19 Sep 2012 02:55:15 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Wed, 19 Sep 2012 02:55:15 -0700 (PDT) In-Reply-To: References: <20120912132434.20539.5223.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 10:55:15 +0100 Message-ID: From: Ben Laurie To: Santosh Chokhani Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlLBgHSLFt8EQ1ci/j9OPPz+arm5RJZTWahznxy3NH+CJT1GJkjU5q9pqTRL4UaDVbNXeJ+ufpYKoTukU41Gpk9fznlx+6/mcrxNkR3KSiFjidpB8+aC2olgZucuv6LZueEc1ZHCA91KPqjnla2EChCUUV1puvDFusAXPkjHFXysXRdfHjvzDvwUhnYuTfdAxzVo7pb Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-00.txt X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 09:55:16 -0000 On 18 September 2012 15:27, Santosh Chokhani wrote= : > Ben, > > One of the things the transparency depends on is the domain owners and au= ditors monitoring the logs. Given the size, if things are not verified, mi= s-issued certificates can fall through the cracks. I have some minor sugge= stions that may strengthen the transparency I-D further. You are welcome t= o consider some or all of these below: > > 1. Discuss this dependency explicitly in the Security Considerations Sec= tion. I'm about to push a revised version, but I'll add something about this. > 2. Since the SCT extension has the certification path used by the log, d= iscuss that the relying party optionally can match that with their path alb= eit the paths could be different in some instances. The SCT does not contain the certification path for exactly this reason. > 3. Include a flag or indication in the SCT extension if the Log has matc= hed one of the CAs in the path authoritative for the domain name if the dom= ain has registered such a CA using out of band means. (I have not fully th= ought out what the relying party will do if flag says no, but would think t= hat if the Log knows CAs for a domain and the certificate is not a descenda= nt of one of the CAs, log will not automatically include the certificate in= the log) I presume you're referring to the use of DANE or CAA or something of that nature? In any case, the log's purpose is not to judge the correctness or otherwise of any particular certificate, but to make a public record so that others can judge. That said, the log could include a flag that said "at the time of issuance, the issuing CA was allowed to issue for the domain, by virtue of a CAA record". The log would presumably have to also include a DNSSEC chain showing that this was so. I'm not sure if DNSSEC chains can be effectively timestamped, though, so it would be hard to prevent the log from lying about this. Finally, we have been considering defining an extension mechanism for the log, and this kind of thing seems like it would fit right in. Does anyone have views on this? > 4. Given the structure of SCT, the determination that a CA speaks for do= main can be made by Log, Auditor or the relying party if they have a visibi= lity into authorized CAs for the domain. Surely this determination is independent of the log? The log could say in the SCT what things looked like at time of submission, but as I say above, the log's function is to record, not judge. From benl@google.com Wed Sep 19 08:12:56 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E62021F8567 for ; Wed, 19 Sep 2012 08:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcbtd4MeGE6P for ; Wed, 19 Sep 2012 08:12:56 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id E58CA21F855E for ; Wed, 19 Sep 2012 08:12:55 -0700 (PDT) Received: by oagn5 with SMTP id n5so640219oag.31 for ; Wed, 19 Sep 2012 08:12:55 -0700 (PDT) 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:x-system-of-record; bh=0AspELOHj3QX5cG4Kk97WKE+SikkNaVxhkLfO3Ctoow=; b=QV0zNNHovX/4ffZm3lIZBdYCPp5+393bU11SY/+95IuB36ZfS8LKzCt8xRSzGUzBGk rihZKyHQ+8WBeZ2pd/lUVDiK3S38zYetFftb12mTyrVGqGbPwbxJhe15nz3Swy8jF8tk Cj90NWbjEjGL2FLImiMEAk2ubEyByCIDhll61ANxL+gb36ATnaFIP8xaB2c/vm2HAb4C OyU0KHKUxkEPJd2oqeMEsYyYFTxkgkD9YoIZASb+0Ha12EgxCvN6tkoDb/w6JI5NXwBq OtL4mgqPQGMuujD9XeGSX27hTzBf9jvGzxAYPTdqJ8ivDxDiqtGneOiirWJKclzCx/Bi 7snQ== X-Google-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:x-system-of-record:x-gm-message-state; bh=0AspELOHj3QX5cG4Kk97WKE+SikkNaVxhkLfO3Ctoow=; b=mPifrITwfwBQ5ZcBrpNInKSGqSEzq7ACPqrOXMydqwAaAUdnNr/vbbTlHN0bHgMKgj kvL8qip01C/i9rjWagdPeTBWKZQzzqr+1bxkrVF6GQznYg2AXLUnU4LitvtQBi9w6pJC M3C+qyoY6On/fV6/ztWST2gSe5Hs0zmOIZn0iOzgnkA8kGyR8FvS2PzxXC5dSRRx/dko 1tfGXDzCH9N3wyGewTb5pgbc4vFmhJsSbObwVUe10QXgi1tHTNXOq7s4LSZ12IlpSG/O rGvTPc5gI4nuwi7+1OK14T+yvBXK5YHswyhQpjveai3qHFAyEDjPwolezuQVZdPi0mbt X06A== Received: by 10.60.1.106 with SMTP id 10mr3258967oel.84.1348067575457; Wed, 19 Sep 2012 08:12:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.1.106 with SMTP id 10mr3258959oel.84.1348067575319; Wed, 19 Sep 2012 08:12:55 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Wed, 19 Sep 2012 08:12:55 -0700 (PDT) In-Reply-To: <20120919150144.22746.18213.idtracker@ietfa.amsl.com> References: <20120919150144.22746.18213.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 16:12:55 +0100 Message-ID: From: Ben Laurie To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlOItA3fVj7O0eE6W2US42gxOcdqTADtzrqWqnaSh4mx9skIhWJm0OpQswLN9leIB/sonWA22/39FJOdhAdsQDsle0Glq+XGOBCTnbSh7XnkJ2SrYOJzdyn9/f1iyw7sJ2QrmY4k4IWqf5Svam6KcqXbqW1h9CGrr3fkz34Qv2zeCf++B/YMXEjuzQNhDLKkKe73+du Subject: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-01.txt X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 15:12:56 -0000 ---------- Forwarded message ---------- From: Date: 19 September 2012 16:01 Subject: New Version Notification for draft-laurie-pki-sunlight-01.txt To: benl@google.com Cc: ekasper@google.com, agl@google.com A new version of I-D, draft-laurie-pki-sunlight-01.txt has been successfully submitted by Ben Laurie and posted to the IETF repository. Filename: draft-laurie-pki-sunlight Revision: 01 Title: Certificate Transparency Creation date: 2012-09-19 WG ID: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-laurie-pki-sunlight-01.txt Status: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight Htmlized: http://tools.ietf.org/html/draft-laurie-pki-sunlight-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-laurie-pki-sunlight-01 Abstract: The aim of Certificate Transparency is to have every public end- entity and intermediate TLS certificate issued by a known Certificate Authority recorded in one or more certificate logs. In order to detect mis-issuance of certificates, all logs are publicly auditable. In particular, domain owners or their agents will be able to monitor logs for certificates issued on their own domain. To protect clients from unlogged mis-issued certificates, logs sign all recorded certificates, and clients can choose not to trust certificates that are not accompanied by an appropriate log signature. For privacy and performance reasons log signatures are embedded in the TLS handshake via the TLS authorization extension [RFC5878], or in the certificate itself via an X.509v3 certificate extension [RFC5280]. To ensure a globally consistent view of the log, logs also provide a global signature over the entire log. Any inconsistency of logs can be detected through cross-checks on the global signature. Consistency between any pair of global signatures, corresponding to snapshots of the log at different times, can be efficiently shown. Logs are only expected to certify that they have seen a certificate, and thus we do not specify any revocation mechanism for log signatures in this document. Logs are append-only, and log signatures will be valid indefinitely. The IETF Secretariat From mrex@sap.com Thu Sep 20 22:51:13 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AE821F8555 for ; Thu, 20 Sep 2012 22:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.188 X-Spam-Level: X-Spam-Status: No, score=-10.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGn4L4MqI3FI for ; Thu, 20 Sep 2012 22:51:12 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 970BC21F8551 for ; Thu, 20 Sep 2012 22:51:11 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q8L5ov1I029436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Sep 2012 07:50:57 +0200 (MEST) In-Reply-To: To: Santosh Chokhani Date: Fri, 21 Sep 2012 07:50:57 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120921055057.5FB3B1A23F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 05:51:13 -0000 Santosh Chokhani wrote: > Ben Laurie, > > I am posting this at the suggestion of Stephen Ferrell. There is no evidence that he supports or is against my analysis. He just thought this mail list is the appropriate place to make my point.. > > My basic tenet is that the OCSP certinfo extension being discussed in PKIX does not protect against RA compromise and may also not protect against CA compromise since the attacker who compromised the CA may be able to create an OCSP Responder certificate and either also put bogus OCSP pointer in the minted certificates or use DNS poisoning on the relying parties. > > Thus, I think the certificate transparency is worth discussing. Locating the OCSP server through AIA in the EE cert might be the problem here. Maybe the OCSP responder ought to be located through an extension in the CA cert itself instead? -Martin From benl@google.com Fri Sep 21 01:58:29 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECCD21F86E4 for ; Fri, 21 Sep 2012 01:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+uO1KkwovDj for ; Fri, 21 Sep 2012 01:58:27 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 781D621F86BA for ; Fri, 21 Sep 2012 01:58:27 -0700 (PDT) Received: by oagn5 with SMTP id n5so2817266oag.31 for ; Fri, 21 Sep 2012 01:58:27 -0700 (PDT) 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:x-system-of-record; bh=R4FfweVSvW9jHrLcLeEOuT9aworFnb5LRSitBjr9k7k=; b=eWhr7aXSiFbc8gZ0/TGiiybsK9O1uuHpnIJfmyIMJajB0yRU1tuol24mfKPfRASpLG qadhnQF9fdzBIJy2Li1s/CsQFI/dOh+CgpAKs3RyTDUAPyzpKhKpUxZzWVZtJsTWr8Iy +ddAAFf3dwO20Zgzg4TY2oDotN2MwBEEf21kbdBiZ4ySrsjjHKZKGJ3I4duRMeBPNqCQ qrbaugUC5i4FwbnblQxBlX8HpsAfJWgIgERolcLDOC0liEw0oOywcznw8y7IkR2yD2r7 1rhOauk33v2zlfz0KAiBmKW0lPQsW+Pj6Sjc6XHM+oYl89tKqG+Fk1pnLjBUwdAnnT5d 2oLA== X-Google-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:x-system-of-record :x-gm-message-state; bh=R4FfweVSvW9jHrLcLeEOuT9aworFnb5LRSitBjr9k7k=; b=W1j/Flv+qgyAJxrhFC77A6U/GKO1ORgpBiCbV26z33Twi8QLYajz5VpChGEcxHFA5W vs30LfvlZ0GwMwFFe0lIlVf9ckJFCq8XD4pRdA07ygjRNmSqoBcHN9q247J65yRjAZ/+ 2WKw7LArma+3P+T2lyahYk8WKtf9S2Stt1jEhozxvOftd91zZmQRf0DVVS8NUA70vEwc TTMVPBOh0YjmdivAqUNnIutTSN47Ym21njpgYGfP5oPIJ5kq2vo4Jx5vwGUHZg0jovEO x8QTTebeN44Ee7rym4v+fmC4W3JLA5sJdKcUHmlYP21gpwF3t9nl3FSzNp84x282IDjr xdbA== Received: by 10.60.29.134 with SMTP id k6mr3282071oeh.5.1348217907121; Fri, 21 Sep 2012 01:58:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.29.134 with SMTP id k6mr3282063oeh.5.1348217907022; Fri, 21 Sep 2012 01:58:27 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Fri, 21 Sep 2012 01:58:26 -0700 (PDT) In-Reply-To: <20120921055057.5FB3B1A23F@ld9781.wdf.sap.corp> References: <20120921055057.5FB3B1A23F@ld9781.wdf.sap.corp> Date: Fri, 21 Sep 2012 09:58:26 +0100 Message-ID: From: Ben Laurie To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmZ3ZULl8zuNOf58zML0/2Ybo4AZF4OccHjJvPjw/WwH4vWFbVePrO5fSZncJKGUGWzPrCobr0MF1nmPwbp0FTKSvNfosTci5YHd16gl7YRSQc2AGcIl3roaeGcey31VuhI1LRzpxsN1m8tGeHRyVpErN/NsLgklyhsmPGCbolztbAaxRR7K/9RHuiUIA6TaKSEpcPP Cc: Santosh Chokhani , "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 08:58:29 -0000 On 21 September 2012 06:50, Martin Rex wrote: > Santosh Chokhani wrote: >> Ben Laurie, >> >> I am posting this at the suggestion of Stephen Ferrell. There is no evi= dence that he supports or is against my analysis. He just thought this mai= l list is the appropriate place to make my point.. >> >> My basic tenet is that the OCSP certinfo extension being discussed in PK= IX does not protect against RA compromise and may also not protect against = CA compromise since the attacker who compromised the CA may be able to crea= te an OCSP Responder certificate and either also put bogus OCSP pointer in = the minted certificates or use DNS poisoning on the relying parties. >> >> Thus, I think the certificate transparency is worth discussing. > > Locating the OCSP server through AIA in the EE cert might be the > problem here. Maybe the OCSP responder ought to be located > through an extension in the CA cert itself instead? That would make CT substantially harder, because then we'd have to deal with authenticating chains instead of just EE certs - and EE certs tend to have multiple authentication chains... From benl@google.com Fri Sep 21 02:33:44 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F0D21F8720 for ; Fri, 21 Sep 2012 02:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6GjoHhG8nIg for ; Fri, 21 Sep 2012 02:33:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAA821F871A for ; Fri, 21 Sep 2012 02:33:43 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3420222obb.31 for ; Fri, 21 Sep 2012 02:33:43 -0700 (PDT) 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:x-system-of-record; bh=jbFLZMp8ZFjGcYS1EdcAU/miFSFmNWWFKf3zIROZ/ws=; b=OBsS15sib+zVgjI+YSeECLdk+P6L05n3Xw4d+UbQyCHYYole8spT7w2WRL/9opn7Ue IKW0y8uWVZh3Mf+Xtdm6iw0U7VPAfJEZgSkQV5kUuAFQojZFYXnEg70oOVBltwTpRTmx IVPk/fk1FaT1D98qFT0BuyYqMgEnX3geoleAHueU4kWDsg+/ObiQRG8WfLvN8TIMjYZj vrIlJEO5HoSSfbcCXESc08f1Y1RvBiEFSeI2YOeeyfMFTcnFnOqVwXgs1CK9qAv8F2z6 Gsd8bXnS+JpkyF7nnE04xy37A6qoBFkGfsAZELCuCpwX+9GJR+Guw7jtup3C++AdUKHv T9MA== X-Google-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:x-system-of-record :x-gm-message-state; bh=jbFLZMp8ZFjGcYS1EdcAU/miFSFmNWWFKf3zIROZ/ws=; b=G3du94AGvoR6rexyw8hCBPyPNE2eBC8YJyvvtZtvPUv6S13OFtlGhDBMq0JbHfl3HM XDhxD2K6dWPy9W8QrgZ8DEGVwcCI456OvP183vWQmw7LDp6oDfVWfaAUM7cJodAkwiPF DXgHBDaLscBSF+FLRlsRRb/lm4Tn9IlIpZG0lRdl5G+qADYY7/7Va3FZgesv9rSJh0ur TnfhbGKcbV6RDjABU1GqDJvFSUFxuiieKNwUIt/8BBdKaHsRwN3+becnfo/ictiCbucx p6sm2Rz5LlkGFKwwSK5/T96B+IoKnqAuqa7PmE84MrhSpQ9lDh/+93sfe1D5u5ggnBca em0g== Received: by 10.182.53.104 with SMTP id a8mr313081obp.80.1348220023562; Fri, 21 Sep 2012 02:33:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.53.104 with SMTP id a8mr313072obp.80.1348220023428; Fri, 21 Sep 2012 02:33:43 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Fri, 21 Sep 2012 02:33:43 -0700 (PDT) In-Reply-To: References: <20120921055057.5FB3B1A23F@ld9781.wdf.sap.corp> Date: Fri, 21 Sep 2012 10:33:43 +0100 Message-ID: From: Ben Laurie To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnZXQfarAE76pRs+8fs7DNYgIfedHnWk0rnXQnbBsay9si9tT7ovwtS5zMDQ3B4ikKTqBa5LT6CLj7uLzQaUjWQUEpiGkJz5AWzq5y0GauF6HREd9NkHw60HZVS891/TZuQL0Vl5wuFIlUQxe0c9P4xpyrDhSA2YC1Q4MbXWB81AdjnON/ncA/ytRPAmfMxc0GDC/xl Cc: Santosh Chokhani , "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:33:44 -0000 On 21 September 2012 09:58, Ben Laurie wrote: > On 21 September 2012 06:50, Martin Rex wrote: >> Santosh Chokhani wrote: >>> Ben Laurie, >>> >>> I am posting this at the suggestion of Stephen Ferrell. There is no ev= idence that he supports or is against my analysis. He just thought this ma= il list is the appropriate place to make my point.. >>> >>> My basic tenet is that the OCSP certinfo extension being discussed in P= KIX does not protect against RA compromise and may also not protect against= CA compromise since the attacker who compromised the CA may be able to cre= ate an OCSP Responder certificate and either also put bogus OCSP pointer in= the minted certificates or use DNS poisoning on the relying parties. >>> >>> Thus, I think the certificate transparency is worth discussing. >> >> Locating the OCSP server through AIA in the EE cert might be the >> problem here. Maybe the OCSP responder ought to be located >> through an extension in the CA cert itself instead? > > That would make CT substantially harder, because then we'd have to > deal with authenticating chains instead of just EE certs - and EE > certs tend to have multiple authentication chains... To be clear, CT does not deal with revocation itself, but there's little point in detecting mis-issuance if mis-issued certificates cannot be revoked! From SChokhani@cygnacom.com Fri Sep 21 04:19:47 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BAE21F8776 for ; Fri, 21 Sep 2012 04:19:47 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1Fnx8gxRtvo for ; Fri, 21 Sep 2012 04:19:46 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9D60121F8773 for ; Fri, 21 Sep 2012 04:19:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,462,1344225600"; d="scan'208";a="6289480" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge1.cygnacom.com with ESMTP; 21 Sep 2012 07:19:33 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Fri, 21 Sep 2012 07:19:32 -0400 From: Santosh Chokhani To: Ben Laurie , "mrex@sap.com" Date: Fri, 21 Sep 2012 07:19:30 -0400 Thread-Topic: [therightkey] Certificate Transparency Working Group? Thread-Index: Ac2X11qRPoAh3Zx9R6KnFrFGD0fcqgAE3ubg Message-ID: References: <20120921055057.5FB3B1A23F@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 11:19:47 -0000 Agree and also in that case the solution is not robust enough from security= standpoint. The adversary needs to do DNS poisoning and then is in busine= ss. -----Original Message----- From: Ben Laurie [mailto:benl@google.com]=20 Sent: Friday, September 21, 2012 4:58 AM To: mrex@sap.com Cc: Santosh Chokhani; therightkey@ietf.org Subject: Re: [therightkey] Certificate Transparency Working Group? On 21 September 2012 06:50, Martin Rex wrote: > Santosh Chokhani wrote: >> Ben Laurie, >> >> I am posting this at the suggestion of Stephen Ferrell. There is no evi= dence that he supports or is against my analysis. He just thought this mai= l list is the appropriate place to make my point.. >> >> My basic tenet is that the OCSP certinfo extension being discussed in PK= IX does not protect against RA compromise and may also not protect against = CA compromise since the attacker who compromised the CA may be able to crea= te an OCSP Responder certificate and either also put bogus OCSP pointer in = the minted certificates or use DNS poisoning on the relying parties. >> >> Thus, I think the certificate transparency is worth discussing. > > Locating the OCSP server through AIA in the EE cert might be the=20 > problem here. Maybe the OCSP responder ought to be located through an=20 > extension in the CA cert itself instead? That would make CT substantially harder, because then we'd have to deal wit= h authenticating chains instead of just EE certs - and EE certs tend to hav= e multiple authentication chains... From mrex@sap.com Mon Sep 24 08:26:04 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB51021F860B for ; Mon, 24 Sep 2012 08:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.193 X-Spam-Level: X-Spam-Status: No, score=-10.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALl7i7MVsXab for ; Mon, 24 Sep 2012 08:26:04 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E686021F84D4 for ; Mon, 24 Sep 2012 08:26:03 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q8OFPx0l009499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Sep 2012 17:25:59 +0200 (MEST) In-Reply-To: To: Santosh Chokhani Date: Mon, 24 Sep 2012 17:25:58 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120924152558.D00861A254@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "therightkey@ietf.org" , "mrex@sap.com" , Ben Laurie Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 15:26:04 -0000 Santosh Chokhani wrote: > > Ben Laurie wrote: >> >> Martin Rex wrote: >>> >>> Locating the OCSP server through AIA in the EE cert might be the >>> problem here. Maybe the OCSP responder ought to be located through an >>> extension in the CA cert itself instead? >> >> That would make CT substantially harder, because then we'd have to deal >> with authenticating chains instead of just EE certs - and EE certs tend >> to have multiple authentication chains... > > Agree and also in that case the solution is not robust enough from > security standpoint. The adversary needs to do DNS poisoning and > then is in business. My comment was not directed at CT itself, but rather at the problem of locating the OCSP server (plus determining authorized OCSP signers), because it is entirely ignorant of mis-issued certificates. The key that signed an EE cert is static and hardwired into the CA certificate, so I see exactly zero problems with hardwiring an (a) OCSP distribution point into the same CA cert and (b) identifying a different CA key within that CA cert extension that is authorized to issue shortlive OCSP signer certs, so that the CA key that issues EE certs is no longer an unavoidable single point of failure. -Martin From benl@google.com Mon Sep 24 08:48:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA45121F87BF for ; Mon, 24 Sep 2012 08:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXv-3TDKsGJ2 for ; Mon, 24 Sep 2012 08:48:25 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB0A21F87BC for ; Mon, 24 Sep 2012 08:48:24 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so6206564obb.31 for ; Mon, 24 Sep 2012 08:48:24 -0700 (PDT) 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:x-system-of-record; bh=xb69zkt6XJ7aPx5VJOoRTgzPl1f0hcpKeI3RbhYCwsI=; b=FKB3KNBJ9CHIrH0uIgiCUTZfbEkTyP0kQSbFqQP05RVYZNC8+sjdsrocxBPoEh9HRf owZxp9GmB4d19Q5cNR4aLy+bogUfi7s+uQcuaC3+Jo33zeuu9grD1+JQ1/s2J/ygUInP 3xSMD8fYTV2zULsMQJND8QzxOpQbE8aGBQxHJN/zSrerEFdil+PqSdey2DUzcJot59Wc mK0cNatvY3ejfw76BiOYKlqQhrzEL7KhVtypbQAhwneL9LsJPvZAyC7RC28BaNUuBygM uSs6zCb2g3iAkV77L4SKlDyZK93PHaNRudRqyTzFFC55DuGwGcrEysagT0KABOPJ1p4p 9WpQ== X-Google-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:x-system-of-record:x-gm-message-state; bh=xb69zkt6XJ7aPx5VJOoRTgzPl1f0hcpKeI3RbhYCwsI=; b=RmMdF3EANwtwN9HC7xpwZaNXmhrP6f9BE8l5BRVZMR/8zVn7he6/Pj9UfysRXZBTkp sGU0OwZ1CtVDTextiwrfsMA9UTWsN8VuVPxTlfaFMy9wUe9WhTpuKniN9RRgCCBjUYYF YY9hrQM2lG292+jTyLfPjSjF8MItTu+qim/MNPWXMDpa/mZUq6RiZk8HAHzGlqhNZd8u rvbL8TSIj3jixxs+VsH0TIolpgztdwUNYE/pIJsJV3b09aOHXjKvXorsx0j/1AbmkRwT /PY+bQ0hyXyI/jdEdFyv7dMu5b+nismdila00fdhmbRLYHgA7FjZCIj6KYSZFp++JBAK u1cA== Received: by 10.60.27.10 with SMTP id p10mr9925786oeg.49.1348501704685; Mon, 24 Sep 2012 08:48:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.27.10 with SMTP id p10mr9925779oeg.49.1348501704602; Mon, 24 Sep 2012 08:48:24 -0700 (PDT) Received: by 10.60.5.72 with HTTP; Mon, 24 Sep 2012 08:48:24 -0700 (PDT) In-Reply-To: <20120924152558.D00861A254@ld9781.wdf.sap.corp> References: <20120924152558.D00861A254@ld9781.wdf.sap.corp> Date: Mon, 24 Sep 2012 16:48:24 +0100 Message-ID: From: Ben Laurie To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkdyuUFVAVCOFfRlazli4pHl3YK9C+l3cSH/0ewyiqoNi/UPYqMQ6ip8rNj0x/swHOGNuSpGePlm4D9oSnDOdoD/BviapKV410DNJbS5X23Uunq69KV0OrEqa167cnBR+4utx6UtHiXNUaETSy7ZswcLPq1p46Ay70v8YG1+hVEpu9qsDQU8KSFb7AWyO6ECDnkjaB/ Cc: Santosh Chokhani , "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 15:48:26 -0000 On 24 September 2012 16:25, Martin Rex wrote: > Santosh Chokhani wrote: >> >> Ben Laurie wrote: >>> >>> Martin Rex wrote: >>>> >>>> Locating the OCSP server through AIA in the EE cert might be the >>>> problem here. Maybe the OCSP responder ought to be located through an >>>> extension in the CA cert itself instead? >>> >>> That would make CT substantially harder, because then we'd have to deal >>> with authenticating chains instead of just EE certs - and EE certs tend >>> to have multiple authentication chains... >> >> Agree and also in that case the solution is not robust enough from >> security standpoint. The adversary needs to do DNS poisoning and >> then is in business. > > My comment was not directed at CT itself, but rather at the problem > of locating the OCSP server (plus determining authorized OCSP signers), > because it is entirely ignorant of mis-issued certificates. > > The key that signed an EE cert is static and hardwired into the > CA certificate, so I see exactly zero problems with hardwiring an > (a) OCSP distribution point into the same CA cert and (b) identifying > a different CA key within that CA cert extension that is authorized > to issue shortlive OCSP signer certs, so that the CA key that issues > EE certs is no longer an unavoidable single point of failure. The problem is that if the OCSP server is not identified in the EE cert, then a misissued cert can be revoked according to one chain and not revoked according to another. This defeats the purpose of CT. There is a question of what to do if the CA issues a cert with the wrong OCSP server in it - the answer, IMO, is you revoke the CA cert, since it clearly cannot be trusted. From rob.stradling@comodo.com Mon Sep 24 09:16:14 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6577421F8699 for ; Mon, 24 Sep 2012 09:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU8m3p2fg4b1 for ; Mon, 24 Sep 2012 09:16:14 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 86F4821F8466 for ; Mon, 24 Sep 2012 09:16:12 -0700 (PDT) Received: (qmail 8090 invoked from network); 24 Sep 2012 16:16:10 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 24 Sep 2012 16:16:10 -0000 Received: (qmail 12538 invoked by uid 1000); 24 Sep 2012 16:16:10 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 24 Sep 2012 17:16:10 +0100 Message-ID: <50608749.1000707@comodo.com> Date: Mon, 24 Sep 2012 12:16:09 -0400 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ben Laurie References: <20120924152558.D00861A254@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Santosh Chokhani , mrex@sap.com, "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 16:16:14 -0000 On 24/09/12 11:48, Ben Laurie wrote: > The problem is that if the OCSP server is not identified in the EE > cert, then a misissued cert can be revoked according to one chain and > not revoked according to another. Disagree. In OCSP, the issuer is identified by Name Hash and Key Hash, not by Certificate. Even a single OCSP Responder could potentially give different responses to different clients, so I don't think having different Responder URLs in different chains would create a problem that isn't already there. > This defeats the purpose of CT. > > There is a question of what to do if the CA issues a cert with the > wrong OCSP server in it - the answer, IMO, is you revoke the CA cert, > since it clearly cannot be trusted. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From mrex@sap.com Mon Sep 24 09:18:01 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEB221F87EC for ; Mon, 24 Sep 2012 09:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.196 X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE3JoZE5wdPJ for ; Mon, 24 Sep 2012 09:18:00 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5C04421F8466 for ; Mon, 24 Sep 2012 09:18:00 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q8OGHvLE016302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Sep 2012 18:17:57 +0200 (MEST) In-Reply-To: To: Ben Laurie Date: Mon, 24 Sep 2012 18:17:56 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120924161756.CF4131A255@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Santosh Chokhani , mrex@sap.com, "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group?< X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 16:18:01 -0000 Ben Laurie wrote: > On 24 September 2012 16:25, Martin Rex wrote: > > Santosh Chokhani wrote: > >> > >> Ben Laurie wrote: > >>> > >>> Martin Rex wrote: > >>>> > >>>> Locating the OCSP server through AIA in the EE cert might be the > >>>> problem here. Maybe the OCSP responder ought to be located through an > >>>> extension in the CA cert itself instead? > >>> > >>> That would make CT substantially harder, because then we'd have to deal > >>> with authenticating chains instead of just EE certs - and EE certs tend > >>> to have multiple authentication chains... > >> > >> Agree and also in that case the solution is not robust enough from > >> security standpoint. The adversary needs to do DNS poisoning and > >> then is in business. > > > > My comment was not directed at CT itself, but rather at the problem > > of locating the OCSP server (plus determining authorized OCSP signers), > > because it is entirely ignorant of mis-issued certificates. > > > > The key that signed an EE cert is static and hardwired into the > > CA certificate, so I see exactly zero problems with hardwiring an > > (a) OCSP distribution point into the same CA cert and (b) identifying > > a different CA key within that CA cert extension that is authorized > > to issue shortlive OCSP signer certs, so that the CA key that issues > > EE certs is no longer an unavoidable single point of failure. > > The problem is that if the OCSP server is not identified in the EE > cert, then a misissued cert can be revoked according to one chain and > not revoked according to another. This defeats the purpose of CT. Huh? It would be silly if CT would depend on that. Different to the CRL distribution point extension, the OCSP AIA information is pretty irrelevant to OCSP, and does not affect the "acceptable" OCSP signers at a.. There are efforts underway to send around stapled OCSP responses where the OCSP AIA information will be completely ignored. So it would be flawed to make anything dependent on the OCSP AIA information in the EE cert. > > There is a question of what to do if the CA issues a cert with the > wrong OCSP server in it - the answer, IMO, is you revoke the CA cert, > since it clearly cannot be trusted. Wrong OCSP AIA information in a cert is at most a functional defect, but by itself not a security problem. However, I believe we're talking past each other. The original concept in X.509 about revocation is that (a) it is assumed that mis-issuance can not possibly happen (b) if it happens anyhow, you'll have to nuke the whole PKI immediately and rekey every entity (a) is dumb and (b) is an unnecessary royal PITA. There are CAs that sign thousands and thousands of certs. The US DoD seems to operate several CAs that have > 1 million certs listed on their CRLs. I assume that the number of their active certs is in the same range. A CA with 1 Million active certs with a lifetime of 3 years each would have to issue ~1000 certs per day (when issuing certs on holidays as well). So that will likely be an online CA. I believe it would be sensible to manage revocation with a key that is distinct from the CA key, so that when an attacker manages to get certs mis-issued with the CA key, determining whether an EE cert&credential is valid can be alternatively performed through that seperate revocation key. It seems easier to secure a CA key for revocation that needs to be used only around once per week and can work on a cert push model exclusively, than to secure a CA key that needs to be used ~1000x/day in online CA scenarios. -Martin From SChokhani@cygnacom.com Mon Sep 24 09:56:06 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E2B21F881B for ; Mon, 24 Sep 2012 09:56:06 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iQz1IfHffjB for ; Mon, 24 Sep 2012 09:56:05 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 663D821F8807 for ; Mon, 24 Sep 2012 09:56:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,476,1344225600"; d="scan'208";a="2020551" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 24 Sep 2012 12:56:04 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Mon, 24 Sep 2012 12:56:04 -0400 From: Santosh Chokhani To: "mrex@sap.com" Date: Mon, 24 Sep 2012 12:56:03 -0400 Thread-Topic: [therightkey] Certificate Transparency Working Group? Thread-Index: Ac2aaOdu+AzqerWCQUmdNIj2EsEQCgADBFcg Message-ID: References: <20120924152558.D00861A254@ld9781.wdf.sap.corp> In-Reply-To: <20120924152558.D00861A254@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" , Ben Laurie Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 16:56:06 -0000 Steve Ferrell, Help please. Does this belong here or in PKIX? Martin, I agree with Ben that this discussion is not related to CT and hence if you= want and Steve agrees, it is best carried out in PKIX. What you say below is not how the OCSP RFC and clients work. For security = and for simplicity, OCSP delegation is done by using the same CA key that s= igned the target certificate in question. Thus, it does not matter where t= he OCSP pointer is. If the CA key or CA is compromised, you should not rel= y on OCSP to indicate mis-issued certificates. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Monday, September 24, 2012 11:26 AM To: Santosh Chokhani Cc: Ben Laurie; mrex@sap.com; therightkey@ietf.org Subject: Re: [therightkey] Certificate Transparency Working Group? Santosh Chokhani wrote: > > Ben Laurie wrote: >> >> Martin Rex wrote: >>> >>> Locating the OCSP server through AIA in the EE cert might be the=20 >>> problem here. Maybe the OCSP responder ought to be located through=20 >>> an extension in the CA cert itself instead? >>=20 >> That would make CT substantially harder, because then we'd have to=20 >> deal with authenticating chains instead of just EE certs - and EE=20 >> certs tend to have multiple authentication chains... > > Agree and also in that case the solution is not robust enough from=20 > security standpoint. The adversary needs to do DNS poisoning and then=20 > is in business. My comment was not directed at CT itself, but rather at the problem of loca= ting the OCSP server (plus determining authorized OCSP signers), because it= is entirely ignorant of mis-issued certificates. The key that signed an EE cert is static and hardwired into the CA certific= ate, so I see exactly zero problems with hardwiring an (a) OCSP distribution point into the same CA cert and (b) identifying a dif= ferent CA key within that CA cert extension that is authorized to issue sho= rtlive OCSP signer certs, so that the CA key that issues EE certs is no lon= ger an unavoidable single point of failure. -Martin From stephen.farrell@cs.tcd.ie Mon Sep 24 17:26:13 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD161F0C9E for ; Mon, 24 Sep 2012 17:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyOUZv9u+ciq for ; Mon, 24 Sep 2012 17:26:12 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id EFF461F041D for ; Mon, 24 Sep 2012 17:26:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 624AD171480; Tue, 25 Sep 2012 01:26:11 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1348532770; bh=P2VNwHVLhV8O5G 4NAXkQ1fHt7BY1f3Rjrw4vSq0gEEA=; b=FMnNbDectg7oHE9Qtrasy0VeXxifqR 0uSSmncgWI1uhfUaVBk4IWeyVlCI/e2f+rO1j5JBIv93eaJsbPXWPjkikjHuN2LZ HbEQlMyqM7drgQhJesVTOQGdHauyDS3Giyrl1Xj+C9XJVnkj5rEf0RbIvmSp+ocX kFhSCBqo0npqkethfWi5kNfevixnQLNtatjS0SpYUNNmA1dX+q0fwUqgzWJIZ1FD rTLDFOZSzyzmXCQbjyNRZJ/C9GV7mOOXiYUZfeDq8FR4np/MZ5YI8dHlQjiktAkh kxh5xxiVV2QKlW/MBYyfC2XfZ7GNYmlS3ZUpQO5CD4KdiGVYBOqkVZYg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id M+bNvM1EtHct; Tue, 25 Sep 2012 01:26:10 +0100 (IST) Received: from [10.87.48.8] (unknown [86.46.22.78]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4CB1117147E; Tue, 25 Sep 2012 01:26:07 +0100 (IST) Message-ID: <5060FA1F.8070005@cs.tcd.ie> Date: Tue, 25 Sep 2012 01:26:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Santosh Chokhani References: <20120924152558.D00861A254@ld9781.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , "mrex@sap.com" , Ben Laurie Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 00:26:13 -0000 On 09/24/2012 05:56 PM, Santosh Chokhani wrote: > Steve Ferrell, Who's he? :-) I'm gonna guess you mean me though. > Help please. Does this belong here or in PKIX? I think this list is probably best devoted to issues related to CT for the moment. This topic seems tangential, but if folks think otherwise that's fine since we're in the process of figuring what is or is not the scope of CT (amongst other BoF questions). There's also a proposed BoF in the OPS area (wpkiops list) about operational aspects of PKI. Discussion about OCSP might be relevant there, if you're talking about what real deployed systems actually do that adheres to, or differs from, what's written in RFCs. As Sean said in Vancouver, he's closing PKIX when current work is done (a decision with which I agree). I don't know if your topic fits one of the existing close-out work items there or not. Cheers, S. > > Martin, > > I agree with Ben that this discussion is not related to CT and hence if you want and Steve agrees, it is best carried out in PKIX. > > What you say below is not how the OCSP RFC and clients work. For security and for simplicity, OCSP delegation is done by using the same CA key that signed the target certificate in question. Thus, it does not matter where the OCSP pointer is. If the CA key or CA is compromised, you should not rely on OCSP to indicate mis-issued certificates. > > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Monday, September 24, 2012 11:26 AM > To: Santosh Chokhani > Cc: Ben Laurie; mrex@sap.com; therightkey@ietf.org > Subject: Re: [therightkey] Certificate Transparency Working Group? > > Santosh Chokhani wrote: >> >> Ben Laurie wrote: >>> >>> Martin Rex wrote: >>>> >>>> Locating the OCSP server through AIA in the EE cert might be the >>>> problem here. Maybe the OCSP responder ought to be located through >>>> an extension in the CA cert itself instead? >>> >>> That would make CT substantially harder, because then we'd have to >>> deal with authenticating chains instead of just EE certs - and EE >>> certs tend to have multiple authentication chains... >> >> Agree and also in that case the solution is not robust enough from >> security standpoint. The adversary needs to do DNS poisoning and then >> is in business. > > My comment was not directed at CT itself, but rather at the problem of locating the OCSP server (plus determining authorized OCSP signers), because it is entirely ignorant of mis-issued certificates. > > The key that signed an EE cert is static and hardwired into the CA certificate, so I see exactly zero problems with hardwiring an > (a) OCSP distribution point into the same CA cert and (b) identifying a different CA key within that CA cert extension that is authorized to issue shortlive OCSP signer certs, so that the CA key that issues EE certs is no longer an unavoidable single point of failure. > > > -Martin > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From benl@google.com Tue Sep 25 03:25:58 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDCD21F8883 for ; Tue, 25 Sep 2012 03:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnP0z3y3rc9t for ; Tue, 25 Sep 2012 03:25:57 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4E7B21F887C for ; Tue, 25 Sep 2012 03:25:57 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so7204111obb.31 for ; Tue, 25 Sep 2012 03:25:57 -0700 (PDT) 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:x-system-of-record; bh=HuTv8lQbYBc4Z0CQXGtMy7IABzOYepzFpVWno4LX8O0=; b=YD6ENvz7qUPd8vGsGVDsPBB3e0pawGlkBa+vcMzXOS2xq3A6cO7xqzpPPGJMQDC47Z naZJzBrbK+TKbwsTRDnQXq3dIAa0mtl+VnABmypW9u+yuIvogGAhCUZ91fJnv6RodiGO jjeHvrkOFYRDCDQe74Ae/qKQLBN/VHZzwDNhdzrJ+A2PqAZiI7n452iQGelSafNtFQDj beATwnLgcd5qYw++GSFuMYcKn4dWpCpaz24tAvz9HWD6gVw+WnFU9Cvb+Mgmrcs8q9IP I/P82nrtZfNlkSTS9uzvDfn+CtPfuSIkgSUEh94TEraMP0dIxnCT+FSR8odA88dO67Wy kBGA== X-Google-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:x-system-of-record:x-gm-message-state; bh=HuTv8lQbYBc4Z0CQXGtMy7IABzOYepzFpVWno4LX8O0=; b=H7nOwAPIbbfHpWPYIsNT0wmtDN1krmx/5A3irXvrl17aqKQxLW7A3D/1oG5jz5qRwi A+uSlTGy4M316pDvDp/cNimhE2ZGc1mJd+OKoEGZp36h7S2SfeBDz2wDuultePxizKjM bk5n7GayVrdLiQTgfZAUcJqLfvdddc/YFQQtXG9EQ/PRqLfjjorK+yNf+Nj15I7huUAf 1uRyk6PqVV/ew2j/pgcsCs93GRFd6hlZ79TEsSe3hT96R42G6A3vbqNtUHTf0ObEzANY 54LdnRIp1TisktqLIqdq64jZ77xfMljY2b894bIH+bUVeLF4ciuBbPvrBXmNWw2fmf9Z Kfgw== Received: by 10.60.7.169 with SMTP id k9mr11834874oea.77.1348568757132; Tue, 25 Sep 2012 03:25:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.7.169 with SMTP id k9mr11834864oea.77.1348568756962; Tue, 25 Sep 2012 03:25:56 -0700 (PDT) Received: by 10.60.39.136 with HTTP; Tue, 25 Sep 2012 03:25:56 -0700 (PDT) In-Reply-To: <50608749.1000707@comodo.com> References: <20120924152558.D00861A254@ld9781.wdf.sap.corp> <50608749.1000707@comodo.com> Date: Tue, 25 Sep 2012 11:25:56 +0100 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlyMSjvCH//Vcs9edMl5xLwqHPlDo+rh+MHVxummYLsNt2HOyYGxIkd+d6xVXQNi69mNjsSA+TjH5C2Fl+fUTziAqHQfNL4I7nwgHnrws/lNvC905ob9Hdpzv+BO0Ye+7GgLVxzAiO+CB1JnrhQRy0Rnxwh8po8NVlZK2Qs5IA7BOZIoSB6N1Xt6UAq2wn8OcFqTH9p Cc: Santosh Chokhani , mrex@sap.com, "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 10:25:58 -0000 On 24 September 2012 17:16, Rob Stradling wrote: > On 24/09/12 11:48, Ben Laurie wrote: > > >> The problem is that if the OCSP server is not identified in the EE >> cert, then a misissued cert can be revoked according to one chain and >> not revoked according to another. > > > Disagree. > > In OCSP, the issuer is identified by Name Hash and Key Hash, not by > Certificate. > > Even a single OCSP Responder could potentially give different responses to > different clients, so I don't think having different Responder URLs in > different chains would create a problem that isn't already there. This is a fair point. I guess from CT's POV so long as the problem is made apparent, and we have an issuer to blame, revocation is somebody else's problem. To cure this problem we need revocation transparency, of course :-) > > >> This defeats the purpose of CT. > >> >> >> There is a question of what to do if the CA issues a cert with the >> wrong OCSP server in it - the answer, IMO, is you revoke the CA cert, >> since it clearly cannot be trusted. > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online From rob.stradling@comodo.com Tue Sep 25 03:30:50 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A9021F8834 for ; Tue, 25 Sep 2012 03:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se9eCtryvZGU for ; Tue, 25 Sep 2012 03:30:50 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 88BB321F8445 for ; Tue, 25 Sep 2012 03:30:49 -0700 (PDT) Received: (qmail 18423 invoked from network); 25 Sep 2012 10:30:46 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 25 Sep 2012 10:30:46 -0000 Received: (qmail 29762 invoked by uid 1000); 25 Sep 2012 10:30:46 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Tue, 25 Sep 2012 11:30:46 +0100 Message-ID: <506187D5.9080709@comodo.com> Date: Tue, 25 Sep 2012 06:30:45 -0400 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ben Laurie References: <20120924152558.D00861A254@ld9781.wdf.sap.corp> <50608749.1000707@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Santosh Chokhani , mrex@sap.com, "therightkey@ietf.org" Subject: Re: [therightkey] Certificate Transparency Working Group? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 10:30:50 -0000 On 25/09/12 06:25, Ben Laurie wrote: >> Even a single OCSP Responder could potentially give different responses to >> different clients, so I don't think having different Responder URLs in >> different chains would create a problem that isn't already there. > > This is a fair point. I guess from CT's POV so long as the problem is > made apparent, and we have an issuer to blame, revocation is somebody > else's problem. Agreed. > To cure this problem we need revocation transparency, of course :-) Yes! -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From stephen.farrell@cs.tcd.ie Wed Sep 26 10:29:16 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE44221F84C5 for ; Wed, 26 Sep 2012 10:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41F7aQzkdzdY for ; Wed, 26 Sep 2012 10:29:15 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C8B5621F84DC for ; Wed, 26 Sep 2012 10:29:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id BDE4B171489 for ; Wed, 26 Sep 2012 18:29:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1348680553; bh=kA1U4te4uFrlX2X0JJeZX96A TMjH24OtiDyxXk96eH0=; b=dMDklLfFz6oKVU1D0HKMMVddHF6gajpxpNEdQATa ByP5eV5qMjLuNKygkp2H/KRlzul6/vz43sqh2fo2BcSt4D+KPPkUBNHJvPNk2fIE YTkZo1NtNUS+sHjCIckkEKYZYTa1HYJ0d52LFDr6VbyEcmH35jHyRgtcf6CSWvkC Hhx4dls2mEeWdORdv10Mtg8rxAXMb5Xf0HkHIeYAvdAvOZ+NgfofpmvnT29+apms LfyebVYLAdlKRU+EB+gbL2K3xPIb8knrGTV/oAqWxS8n6nl8AbFdhkc9+OpmaFcM byodZdmALQGpuwNzY2/NtApEl5PpQ4icgQu9AEcAYfBIZA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Q2pWjJeTTtwk for ; Wed, 26 Sep 2012 18:29:13 +0100 (IST) Received: from [IPv6:2001:770:10:203:1518:fca5:d414:38dc] (unknown [IPv6:2001:770:10:203:1518:fca5:d414:38dc]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 83708171471 for ; Wed, 26 Sep 2012 18:29:10 +0100 (IST) Message-ID: <50633B66.3080101@cs.tcd.ie> Date: Wed, 26 Sep 2012 18:29:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "therightkey@ietf.org" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [therightkey] certrans BoF approved X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 17:29:16 -0000 Hi all, The certrans BoF for IETF-85 was just approved. Scheduling will be later as always. Paul H. will start up agendizing etc soon. Cheers, Stephen. From paul.hoffman@vpnc.org Sat Sep 29 08:09:01 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4659721F8599 for ; Sat, 29 Sep 2012 08:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMV7owdM9vzd for ; Sat, 29 Sep 2012 08:09:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B76E321F8550 for ; Sat, 29 Sep 2012 08:09:00 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8TF8nJY046578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 29 Sep 2012 08:08:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: <50633B66.3080101@cs.tcd.ie> Date: Sat, 29 Sep 2012 08:08:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50633B66.3080101@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1498) Cc: "therightkey@ietf.org" Subject: Re: [therightkey] certrans BoF approved X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 15:09:01 -0000 On Sep 26, 2012, at 10:29 AM, Stephen Farrell = wrote: > The certrans BoF for IETF-85 was just approved. Scheduling will > be later as always. Paul H. will start up agendizing etc soon. Actually, not soon. Given that this is BoF that still has many ideas = swirling about, I think it might be best to create the agenda at the = last possible moment, which would be 2012-10-24. FAIR WARNING: Monday the 15th is the cutoff for -00 drafts and Monday = the 22nd is the cutoff for all drafts. Those dates are weeks away from = now. When I do put together the agenda, I will probably ignore requests = from people who want to talk about something for which there is no = draft. --Paul Hoffman=