From nobody Fri Dec 5 19:54:12 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1BE1A8AA0 for ; Fri, 5 Dec 2014 19:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXmmTBhaSOUl for ; Fri, 5 Dec 2014 19:54:09 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52CEE1A8824 for ; Fri, 5 Dec 2014 19:54:09 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 47236817C1; Fri, 5 Dec 2014 22:54:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1417838047; bh=zHVUSw127S9CvPYv/BBu1r9DobHC4658x/8TRN+ymP0=; h=Date:From:To:cc:Subject; b=mAE+072Zo3q0VmtiK0hXNPTtxXd2378Xpmug7tfZ7qvwazwH9G9CS7Yh5oIQ48kLr QGLxxUcZ0VMt8Are+YwNRfFYmcO9RZIc+CbtombUPOlTfQe5L/bpOft2S+xh3jGOwe d5BTTbmr7uYtRP0byryoiXwSxNbYInWf8/zBEIoE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sB63s6YK012338; Fri, 5 Dec 2014 22:54:06 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 5 Dec 2014 22:54:06 -0500 (EST) From: Paul Wouters To: trans@ietf.org Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/trans/XA66lFkTWa6e2-Rz5I7nQjsJvqY Cc: Melinda Shore Subject: [Trans] IETF-91 draft minutes posted X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2014 03:54:11 -0000 The IETF-91 draft minutes posted are now available at: http://www.ietf.org/proceedings/91/minutes/minutes-91-trans Apologies for the delay, Paul From nobody Thu Dec 11 08:48:35 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC601A70FF for ; Thu, 11 Dec 2014 08:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIQ8o_bKZ81y for ; Thu, 11 Dec 2014 08:48:32 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59281A711A for ; Thu, 11 Dec 2014 08:48:30 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so5349768pdb.10 for ; Thu, 11 Dec 2014 08:48:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=qdAYzhOJQO5jkZOCOFxnnaE62bDvgz4ywMFZ38nYPn8=; b=UrRS/pcxeas3ectefGP9xoykTxtqLOkAMHtA2T00hCqFbNX5sw7nlV2UNvgAWDHhfh PeU9XRT6OYA7DEUgFJkoVyOJtVW7WURc0p1DPw0e3wSb+i5SBG/iSYi+fDQC9AaPQ5dA HtImJgru9kwH+YtCcgqqI1gqPZlB2TAhdUbUVT5ov3x57ckjVTq6ybCZPofFlXvMBh6B FTyZ2wAsIphSVRkNKv5b1fn8R/mlBo+X8fhdbrIytILpIuEVhMaVQXvQQipglvSThLvF t9r20xbsH7yZoOJ/PqA/OXF4K7YeYE+bgMyNm6RJeiwSXihwm2WTpVvjvKMmKFOm3LRl Debw== X-Received: by 10.66.236.36 with SMTP id ur4mr18187198pac.107.1418316509892; Thu, 11 Dec 2014 08:48:29 -0800 (PST) Received: from spandex.local (209-112-184-52-rb2.fai.dsl.dynamic.acsalaska.net. [209.112.184.52]) by mx.google.com with ESMTPSA id se3sm1857136pbc.24.2014.12.11.08.48.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Dec 2014 08:48:29 -0800 (PST) Message-ID: <5489CADB.4090002@gmail.com> Date: Thu, 11 Dec 2014 07:48:27 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Yt-SMBm0qwvRPo6CEUHACyUqYvk Subject: [Trans] SCT encoding X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 16:48:33 -0000 One of the open issues (ticket 34: https://tools.ietf.org/wg/trans/trac/ticket/34) concerns SCT syntax, with Steve Kent arguing that either ASN.1 should be used or that there needs to be a clearer justification for the choice of 5246 representation (see RFC 5246, section 4). We need to come to a decision whether or not to go ahead and carry forward what's in 6962 (the TLS format). This is a call for discussion - we'd really like to close this in the next week or so. Melinda From nobody Thu Dec 11 08:51:01 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25691A7D82 for ; Thu, 11 Dec 2014 08:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5cDgFPZsGYn for ; Thu, 11 Dec 2014 08:50:57 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906BA1A6FEC for ; Thu, 11 Dec 2014 08:50:57 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 68AFD80046; Thu, 11 Dec 2014 11:50:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1418316655; bh=JwWKT1k6qn0wKeWJKlqKdUpAToLvLbIXfIh4XA0mjpY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Vh7Kbctpo0Ad8NMQrnMaSUbZGOiCyAyv4CnUaIoqj/fjDgLpieh9En0UoMUUGwm2G fxGz65UMvIxsW4Vpo7xmvH+NZE2c/nnsHBtlQrKvcaM3x5RPXckmaz3QyfsJT1ie0M BURyEapFBOoAXKkTEtCUHUYtT6CC/IJKVl8CK3gk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sBBGotJP009472; Thu, 11 Dec 2014 11:50:55 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 11 Dec 2014 11:50:55 -0500 (EST) From: Paul Wouters To: Melinda Shore In-Reply-To: <5489CADB.4090002@gmail.com> Message-ID: References: <5489CADB.4090002@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/trans/8hENpm4dp525tKdt4jeldWTPyXc Cc: "trans@ietf.org" Subject: Re: [Trans] SCT encoding X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 16:51:00 -0000 On Thu, 11 Dec 2014, Melinda Shore wrote: > One of the open issues (ticket 34: > https://tools.ietf.org/wg/trans/trac/ticket/34) > concerns SCT syntax, with Steve Kent arguing that either ASN.1 should > be used or that there needs to be a clearer justification for the > choice of 5246 representation (see RFC 5246, section 4). We need to > come to a decision whether or not to go ahead and carry forward what's > in 6962 (the TLS format). This is a call for discussion - we'd really > like to close this in the next week or so. See also Ben's slide deck from IETF-91 (slide 6 & 7) http://www.ietf.org/proceedings/91/slides/slides-91-trans-4.pdf And the raw minutes (look for "slides-91-trans-4.pdf" in the text) http://www.ietf.org/proceedings/91/minutes/minutes-91-trans Ben has argued that SCT's appear only as TLS structures or DER format, and prefers the TLS structure as the DER format is used with OCSP only. Steve has argued against that since two of the three formats are ASN.1. At IETF-91, various people mumbled semi-off mic that ASN.1 would not be their preferred format. So while it seems to be leaning towards using the TLS structure, it would be good to get some additional voices heard from the people who were not at the last meeting and from those who only made comments off-mic to explain themselves a bit better. Paul From nobody Fri Dec 12 04:53:15 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0401A8856 for ; Fri, 12 Dec 2014 04:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8g1AivGAgQE for ; Fri, 12 Dec 2014 04:53:12 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5E51A1B3D for ; Fri, 12 Dec 2014 04:53:11 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id x3so5455126qcv.15 for ; Fri, 12 Dec 2014 04:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v5DVEOqhYrBRBwd9pg9NzgZZqJnXR0wtmeKUT3RLPkM=; b=Dn6CKt27vW3qm6LFYD3cjpDiHxOV/s+U9LIf1wJfGvxGbl9GxfwQGbgpHPnEWzB3BD qAPaU+RGMCUaYt+t5KlhBVpYf5ROcoBmjymWmXwh+BE6a5VfUhU6zXthxYcZRjtBNOR+ hed8zHY7Hc/JFbQXEKkN8u5P6Wo2Xsm4hOs7Scx77RozxhdzKAQEJdw6qsGcIa181Ckt +Ysgw+q3EQ+chzBbvJ9IELq8F411THW4VNxGsp/HlIq+OXgg+T87UXxzIS+hNolTZN9R AOug1STzvyJsWWPuVlOljTpBPFJDwlO7WM6X7j3IMaXRMSGGnogA9u5hbD8swImW04ft 63oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v5DVEOqhYrBRBwd9pg9NzgZZqJnXR0wtmeKUT3RLPkM=; b=JqJvNfvBHSfDPMAMl/0zMBE7Srd94y8Qxcq53D38kZGMUS0hm6Qe5GU+YjgQYRMOCE 4auo7fqZ3wCNwI0QjN0p4NNa/mFmshicSTkmbFRMH0tozyJGH38s0C1J0h43RiL5H5z9 P7ExkHrjEWJRw10NwdmFDSTZK2/HMjjH6l+CnRutDlYC7bf2qzp1jqdVWM+mN1zXTl+U 0hyEyENh+xVjJqxm5zBQakRqRyG8jeBl/F9BhE2xYUEOlra90rcA6w0zTzqFLKBgzxb+ cO57hbO3kdDIKB5GWXlDJKfFM7EhPYrtGjNOp5oT4wmeZEL5eGKStvre/9PbuJxrgIt0 hYDg== X-Gm-Message-State: ALoCoQmWkeGsaBl9Tfsc8sn5odGiAXp+yMZN2f2WYaStX4YF8eL8iC2PgDETaxX2FCtl3I6bswWw MIME-Version: 1.0 X-Received: by 10.224.129.196 with SMTP id p4mr30794280qas.1.1418388791118; Fri, 12 Dec 2014 04:53:11 -0800 (PST) Received: by 10.229.183.201 with HTTP; Fri, 12 Dec 2014 04:53:11 -0800 (PST) In-Reply-To: References: <5489CADB.4090002@gmail.com> Date: Fri, 12 Dec 2014 12:53:11 +0000 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/6LjdJyWz9XPfstaQD1GSpnVnNgI Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] SCT encoding X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 12:53:13 -0000 On 11 December 2014 at 16:50, Paul Wouters wrote: > On Thu, 11 Dec 2014, Melinda Shore wrote: > >> One of the open issues (ticket 34: >> https://tools.ietf.org/wg/trans/trac/ticket/34) >> concerns SCT syntax, with Steve Kent arguing that either ASN.1 should >> be used or that there needs to be a clearer justification for the >> choice of 5246 representation (see RFC 5246, section 4). We need to >> come to a decision whether or not to go ahead and carry forward what's >> in 6962 (the TLS format). This is a call for discussion - we'd really >> like to close this in the next week or so. > > > See also Ben's slide deck from IETF-91 (slide 6 & 7) > > http://www.ietf.org/proceedings/91/slides/slides-91-trans-4.pdf > > And the raw minutes (look for "slides-91-trans-4.pdf" in the text) > > http://www.ietf.org/proceedings/91/minutes/minutes-91-trans > > Ben has argued that SCT's appear only as TLS structures or DER format, > and prefers the TLS structure as the DER format is used with OCSP only. Actually, also used in certs. > Steve has argued against that since two of the three formats are ASN.1. That's not really an argument. My argument is that in ten years' time almost all CT info will be transmitted as TLS extensions. From nobody Fri Dec 12 08:55:31 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E19B1A0027 for ; Fri, 12 Dec 2014 08:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpRIVydv7-Bb for ; Fri, 12 Dec 2014 08:55:18 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877341ACF05 for ; Fri, 12 Dec 2014 08:55:18 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id z12so9688298wgg.29 for ; Fri, 12 Dec 2014 08:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Ih97jSnShvapmp7ooOEhUSsHe3OLc49t82+MFwlU2VI=; b=z5Lp+CJaQNdSG2klVvWJVZePja+O4HCV2/aUpsx7zKzLOT9740X5ayr1lGnasaFoW9 suqCKdoM4btA1vXQWdWSLJBP7PruUD8N1wTPD6QgLtszc/jQx05n02TolD691kefpZwe n/lvEQ3biqJFLpGhTaEIVBfjyfStnF1ZEVTbXYzTVHrQ6BQiDTdoZ15KGfl9x8LPm+m9 OJIaGYgZ8Co5A/EKjopsFRdDE390SPTPYNj/z0suOcB1ODTcy2CC+aG1s6GdasctDjLY wMKgSPrR5j70S8s1A4q/RVP2HxUywSuZdmTRwqUau/W7fhJLMJdXwtiUDwVNFmSnpY/5 AYUA== X-Received: by 10.194.79.199 with SMTP id l7mr29325173wjx.136.1418403317181; Fri, 12 Dec 2014 08:55:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.148.68 with HTTP; Fri, 12 Dec 2014 08:54:56 -0800 (PST) From: Fabrice Gautier Date: Fri, 12 Dec 2014 08:54:56 -0800 Message-ID: To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/wWLgGqCNendJ_w_xSt5lemzAUEQ Subject: [Trans] TLS server with SCTs in stapled OCSP responses ? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 16:55:20 -0000 Hi, Are there any TLS servers out there that implement OCSP stapling and provide SCTs in their stapled OCSP response ? Thanks. -- Fabrice From nobody Fri Dec 12 11:15:25 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF771AC416 for ; Fri, 12 Dec 2014 11:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsoutXjHGNA8 for ; Fri, 12 Dec 2014 11:15:12 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9531A9173 for ; Fri, 12 Dec 2014 11:15:11 -0800 (PST) Received: (qmail 30667 invoked by uid 1004); 12 Dec 2014 19:15:09 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 12 Dec 2014 19:15:09 +0000 Received: (qmail 8851 invoked by uid 1000); 12 Dec 2014 19:15:09 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 12 Dec 2014 19:15:09 +0000 Message-ID: <548B3EBC.2020206@comodo.com> Date: Fri, 12 Dec 2014 19:15:08 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Fabrice Gautier , "trans@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/QfVMn2raQupmsBjjMfbXRyd5HnU Subject: Re: [Trans] TLS server with SCTs in stapled OCSP responses ? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 19:15:18 -0000 On 12/12/14 16:54, Fabrice Gautier wrote: > Hi, > > Are there any TLS servers out there that implement OCSP stapling and > provide SCTs in their stapled OCSP response ? Hi Fabrice. https://sslanalyzer.comodoca.com currently serves an ECC cert with a Stapled OCSP Response that has 2 SCTs (from the Pilot and Aviator logs). (For clients that don't support ECC, it currently serves an RSA cert with 1 embedded SCT). Hope this helps. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Dec 12 12:53:20 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0021A87E4 for ; Fri, 12 Dec 2014 12:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ--pYO8imDL for ; Fri, 12 Dec 2014 12:53:17 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768E31A6FE6 for ; Fri, 12 Dec 2014 12:53:16 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:45689 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XzXD9-0004RU-6Y for trans@ietf.org; Fri, 12 Dec 2014 15:53:15 -0500 Message-ID: <548B55BB.4010501@bbn.com> Date: Fri, 12 Dec 2014 15:53:15 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <5489CADB.4090002@gmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/OmOFJELiazCMk6QMeTrJgGhOSXw Subject: Re: [Trans] SCT encoding X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 20:53:19 -0000 Ben, > On 11 December 2014 at 16:50, Paul Wouters wrote: >> On Thu, 11 Dec 2014, Melinda Shore wrote: >> >>> One of the open issues (ticket 34: >>> https://tools.ietf.org/wg/trans/trac/ticket/34) >>> concerns SCT syntax, with Steve Kent arguing that either ASN.1 should >>> be used or that there needs to be a clearer justification for the >>> choice of 5246 representation (see RFC 5246, section 4). We need to >>> come to a decision whether or not to go ahead and carry forward what's >>> in 6962 (the TLS format). This is a call for discussion - we'd really >>> like to close this in the next week or so. >> See also Ben's slide deck from IETF-91 (slide 6 & 7) >> >> http://www.ietf.org/proceedings/91/slides/slides-91-trans-4.pdf >> >> And the raw minutes (look for "slides-91-trans-4.pdf" in the text) >> >> http://www.ietf.org/proceedings/91/minutes/minutes-91-trans >> >> Ben has argued that SCT's appear only as TLS structures or DER format, >> and prefers the TLS structure as the DER format is used with OCSP only. > Actually, also used in certs. Yes, but when used in certs (and OCSP responses) the SCT will be in an ASN.1 encoded context. >> Steve has argued against that since two of the three formats are ASN.1. > That's not really an argument. My argument is that in ten years' time > almost all CT info will be transmitted as TLS extensions. I think mine is a very valid argument based on the fact that 6962-bis proposed 3 ways to convey the same data and did not explain why we need all three ways. Your argument above says that CAs will (essentially) cease logging pre-certs, after having rewritten their code to do so to meet Google's mandate for EV certs and Chrome acceptance in early 2015. This seems like a questionable projection to me, but maybe there are other details that lead you to this conclusion, but which you have mot shared. Can you elaborate on why you anticipate such a change? (The analysis should be on the list, to facilitate discussion, but it also belongs in the document if the WG elects to retain the 5246 encoding convention.) Steve From nobody Fri Dec 12 21:06:30 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC77E1A1B8F for ; Fri, 12 Dec 2014 21:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1d8OdM8B3PR for ; Fri, 12 Dec 2014 21:06:24 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 426DE1A923C for ; Fri, 12 Dec 2014 21:06:23 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id z12so10720636wgg.15 for ; Fri, 12 Dec 2014 21:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DwEgRewLazPJ/TBme0OZxNZrabbpx/jgj/gy/V0ymeA=; b=nTrIvrdDNq3vtijDxCUcZynlZw885t511J3cRFtAGEvwlN0shzUAdlWacOslbGURHU q9GWKjJ1rMOl4AHinuWzTx8gVpvKZBT4WvTJ9ZsEol2KBbNfGRCXuHlSzyKRnfzNXKY+ /yuf5xLzY4r6fEVHX/Z1GWhpA9kCfDxTNb4skrXfvN3msBKo82Z88hDI6EejCsMCCeav zLrJKzkhLKT+orf3UMdX33sfoydINqThO9mSC4bJ3bpkHQHenNNK3njQeuygCcJ6Ec0n lIWsf1HH0/i8RpSryV6rA6kvC/6ORxwMYQ9Zo03GgEFCne4fDxQj9Pqz9Hv755WNUTY7 eitA== X-Received: by 10.180.75.42 with SMTP id z10mr13444083wiv.70.1418447182057; Fri, 12 Dec 2014 21:06:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.148.68 with HTTP; Fri, 12 Dec 2014 21:06:01 -0800 (PST) In-Reply-To: <548B3EBC.2020206@comodo.com> References: <548B3EBC.2020206@comodo.com> From: Fabrice Gautier Date: Fri, 12 Dec 2014 21:06:01 -0800 Message-ID: To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/1tcpxt2EI3bqiI947IUrovgLl4Q Cc: "trans@ietf.org" Subject: Re: [Trans] TLS server with SCTs in stapled OCSP responses ? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2014 05:06:28 -0000 On Fri, Dec 12, 2014 at 11:15 AM, Rob Stradling wrote: > On 12/12/14 16:54, Fabrice Gautier wrote: >> >> Hi, >> >> Are there any TLS servers out there that implement OCSP stapling and >> provide SCTs in their stapled OCSP response ? > > > Hi Fabrice. > > https://sslanalyzer.comodoca.com currently serves an ECC cert with a Stapled > OCSP Response that has 2 SCTs (from the Pilot and Aviator logs). > (For clients that don't support ECC, it currently serves an RSA cert with 1 > embedded SCT). > > Hope this helps. Yes it will, Thanks -- Fabrice > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online From nobody Wed Dec 17 07:49:08 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2951A1B86 for ; Wed, 17 Dec 2014 07:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb7zR4Pok3ZU for ; Wed, 17 Dec 2014 07:48:55 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4182B1A1B7C for ; Wed, 17 Dec 2014 07:48:52 -0800 (PST) Received: from localhost ([::1]:34348 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y1GqJ-00007G-QK; Wed, 17 Dec 2014 07:48:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com X-Trac-Project: trans Date: Wed, 17 Dec 2014 15:48:51 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/26#comment:1 Message-ID: <071.04cdb1705aa6b80eb4dc394963c8f731@tools.ietf.org> References: <056.eb75bd494f786a9950a7a694bb5dfc0f@tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <056.eb75bd494f786a9950a7a694bb5dfc0f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/trans/BhtO0fy98fyVgqNMYF4BK1fulWs Cc: trans@ietf.org Subject: Re: [Trans] [trans] #26 (rfc6962-bis): Precertificates: Find alternative format to X.509 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:49:04 -0000 #26: Precertificates: Find alternative format to X.509 Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com Comment: Decision (finally!): Precertificates will be CMS signed-data objects instead of X.509 certs. This has been discussed on the TRANS mailing list and at the Hawaii TRANS meeting, and AFAIK nobody has objected to this approach. Proposed text: https://github.com/google/certificate-transparency-rfcs/pull/9 -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Wed Dec 17 07:53:06 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376E31A1A42 for ; Wed, 17 Dec 2014 07:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2Rs9iF0G34d for ; Wed, 17 Dec 2014 07:53:02 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68321A1B87 for ; Wed, 17 Dec 2014 07:53:02 -0800 (PST) Received: from localhost ([::1]:34501 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y1GuL-0005MM-EF; Wed, 17 Dec 2014 07:53:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com X-Trac-Project: trans Date: Wed, 17 Dec 2014 15:53:01 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/44#comment:1 Message-ID: <079.a410fa9f33f70043dd74d281309611f4@tools.ietf.org> References: <064.03e5eb3e0070eb23d0712bf49b009462@tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <064.03e5eb3e0070eb23d0712bf49b009462@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Bu8DrfWaRSU0qTmCEcIrkBBQR6s Cc: trans@ietf.org Subject: Re: [Trans] [trans] #44 (rfc6962-bis): Precertificates SHOULD NOT be submitted to add-chain X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:53:05 -0000 #44: Precertificates SHOULD NOT be submitted to add-chain Changes (by rob.stradling@comodo.com): * status: new => closed * resolution: => invalid Comment: The issue raised by this ticket is no longer a concern, because we're changing the Precertificate format to a CMS signed-data object (see ticket #26). -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: invalid Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Wed Dec 17 08:00:50 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAD31A8AD6 for ; Wed, 17 Dec 2014 08:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsoDyeRNaOSN for ; Wed, 17 Dec 2014 08:00:45 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736E71A8ADF for ; Wed, 17 Dec 2014 08:00:44 -0800 (PST) Received: from localhost ([::1]:34769 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y1H1l-0006iR-7V; Wed, 17 Dec 2014 08:00:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: rob.stradling@comodo.com, benl@google.com, eranm@google.com, rick_andrews@symantec.com X-Trac-Project: trans Date: Wed, 17 Dec 2014 16:00:41 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/10#comment:16 Message-ID: <079.90ba09d84d3bf025b3f27842b7d7dede@tools.ietf.org> References: <064.6e282ba47646121b864c2ac90e52d1dd@tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <064.6e282ba47646121b864c2ac90e52d1dd@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, eranm@google.com, rick_andrews@symantec.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/trans/yFxswD-CR8P483zxv5Khp4SLeaA Cc: trans@ietf.org Subject: Re: [Trans] [trans] #10 (rfc6962-bis): Permit Precertificate SCTs to be delivered via OCSP Stapling and the TLS Extension X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 16:00:47 -0000 #10: Permit Precertificate SCTs to be delivered via OCSP Stapling and the TLS Extension Comment (by rob.stradling@comodo.com): Replying to [comment:14 rob.stradling@…]: > (If name redaction is never allowed, then this ticket is pointless and should be marked WONTFIX). There seems to be consensus that 6962-bis should specify a name redaction mechanism, so this ticket is not pointless. :-) Ticket #34 is currently being discussed on the TRANS mailing list. Once that is resolved, we can make progress on this ticket. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Wed Dec 17 08:35:55 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B3C1A8AF5 for ; Wed, 17 Dec 2014 08:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVmuFF0q36Y6 for ; Wed, 17 Dec 2014 08:35:50 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D251A8B84 for ; Wed, 17 Dec 2014 08:35:49 -0800 (PST) Received: from localhost ([::1]:36701 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Y1HZj-0000Nt-8S; Wed, 17 Dec 2014 08:35:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "trans issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com X-Trac-Project: trans Date: Wed, 17 Dec 2014 16:35:47 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/54 Message-ID: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> X-Trac-Ticket-ID: 54 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, trans@ietf.org X-SA-Exim-Mail-From: trac+trans@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: agl@google.com, benl@google.com, ekasper@google.com, rob.stradling@comodo.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/h3UQndsPVMMTf6KqlJ4UZP3jIfw Cc: trans@ietf.org Subject: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 16:35:52 -0000 #54: Simplify name redaction The name redaction mechanism, as currently defined, does not reveal how many labels have been redacted. This seems unnecessary. If we're happy to reveal the number of redacted labels, then we could simplify the name redaction mechanism by... - scrapping the "redactedLabels" Certificate extension (1.3.6.1.4.1.11129.2.4.6). - stating that the literal string "(PRIVATE)" always covers precisely _one_ label. So for example, if you wanted to redact 3 components, you'd put "SAN:dNSName=(PRIVATE).(PRIVATE).(PRIVATE).mydomain.com" in the Precertificate. To reduce bloat, I think we should also change "(PRIVATE)" to "?". e.g. "SAN:dNSName=?.?.?.mydomain.com" This simplification would make ticket #17 easier to resolve. i.e. We could permit "CN=?.?.?.mydomain.com". When I proposed this on the TRANS list back in September, Eran commented: "+1 to that - seems like it would significantly simplify the implementation of redacted domain name label: The risk of misalignment between the values in the extension that counts the number of redacted subdomains for each SAN and the actual SANs goes away." -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Wed Dec 17 10:17:05 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3621A1BC6 for ; Wed, 17 Dec 2014 10:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkKi9jvMm0Kk for ; Wed, 17 Dec 2014 10:16:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2421A1B8B for ; Wed, 17 Dec 2014 10:16:59 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:46680 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Y1J9e-000Mc0-0e for trans@ietf.org; Wed, 17 Dec 2014 13:16:58 -0500 Message-ID: <5491C894.2070005@bbn.com> Date: Wed, 17 Dec 2014 13:16:52 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> In-Reply-To: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/cSqtIW8SDQGdGqtxD00kPfgxhGQ Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 18:17:01 -0000 Rob, > #54: Simplify name redaction > > The name redaction mechanism, as currently defined, does not reveal how > many labels have been redacted. This seems unnecessary. If we're happy > to reveal the number of redacted labels, then we could simplify the name > redaction mechanism by... > - scrapping the "redactedLabels" Certificate extension > (1.3.6.1.4.1.11129.2.4.6). I think that indicating how many names have been redacted is a good simplification. > - stating that the literal string "(PRIVATE)" always covers precisely > _one_ label. Since DNS names are case insensitive, I suggest we not represent a reserved label in uppercase. It may cause some readers to believe that the label is special because of its case. > So for example, if you wanted to redact 3 components, you'd put > "SAN:dNSName=(PRIVATE).(PRIVATE).(PRIVATE).mydomain.com" in the > Precertificate. > > To reduce bloat, I think we should also change "(PRIVATE)" to "?". > e.g. "SAN:dNSName=?.?.?.mydomain.com" Is "?" a legal DNS label character? It doesn't seem so as per RFC 1034, and RFC 5280 cites 1034 as the normative spec for dNSName syntax in the subjectAltName extension. Steve From nobody Tue Dec 23 06:04:27 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC911ACE52 for ; Tue, 23 Dec 2014 06:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoDeLg9IUmOk for ; Tue, 23 Dec 2014 06:04:22 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD3251ACE6D for ; Tue, 23 Dec 2014 06:02:42 -0800 (PST) Received: (qmail 13026 invoked by uid 1004); 23 Dec 2014 14:02:40 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Tue, 23 Dec 2014 14:02:40 +0000 Received: (qmail 25950 invoked by uid 1000); 23 Dec 2014 14:02:40 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 23 Dec 2014 14:02:40 +0000 Message-ID: <54997600.4060506@comodo.com> Date: Tue, 23 Dec 2014 14:02:40 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <064.02456fc951e2ba2c1a340f8cba4b870a@tools.ietf.org> <5491C894.2070005@bbn.com> In-Reply-To: <5491C894.2070005@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/__nEcLCG0AWmnYLNXMZskzU57Vw Subject: Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 14:04:25 -0000 On 17/12/14 18:16, Stephen Kent wrote: > Rob, > >> #54: Simplify name redaction >> >> The name redaction mechanism, as currently defined, does not reveal how >> many labels have been redacted. This seems unnecessary. If we're >> happy >> to reveal the number of redacted labels, then we could simplify the >> name >> redaction mechanism by... >> - scrapping the "redactedLabels" Certificate extension >> (1.3.6.1.4.1.11129.2.4.6). > > I think that indicating how many names have been redacted is a good > simplification. Thanks Stephen. >> - stating that the literal string "(PRIVATE)" always covers precisely >> _one_ label. > Since DNS names are case insensitive, I suggest we not represent a reserved > label in uppercase. It may cause some readers to believe that the label is > special because of its case. The private label _is_ "special" though. :-) It's intended to be a placeholder for a real label. >> So for example, if you wanted to redact 3 components, you'd put >> "SAN:dNSName=(PRIVATE).(PRIVATE).(PRIVATE).mydomain.com" in the >> Precertificate. >> >> To reduce bloat, I think we should also change "(PRIVATE)" to "?". >> e.g. "SAN:dNSName=?.?.?.mydomain.com" > > Is "?" a legal DNS label character? It doesn't seem so as per RFC 1034, > and RFC 5280 cites 1034 as the normative spec for dNSName syntax in > the subjectAltName extension. I agree that "?" is not a valid DNS label character according to RFC 1034, but that's actually a useful characteristic here. If it was a valid DNS label character, then it could be mistakenly interpreted as a real label rather than as just a placeholder! "*" isn't a valid DNS label character either, and yet it is commonly used in SAN->dNSName fields as a placeholder. You're referring to this part of RFC5280 Section 4.2.1.6: "When the subjectAltName extension contains a domain name system label, the domain name MUST be stored in the dNSName (an IA5String). The name MUST be in the "preferred name syntax", as specified by Section 3.5 of [RFC1034] and as modified by Section 2.1 of [RFC1123]." If one or more labels is a placeholder rather than a real label, then IMHO the string is _not_ a "domain name system label". And therefore, the two MUST requirements quoted above don't apply. Also, AFAICT RFC5280 doesn't prohibit putting strings that are _not_ "domain name system labels" into SAN->dNSName fields. Towards the end of Section 4.2.1.6 it says: "Finally, the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification. Applications with specific requirements MAY use such names, but they must define the semantics." So, as long as we "define the semantics" for our use of "?", I don't think we're doing anything wrong. Do you agree? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Dec 24 07:46:39 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB35A1A8A80 for ; Wed, 24 Dec 2014 07:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FQEBHzxcmwl for ; Wed, 24 Dec 2014 07:46:36 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF531A8A7F for ; Wed, 24 Dec 2014 07:46:36 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id m20so6004935qcx.31 for ; Wed, 24 Dec 2014 07:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0w19oangBBbBNvwLqPB0ByTEJ5sWpjAKkFLNmhllpvE=; b=N4XJ6hA9i0335LfzPNhl1Ry3Y3feiFTS3nTs97eqKHjl+GyvAXTVwkCsCnFdnLWREh s0mCHNrl5pdm57hlv0RWPYvxircX3Znx/eEa3bJMqEOV5lsAWuVJ5wtr+r9Lh37nYP+i CZ7rc8p9G7TUVxZ1P0nTkbDLywJJkYNOG9ldS3KZ4ybJFDNQME6/XGO8Cz+qv0kcF7mf Y4JVmHlMmEOC/C/md3KhygSJUyilrpkYOrfFCBMC0S34V7lzAcRDKR4sGKpWq5qS3Lmh 33nCnCpgFLDydShU9fOZXUySCRagTTw/OMv8pa4yCVtHA7QAFOV0J+9vmcBDteC3BZ5R BS6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0w19oangBBbBNvwLqPB0ByTEJ5sWpjAKkFLNmhllpvE=; b=CzXsDqiPuGAgaszLO2SjL2Zs9xhOnH8Pz21opAiMvq+ohgVbggwOC9F4T7FMnEaogu guRHjBNz19wa6EZHmG9l+v/zcH3tpYzI+BnSs3TA0bnylXlEA0wGiFDK8bShDSlUyyna JirkdKv8Srd1sU9qmyZcLxwHLwHvmpPW4bG3BxKZ/8lb7FLFGjNXWglJiKvi3M5JNl3P jaB3LteQIN2pfbNTq73eB1tdybWxBpezQHBglYBwPvLCh19Ic8qfmkMTv2uUbJK88oze SWKodolaS4UcvHMD3ib0PaJkVnOzdXn9FcgLd7un2zSjW8cAVjhUpVMYbPnECMuH/TkF C75w== X-Gm-Message-State: ALoCoQkXP0EUrVjyuu1stHMv+3jxFwJxh7KINF2ssRfiwU+weSXuwKgt0QotnvkWmjrMACTTCfYo MIME-Version: 1.0 X-Received: by 10.229.135.202 with SMTP id o10mr55643679qct.9.1419435995578; Wed, 24 Dec 2014 07:46:35 -0800 (PST) Received: by 10.229.183.201 with HTTP; Wed, 24 Dec 2014 07:46:35 -0800 (PST) In-Reply-To: <548B55BB.4010501@bbn.com> References: <5489CADB.4090002@gmail.com> <548B55BB.4010501@bbn.com> Date: Wed, 24 Dec 2014 15:46:35 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/b9Wme6zp2nezIbngCgwKpTibniU Cc: "trans@ietf.org" Subject: Re: [Trans] SCT encoding X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2014 15:46:38 -0000 On 12 December 2014 at 20:53, Stephen Kent wrote: > Ben, > >> On 11 December 2014 at 16:50, Paul Wouters wrote: >>> >>> On Thu, 11 Dec 2014, Melinda Shore wrote: >>> >>>> One of the open issues (ticket 34: >>>> https://tools.ietf.org/wg/trans/trac/ticket/34) >>>> concerns SCT syntax, with Steve Kent arguing that either ASN.1 should >>>> be used or that there needs to be a clearer justification for the >>>> choice of 5246 representation (see RFC 5246, section 4). We need to >>>> come to a decision whether or not to go ahead and carry forward what's >>>> in 6962 (the TLS format). This is a call for discussion - we'd really >>>> like to close this in the next week or so. >>> >>> See also Ben's slide deck from IETF-91 (slide 6 & 7) >>> >>> http://www.ietf.org/proceedings/91/slides/slides-91-trans-4.pdf >>> >>> And the raw minutes (look for "slides-91-trans-4.pdf" in the text) >>> >>> http://www.ietf.org/proceedings/91/minutes/minutes-91-trans >>> >>> Ben has argued that SCT's appear only as TLS structures or DER format, >>> and prefers the TLS structure as the DER format is used with OCSP only. >> >> Actually, also used in certs. > > Yes, but when used in certs (and OCSP responses) the SCT will be in > an ASN.1 encoded context. >>> >>> Steve has argued against that since two of the three formats are ASN.1. >> >> That's not really an argument. My argument is that in ten years' time >> almost all CT info will be transmitted as TLS extensions. > > I think mine is a very valid argument based on the fact that 6962-bis > proposed 3 ways to convey the same data and did not explain why we need > all three ways. Your argument above says that CAs will (essentially) cease > logging pre-certs, after having rewritten their code to do so to meet > Google's mandate for EV certs and Chrome acceptance in early 2015. This > seems > like a questionable projection to me, but maybe there are other details that > lead you to this conclusion, but which you have mot shared. Can you > elaborate > on why you anticipate such a change? (The analysis should be on the list, to > facilitate discussion, but it also belongs in the document if the WG elects > to retain the 5246 encoding convention.) Because of the risk of logs becoming untrusted, SCTs in certificates may become invalid before the certificate expires, effectively terminating the cert early. You can mitigate this to some extent by including many SCTs, but its clearly better/safer to use SCTs that are retrieved "live" so that you can always be sure they're valid. This requires either OCSP stapling or the TLS extension. Using the TLS extension puts updating the SCTs in the control of the site operator, which seems like the best way forward.