From nobody Tue May 12 03:35:15 2015 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 C750E1A3BA7 for ; Tue, 12 May 2015 03:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.049 X-Spam-Level: * X-Spam-Status: No, score=1.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMjMfXERWh6e for ; Tue, 12 May 2015 03:35:11 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (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 27A5B1A8729 for ; Tue, 12 May 2015 03:35:10 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4CAZ9oQ026176 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 12 May 2015 12:35:09 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id t4CAZ5ZL021019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 May 2015 10:35:08 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1431426908; bh=x443VLACjb+3ORmF6KNup+XtixbihAinFvJPPu1SpyA=; h=From:To:Subject:Date; b=U3oocK6kUSfvqVodPLD5T9QAuBaUb7SLGN77LOYnq/UXI/l1ibEgrPrOJdEBEhs5o GBePyoRZGpJgVisI15kqAzylqlFmH+vzdWzWe+nJCA2jeKpfULuxuivIgySabE5bBW SHGYlSySGP99RRcPLyn9tMGdxcRqw398jkMnAKzE= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) for trans@ietf.org; Tue, 12 May 2015 12:37:21 +0200 From: Linus Nordberg To: trans@ietf.org Organization: NORDUnet A/S Date: Tue, 12 May 2015 12:35:03 +0200 Message-ID: <87sib2qe20.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aOqWz95N - 73b0677eadf3 - 20150512 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.110.42 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.110.42; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Subject: [Trans] Empty extra_data 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, 12 May 2015 10:35:14 -0000 Hi, I'd like to doublecheck that our reading of RFC6962 is correct regarding how to store a submitted root cert. --8<---------------cut here---------------start------------->8--- 3.1. Log Entries ... "leaf_certificate" is the end-entity certificate submitted for auditing. "certificate_chain" is a chain of additional certificates required to verify the end-entity certificate. The first certificate MUST certify the end-entity certificate. Each following certificate MUST directly certify the one preceding it. The final certificate MUST be a root certificate accepted by the log. --8<---------------cut here---------------end--------------->8--- In the case of a root certificate, our implementation treats the (only) certificate as the leaf_certificate and sees certificate_chain as empty. v1/get-entries accordingly returns the cert in leaf_input and nothing in extra_data. Do you think that this is conformant with the specification? From nobody Tue May 12 03:40:39 2015 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 060CD1A701E for ; Tue, 12 May 2015 03:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 5OCcs8wSuaYr for ; Tue, 12 May 2015 03:40:35 -0700 (PDT) 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 2BD0B1A3BA7 for ; Tue, 12 May 2015 03:40:35 -0700 (PDT) Received: (qmail 8535 invoked by uid 1004); 12 May 2015 10:40:33 -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, 12 May 2015 11:40:33 +0100 Received: (qmail 21022 invoked by uid 1000); 12 May 2015 10:40:33 -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, 12 May 2015 11:40:33 +0100 Message-ID: <5551D8A1.4020506@comodo.com> Date: Tue, 12 May 2015 11:40:33 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Linus Nordberg , trans@ietf.org References: <87sib2qe20.fsf@nordberg.se> In-Reply-To: <87sib2qe20.fsf@nordberg.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by Qremote 0.29 at mmextmx1.mcr.colo.comodoca.net Archived-At: Subject: Re: [Trans] Empty extra_data 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, 12 May 2015 10:40:39 -0000 Hi Linus. There's at least one root cert that has an entry in Google's=20 Pilot log... $ wget -q -O/dev/stdout=20 "https://ct.googleapis.com/pilot/ct/v1/get-entries?start=3D2284426&end=3D= 2284426"=20 =20 {"entries":[{"leaf_input":"AAAAAAE/rhvJDwAAAALrMIIC5zCCAlACAQEwDQYJKoZIhv= cNAQEFBQAwgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBUGA1U= EChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5IFZh= bGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvbS8xI= DAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMB4XDTk5MDYyNjAwMTk1NFoXDTE5MD= YyNjAwMTk1NFowgbsxJDAiBgNVBAcTG1ZhbGlDZXJ0IFZhbGlkYXRpb24gTmV0d29yazEXMBU= GA1UEChMOVmFsaUNlcnQsIEluYy4xNTAzBgNVBAsTLFZhbGlDZXJ0IENsYXNzIDIgUG9saWN5= IFZhbGlkYXRpb24gQXV0aG9yaXR5MSEwHwYDVQQDExhodHRwOi8vd3d3LnZhbGljZXJ0LmNvb= S8xIDAeBgkqhkiG9w0BCQEWEWluZm9AdmFsaWNlcnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4= GNADCBiQKBgQDOOnHK5avIWZJV16vYdA757tn2VUdZZUcOBVXc65g2PFxTXdMwzzjsvUGJ7SV= CCSRrCl6zfN1SLUzm1NZ9WlmpZdRJEy0kTRxQb7XBhVQ7/nHk01xC+YDgkRoKWzk2Z/M/VXwb= P7RfZHM047QSv4dk+NoS/zcnwbNDu+97bi5p9wIDAQABMA0GCSqGSIb3DQEBBQUAA4GBADt/U= G9vUJSZSWI4OB9L+KXIPqeCgfYrx+jFzug6EILLGACOTb2oWH+heQC1u+mNr0HZDzTuIYEZoD= JJKPTEjlbVUjP9UNV+mWwD5MlM/Mtsq2azSiGM5bUMMj4Qssxs odyamEwCW/POuZ6lcg5Ktz885hZo+L7tdEy8W9ViH0PdAAA=3D","extra_data":"AAAA"}]= } $ echo AAAA | base64 -d | xxd 0000000: 0000 00 ... On 12/05/15 11:35, Linus Nordberg wrote: > Hi, > > I'd like to doublecheck that our reading of RFC6962 is correct regardin= g > how to store a submitted root cert. > > --8<---------------cut here---------------start------------->8--- > 3.1. Log Entries > ... > "leaf_certificate" is the end-entity certificate submitted for > auditing. > > "certificate_chain" is a chain of additional certificates required t= o > verify the end-entity certificate. The first certificate MUST > certify the end-entity certificate. Each following certificate MUS= T > directly certify the one preceding it. The final certificate MUST b= e > a root certificate accepted by the log. > --8<---------------cut here---------------end--------------->8--- > > In the case of a root certificate, our implementation treats the (only) > certificate as the leaf_certificate and sees certificate_chain as > empty. > > v1/get-entries accordingly returns the cert in leaf_input and nothing i= n > extra_data. > > Do you think that this is conformant with the specification? > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --=20 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=20 intended solely for the use of the individual or entity to whom they are=20 addressed. If you have received this email in error please notify the=20 sender by replying to the e-mail containing this attachment. Replies to=20 this email may be monitored by COMODO for operational or business=20 reasons. Whilst every endeavour is taken to ensure that e-mails are free=20 from viruses, no liability can be accepted and the recipient is=20 requested to use their own virus checking software. From nobody Tue May 12 04:45:27 2015 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 1CE351A8A83 for ; Tue, 12 May 2015 04:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3r_5-T0Q_Bs2 for ; Tue, 12 May 2015 04:45:23 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (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 641961A8A4A for ; Tue, 12 May 2015 04:45:15 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4CBj3AM020864 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 May 2015 13:45:03 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id t4CBj0wu002228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 May 2015 11:45:03 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1431431103; bh=9MuhTkSgTEe2DN796PY7LpsjCNSM+lxBrzsGv2meC6w=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Ov6eXqfaYPqkIY/G7DZmtuaZ0AuXzsABkzuhAFPmluzHzFnCP4pC7o8pmg3qatFgY rxu+iJuRXGQYWFxRXQkzgKwvrsC9Fgws+1KBQqOwp2UDKld9KiUZNp6giwpQbvjoAc OGAXE6L0DTkDXffzKsTafi7CanMbgyNRrnF871YQ= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 12 May 2015 13:47:15 +0200 From: Linus Nordberg To: Rob Stradling Organization: NORDUnet A/S References: <87sib2qe20.fsf@nordberg.se> <5551D8A1.4020506@comodo.com> Date: Tue, 12 May 2015 13:44:56 +0200 In-Reply-To: <5551D8A1.4020506@comodo.com> (Rob Stradling's message of "Tue, 12 May 2015 11:40:33 +0100") Message-ID: <87a8xaqatj.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aOqXJ3Gd - b2adbe46c929 - 20150512 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.110.42 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.110.42; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] Empty extra_data 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, 12 May 2015 11:45:25 -0000 Rob Stradling wrote Tue, 12 May 2015 11:40:33 +0100: | Hi Linus. There's at least one root cert that has an entry in | Google's Pilot log... Hi Rob, This is how we present a root cert too. Thanks. Now we know how the authors meant it to be. :) The wording is not crystal clear but as the meaning is pretty intuitive I'll not insist on a clarification. From nobody Tue May 12 05:27:27 2015 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 D047E1ACD09 for ; Tue, 12 May 2015 05:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 exdeYLADg7ed for ; Tue, 12 May 2015 05:27:23 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0B51ACCF4 for ; Tue, 12 May 2015 05:27:21 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lmJKw68m0z3d7; Tue, 12 May 2015 14:27:16 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=HjHFCIjj X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id sS57HQFMtZf1; Tue, 12 May 2015 14:27:14 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 12 May 2015 14:27:14 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AB3948002E; Tue, 12 May 2015 08:27:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1431433632; bh=+wUKA/i5TCm/hnUsQdmpRwiv2lzt88rpHvsrvtJyw/w=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=HjHFCIjj2jSUbWqhYYivjy9Dl0NhsK47jjMf9ctqN0oXRrZlQCKcaksHMwwVj8vMx ikLYwgB+cs+Ehh5QXeGr9XAWb58aPP2L78MJ7syARZDcwiM1aETYjJDLy4lPfbXDvB adPFHGrExcdVwbwvq1XwB+a0TPDsRrWqhVHasJEo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t4CCRBYF008922; Tue, 12 May 2015 08:27:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 12 May 2015 08:27:11 -0400 (EDT) From: Paul Wouters To: Linus Nordberg In-Reply-To: <87a8xaqatj.fsf@nordberg.se> Message-ID: References: <87sib2qe20.fsf@nordberg.se> <5551D8A1.4020506@comodo.com> <87a8xaqatj.fsf@nordberg.se> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: Rob Stradling , trans@ietf.org Subject: Re: [Trans] Empty extra_data 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, 12 May 2015 12:27:26 -0000 On Tue, 12 May 2015, Linus Nordberg wrote: > This is how we present a root cert too. Thanks. > > Now we know how the authors meant it to be. :) > > The wording is not crystal clear but as the meaning is pretty intuitive > I'll not insist on a clarification. As an implementer, can you offer improved text? We are in the process of writing a bis document after all - now is a good time. Paul From nobody Wed May 13 21:43:28 2015 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 B44061B3342 for ; Wed, 13 May 2015 21:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F4JRK6BGm-a for ; Wed, 13 May 2015 21:43:25 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (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 0E6A81B333E for ; Wed, 13 May 2015 21:43:24 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4E4h1tc018714 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 May 2015 06:43:01 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id t4E4gtSY009350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2015 04:42:58 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1431578581; bh=pDavnmTi3p/CLRs3QElNtEbo95HmCiiVH7q4iuMCXm0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=ma3VLkDHkuMyuoGhjFpQYmP/2hECDLGcs+Fjohyi4dCAGwOcW6RRqdVZSfiJ+rQAp pTWRlh/xc4cH97Ucmdn1mccvHJgz3b22GM2f05UrpH51+x6jVw7W53khlroG4yjvRY 2U9igNbxE3cKI29KZO58uz8O7qc4/NeIM1kk7tiY= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 14 May 2015 06:45:10 +0200 From: Linus Nordberg To: Paul Wouters Organization: NORDUnet A/S References: <87sib2qe20.fsf@nordberg.se> <5551D8A1.4020506@comodo.com> <87a8xaqatj.fsf@nordberg.se> Date: Thu, 14 May 2015 06:42:54 +0200 In-Reply-To: (Paul Wouters's message of "Tue, 12 May 2015 08:27:11 -0400 (EDT)") Message-ID: <87bnhnepm9.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aOrEH1pB - ee9797b08a9a - 20150514 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.110.42 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.110.42; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Cc: Rob Stradling , trans@ietf.org Subject: Re: [Trans] Empty extra_data 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, 14 May 2015 04:43:27 -0000 Paul Wouters wrote Tue, 12 May 2015 08:27:11 -0400 (EDT): | As an implementer, can you offer improved text? We are in the process of | writing a bis document after all - now is a good time. Current 6962bis: --8<---------------cut here---------------start------------->8--- "leaf_certificate" is the end-entity certificate submitted for auditing. "certificate_chain" is a chain of additional certificates required to verify the end-entity certificate. The first certificate MUST certify the end-entity certificate. Each following certificate MUST directly certify the one preceding it. The final certificate MUST either be, or be issued by, a root certificate accepted by the log. --8<---------------cut here---------------end--------------->8--- Proposed 6962bis: --8<---------------cut here---------------start------------->8--- "leaf_certificate" is the end-entity certificate submitted for auditing. "certificate_chain" is a chain of additional certificates required to verify the end-entity certificate. A root certificate has an empty certificate_chain. If present, the first certificate MUST certify the end-entity certificate. Each following certificate MUST directly certify the one preceding it. The final certificate MUST either be, or be issued by, a root certificate accepted by the log. --8<---------------cut here---------------end--------------->8--- From nobody Thu May 14 02:25:18 2015 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 1F8811B3562 for ; Thu, 14 May 2015 02:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 WoYjI6bWozIx for ; Thu, 14 May 2015 02:25:11 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 7D9471B355E for ; Thu, 14 May 2015 02:25:11 -0700 (PDT) Received: by oiko83 with SMTP id o83so51265104oik.1 for ; Thu, 14 May 2015 02:25:11 -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; bh=OChHw3TOMDbf4HMyX66J1JX6dksDBTZdmoKPZ80WkFU=; b=ByRD6EnFDpzQGNl0CIS75Lyb12IUF5J7TrlhUEKLpqmVm+M6YjTZKF19q1WcjtXCx+ G8EBgKoII6Srmy+5fXVsv2VQKdvykFHa1nn0PjrQ0wfcXY/zRuoi7ayxXhGpQCLwHkF9 /6VJrNdIdkQfjoLtSRjgkKwiae/6ijMLcM0VXxJak508GjI1g/3/tJ7I1d4g0nHD9/Lr rOLlIbJZTBGmu47SAfkF6HB5RIv9Nz6XGrWwT45vZItYNBNIwo+m21ggh7Exkexj3Mix fWyTNxmBK33JfjTby9OGpkiv82v/dceV81e82RJkdRCC3ZHM685rd4vyjbf+9Wo/o/sl nRfg== 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=OChHw3TOMDbf4HMyX66J1JX6dksDBTZdmoKPZ80WkFU=; b=gkkt59+MbpvJ5gOGcXxMqfffNFAbRf6YUchAm0EW17FgA/S+IWXr2/61PR1jtTNXyh XJTyRlUEwUIegmknz5x0gE8SKXIEygmro8yoaOM2dvwtSiOCyOu42llLxWI93SXqW015 DuDO1D+LDMhsTYVyAYVp2E3x7tfYkX6c9vbnSjupbOguhooiEUsEk9vt6yrqLvHuzYpH +uG11Qbt2UFznu22wcVtmJvT2mNi0OjyE9J0klJS0QOJ+kBXzhCvhte5Ckwn4IQnc59x EnzxJBh2nSdVkp7osYn6ai2/qowj24qzimcXI9RD02xeoots12Vh5TqWCItvU8yxPVAT /+MQ== X-Gm-Message-State: ALoCoQkmeOxfh11BZZjcU+4ECcueg6puzR7ahr6uAivLCPdVH7QeUia5+YTIhNGbsqzoVCud24Rh MIME-Version: 1.0 X-Received: by 10.60.54.3 with SMTP id f3mr2746947oep.6.1431595510913; Thu, 14 May 2015 02:25:10 -0700 (PDT) Received: by 10.182.197.102 with HTTP; Thu, 14 May 2015 02:25:10 -0700 (PDT) In-Reply-To: <87bnhnepm9.fsf@nordberg.se> References: <87sib2qe20.fsf@nordberg.se> <5551D8A1.4020506@comodo.com> <87a8xaqatj.fsf@nordberg.se> <87bnhnepm9.fsf@nordberg.se> Date: Thu, 14 May 2015 10:25:10 +0100 Message-ID: From: Eran Messeri To: Linus Nordberg Content-Type: multipart/alternative; boundary=089e01176191e405f00516074dbe Archived-At: Cc: Paul Wouters , "trans@ietf.org" , Rob Stradling Subject: Re: [Trans] Empty extra_data 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, 14 May 2015 09:25:14 -0000 --089e01176191e405f00516074dbe Content-Type: text/plain; charset=UTF-8 Looks good, except I'd move the sentence about a root certificate having an empty certificate_chain to the end (since it's not the common case). Linus, mind filing a ticket in trac.tools.ietf.org/wg/trans/trac/ so we can track this change? On Thu, May 14, 2015 at 5:42 AM, Linus Nordberg wrote: > Paul Wouters wrote > Tue, 12 May 2015 08:27:11 -0400 (EDT): > > | As an implementer, can you offer improved text? We are in the process of > | writing a bis document after all - now is a good time. > > Current 6962bis: > --8<---------------cut here---------------start------------->8--- > "leaf_certificate" is the end-entity certificate submitted for > auditing. > > "certificate_chain" is a chain of additional certificates required to > verify the end-entity certificate. The first certificate MUST > certify the end-entity certificate. Each following certificate MUST > directly certify the one preceding it. The final certificate MUST > either be, or be issued by, a root certificate accepted by the log. > --8<---------------cut here---------------end--------------->8--- > > Proposed 6962bis: > --8<---------------cut here---------------start------------->8--- > "leaf_certificate" is the end-entity certificate submitted for > auditing. > > "certificate_chain" is a chain of additional certificates required to > verify the end-entity certificate. A root certificate has an empty > certificate_chain. If present, the first certificate MUST > certify the end-entity certificate. Each following certificate MUST > directly certify the one preceding it. The final certificate MUST > either be, or be issued by, a root certificate accepted by the log. > --8<---------------cut here---------------end--------------->8--- > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --089e01176191e405f00516074dbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Looks good, except I'd move the sentence about a root = certificate having an empty certificate_chain to the end (since it's no= t the common case).

Linus, mind filing a ticket in=C2=A0= trac.tools.ietf.org/w= g/trans/trac/ so we can track this change?

On Thu, May 14, 2015 at 5:42 AM, L= inus Nordberg <linus@nordu.net> wrote:
Paul Wouters <paul@nohats.c= a> wrote
Tue, 12 May 2015 08:27:11 -0400 (EDT):

| As an implementer, can you offer improved text? We are in the process of<= br> | writing a bis document after all - now is a good time.

Current 6962bis:
--8<---------------cut here---------------start------------->8---
=C2=A0 =C2=A0"leaf_certificate" is the end-entit= y certificate submitted for
=C2=A0 =C2=A0auditing.

=C2=A0 =C2=A0"certificate_chain" is a chain of additional certifi= cates required to
=C2=A0 =C2=A0verify the end-entity certificate.=C2=A0 The first certificate= MUST
=C2=A0 =C2=A0certify the end-entity certificate.=C2=A0 Each following certi= ficate MUST
=C2=A0 =C2=A0directly certify the one preceding it.=C2=A0 The final certifi= cate MUST
=C2=A0 =C2=A0either be, or be issued by, a root certificate accepted= by the log.
--8<---------------cut here---------------end--------------->8---

Proposed 6962bis:
--8<---------------cut here---------------start------------->8---
=C2=A0 =C2=A0"leaf_certificate" is the end-entit= y certificate submitted for
=C2=A0 =C2=A0auditing.

=C2=A0 =C2=A0"certificate_chain" is a chain of additional certifi= cates required to
=C2=A0 =C2=A0verify the end-entity certificate.=C2=A0 A root certifi= cate has an empty
=C2=A0 =C2=A0certificate_chain.=C2=A0 If present, the first certificate MUS= T
=C2=A0 =C2=A0certify the end-entity certificate.=C2=A0 Eac= h following certificate MUST
=C2=A0 =C2=A0directly certify the one preceding it.=C2=A0 The final certifi= cate MUST
=C2=A0 =C2=A0either be, or be issued by, a root certificate accepted= by the log.
--8<---------------cut here---------------end--------------->8---

_______________________________________________
Trans mailing list
Trans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trans

--089e01176191e405f00516074dbe-- From nobody Mon May 18 07:29:02 2015 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 5BA7F1A9080 for ; Mon, 18 May 2015 07:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 n8iSVp7uta1N for ; Mon, 18 May 2015 07:29:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (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 BED3F1A8AC1 for ; Mon, 18 May 2015 07:28:35 -0700 (PDT) Received: from localhost ([::1]:39840 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YuM1m-0002ud-BV; Mon, 18 May 2015 07:28:22 -0700 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, eranm@google.com X-Trac-Project: trans Date: Mon, 18 May 2015 14:28:22 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/82#comment:3 Message-ID: <073.fa42c041ac07ef1fc41703565da0564b@tools.ietf.org> References: <058.605775396b2af7a29113e5c5c8670c40@tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <058.605775396b2af7a29113e5c5c8670c40@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, eranm@google.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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150518142835.BED3F1A8AC1@ietfa.amsl.com> Resent-Date: Mon, 18 May 2015 07:28:35 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #82 (rfc6962-bis): add integrity validation to get-entries (and fetching SCTs?) 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: Mon, 18 May 2015 14:29:01 -0000 #82: add integrity validation to get-entries (and fetching SCTs?) Comment (by eranm@google.com): Note that the SCTs do not cover the extra_data hence this addition will not provide integrity for the extra_data field (but accessing logs over HTTPS, which the RFC mandates they support, would). -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon May 18 07:33:43 2015 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 715841A8AA3 for ; Mon, 18 May 2015 07:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 J2iIJ1MaBIYB for ; Mon, 18 May 2015 07:33:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (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 9D79D1A9088 for ; Mon, 18 May 2015 07:33:33 -0700 (PDT) Received: from localhost ([::1]:40033 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YuM6c-0001Jm-Sb; Mon, 18 May 2015 07:33:22 -0700 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, eranm@google.com X-Trac-Project: trans Date: Mon, 18 May 2015 14:33:22 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/82#comment:4 Message-ID: <073.b49c17683000e154155f799fbb26a9fa@tools.ietf.org> References: <058.605775396b2af7a29113e5c5c8670c40@tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <058.605775396b2af7a29113e5c5c8670c40@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, eranm@google.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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150518143333.9D79D1A9088@ietfa.amsl.com> Resent-Date: Mon, 18 May 2015 07:33:33 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #82 (rfc6962-bis): Add a way to get the SCTs for entries returned by get-entries (was: add integrity validation to get-entries (and fetching SCTs?)) 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: Mon, 18 May 2015 14:33:41 -0000 #82: Add a way to get the SCTs for entries returned by get-entries -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon May 18 07:37:54 2015 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 A90371A8A0F for ; Mon, 18 May 2015 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 S_SshZ7w94YK for ; Mon, 18 May 2015 07:37:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (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 B5E6F1A8AA3 for ; Mon, 18 May 2015 07:37:52 -0700 (PDT) Received: from localhost ([::1]:40248 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YuMAx-0005QF-M6; Mon, 18 May 2015 07:37:51 -0700 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, eranm@google.com X-Trac-Project: trans Date: Mon, 18 May 2015 14:37:51 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/82#comment:5 Message-ID: <073.eb651aeeb9af7d954f47727900e16bf5@tools.ietf.org> References: <058.605775396b2af7a29113e5c5c8670c40@tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <058.605775396b2af7a29113e5c5c8670c40@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, eranm@google.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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150518143752.B5E6F1A8AA3@ietfa.amsl.com> Resent-Date: Mon, 18 May 2015 07:37:52 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #82 (rfc6962-bis): Add a way to get the SCTs for entries returned by get-entries 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: Mon, 18 May 2015 14:37:53 -0000 #82: Add a way to get the SCTs for entries returned by get-entries Comment (by eranm@google.com): Out for review in https://github.com/google/certificate-transparency- rfcs/pull/42 I've changed the ticket to reflect that what's needed is a way to get back SCTs, not integrity validation to get-entries: * Integrity can be provided by accessing the log over HTTPS (assuming the TLS client checks the log's certificate chain correctly). * the extra_data field is not currently covered by any signature so it'd be impossible to distinguish between transit and storage corruptions. * Providing the SCTs is enough to allow log mirroring. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon May 18 07:51:18 2015 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 3ED011A90ED for ; Mon, 18 May 2015 07:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 jfVUrwJHWUib for ; Mon, 18 May 2015 07:51:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596811A90E8 for ; Mon, 18 May 2015 07:51:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7FA91BEF1 for ; Mon, 18 May 2015 15:51:08 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3C3pcSfN-h2 for ; Mon, 18 May 2015 15:51:07 +0100 (IST) Received: from [172.20.5.45] (unknown [122.112.117.133]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9C576BF24 for ; Mon, 18 May 2015 15:51:05 +0100 (IST) Message-ID: <5559FC4D.1080701@cs.tcd.ie> Date: Mon, 18 May 2015 15:50:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: trans@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] question: short lived certs 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: Mon, 18 May 2015 14:51:17 -0000 (All those issue tracker mails reminded me of a question I'd meant to and had forgotten to ask...) At the acme BoF there was some talk of short lived certs. The thought was that if acme succeeds then it'd be more practical to use certs with a lifetime of a day or so. And that might raise a question as to how that'd affect CT or if there's an elegant way to support such. I don't think this is something that has to be part of the current bis RFC necessarily but it'd probably be good to get the collective wisdom of the list on the topic. So, what do we think of CT when faced with 1 day duration certs or similar? Ta, S. From nobody Mon May 18 09:07:06 2015 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 B9F421AC438 for ; Mon, 18 May 2015 09:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.012 X-Spam-Level: X-Spam-Status: No, score=0.012 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 QUawsDKEaVMW for ; Mon, 18 May 2015 09:07:00 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (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 3AB1B1AC3EC for ; Mon, 18 May 2015 09:07:00 -0700 (PDT) Received: by obfe9 with SMTP id e9so129275792obf.1 for ; Mon, 18 May 2015 09:06:59 -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; bh=zWeXLOwWQZXIkwNrEWsIjhYXo2HNMYoVAB3ETfUVAaU=; b=aK202g+cooxMLar/GlYDge/5G3tjisnqfCvInFuNhspTJh3xwN6w3rqTf9sgfZqDAn Qa3YDdBLFhYLIU0inNgdldVBzHAEkw5TIR5Fsxn8p5xsibiKJc5odbzPW/2GUD4wfWdw SC7zEBa8kX/bBePpJoVikjjvB1QdnerxSMj2l9gBtbHp2Ie10x1eX4t0eP5LlUNwxKT+ rZB4Flu393n5mpApQN2FfLOra1FXSEb1l/H7K4DistSlrcRiEmwOvVirMpAUDX0NDfux lonycQ3DQPmPRHMiVk9AZ3/oFXHJ8PH0pWJbQJNTxwy8DAg24yGzklsmPVJ2FqxcZag3 ttHQ== 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=zWeXLOwWQZXIkwNrEWsIjhYXo2HNMYoVAB3ETfUVAaU=; b=SNShlHYmKYoEFYw6YLVqkyhHGL8V4iQ6T6BqPK5k1HJ1+G6WYULGBzAmviI3O0PK13 GQmeB6bUKSCx0qBknb/vJOFsuJFdcyNctrtYsQv2crRGS7dLIaVpS/pcdWfVAQ9tF5B8 Fvxfhggi/tTF9qf6iQsTm+WUgcnOYXR8VSAhmI3AiQ0xzZUX61xP5XRpQvgFLFPNsf7a N7FqdQs2NvKKBHclsVqF4SCcQjX+WnSC0N69WnZu6Al6183wP5rVW/hIOWgY3ACFSwfM b4jIadsWjFfskoMZrbDXnI1IUkTii85TS+UoizvGgOawiXBcyl+um6/N/+4/R7E3oYqC ZIiw== X-Gm-Message-State: ALoCoQlGN1a7wuFLNU9uM7jGHzsCVU6zPHXtjrDRy46dl9TzgfOLpZuc5p13quylfxEs9fTleR+H MIME-Version: 1.0 X-Received: by 10.182.66.68 with SMTP id d4mr20165253obt.74.1431965219337; Mon, 18 May 2015 09:06:59 -0700 (PDT) Received: by 10.182.197.102 with HTTP; Mon, 18 May 2015 09:06:59 -0700 (PDT) In-Reply-To: <5559FC4D.1080701@cs.tcd.ie> References: <5559FC4D.1080701@cs.tcd.ie> Date: Mon, 18 May 2015 17:06:59 +0100 Message-ID: From: Eran Messeri To: Stephen Farrell Content-Type: multipart/alternative; boundary=e89a8f2346893ae39d05165d6235 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] question: short lived certs 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: Mon, 18 May 2015 16:07:04 -0000 --e89a8f2346893ae39d05165d6235 Content-Type: text/plain; charset=UTF-8 Two approaches mentioned in the past: * By Ben: Have separate logs for short-lived and long-lived certificates, cycle logs for short-lived certificates periodically. * By Matt Palmer: Trimming the merkle tree (not currently specified in the RFC). Eran On Mon, May 18, 2015 at 3:50 PM, Stephen Farrell wrote: > (All those issue tracker mails reminded me of a question > I'd meant to and had forgotten to ask...) > > At the acme BoF there was some talk of short lived certs. > The thought was that if acme succeeds then it'd be more > practical to use certs with a lifetime of a day or so. And > that might raise a question as to how that'd affect CT or if > there's an elegant way to support such. > > I don't think this is something that has to be part of the > current bis RFC necessarily but it'd probably be good to > get the collective wisdom of the list on the topic. > > So, what do we think of CT when faced with 1 day duration > certs or similar? > > Ta, > S. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --e89a8f2346893ae39d05165d6235 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Two approaches mentioned in the past:
* By Ben: Have s= eparate logs for short-lived and long-lived certificates, cycle logs for sh= ort-lived certificates periodically.
* By Matt Palmer: Trimming t= he merkle tree=C2=A0(not currently specified in the = RFC).

Eran


On Mon, May 18, 2015 at 3:50 P= M, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote= :
(All those issue tracker mails reminded= me of a question
I'd meant to and had forgotten to ask...)

At the acme BoF there was some talk of short lived certs.
The thought was that if acme succeeds then it'd be more
practical to use certs with a lifetime of a day or so. And
that might raise a question as to how that'd affect CT or if
there's an elegant way to support such.

I don't think this is something that has to be part of the
current bis RFC necessarily but it'd probably be good to
get the collective wisdom of the list on the topic.

So, what do we think of CT when faced with 1 day duration
certs or similar?

Ta,
S.

_______________________________________________
Trans mailing list
Trans@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/trans

--e89a8f2346893ae39d05165d6235-- From nobody Mon May 18 09:08:41 2015 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 8B7E41ACE3C for ; Mon, 18 May 2015 09:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.511 X-Spam-Level: X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 RIZoLUmPEiQk for ; Mon, 18 May 2015 09:08:39 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (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 48A181ACE15 for ; Mon, 18 May 2015 09:08:39 -0700 (PDT) Received: by qctt3 with SMTP id t3so10541155qct.1 for ; Mon, 18 May 2015 09:08:38 -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; bh=tDVwUlaf4VFQ35Ta1fIECvIs8J0CJ+S4B+zHK5ymzvQ=; b=NH2Fj9ZkU8AFWewc1r06H0ZWAA5/4FAURiCJZM7AcZighPLrUoviCX5z0x7vrZyLeX FUrj5jPGaJzWfA3jMXv3GMdaL6h+HwmKsNlfPsJmdSTcdx63ApqHyVILqFyTpmkjjpfu CgSRhjjGYr9vObg/6zdR2yKU0l3/MDkkZl5GMo8cvFSRUtGDj5K1Sl3UkhegVrfFti2j FRx/iz+WG0KzI9AhhhR4dMFWpKI0IsxdIwoDAyYevaQpsHitnO1iE3qXmBJvwP0FuiU1 1WxXDKbYEHu6ixr7QGp6v4ayrH/T7bjjFCCNtcnrwzlh+Tb5h5S/HiTwelRua/XcqAAA vhkg== 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=tDVwUlaf4VFQ35Ta1fIECvIs8J0CJ+S4B+zHK5ymzvQ=; b=U2Dd+/erYXqPWzQw2t75s5NQHSZbhNNhx09OKrIAJ4FObS54hVSZ/FucetRrvhsp2h gqKO6wXMn/LMGUqW3GxrZIRn1LA6ZGe/RhsGMPW843EcpSvDUjIxWZdApTnuJaKoiM1g +pd0x4oscst7XD2IgltXKIbLquPq8LrBrhIZhv+jZS9ar7sJXlaisNHfBp8Om62XZkSo IU58PvAcndfXTuprKPQLvoKnxDAKrT1Fkcf3eYJ9NsK31aeluixeWa+/IoU9hdBOUhMW OMHHxvCLKoWLj5qN7UEp3lkcHfjSsRIwVZhy5PydNlwMGsOHSviC3k8tczEmahEyPZx2 o1gg== X-Gm-Message-State: ALoCoQnfnosRyUw0kYr3zasv4+/is0emxVZrggozFGkDbm+G2sA6XvNxVoeakiOty5OR1UxQRFhZ MIME-Version: 1.0 X-Received: by 10.55.20.10 with SMTP id e10mr49790721qkh.36.1431965318395; Mon, 18 May 2015 09:08:38 -0700 (PDT) Received: by 10.229.155.138 with HTTP; Mon, 18 May 2015 09:08:38 -0700 (PDT) In-Reply-To: <5559FC4D.1080701@cs.tcd.ie> References: <5559FC4D.1080701@cs.tcd.ie> Date: Mon, 18 May 2015 17:08:38 +0100 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a1137de322267d505165d6891 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] question: short lived certs 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: Mon, 18 May 2015 16:08:40 -0000 --001a1137de322267d505165d6891 Content-Type: text/plain; charset=UTF-8 On 18 May 2015 at 15:50, Stephen Farrell wrote: > (All those issue tracker mails reminded me of a question > I'd meant to and had forgotten to ask...) > > At the acme BoF there was some talk of short lived certs. > The thought was that if acme succeeds then it'd be more > practical to use certs with a lifetime of a day or so. And > that might raise a question as to how that'd affect CT or if > there's an elegant way to support such. > > I don't think this is something that has to be part of the > current bis RFC necessarily but it'd probably be good to > get the collective wisdom of the list on the topic. > > So, what do we think of CT when faced with 1 day duration > certs or similar? > CT is necessarily after the fact detection anyway. However, 1 day duration certs would make that more painfully obvious! That said, if you are issuing 1 day certs, then clearly you are going to be replacing them every day. Presumably you could issue them in advance, so they appeared in the log before they were valid. The other thing to consider is the size of the log - I would want a different log for short-duration certs, since it will grow fast, but also most of it rapidly becomes irrelevant and can be ignored. --001a1137de322267d505165d6891 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 18 May 2015 at 15:50, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
(All those i= ssue tracker mails reminded me of a question
I'd meant to and had forgotten to ask...)

At the acme BoF there was some talk of short lived certs.
The thought was that if acme succeeds then it'd be more
practical to use certs with a lifetime of a day or so. And
that might raise a question as to how that'd affect CT or if
there's an elegant way to support such.

I don't think this is something that has to be part of the
current bis RFC necessarily but it'd probably be good to
get the collective wisdom of the list on the topic.

So, what do we think of CT when faced with 1 day duration
certs or similar?

CT is necessarily aft= er the fact detection anyway. However, 1 day duration certs would make that= more painfully obvious!

That said, if you are iss= uing 1 day certs, then clearly you are going to be replacing them every day= . Presumably you could issue them in advance, so they appeared in the log b= efore they were valid.

The other thing to consider= is the size of the log - I would want a different log for short-duration c= erts, since it will grow fast, but also most of it rapidly becomes irreleva= nt and can be ignored.
--001a1137de322267d505165d6891-- From nobody Mon May 18 09:49:38 2015 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 329C21A1A80 for ; Mon, 18 May 2015 09:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlzsTaXJ2uzM for ; Mon, 18 May 2015 09:49:32 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0095.outbound.protection.outlook.com [65.55.169.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3BC51AD0B2 for ; Mon, 18 May 2015 09:49:31 -0700 (PDT) Received: from SN1PR06MB1839.namprd06.prod.outlook.com (25.162.133.18) by SN1PR06MB1840.namprd06.prod.outlook.com (25.162.133.15) with Microsoft SMTP Server (TLS) id 15.1.160.19; Mon, 18 May 2015 16:49:28 +0000 Received: from SN1PR06MB1839.namprd06.prod.outlook.com ([25.162.133.18]) by SN1PR06MB1839.namprd06.prod.outlook.com ([25.162.133.18]) with mapi id 15.01.0160.009; Mon, 18 May 2015 16:49:28 +0000 From: Robin Wilton To: Ben Laurie Thread-Topic: [Trans] question: short lived certs Thread-Index: AQHQkXoco1W7aC3ENEuzgFOYTUu6O52B5tgAgAAMUAA= Date: Mon, 18 May 2015 16:49:26 +0000 Message-ID: <0DE609AF-C18E-47A3-AB27-B99B48631451@isoc.org> References: <5559FC4D.1080701@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wilton@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [94.174.34.240] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR06MB1840; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR06MB1840; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB1840; x-forefront-prvs: 058043A388 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(199003)(189002)(5001830100001)(189998001)(86362001)(122556002)(46102003)(81156007)(4001540100001)(5001960100002)(97736004)(110136002)(5001860100001)(5001920100001)(64706001)(50986999)(99936001)(106116001)(106356001)(76176999)(54356999)(68736005)(66066001)(62966003)(77156002)(19580395003)(19580405001)(82746002)(105586002)(83716003)(15975445007)(102836002)(92566002)(99286002)(16236675004)(2656002)(101416001)(36756003)(2900100001)(33656002)(87936001)(2950100001)(40100003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR06MB1840; H:SN1PR06MB1839.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) Content-Type: multipart/signed; boundary="Apple-Mail=_3E91CD88-416A-4E78-AE20-CE7CEA85DE2A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2015 16:49:26.7813 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB1840 Archived-At: Cc: "trans@ietf.org" , Stephen Farrell Subject: Re: [Trans] question: short lived certs 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: Mon, 18 May 2015 16:49:35 -0000 --Apple-Mail=_3E91CD88-416A-4E78-AE20-CE7CEA85DE2A Content-Type: multipart/alternative; boundary="Apple-Mail=_993F21C2-77D5-441C-9606-1AED6CEFF51B" --Apple-Mail=_993F21C2-77D5-441C-9606-1AED6CEFF51B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 18 May 2015, at 17:08, Ben Laurie wrote: >=20 >=20 > On 18 May 2015 at 15:50, Stephen Farrell = wrote: > (All those issue tracker mails reminded me of a question > I'd meant to and had forgotten to ask...) >=20 > At the acme BoF there was some talk of short lived certs. > The thought was that if acme succeeds then it'd be more > practical to use certs with a lifetime of a day or so. And > that might raise a question as to how that'd affect CT or if > there's an elegant way to support such. >=20 > I don't think this is something that has to be part of the > current bis RFC necessarily but it'd probably be good to > get the collective wisdom of the list on the topic. >=20 > So, what do we think of CT when faced with 1 day duration > certs or similar? >=20 > CT is necessarily after the fact detection anyway. However, 1 day = duration certs would make that more painfully obvious! >=20 > That said, if you are issuing 1 day certs, then clearly you are going = to be replacing them every day. Presumably you could issue them in = advance, so they appeared in the log before they were valid. >=20 > The other thing to consider is the size of the log - I would want a = different log for short-duration certs, since it will grow fast, but = also most of it rapidly becomes irrelevant and can be ignored. +1; it seems to me that the sensible way to improve scalability is to = segregate the high-volume, ephemeral certs from the longer-lived ones as = early as possible (presumably by checking if =93not valid after=94 is = only a day or so greater than =93not valid before=94). As Ben implies, I think it=92s also generally valid to assume that = ephemeral certs would give rise to a different kind of risk from that of = longer-lived certs, so the corresponding CT logs would benefit from = different management/policy. Yrs., Robin=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --Apple-Mail=_993F21C2-77D5-441C-9606-1AED6CEFF51B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On 18 May 2015, at 17:08, Ben Laurie <benl@google.com> wrote:



On 18 May 2015 at 15:50, Stephen Farrell <stephen.farrell@cs.tcd.ie> = wrote:
(All those issue = tracker mails reminded me of a question
I'd meant to and had forgotten to ask...)

At the acme BoF there was some talk of short lived certs.
The thought was that if acme succeeds then it'd be more
practical to use certs with a lifetime of a day or so. And
that might raise a question as to how that'd affect CT or if
there's an elegant way to support such.

I don't think this is something that has to be part of the
current bis RFC necessarily but it'd probably be good to
get the collective wisdom of the list on the topic.

So, what do we think of CT when faced with 1 day duration
certs or similar?

CT is necessarily = after the fact detection anyway. However, 1 day duration certs would = make that more painfully obvious!

That said, if = you are issuing 1 day certs, then clearly you are going to be replacing = them every day. Presumably you could issue them in advance, so they = appeared in the log before they were valid.

The = other thing to consider is the size of the log - I would want a = different log for short-duration certs, since it will grow fast, but = also most of it rapidly becomes irrelevant and can be = ignored.

+1; it = seems to me that the sensible way to improve scalability is to segregate = the high-volume, ephemeral certs from the longer-lived ones as early as = possible (presumably by checking if =93not valid after=94 is only a day = or so greater than =93not valid before=94).

As = Ben implies, I think it=92s also generally valid to assume that = ephemeral certs would give rise to a different kind of risk from that of = longer-lived certs, so the corresponding CT logs would benefit from = different = management/policy.

Yrs.,
Robin 



_______________________________________________
Trans mailing = list
Trans@ietf.org
https://www.ietf.org/= mailman/listinfo/trans

= --Apple-Mail=_993F21C2-77D5-441C-9606-1AED6CEFF51B-- --Apple-Mail=_3E91CD88-416A-4E78-AE20-CE7CEA85DE2A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlVaGNoACgkQx1kEWLxmyT0rRwCfcr3n1VzFd3Qn2O+KGif5D6cA xZoAoIF6gw1KZUk6BHuwXaTNuk8iXss/ =j5Vm -----END PGP SIGNATURE----- --Apple-Mail=_3E91CD88-416A-4E78-AE20-CE7CEA85DE2A-- From nobody Thu May 21 08:27:12 2015 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 47D3F1A8712 for ; Thu, 21 May 2015 08:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 lg5bhzo2eTuf for ; Thu, 21 May 2015 08:27:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (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 E4B001A8768 for ; Thu, 21 May 2015 08:27:07 -0700 (PDT) Received: from localhost ([::1]:40308 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YvSNC-00050X-29; Thu, 21 May 2015 08:27:02 -0700 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, linus@nordu.net X-Trac-Project: trans Date: Thu, 21 May 2015 15:27:02 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/84 Message-ID: <055.ea272dc06c58ca33b8cd9ebbf05ce7b3@tools.ietf.org> X-Trac-Ticket-ID: 84 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, linus@nordu.net, 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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150521152707.E4B001A8768@ietfa.amsl.com> Resent-Date: Thu, 21 May 2015 08:27:07 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #84 (rfc6962-bis): Clarify that root certs have empty certificate_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: Thu, 21 May 2015 15:27:11 -0000 #84: Clarify that root certs have empty certificate_chain Suggested new text for 3.1 Log Entries in bis: {{{{ "certificate_chain" is a chain of additional certificates required to verify the end-entity certificate. If present, the first certificate MUST certify the end-entity certificate. Each following certificate MUST directly certify the one preceding it. The final certificate MUST either be, or be issued by, a root certificate accepted by the log. A root certificate has an empty certificate_chain. }}}} See thread "Empty extra_data" for details. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- linus@nordu.net | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu May 21 08:28:30 2015 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 C74811A1A9C for ; Thu, 21 May 2015 08:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoXUWoBPMfTj for ; Thu, 21 May 2015 08:28:20 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (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 A4E421A8702 for ; Thu, 21 May 2015 08:28:19 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4LFS34A014406 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 May 2015 17:28:03 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id t4LFRvWj006766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 May 2015 15:28:00 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1432222082; bh=ihZSPMl62wDQBeacbBOxXYew/hz/DjQFuu7h/wu8x9s=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=FgOAJuUc/HvDDVhmz8Nay3EWzYExhrMPoGusjP0nvPcC848xbvDm91kNoplFX/taH AQiKR4VIqJ7q/+33Fp3qMnPqZd+Q3uv6HzrunVzRtfQrvvo8dD+u7S/N8x9fQFAyWG J2I3/1hJuO+iDabTA2l9kx/tDrBU8XWuSBBGRJEA= X-Footer: bm9yZHUubmV0 Received: from flogsta ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 21 May 2015 17:30:12 +0200 From: Linus Nordberg To: Eran Messeri Organization: NORDUnet A/S References: <87sib2qe20.fsf@nordberg.se> <5551D8A1.4020506@comodo.com> <87a8xaqatj.fsf@nordberg.se> <87bnhnepm9.fsf@nordberg.se> Date: Thu, 21 May 2015 17:27:55 +0200 In-Reply-To: (Eran Messeri's message of "Thu, 14 May 2015 10:25:10 +0100") Message-ID: <87lhgi3q84.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aOuDs3Qg - 631aaf252776 - 20150521 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.110.42 is neither permitted nor denied by domain linus@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.110.42; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom Archived-At: Cc: Paul Wouters , "trans@ietf.org" , Rob Stradling Subject: Re: [Trans] Empty extra_data 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, 21 May 2015 15:28:23 -0000 Looks like I dropped the ball on this. #84 created. Eran Messeri wrote Thu, 14 May 2015 10:25:10 +0100: | Looks good, except I'd move the sentence about a root certificate having an | empty certificate_chain to the end (since it's not the common case). | | Linus, mind filing a ticket in trac.tools.ietf.org/wg/trans/trac/ so we can | track this change? | | On Thu, May 14, 2015 at 5:42 AM, Linus Nordberg wrote: | | > Paul Wouters wrote | > Tue, 12 May 2015 08:27:11 -0400 (EDT): | > | > | As an implementer, can you offer improved text? We are in the process of | > | writing a bis document after all - now is a good time. | > | > Current 6962bis: | > --8<---------------cut here---------------start------------->8--- | > "leaf_certificate" is the end-entity certificate submitted for | > auditing. | > | > "certificate_chain" is a chain of additional certificates required to | > verify the end-entity certificate. The first certificate MUST | > certify the end-entity certificate. Each following certificate MUST | > directly certify the one preceding it. The final certificate MUST | > either be, or be issued by, a root certificate accepted by the log. | > --8<---------------cut here---------------end--------------->8--- | > | > Proposed 6962bis: | > --8<---------------cut here---------------start------------->8--- | > "leaf_certificate" is the end-entity certificate submitted for | > auditing. | > | > "certificate_chain" is a chain of additional certificates required to | > verify the end-entity certificate. A root certificate has an empty | > certificate_chain. If present, the first certificate MUST | > certify the end-entity certificate. Each following certificate MUST | > directly certify the one preceding it. The final certificate MUST | > either be, or be issued by, a root certificate accepted by the log. | > --8<---------------cut here---------------end--------------->8--- | > | > _______________________________________________ | > Trans mailing list | > Trans@ietf.org | > https://www.ietf.org/mailman/listinfo/trans> | _______________________________________________ | Trans mailing list | Trans@ietf.org | https://www.ietf.org/mailman/listinfo/trans From nobody Sun May 24 22:11:09 2015 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 B58B51A1A24 for ; Sun, 24 May 2015 22:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 lJ73mCG1ivQh for ; Sun, 24 May 2015 22:11:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719BE1A0406 for ; Sun, 24 May 2015 22:11:03 -0700 (PDT) Received: from [128.89.255.234] (port=52002 helo=Johns-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YwkfF-000PIT-L6 for trans@ietf.org; Mon, 25 May 2015 01:11:01 -0400 Message-ID: <5562AEE5.6080704@bbn.com> Date: Mon, 25 May 2015 01:11:01 -0400 From: Karen Seo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <553AC811.80708@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060308070000010603090406" Archived-At: Subject: Re: [Trans] Threat Analysis for CT adopted by the working group 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: Mon, 25 May 2015 05:11:07 -0000 This is a multi-part message in MIME format. --------------060308070000010603090406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit My apologies for the delay in delivering the threat analysis draft. Steve asked me to do some editing on it and I've been held up by an unfortunate combination of project/contract issues and my disk drive getting corrupted. Barring unforeseen problems, I expect that the draft will be submitted later this week. On 4/24/15 7:05 PM, Melinda Shore wrote: > > Thanks! I was wondering why we hadn't heard from him yet. When he's > back we can work out a timeline etc. > > Melinda > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --------------060308070000010603090406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
My apologies for the delay in delivering the threat analysis draft.  Steve asked me to do some editing on it and I've been held up by an unfortunate combination of project/contract issues and my disk drive getting corrupted.  Barring unforeseen problems, I expect that the draft will be submitted later this week.

On 4/24/15 7:05 PM, Melinda Shore wrote:

Thanks!  I was wondering why we hadn't heard from him yet.   When he's back we can work out a timeline etc.

Melinda



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

--------------060308070000010603090406-- From nobody Sun May 24 22:15:59 2015 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 7213F1A1A4D for ; Sun, 24 May 2015 22:15:57 -0700 (PDT) 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 W4dMPAf1IRno for ; Sun, 24 May 2015 22:15:55 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 A5E221A1A4A for ; Sun, 24 May 2015 22:15:53 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so63476012pac.2 for ; Sun, 24 May 2015 22:15:53 -0700 (PDT) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=dFfOF2YE7uNFcTHRfBDFUD65sAKQEM+OzTTSTNHf81o=; b=a9v0Z1erHLal5zuHlXF+wvB/swAAuczsHFvYYkMx1CMtQ3wo2RAlD8kvhlNQjKqZao C/AVMoJYz+IK9hZYZYO0ifoAb99srF2NNWSi5RjQ7IUhS6mgKbh/5spbAG1ghR3l+/I5 MIJH8yYMapu25yJiG2QVjvgzX5CUoGgaNBnGPGo7B/Cnl4Owei/Md3JTk7bn1SGUmmxi ohHuZMocgaEXUgjOgbL5p1SkqG9zKlLnbzRF/RuaV3ef0C+DgyIFsGVik6gul7ci6rVn QWLnRgzKbHc+a65K/F7/L9kBr59YssMFtJFG78RRxfHaumS2kCSRdM8gt+jGG1xgGnHq fufg== X-Received: by 10.70.124.233 with SMTP id ml9mr36886755pdb.9.1432530953402; Sun, 24 May 2015 22:15:53 -0700 (PDT) Received: from spandex.local (216-67-51-67-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.51.67]) by mx.google.com with ESMTPSA id rx6sm8601086pbc.54.2015.05.24.22.15.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 May 2015 22:15:52 -0700 (PDT) Message-ID: <5562B006.1010303@gmail.com> Date: Sun, 24 May 2015 21:15:50 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Karen Seo , trans@ietf.org, Paul Wouters References: <553AC811.80708@bbn.com> <5562AEE5.6080704@bbn.com> In-Reply-To: <5562AEE5.6080704@bbn.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Threat Analysis for CT adopted by the working group 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: Mon, 25 May 2015 05:15:57 -0000 On 5/24/15 9:11 PM, Karen Seo wrote: > My apologies for the delay in delivering the threat analysis draft. > Steve asked me to do some editing on it and I've been held up by an > unfortunate combination of project/contract issues and my disk drive > getting corrupted. Barring unforeseen problems, I expect that the draft > will be submitted later this week. Excellent - thanks for the update. We'll get some discussion going on the mailing list once it's posted. Melinda From nobody Fri May 29 06:52:15 2015 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 550FF1A8F49 for ; Fri, 29 May 2015 06:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.039 X-Spam-Level: ** X-Spam-Status: No, score=2.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 8HaEEA-yHPva for ; Fri, 29 May 2015 06:52:12 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8751A8F43 for ; Fri, 29 May 2015 06:52:12 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:2c97:df86:3fb6:6774] (unknown [IPv6:2001:1488:fffe:6:2c97:df86:3fb6:6774]) by mail.nic.cz (Postfix) with ESMTPSA id 9F2F513F678 for ; Fri, 29 May 2015 15:52:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1432907530; bh=Gmdv0UcY6aDjWfqwhesJNpCSq6emnBh3e2AxtRaS1ow=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=jtFQCFWySeGLje9k3FJYp0CulhZmO9V7vptfcowrW2CbEpMyfsYYL0celZpBGBflU e0BkSgp4L7EcyPgWoCc6IkFxYOWTtkPzqUSoSLlm4U6TAm8UqJFzqB4t/et+SEehuJ JRDSm9lS17/2R0/xZ55+l2dCQ6A/sSoMY/d+eVw4= Message-ID: <55686ED3.4040705@nic.cz> Date: Fri, 29 May 2015 15:51:15 +0200 From: Ondrej Mikle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.6 at mail X-Virus-Status: Clean Archived-At: Subject: [Trans] LogEntryType for SCTs in case of TLS extension? 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, 29 May 2015 13:52:14 -0000 Hi, what should be the LogEntryType for SCTs in case of SCTs sent in TLS extension? I think it's missing in section 3.4.1 in 6962-bis (sections 3.4.2.1 and 3.4.2.2 specify it). By looking at the reference CT client it seems that it is expected to be "x509_entry" (in CertSubmissionHandler::X509ChainToEntry). Ondrej From nobody Sun May 31 11:48:18 2015 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 BC73E1A8870 for ; Sun, 31 May 2015 11:48:17 -0700 (PDT) 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 mCWO4X5p_mE6 for ; Sun, 31 May 2015 11:48:16 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 7BA991A886C for ; Sun, 31 May 2015 11:48:16 -0700 (PDT) Received: by padj3 with SMTP id j3so28073089pad.0 for ; Sun, 31 May 2015 11:48:16 -0700 (PDT) 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:cc:subject :content-type:content-transfer-encoding; bh=K/VRntHOl0Y7ISowOMVJOKMsQksulKuhHv0QpHX6bCA=; b=vIl4wup9qvhroTRyiwmpYXBf/MAzOC8FQzbZ7h3GzmS2KbwfvciVhzIagkN/oGxwUp kH+y5Mvbs/CKgUUB4PF+zRL4e+bclYlkcJdV8ypX8oE7z9C95iK42AY3prwgMNZ/m3Za zWL10aS4P+01T+KX+StptDH+Q0xDw/7xIIb/Bm9jOjWDSRBmjBzZeh9+Xg39RB/OUHbO Cbm/PAU4kKh7JiixG82dpGleybXfHjwCN/NekTdPuPMsGDt4IT2b8iZFnkzjE7P5zEIF bfUl0jLVna+myIH14T06EOMJpVUUxc0Nk3H2sOew1Vs5VpYTtcrC8mwIls2S2Yxr/LM9 A7tA== X-Received: by 10.68.252.38 with SMTP id zp6mr34030989pbc.159.1433098096128; Sun, 31 May 2015 11:48:16 -0700 (PDT) Received: from spandex.local (216-67-27-52-rb2.nwc.dsl.dynamic.acsalaska.net. [216.67.27.52]) by mx.google.com with ESMTPSA id pa1sm11910623pdb.73.2015.05.31.11.48.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 May 2015 11:48:15 -0700 (PDT) Message-ID: <556B576D.3090907@gmail.com> Date: Sun, 31 May 2015 10:48:13 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Stephen Farrell Subject: [Trans] Work on dnssec logging 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: Sun, 31 May 2015 18:48:17 -0000 Hello: As a general rule (and it's a good rule), working group chairs do not get deeply involved with the technical work of their working group and they do not author or edit working group deliverables. Our situation in trans with regard to dnssec logging is that there's substantial interest, but dnssec is a very highly specialized technical area and the dns in general has scaling characteristics that are somewhat unusual in the IETF. Paul Wouters, one of the working group chairs, has significant expertise in this area and is interested in participating in the technical work on logging dnssec. In the interest of transparency and fairness we thought it would be a good idea to check with the working group to see if there were objections. What this means for how the work would be progressed is that if a dnssec logging spec were to become a working group deliverable, Paul would not be involved with identifying consensus, conflict resolution, or with other management aspects (like document shepherding) on that document. If anybody has concerns or objections, please let us know. Melinda