From nobody Mon Jun 1 04:21:24 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 C51851A0066 for ; Mon, 1 Jun 2015 04:21:22 -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 A20F7tBb-A89 for ; Mon, 1 Jun 2015 04:21:21 -0700 (PDT) Received: from mail-vn0-x232.google.com (mail-vn0-x232.google.com [IPv6:2607:f8b0:400c:c0f::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 852221A0065 for ; Mon, 1 Jun 2015 04:21:21 -0700 (PDT) Received: by vnbf190 with SMTP id f190so15512914vnb.0 for ; Mon, 01 Jun 2015 04:21:19 -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=1S0YqGGtx7KUOYkazpSbEJoGzzPNQ/CnbDUqrB9tUkE=; b=QqJBxrRPOo1KBhDAI0QT6b5QPL2CN0HZniUaEorPPDpqW1u5EgGpoz14jRQIMhic5i GwdvXDVUaqbdBlUWJtCI6bc4S7twpnt4YP8CF+f7okM6chWCT4ZiLFUktCUlQCMuedIi zaG2j+2nuipCDBGCAnO51TuwJ5eBmdmrke6Uk4foWkVG4Emko8aubhSLdHiA66jghrYH q2hBxu/ulHxMSMrkJu62ZbDrpxeNVZPlh48XkIsGbxploSvyCwB9H6gExahGKbDnk9X+ nbJ1l4ogcFYuLWAL3LkgZzw8akGliL4AML2g360ofDIN+0NFJity7Bq6OUi/CXAaQmMN 57Lg== 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=1S0YqGGtx7KUOYkazpSbEJoGzzPNQ/CnbDUqrB9tUkE=; b=KtD3FrtCzajA3vu+v/qB/pXMogLoX+uoLRmoKRud+11x9md6b08Ut49LxueQ1oRkyw IEe+Od65Owr3rG8i3Q0BHUKlX/cEXAGteo7k6FneJm36E4ugo4F50rU3HC4oSefoOEU6 1caPF4LVyvELGaWDSYwYzTw6Z6cfZF2KzJ16q5EUu4E4aMDv/nJXA8Fci7Rpk1k+4ygT BoDkZ3tKGSD5r4Jqu3tBZ91u3XuvoMXjsoaNDfzEVpK2/nuZoDfDryIThqTJ+wLk5mGX 7+9fMhOzRpBQAQBlLexl6TXzmQw06LN8ZLVxGIFkQRSEIK13em+k3+hL0eAdO8x0ysAa DQQw== X-Gm-Message-State: ALoCoQlmtNgQhesWPAr7cZLYpO/sxKIV7CLMhhEqQjLoCOqktgoXZNUjEJsJhKdyivvFaMnkG8BW MIME-Version: 1.0 X-Received: by 10.52.139.168 with SMTP id qz8mr27395788vdb.82.1433157679639; Mon, 01 Jun 2015 04:21:19 -0700 (PDT) Received: by 10.52.136.172 with HTTP; Mon, 1 Jun 2015 04:21:19 -0700 (PDT) In-Reply-To: <556B576D.3090907@gmail.com> References: <556B576D.3090907@gmail.com> Date: Mon, 1 Jun 2015 12:21:19 +0100 Message-ID: From: Ben Laurie To: Melinda Shore Content-Type: multipart/alternative; boundary=bcaec51a742c67155505177306ef Archived-At: Cc: "trans@ietf.org" , Stephen Farrell Subject: Re: [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: Mon, 01 Jun 2015 11:21:22 -0000 --bcaec51a742c67155505177306ef Content-Type: text/plain; charset=UTF-8 On 31 May 2015 at 19:48, Melinda Shore wrote: > 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. > On the contrary - this seems fine to me. Does this mean that someone is thinking of starting work on dnssec? --bcaec51a742c67155505177306ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 31 May 2015 at 19:48, Melinda Shore <melinda.shore@gmail.com<= /a>> wrote:
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.=C2=A0 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.=C2=A0 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.=C2=A0 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.
=

On the contrary - this seems fine to me.

=
Does this mean that someone is thinking of starting work on dnss= ec?

--bcaec51a742c67155505177306ef-- From nobody Mon Jun 1 06:19:52 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 CB7371ACD88 for ; Mon, 1 Jun 2015 06:19:50 -0700 (PDT) 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 IcS0NYWoPeZ7 for ; Mon, 1 Jun 2015 06:19:49 -0700 (PDT) Received: from mail-vn0-x233.google.com (mail-vn0-x233.google.com [IPv6:2607:f8b0:400c:c0f::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 450AB1ACD5B for ; Mon, 1 Jun 2015 06:19:49 -0700 (PDT) Received: by vnbf62 with SMTP id f62so16004268vnb.7 for ; Mon, 01 Jun 2015 06:19:48 -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=Kl2ofEFVrHHr+0NvW2RJX5YLfZ50MgEOljYPiN/cxbc=; b=Ak3k2w7oc49qQ4k4KTCNWxU+CTYHsPnyKqr0B+yeGzC0keO//y9bNeBNvE/Y/eeiFM JF6/77JzaG+Y3sUzwenw8ipKBAuonFG0A1WA37ud4MK/jg2Iv5QhYe9Pna6Ep8QsrMIg 7cz45b6ONxex4W83G9Uvm8wjOZ58+WJhEeoXWkAvRQPsPBHZ1kJzkaGZKCw8v6fMgTsM V45XThVvtmOF0yD1kKjTLZK+bPA3yiepfOlTvQA1uskgHnzJaSwgGnGyaXPUDwNH40NZ 7rjGOvOYvO7VS3SgRduBWWk5eipJzIayoUVtAQDZ3sP4b9DZA/YIxhMSLwhNj8a65cvW dKnw== 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=Kl2ofEFVrHHr+0NvW2RJX5YLfZ50MgEOljYPiN/cxbc=; b=ZRpBnwFOiMMcs2F25HiANLSW+HJnz1SuKSBS1PZTp/G4mbDnsj/zdZHMmHxn/fShJf 3rA2KFuy4eXb/3BNmR+XFGmzF5QPy6+hKLkDrSSaUE1BkqI0YtPKFtnA/DofXQc3ur4a OS5ycTFRCKRD5HjY5BCfcNuwgYB7KaOVvPjAaly3ZLrpr6Of7YCGyuuGJToFsSkouYE5 I0mpGULcMyHToSBFVQZCDOi7AeiO5SXFMYAfC8r5SYvAenD03dGiZL4xYMxf5iEWM0DJ gATJSgAXmUJSlvwWP+vlVyUhoy2d5bAAMO4d/nSS6R4zvxHo8gnIicbilycvYjf0SiCm +t4A== X-Gm-Message-State: ALoCoQl/nQqmx3NrPXBaJ4s1QeLMbnQzaz33WDmxPoerN266fLC3lCQ7aipuLnXvei0ZLIym7KgC MIME-Version: 1.0 X-Received: by 10.52.139.168 with SMTP id qz8mr28294501vdb.82.1433164788409; Mon, 01 Jun 2015 06:19:48 -0700 (PDT) Received: by 10.52.136.172 with HTTP; Mon, 1 Jun 2015 06:19:48 -0700 (PDT) In-Reply-To: <55686ED3.4040705@nic.cz> References: <55686ED3.4040705@nic.cz> Date: Mon, 1 Jun 2015 14:19:48 +0100 Message-ID: From: Ben Laurie To: Ondrej Mikle Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [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: Mon, 01 Jun 2015 13:19:51 -0000 On 29 May 2015 at 14:51, Ondrej Mikle wrote: > > 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). Not sure there's any need to require particular types for SCTs. In practice, an SCT included in an X509v3 extension has to be a precertificate SCT, of course. But in other contexts it could be either type - though it would obviously be expected that for OCSP and TLS extensions it would be an x509_entry, there's no reason I can see to force this choice. From nobody Mon Jun 1 10:01: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 5BB1F1B2AF7 for ; Mon, 1 Jun 2015 10:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDTnFzkHpyUq for ; Mon, 1 Jun 2015 10:01:36 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AD3D01B2AD4 for ; Mon, 1 Jun 2015 10:01:36 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 8D89D2005D91F; Mon, 1 Jun 2015 10:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=7cvwdF67YvObUY OGLqVZhjNLJXo=; b=YuANu8vZvFkiDO2kj39/p7g6MI2JdtudC0oD/e3qIj2o9r +ygTNGULYsb4xsArhNlPfC0ZVzlnSBzHlPx/Fqd3k/RFI81UkHbVRam7g8Vbn8U+ 7lfiDiaNbab4U+Xb6r4AGHjOFbtRmD/yKxIaU4DMYuaLzzc3b5kL4UrZDjXYo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id 4121D2005D82D; Mon, 1 Jun 2015 10:01:35 -0700 (PDT) Date: Mon, 1 Jun 2015 12:01:34 -0500 From: Nico Williams To: Melinda Shore Message-ID: <20150601170133.GG600@localhost> References: <556B576D.3090907@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556B576D.3090907@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "trans@ietf.org" , Stephen Farrell Subject: Re: [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: Mon, 01 Jun 2015 17:01:37 -0000 On Sun, May 31, 2015 at 10:48:13AM -0800, Melinda Shore wrote: > 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. This is one reason to have multiple chairs. When Paul is wearing the CT-for-DNSSEC autor/editor hat, he can't wear the chair hat (or maybe he can but with much care, and only in the absence of the other chairs, but it's best not to). In other contexts he can wear the chair hat just fine. There's nothing objectionable here. Nico -- From nobody Mon Jun 1 10:20:55 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 0604D1B2B3D for ; Mon, 1 Jun 2015 10:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 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_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 XuoVsZWIe_44 for ; Mon, 1 Jun 2015 10:20:52 -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 5E0811B2A6E for ; Mon, 1 Jun 2015 10:20:51 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:a03f:69bc:74e5:598d] (unknown [IPv6:2001:1488:fffe:6:a03f:69bc:74e5:598d]) by mail.nic.cz (Postfix) with ESMTPSA id 0F2ED1400F9; Mon, 1 Jun 2015 19:20:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1433179250; bh=A2P/KVtBIMCMq9ESUsQ+mHU+/21LoNVdgygBk9cnLDg=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dbhEakMQ98n0F4KpKfBt48r7nkRVGJ2TbVLpPXQs42u72EOA/jXX8BIroibx2q2ed cRGHZ2GPzgZJqpi4VNFnbeIuqh2f2Sh56Db6lurnKmdc0Wh7BAAS5oq41peD1gIQ3X 9zBA5jxU4fN2p4g3cfC5KDj/hVLZkaIoMfMgl0hQ= Message-ID: <556C9439.5060908@nic.cz> Date: Mon, 01 Jun 2015 19:19:53 +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: Ben Laurie References: <55686ED3.4040705@nic.cz> In-Reply-To: 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: Cc: "trans@ietf.org" Subject: Re: [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: Mon, 01 Jun 2015 17:20:54 -0000 On 06/01/2015 03:19 PM, Ben Laurie wrote: > On 29 May 2015 at 14:51, Ondrej Mikle wrote: >> >> 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). > > Not sure there's any need to require particular types for SCTs. In > practice, an SCT included in an X509v3 extension has to be a > precertificate SCT, of course. But in other contexts it could be > either type - though it would obviously be expected that for OCSP and > TLS extensions it would be an x509_entry, there's no reason I can see > to force this choice. Unless it's explicitly specified, the code has to try both variants (precert_entry and x509_entry) to see which one would match the signature. At least I thought that was the reason LogEntryType was explicitly specified for OCSP extension and certificate extension in 6962-bis (and was wondering why explicit LogEntryType was missing in for TLS extension). Ondrej From nobody Wed Jun 3 07:27:07 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 651301A892F for ; Wed, 3 Jun 2015 07:27:04 -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 0ZK_4ebMgpQf for ; Wed, 3 Jun 2015 07:27:00 -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 677961A8920 for ; Wed, 3 Jun 2015 07:26:59 -0700 (PDT) Received: (qmail 29898 invoked by uid 1004); 3 Jun 2015 14:26:57 -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; Wed, 03 Jun 2015 15:26:57 +0100 Received: (qmail 14745 invoked by uid 1000); 3 Jun 2015 14:26:57 -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; Wed, 03 Jun 2015 15:26:57 +0100 Message-ID: <556F0EB1.1060400@comodo.com> Date: Wed, 03 Jun 2015 15:26:57 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Melinda Shore , "trans@ietf.org" References: <53D9600C.6040805@gmail.com> In-Reply-To: <53D9600C.6040805@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Tracking implementations 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, 03 Jun 2015 14:27:04 -0000 https://crt.sh Pronounced "search". :-) It's a web interface that lets you search for certs that have been logged by the publicly known RFC6962 logs. Right now it's half a Monitor. It fetches all new entries soon after they're added to the logs, but it doesn't (yet) verify STH signatures. No current plans to release source code. Feel free to mention this on the wiki page. On 30/07/14 22:13, Melinda Shore wrote: > During the session last week I was a bit surprised by the number of > people saying that they were doing implementations, and I think it > might be useful to get a better handle on that. If nothing else, it > helps quite a bit during the publication process if it's known > that there are interoperable implementations and that we know a little > bit about them. > > So, I'd be grateful if people who've are working on implementations > and who can discuss them publicly could speak up, let us know the > status and whether or not you'll be releasing source, and provide a > pointer to a repo or other documentation if you're able. Also let > me know whether or not you'd be willing to have your implementation > mentioned on a wiki page listing implementations. > > Thanks again, > > Melinda -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Jun 3 09:50:20 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 B775E1A92B4 for ; Wed, 3 Jun 2015 09:50:18 -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 KHYz1Aohja4s for ; Wed, 3 Jun 2015 09:50:16 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935651A923E for ; Wed, 3 Jun 2015 09:50:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3m1x7B2sHwz1K8; Wed, 3 Jun 2015 18:50:14 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=eEpjKmHh 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 kcCVcQQj5qdN; Wed, 3 Jun 2015 18:50:11 +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; Wed, 3 Jun 2015 18:50:11 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B731C8004A; Wed, 3 Jun 2015 12:50:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1433350209; bh=0nfGxNyLuzR6eZZ4ZL9wHIgraQOnVQvmY8r4v91DHJg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eEpjKmHhL/zKpF7ikepaJc0ExJxixOBBtoASu+jdMaWW8fsiNSB11Mohy2IV2tl2J ItoqAr28DvS8La/35l7tKS9upPMYvOASlK3MAGHq/9DW3J23vgRQ9RbWD8dHCU/ZP7 BNCdhFjkyVi8TYrribxjniAtWV1oT2bGD5e3kbOQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.1/8.15.1/Submit) with ESMTP id t53Go8sq029811; Wed, 3 Jun 2015 12:50:09 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 3 Jun 2015 12:50:08 -0400 (EDT) From: Paul Wouters To: Rob Stradling In-Reply-To: <556F0EB1.1060400@comodo.com> Message-ID: References: <53D9600C.6040805@gmail.com> <556F0EB1.1060400@comodo.com> 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: "trans@ietf.org" Subject: Re: [Trans] Tracking implementations 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, 03 Jun 2015 16:50:18 -0000 On Wed, 3 Jun 2015, Rob Stradling wrote: > https://crt.sh > > Pronounced "search". :-) > > It's a web interface that lets you search for certs that have been logged by > the publicly known RFC6962 logs. Very cool! Paul From nobody Wed Jun 3 10:40:47 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 648E61A87EA for ; Wed, 3 Jun 2015 10:40:43 -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 T1W5SV11lnQ6 for ; Wed, 3 Jun 2015 10:40:34 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (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 410BF1A9171 for ; Wed, 3 Jun 2015 10:40:34 -0700 (PDT) Received: by qcej9 with SMTP id j9so7292030qce.1 for ; Wed, 03 Jun 2015 10:40:33 -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=TQVgPqPHsRqo8dKx/HDb58YffSZOiTC+efKVYm8b+nQ=; b=i9YRsT/wv6uWHa2zRNxLbbNdlmRwaCUO08FGDnLo2CkL4gE6zhCORe/CmpoFquySDk nMvKTdyAJGDd2grafhKzK0pjWRU/cdyNbdjYtYcg8z+mecxpTWoEofPjCLrx4zT46MKa ZSv2sId8AXuMDCVuBtPXX3Y6Lal7fj6JmjXg7dMlnHwjODLyI5FgUktHoYuaAJ3Y3rGq 7mYOpTm1awEQx77TK5/sHqPrHHp3mz7CMnspJPPiaHQ0kD7IF0eh2J2Ifx7ZtoPT6Jnm kUaHLkhmSIQDetAhaswSQ97X8DDN1JkoYpa3etn0Qbb6AqPGu0EAzwdFYCzkuXIlTcoW ipNw== X-Received: by 10.140.21.134 with SMTP id 6mr37056654qgl.47.1433353233532; Wed, 03 Jun 2015 10:40:33 -0700 (PDT) Received: from twicinski-ltm.internal.salesforce.com ([204.14.239.17]) by mx.google.com with ESMTPSA id j60sm754394qge.38.2015.06.03.10.40.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2015 10:40:32 -0700 (PDT) Message-ID: <556F3C0F.9020607@gmail.com> Date: Wed, 03 Jun 2015 10:40:31 -0700 From: Tim Wicinski 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: <53D9600C.6040805@gmail.com> <556F0EB1.1060400@comodo.com> In-Reply-To: <556F0EB1.1060400@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Tracking implementations 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, 03 Jun 2015 17:40:43 -0000 Thanks Rob. The security folks at my employer already found a domain that was set up by some marketing folks that has a less than optimal cert, and the domain appears to be in someone's personal account, and they are no longer with the company. Of course the domain is active. sigh tim On 6/3/15 7:26 AM, Rob Stradling wrote: > https://crt.sh > > Pronounced "search". :-) > > It's a web interface that lets you search for certs that have been > logged by the publicly known RFC6962 logs. > > Right now it's half a Monitor. It fetches all new entries soon after > they're added to the logs, but it doesn't (yet) verify STH signatures. > > No current plans to release source code. > > Feel free to mention this on the wiki page. > > On 30/07/14 22:13, Melinda Shore wrote: >> During the session last week I was a bit surprised by the number of >> people saying that they were doing implementations, and I think it >> might be useful to get a better handle on that. If nothing else, it >> helps quite a bit during the publication process if it's known >> that there are interoperable implementations and that we know a little >> bit about them. >> >> So, I'd be grateful if people who've are working on implementations >> and who can discuss them publicly could speak up, let us know the >> status and whether or not you'll be releasing source, and provide a >> pointer to a repo or other documentation if you're able. Also let >> me know whether or not you'd be willing to have your implementation >> mentioned on a wiki page listing implementations. >> >> Thanks again, >> >> Melinda > From nobody Wed Jun 3 10:58:55 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 26C701ACED5 for ; Wed, 3 Jun 2015 10:58:53 -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 j2QecPCxUNG2 for ; Wed, 3 Jun 2015 10:58:49 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::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 7CAC71ACEC3 for ; Wed, 3 Jun 2015 10:58:49 -0700 (PDT) Received: by pabqy3 with SMTP id qy3so11909627pab.3 for ; Wed, 03 Jun 2015 10:58:49 -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=Hxj9SYg74ko5Pt+mXOIevBOjoCyvF1v1XbdYTmnfLV4=; b=vVy+636D1Dagrgoy5uhHEwBY7/xhE4DcvqhVwqEoAMM9Qm4s0m8NEFSb5cccIzr7th FTHP1hibJeeV+lC9DKZ1XYMfCzqHOMXjYCkhjkrdcvr9rvPKMhKsvAKjomtfRbiwlR17 QwgtPr2/kGCPQLOFD/23qoB3QQsAbJxTVHyAx2MirAGcGC6B2EltJ6M5NRxPDL9iZ/r1 WxD+CKK39yBP31cFVKDgYNxhjQTDlNv3N1dTJDe+I6P1Mmx9B0jl1C2u/M3Q1oCQxCNr uvE85njK3DXXSHBVl3PCmhAngmeiC9x+FgPFmLDQmOZd3i/nn9yY1PeQ7hQCH0Rwvrbo 3ANA== X-Received: by 10.68.246.1 with SMTP id xs1mr24000282pbc.53.1433354329107; Wed, 03 Jun 2015 10:58:49 -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 y11sm1444371pdi.16.2015.06.03.10.58.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2015 10:58:48 -0700 (PDT) Message-ID: <556F4055.6040609@gmail.com> Date: Wed, 03 Jun 2015 09:58:45 -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: Rob Stradling , "trans@ietf.org" References: <53D9600C.6040805@gmail.com> <556F0EB1.1060400@comodo.com> In-Reply-To: <556F0EB1.1060400@comodo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Tracking implementations 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, 03 Jun 2015 17:58:53 -0000 Excellent - thanks! I've updated the wiki: http://trac.tools.ietf.org/wg/trans/trac/wiki If there are other implementations underway, please let us know. Melinda From nobody Wed Jun 3 11:55: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 84DE01AD376 for ; Wed, 3 Jun 2015 11:55:05 -0700 (PDT) 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 0u7YKqubx-67 for ; Wed, 3 Jun 2015 11:55:02 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3F61AD371 for ; Wed, 3 Jun 2015 11:55:01 -0700 (PDT) Received: (qmail 25581 invoked by uid 1004); 3 Jun 2015 18:54:59 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 03 Jun 2015 19:54:59 +0100 Received: (qmail 2451 invoked by uid 1000); 3 Jun 2015 18:54:59 -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; Wed, 03 Jun 2015 19:54:59 +0100 Message-ID: <556F4D83.8060205@comodo.com> Date: Wed, 03 Jun 2015 19:54:59 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul Wouters References: <53D9600C.6040805@gmail.com> <556F0EB1.1060400@comodo.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Tracking implementations 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, 03 Jun 2015 18:55:05 -0000 On 03/06/15 17:50, Paul Wouters wrote: > On Wed, 3 Jun 2015, Rob Stradling wrote: > >> https://crt.sh >> >> Pronounced "search". :-) >> >> It's a web interface that lets you search for certs that have been >> logged by the publicly known RFC6962 logs. > > Very cool! > > Paul Thanks Paul. :-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Jun 3 11:57: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 2CCD31B2850 for ; Wed, 3 Jun 2015 11:57:10 -0700 (PDT) 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 OmCt4-6F3Jbw for ; Wed, 3 Jun 2015 11:57:08 -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 921DC1AD37C for ; Wed, 3 Jun 2015 11:57:07 -0700 (PDT) Received: (qmail 16774 invoked by uid 1004); 3 Jun 2015 18:57:06 -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; Wed, 03 Jun 2015 19:57:06 +0100 Received: (qmail 3873 invoked by uid 1000); 3 Jun 2015 18:57:06 -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; Wed, 03 Jun 2015 19:57:06 +0100 Message-ID: <556F4E01.6030204@comodo.com> Date: Wed, 03 Jun 2015 19:57:05 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tim Wicinski References: <53D9600C.6040805@gmail.com> <556F0EB1.1060400@comodo.com> <556F3C0F.9020607@gmail.com> In-Reply-To: <556F3C0F.9020607@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] Tracking implementations 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, 03 Jun 2015 18:57:10 -0000 Thanks Tim. :-) On 03/06/15 18:40, Tim Wicinski wrote: > Thanks Rob. The security folks at my employer already found a domain > that was set up by some marketing folks that has a less than optimal > cert, and the domain appears to be in someone's personal account, and > they are no longer with the company. Of course the domain is active. > > sigh > > tim > > > On 6/3/15 7:26 AM, Rob Stradling wrote: >> https://crt.sh >> >> Pronounced "search". :-) >> >> It's a web interface that lets you search for certs that have been >> logged by the publicly known RFC6962 logs. >> >> Right now it's half a Monitor. It fetches all new entries soon after >> they're added to the logs, but it doesn't (yet) verify STH signatures. >> >> No current plans to release source code. >> >> Feel free to mention this on the wiki page. >> >> On 30/07/14 22:13, Melinda Shore wrote: >>> During the session last week I was a bit surprised by the number of >>> people saying that they were doing implementations, and I think it >>> might be useful to get a better handle on that. If nothing else, it >>> helps quite a bit during the publication process if it's known >>> that there are interoperable implementations and that we know a little >>> bit about them. >>> >>> So, I'd be grateful if people who've are working on implementations >>> and who can discuss them publicly could speak up, let us know the >>> status and whether or not you'll be releasing source, and provide a >>> pointer to a repo or other documentation if you're able. Also let >>> me know whether or not you'd be willing to have your implementation >>> mentioned on a wiki page listing implementations. >>> >>> Thanks again, >>> >>> Melinda >> > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Wed Jun 3 12:10:31 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 69FB91B29ED for ; Wed, 3 Jun 2015 12:10:28 -0700 (PDT) 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 TS2MrePcdIXT for ; Wed, 3 Jun 2015 12:10:27 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD71A1B29F2 for ; Wed, 3 Jun 2015 12:10:26 -0700 (PDT) Received: (qmail 26165 invoked by uid 1004); 3 Jun 2015 19:10:25 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 03 Jun 2015 20:10:25 +0100 Received: (qmail 26892 invoked by uid 1000); 3 Jun 2015 19:10:25 -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; Wed, 03 Jun 2015 20:10:25 +0100 Message-ID: <556F5121.8000902@comodo.com> Date: Wed, 03 Jun 2015 20:10:25 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Melinda Shore , "trans@ietf.org" References: <53D9600C.6040805@gmail.com> <556F0EB1.1060400@comodo.com> <556F4055.6040609@gmail.com> In-Reply-To: <556F4055.6040609@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Tracking implementations 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, 03 Jun 2015 19:10:28 -0000 On 03/06/15 18:58, Melinda Shore wrote: > Excellent - thanks! I've updated the wiki: > http://trac.tools.ietf.org/wg/trans/trac/wiki Thanks. > If there are other implementations underway, > please let us know. Chromium/Chrome really should get a mention, I think. OpenSSL-1.0.2 can pretty-print RFC6962 SCTs embedded in certs and OCSP responses. Incidentally, this is used by crt.sh (e.g. [1]) although I've adapted it slightly to also show the log name. There's also work in progress (well, it's on hold for now until 6962-bis is a bit more settled) to add a full API for handling SCTs to OpenSSL-next. [1] https://crt.sh/?id=7842948 Search for "Signed Certificate Timestamp" -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Jun 3 14:00:32 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 48F0D1B2D32; Wed, 3 Jun 2015 14:00:31 -0700 (PDT) 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 Fx3Sevq7FQWi; Wed, 3 Jun 2015 14:00:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9C11B2D2B; Wed, 3 Jun 2015 14:00:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> Date: Wed, 03 Jun 2015 14:00:30 -0700 Archived-At: Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 03 Jun 2015 21:00:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Threat Analysis for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-00.txt Pages : 18 Date : 2015-06-02 Abstract: This document describes a threat model for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates will be developed. The threat model covers both syntactic and semantic mis-issuance, using a taxonomy of threats starting with whether the mis-issuance was done by the CA maliciously or not; then whether or not the certificate was logged; and then whether the log(s) or monitor(s) are benign or malicious, whether the certificate subject is self-monitoring and whether a client is doing any checks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 3 14:22: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 C94AB1B2F9A for ; Wed, 3 Jun 2015 14:22:00 -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 SwlFFBS-lD29 for ; Wed, 3 Jun 2015 14:21:59 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (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 2AAF61AD34E for ; Wed, 3 Jun 2015 14:21:59 -0700 (PDT) Received: by pdbki1 with SMTP id ki1so15663565pdb.1 for ; Wed, 03 Jun 2015 14:21:58 -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 :references:in-reply-to:content-type:content-transfer-encoding; bh=8KS0DWk7xLGhURie6mtYL3Pwk1xfnWRkM2J5UoV2Qh8=; b=QVVmPjjVzmCQXGfVvVzzWoFbiwgIxXkie+n1FKeyQa5e9SFLSK6lbq65rQoZyoFfUE TFtVirfJa4nRezMkFmVScBtA+WbxyE5+AXuUWAT4JoAQj8S/m219QAiISPxln4/8J+pR PRSX78FRyyz7NBC4vuFzO2loT+HPIJSgwKiesJ2GqcxW98+e5vMDu6vc+3uCDJj+dElP gVyNNPsVm+jt4Mo8sq28fizwqvUd9rPsKfbs1F6UZavyHhTAkDl2bjMRIS4DgYKjAIWe /ltex0LpGF9BCCDdQyAMKo2IBR1Cct+A8yn81ckERG1PKbR/hE4JFhP94Ufo6lYXZDAe o1uA== X-Received: by 10.70.48.34 with SMTP id i2mr33857907pdn.125.1433366518798; Wed, 03 Jun 2015 14:21:58 -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 fe10sm1678334pdb.59.2015.06.03.14.21.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jun 2015 14:21:57 -0700 (PDT) Message-ID: <556F6FF4.2000300@gmail.com> Date: Wed, 03 Jun 2015 13:21:56 -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" References: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> In-Reply-To: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Stephen Kent Subject: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 03 Jun 2015 21:22:00 -0000 The initial draft of the threat analysis document is out. Please give it a careful read and post comments to the mailing list. Steve, if you could highlight issues that need particular attention, that can get working group discussion off to a strong start. Melinda -------- Forwarded Message -------- Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt Date: Wed, 03 Jun 2015 14:00:30 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: trans@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Threat Analysis for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-00.txt Pages : 18 Date : 2015-06-02 Abstract: This document describes a threat model for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates will be developed. The threat model covers both syntactic and semantic mis-issuance, using a taxonomy of threats starting with whether the mis-issuance was done by the CA maliciously or not; then whether or not the certificate was logged; and then whether the log(s) or monitor(s) are benign or malicious, whether the certificate subject is self-monitoring and whether a client is doing any checks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Wed Jun 3 16:44:16 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 4BE061A0387 for ; Wed, 3 Jun 2015 16:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z7cYQJ-vbNnZ for ; Wed, 3 Jun 2015 16:44:09 -0700 (PDT) Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A581A010D for ; Wed, 3 Jun 2015 16:44:08 -0700 (PDT) X-AuditID: a66201d2-f79e56d0000077f1-a6-556f91475098 Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by ecl1mtaoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 67.16.30705.7419F655; Wed, 3 Jun 2015 23:44:07 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1Z0IKM-0004JP-GC; Wed, 03 Jun 2015 19:44:06 -0400 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Wed, 3 Jun 2015 16:44:06 -0700 From: Rick Andrews To: Melinda Shore , "trans@ietf.org" Date: Wed, 3 Jun 2015 16:44:04 -0700 Thread-Topic: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt Thread-Index: AdCeQ1mVL45LXw8mSwq6ypRHVCkfJQAECg8w Message-ID: <544B0DD62A64C1448B2DA253C011414615AFCD53E6@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> <556F6FF4.2000300@gmail.com> In-Reply-To: <556F6FF4.2000300@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0039_01D09E1C.8059B520" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsXCZeB6Std9Yn6owbkJOhYbZzNatLXNYrFY +/giiwOzx9TzoR47Z91l91iy5CdTAHMUl01Kak5mWWqRvl0CV8aSH0sYC26mV2y+vYqpgfFb bBcjJ4eEgInE4+6jrBC2mMSFe+vZuhi5OIQE3jFKrJmxhx0kISTwilGi40gpRGIlo8ShWzfA OtgE9CS2PL4CViQi4CfRffkRM4jNLCAv8WzBcjCbRUBFYtbP3ywgtrBAgMSdbReBNnAA1QdK 3D6qD9FqJHGk+xzYSF6BKImm3stMEHsTJF6fnAIW5xTQlDj44x+YzQh06PdTa5ggVolL3Hoy nwniARGJhxdPs0HYohIvH8PUi0rcaV/PCHI/s0Avo8TNrecYIZYJSpyc+YRlAqPYLCSzZiGr m4WkbhbQ3cxAP7dtZJwF9eb2t3OYIWxriRm/DrJB2IoSU7ofskPYphKvj35kXMDIsYpRJjU5 xzC3JDG/tKQgtcLASK+4MjcRGLvJesn5uZsYgfG7LInx0g7G+4d1DzEKcDAq8fAKteeHCrEm lgFVHmJUARr3aMPqC4xSLHn5ealKIryvjYDSvCmJlVWpRfnxRaU5qcWHGKU5WJTEeSf254QK CaQnlqRmp6YWpBbBZJk4OKUaGPkFJsV8FmrerrrwgOfXa3s5tz0piEuI/rGir3Nnhr7KvZyd BTG16l3T+bbezA2apHm10sdjpZPbld6+u+uqLjV/kWZT55RxXGpwk9XGt1ysv9BMUnrT1PMH Wp+cy5B8NzM8qeJyTGbQK98Xl2JbdN0zNm2eyW1YrLwhz9t5R/2EwImHl0ntUmIpzkg01GIu Kk4EAL5VdQHnAgAA Archived-At: Cc: Stephen Kent Subject: Re: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 03 Jun 2015 23:44:15 -0000 ------=_NextPart_000_0039_01D09E1C.8059B520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stephen, 2.2.2. Certificate not logged Because the CA is presumed malicious, it may choose to not submit a (pre-)certificate to a log. This means there is no SCT for the certificate. ... 2.2.2.1. Self-monitoring Subject A Subject performing self-monitoring will be able to detect the lack of SCT and notify the CA about the bogus certificate and request revocation. [Rick] Since the certificate is not logged, how will the self-monitoring Subject detect the lack of SCT? The CA could mis-issue the cert but not send it to the Subject. You need a Careful Browser detecting the lack of SCTs and notifying the Subject for the Subject to be aware of this case. Likewise, I think this sentence in 2.2.2.2 is incorrect: "If, when an SCT is not provided, clients do not reject certificates and do not notify the CA or the Subject, this form of mis-issuance will succeed unless the Subject is self-monitoring (See 2.2.2.1 and Note 3.)" 3.1. Non-malicious Web PKI CA context This section analyzes the scenario in which the CA has no intent to issue a syntactically incorrect certificate. Throughout the remainder of this document we refer to a syntactically incorrect certificate as ''erroneous''. [Rick] In the sections below, you also refer to certificates as "malformed". I think "erroneous" could/should be used in those cases instead of "malformed". 3.1.1.1. Benign log ... . If a (pre-)certificate is submitted by a third party, that party might contact the Subject or the issuing CA, but because the party is not the Subject of the certificate it is not clear how the CA will respond. [Rick] I think you should remove "(pre-)", because pre-certificates cannot be submitted by third parties, only by the CA. 3.1.2. Certificate not logged If a CA does not submit a certificate to a log, there can be no syntactic checking by the log. Detection of syntactic errors will depend on Subjects or Monitors performing the requisite checks. [Rick] Detection could also be done by Careful Browsers (though I agree with your caveat in 3.1.1.4). If you think that Careful Browsers should be added to this Section, then they should also be added to 3.2.1.3. But I'm guessing you intentionally didn't add Careful Browsers because to date, any checking they have performed generally did not result in notification to Subjects or Issuing CAs. So I'm ok if you leave them out of both Sections. -Rick -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Wednesday, June 03, 2015 2:22 PM To: trans@ietf.org Cc: Stephen Kent Subject: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt The initial draft of the threat analysis document is out. Please give it a careful read and post comments to the mailing list. Steve, if you could highlight issues that need particular attention, that can get working group discussion off to a strong start. Melinda -------- Forwarded Message -------- Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt Date: Wed, 03 Jun 2015 14:00:30 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: trans@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Threat Analysis for Certificate Transparency Author : Stephen Kent Filename : draft-ietf-trans-threat-analysis-00.txt Pages : 18 Date : 2015-06-02 Abstract: This document describes a threat model for the Web PKI context in which security mechanisms to detect mis-issuance of web site certificates will be developed. The threat model covers both syntactic and semantic mis-issuance, using a taxonomy of threats starting with whether the mis-issuance was done by the CA maliciously or not; then whether or not the certificate was logged; and then whether the log(s) or monitor(s) are benign or malicious, whether the certificate subject is self-monitoring and whether a client is doing any checks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 ------=_NextPart_000_0039_01D09E1C.8059B520 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRhzCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBkwwggU0oAMCAQICEBw3Lcu5cD5rtz7z+tELQgYwDQYJ KoZIhvcNAQELBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTE1MDEwNjAw MDAwMFoXDTI1MDEwNTIzNTk1OVowgbAxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExKjAoBgNVBAMTIVN5bWFu dGVjIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALbX9Fd7nt9wUT7ISGRoQMGJbj8EkkrtHHQnINo4z1KTPLnRWscXLT5oTmFpC7JuaHn0AnYK +NJutht+e0vGtU/avfhJDgLP7K1qZ+vOBHm9hMzzmiME1s9CP0nOlifrJK5h2TS5Znq8g4kfGJTA asB5zmfjNVCJomx17jhf8fuZrvMXSBsWDxl6NGohZloUgxFAwrCe0NuDzt8E8jJCgw5lewsqjlll eBvJbCxOXhcuMvjK6/ilNC1WjkaIlTWXyaraGQAMPm2nsZED4+aBNRMX855Amtk5zAoKh1oeIiN7 2YaPVmiIIOeGKqY0B3RYTY7cmxgU4RA5xgKA3LeMIP0CAwEAAaOCAkQwggJAMBIGA1UdEwEB/wQI MAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8v d3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29t L3JwYTAOBgNVHQ8BAf8EBAMCAQYwNwYIKwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8v cGtpLW9jc3Auc3ltYXV0aC5jb20wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL2NybC53cy5zeW1h bnRlYy5jb20vcGNhMi1nMy5jcmwwKAYDVR0RBCEwH6QdMBsxGTAXBgNVBAMTEFN5bWFudGVjUEtJ LTItMjMwHQYDVR0OBBYEFKQzr7DDRoer5XhJsrTiRp/qCfwVMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MA0GCSqG SIb3DQEBCwUAA4IBAQChthp96rPOdkvEEfo4yk4Q8auHf5LqUJUlwDdoAvuCrYDLM9TMQzCwRWf7 IpiGPMAVnddFj2ohiX3bYd0tkaqyjfDJDtZQK9YgN5GD0RTO2gHS0PHOOyJBSDJ5G0um4NLofhkB h9RqEE3mBF68RGe4Te7Z5ST+pvgqGzC8v/2xDEZcClXhch8gNU7muFl18YdX9gWV54BcTj0lo9E9 9/2HVCPB5QAzFhHqgHjDnETpw5S3JlpKTEMXyqaWd/5+Vo+ID+jd51HS+BS1u2Dguv+FvgINTVrr IO1ymEh5L3XM4gQrCgD7yajPRf/BIjyF/xzL/ONUoxd8e1gR/E1N98oyMIIHFjCCBf6gAwIBAgIQ eoZCXnmupqYl/udPRmNrEjANBgkqhkiG9w0BAQsFADCBsDELMAkGA1UEBhMCVVMxHTAbBgNVBAoT FFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTUw MwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEqMCgG A1UEAxMhU3ltYW50ZWMgQ2xhc3MgMiBFbXBsb3llZSBDQSAtIEczMB4XDTE1MDUwNTAwMDAwMFoX DTE2MDUwNDIzNTk1OVowWDEdMBsGA1UECgwUU3ltYW50ZWMgQ29ycG9yYXRpb24xIDAeBgNVBAsM F1N5bWFudGVjIEVtcGxveWVlIEVtYWlsMRUwEwYDVQQDDAxSaWNrIEFuZHJld3MwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDWeX7BpH/VSe/Uh1ySecwUqQx99drCpfBTqnDch18Ufr1i e6ITpTm/aP6Wouxm+lDQqZqh0k6dXl8iL6ND7o8OWVaRT3SC0YwGOtVPH5ukjUxo18dfhPFQxd3B 5QmfG8U8n2HUSyX90aomHk/2weJBZs5QIEZtrH0iLsXiK0W5jMdrpnZf4UPHqImpWPeMoh5Vc2h7 ajB/78N+R68ipLEtM468APn5h8oSp7VUZ0T2JoT5YyQ0qEOqAYmbuaPNAuUZu8SbjFEE7Y9/5apY g+XF2dgsFBEMXLfPRVlTaJ+pyyV/lHl5zswhUJZ/iwTI0DXYX842e8xcg9+i2ImJUwcLAgMBAAGj ggOBMIIDfTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFoDAWBgNVHSUBAf8EDDAKBggrBgEF BQcDBDAdBgNVHQ4EFgQUVoVKaC1xEPB9EWKq3dWrwskIufkwJAYDVR0RBB0wG4EZcmlja19hbmRy ZXdzQHN5bWFudGVjLmNvbTAfBgNVHSMEGDAWgBSkM6+ww0aHq+V4SbK04kaf6gn8FTCCAWQGCCsG AQUFBwEBBIIBVjCCAVIwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTCC ASUGCCsGAQUFBzAChoIBF2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24uY29tL0NOJTIwJTNEJTIw U3ltYW50ZWMlMjBDbGFzcyUyMDIlMjBFbXBsb3llZSUyMENBJTIwLSUyMEczJTJDJTIwT1UlMjAl M0QlMjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIl MjBDQSUyQyUyME9VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkMlMjBPJTIw JTNEJTIwU3ltYW50ZWMlMjBDb3Jwb3JhdGlvbiUyQyUyMEMlMjAlM0QlMjBVUz9jQUNlcnRpZmlj YXRlO2JpbmFyeTBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9j YV8yYzc5ZDVmMGM0NTZlMGUzZTJmYjNlMjM2OTAzZGExNS9MYXRlc3RDUkwuY3JsMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkP BDUwMzAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAr BgpghkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICAQGdpPp0FgUxNjc0ODA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEB CwUAA4IBAQBbMHjFqlBy9AoLMyWwc0oaHgajD9EciJL0qTz0npcrHuEFgAkwyE+D6my83+V03LLg ry6iZcA7E2UJv4g5lGIWmbxzs5ICry1R366twCctdLk0fDcthVUkerrmUpS70uQXKPq1MChHz+rh if5GZsW+BU2EQSUTf33eO5Wdm44tFf6Wtp5iyWEHOXMiqEDQau+5f6ZravcTEADjNNSZxqB1AyTo tznhaDLLjXwsqLWfLJcH9slt0miLI9F/mCK0x3l8GlCr0d2lOSp8G17TpgAyG7+VWrTZQf26oVC5 i+83V6YDoqrRdQuFThnTwpGbcGNg2O1Jhm+IVBSC6FKhCEw1MYIEsDCCBKwCAQEwgcUwgbAxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExKjAoBgNVBAMTIVN5bWFudGVjIENsYXNzIDIgRW1wbG95ZWUgQ0EgLSBH MwIQeoZCXnmupqYl/udPRmNrEjAJBgUrDgMCGgUAoIICvzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MDMyMzQ0MDRaMCMGCSqGSIb3DQEJBDEWBBSLs4tpulpn mRXQXaM+8W8cyvYCgDCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQME ARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUD BAICMAsGCWCGSAFlAwQCATCB1gYJKwYBBAGCNxAEMYHIMIHFMIGwMQswCQYDVQQGEwJVUzEdMBsG A1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB MSowKAYDVQQDEyFTeW1hbnRlYyBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCEHqGQl55rqamJf7n T0ZjaxIwgdgGCyqGSIb3DQEJEAILMYHIoIHFMIGwMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNV BAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMSowKAYDVQQD EyFTeW1hbnRlYyBDbGFzcyAyIEVtcGxveWVlIENBIC0gRzMCEHqGQl55rqamJf7nT0ZjaxIwDQYJ KoZIhvcNAQEBBQAEggEACxFKYMTY1Xjxhx1y7GKLRx7mEi6MsEqpduEoRjpt+PvHrmiU0h7mRnEo xj7dBBqZd+FmP1LYyR+MQ9mAJd6xXkp95GCR2eJJRnvLkSx5WQS3iM89LOvdYjLXfZVfa1iFvF2Z sTAtoIMl68bHVC6dX8MLjK60zDEM68tSbF8Q4Qlp1vAPskcLdcnqey/GSZCKbvUrjxBzXqQli62y nDvbjOi3svgTcu2ZQ0iK5Gcj4lb1YHoH7Oxs7T+SGQOwVZW3d8qzBdOSftTrR0XYQHXgttcH9b7r 6ST8IRJBgY+xqs/6noXbWGw3TP3O/2msblBOYBDsCzzBI8BUH++fXjxexgAAAAAAAA== ------=_NextPart_000_0039_01D09E1C.8059B520-- From nobody Wed Jun 3 18:59:23 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 A80EC1B315E for ; Wed, 3 Jun 2015 18:59:22 -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_05=-0.5, 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 80eLbP2jElCg for ; Wed, 3 Jun 2015 18:59:20 -0700 (PDT) Received: from mail.hezmatt.org (sasquatch.hezmatt.org [70.85.129.92]) by ietfa.amsl.com (Postfix) with ESMTP id B41181B317C for ; Wed, 3 Jun 2015 18:59:19 -0700 (PDT) Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id 6C8FC8ADB3 for ; Thu, 4 Jun 2015 11:59:18 +1000 (AEST) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 34D1E9FC8D; Thu, 4 Jun 2015 11:59:18 +1000 (AEST) Date: Thu, 4 Jun 2015 11:59:18 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20150604015918.GH724@hezmatt.org> References: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 04 Jun 2015 01:59:22 -0000 On Wed, Jun 03, 2015 at 02:00:30PM -0700, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Public Notary Transparency Working Group of the IETF. > > Title : Threat Analysis for Certificate Transparency A good enumeration of the threat space. My thoughts: > 2.1.1.2. Malicious or conspiring log > > In this case, the bogus (pre-)certificate has been submitted to one > or more logs that are either simply malicious or are conspiring with > the attacker. It is assumed that the logs issue SCTs (in an attempt > to fool browsers and/or Monitors). In this context, a log probably > will suppress a bogus certificate log entry. (This case encompasses > the scenario in which a log creates an entry for the certificate but > reports it selectively.) Do you have any thoughts on what a "simply malicious" log might look like, behaviourally speaking? Is there a way to differentiate, from the outside, whether a log is "simply malicious" or "conspiring"? Do we even care that there's a difference? I wonder if it would be clearer to stick to observed behaviour, rather than motivation? So, rather than talking about a "simply malicious" or "conspiring" log, say instead something like, "a log which does not faithfully report all submitted entries, and/or presents different views of the log to different observers". > Note that a malicious log also could create and report entries for > bogus certificates that have not been issued by the indicated CA. > These could cause the Monitor to report non-existent semantic > problems to the Subject who would in turn report them to the > (apparently) issuing CA. This might cause the CA to do needless > investigative work or perhaps incorrectly revoke and re-issue the > Subject's certificate. How is a malicious log going to be able to report bogus certificates? The closest a malicious log could come is to whack together a cert chain that has the same issuer names, etc, but that won't validate to the CA's *actual* root certificate. Is the point of this section, then, to indicate that reporters of bogus certificates (or the CAs that receive them) should validate the cert chain before taking action? >From Note 5: > Absent a ''gossip'' mechanism that enables Monitors to verify that > data from logs are reported in a consistent fashion, CT cannot claim > to provide protection against logs that are malicious or may > conspire with, or are victims of, attackers effecting certificate > mis-issuance. Developing such a mechanism is not easy. The mechanism > SHOULD protect the privacy of users (with respect to which web sites > they visit). It needs to scale to accommodate a potentially large > number of self-monitoring Subjects and a vast number of browsers (if > browsers are part of the mechanism). Even when a gossip mechanism is > defined, it will be necessary to describe how the CT system will > deal with a mis-behaving or compromised log. For example, will there > be a mechanism to alert all TLS clients to reject SCTs issued by > such a log? Absent a description of a mitigation strategy to deal > with mis-behaving or compromised logs, CT cannot ensure detection of > mis-issuance in a wide range of scenarios. This doesn't seem so much an issue of threat model, as it is a commentary on the current state of CT, and I don't think it belongs in this document. - Matt From nobody Thu Jun 4 04:14:42 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 CB3A01A0161 for ; Thu, 4 Jun 2015 04:14:40 -0700 (PDT) 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 9M76y5uXoJYA for ; Thu, 4 Jun 2015 04:14:39 -0700 (PDT) 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 D8A381A017A for ; Thu, 4 Jun 2015 04:14:36 -0700 (PDT) Received: from localhost ([::1]:47985 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z0T6Z-0003e4-KZ; Thu, 04 Jun 2015 04:14:35 -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: rob.stradling@comodo.com X-Trac-Project: trans Date: Thu, 04 Jun 2015 11:14:35 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/85 Message-ID: <064.77ac23aa5bfca1f37014dcdb7c53be83@tools.ietf.org> X-Trac-Ticket-ID: 85 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: Cc: trans@ietf.org Subject: [Trans] [trans] #85 (rfc6962-bis): Precertificate CMS structures MUST be DER 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, 04 Jun 2015 11:14:41 -0000 #85: Precertificate CMS structures MUST be DER Ben wrote: "Just chatting with Adam Langley, and he points out that CMS allows BER. We should subset it to DER only for CT." I agree that we definitely need to specify that the TBSCertificate included in the CMS structure MUST be DER. Whilst we could (I think) in theory permit BER for the other parts of the CMS structure, it would be simpler to mandate DER throughout. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: new Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: trans From nobody Thu Jun 4 04:15:40 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 41DD61A017E for ; Thu, 4 Jun 2015 04:15:38 -0700 (PDT) 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 Vo8edJa49xTM for ; Thu, 4 Jun 2015 04:15:36 -0700 (PDT) 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 DF1791A017A for ; Thu, 4 Jun 2015 04:15:36 -0700 (PDT) Received: from localhost ([::1]:48047 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z0T7Y-000442-Is; Thu, 04 Jun 2015 04:15:36 -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: rob.stradling@comodo.com X-Trac-Project: trans Date: Thu, 04 Jun 2015 11:15:36 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/85#comment:1 Message-ID: <079.05ab0964ddab9de8df81a77810eb476c@tools.ietf.org> References: <064.77ac23aa5bfca1f37014dcdb7c53be83@tools.ietf.org> X-Trac-Ticket-ID: 85 In-Reply-To: <064.77ac23aa5bfca1f37014dcdb7c53be83@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: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #85 (rfc6962-bis): Precertificate CMS structures MUST be DER 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, 04 Jun 2015 11:15:38 -0000 #85: Precertificate CMS structures MUST be DER Changes (by rob.stradling@comodo.com): * status: new => assigned -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Thu Jun 4 09:09:40 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 AE55E1A8AC9 for ; Thu, 4 Jun 2015 09:09:38 -0700 (PDT) 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 UzRX4gQ60crM for ; Thu, 4 Jun 2015 09:09:37 -0700 (PDT) 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 BE9C51A8FD5 for ; Thu, 4 Jun 2015 09:09:36 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:37452 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z0Xi3-0000uy-Ge for trans@ietf.org; Thu, 04 Jun 2015 12:09:35 -0400 Message-ID: <5570783F.8010009@bbn.com> Date: Thu, 04 Jun 2015 12:09:35 -0400 From: Stephen Kent 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: <064.77ac23aa5bfca1f37014dcdb7c53be83@tools.ietf.org> In-Reply-To: <064.77ac23aa5bfca1f37014dcdb7c53be83@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #85 (rfc6962-bis): Precertificate CMS structures MUST be DER 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, 04 Jun 2015 16:09:38 -0000 I concur with Rob's suggestion. Stevez > #85: Precertificate CMS structures MUST be DER > > Ben wrote: > "Just chatting with Adam Langley, and he points out that CMS allows > BER. We should subset it to DER only for CT." > > I agree that we definitely need to specify that the TBSCertificate > included in the CMS structure MUST be DER. > > Whilst we could (I think) in theory permit BER for the other parts of the > CMS structure, it would be simpler to mandate DER throughout. > From nobody Thu Jun 4 09:10:47 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 790BB1A8ABD for ; Thu, 4 Jun 2015 09:10:45 -0700 (PDT) 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 3BzEXsw9Ww-S for ; Thu, 4 Jun 2015 09:10:44 -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 245761A1B28 for ; Thu, 4 Jun 2015 09:10:44 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:57280 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z0Xj4-000DYI-LX; Thu, 04 Jun 2015 12:10:38 -0400 Message-ID: <5570787E.8070206@bbn.com> Date: Thu, 04 Jun 2015 12:10:38 -0400 From: Stephen Kent 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: Rick Andrews , "trans@ietf.org" References: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> <556F6FF4.2000300@gmail.com> <544B0DD62A64C1448B2DA253C011414615AFCD53E6@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: <544B0DD62A64C1448B2DA253C011414615AFCD53E6@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 04 Jun 2015 16:10:45 -0000 Rick, Thanks for reading the doc and providing comments. > Stephen, > > 2.2.2. Certificate not logged > > Because the CA is presumed malicious, it may choose to not submit a > (pre-)certificate to a log. This means there is no SCT for the > certificate. > ... > 2.2.2.1. Self-monitoring Subject > > A Subject performing self-monitoring will be able to detect the lack > of SCT and notify the CA about the bogus certificate and request > revocation. > > [Rick] Since the certificate is not logged, how will the self-monitoring > Subject detect the lack of SCT? The CA could mis-issue the cert but not send > it to the Subject. You need a Careful Browser detecting the lack of SCTs and > notifying the Subject for the Subject to be aware of this case. Likewise, I > think this sentence in 2.2.2.2 is incorrect: "If, when an SCT is not > provided, clients do not reject certificates and do not notify the CA or the > Subject, this form of mis-issuance will succeed unless the Subject is > self-monitoring (See 2.2.2.1 and Note 3.)" You're right. A self-monitoring Subject can detect a cert issued to it by lacking an SCT, and complain to the CA, even if the cert is not logged. (The Subject received the cert from the CA, so it has a copy and thus can detect the absence of an SCT). But, a bogus cert would not be delivered to the (legitimate) Subject, and thus the text above is wrong. Sorry 'bout that. > 3.1. Non-malicious Web PKI CA context > > This section analyzes the scenario in which the CA has no intent to > issue a syntactically incorrect certificate. Throughout the > remainder of this document we refer to a syntactically incorrect > certificate as ''erroneous''. > [Rick] In the sections below, you also refer to certificates as "malformed". > I think "erroneous" could/should be used in those cases instead of > "malformed". Good catch. We'll make that change. > 3.1.1.1. Benign log > > ... > . If a (pre-)certificate is submitted by a third party, that party > might contact the Subject or the issuing CA, but because the > party is not the Subject of the certificate it is not clear how > the CA will respond. > [Rick] I think you should remove "(pre-)", because pre-certificates cannot > be submitted by third parties, only by the CA. OK, we'll remove "(pre-)". > 3.1.2. Certificate not logged > > If a CA does not submit a certificate to a log, there can be no > syntactic checking by the log. Detection of syntactic errors will > depend on Subjects or Monitors performing the requisite checks. > [Rick] Detection could also be done by Careful Browsers (though I agree with > your caveat in 3.1.1.4). If you think that Careful Browsers should be added > to this Section, then they should also be added to 3.2.1.3. But I'm guessing > you intentionally didn't add Careful Browsers because to date, any checking > they have performed generally did not result in notification to Subjects or > Issuing CAs. So I'm ok if you leave them out of both Sections. Your interpretation is right, but I should probably include more explicit text here. Steve From nobody Thu Jun 4 09:13:51 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 4D0261A9005 for ; Thu, 4 Jun 2015 09:13:50 -0700 (PDT) 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 b8INzy-CDcv6 for ; Thu, 4 Jun 2015 09:13:48 -0700 (PDT) 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 B5FCC1A8FD6 for ; Thu, 4 Jun 2015 09:13:48 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:37477 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z0Xm7-00011f-NT for trans@ietf.org; Thu, 04 Jun 2015 12:13:47 -0400 Message-ID: <5570793B.2070306@bbn.com> Date: Thu, 04 Jun 2015 12:13:47 -0400 From: Stephen Kent 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: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> <20150604015918.GH724@hezmatt.org> In-Reply-To: <20150604015918.GH724@hezmatt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 04 Jun 2015 16:13:50 -0000 Matt, Thanks for the review and comments. > >> 2.1.1.2. Malicious or conspiring log >> >> In this case, the bogus (pre-)certificate has been submitted to one >> or more logs that are either simply malicious or are conspiring with >> the attacker. It is assumed that the logs issue SCTs (in an attempt >> to fool browsers and/or Monitors). In this context, a log probably >> will suppress a bogus certificate log entry. (This case encompasses >> the scenario in which a log creates an entry for the certificate but >> reports it selectively.) > Do you have any thoughts on what a "simply malicious" log might look like, > behaviourally speaking? Is there a way to differentiate, from the outside, > whether a log is "simply malicious" or "conspiring"? Do we even care that > there's a difference? probably not. we'll avoid making the distinction in the next rev. > I wonder if it would be clearer to stick to observed behaviour, rather than > motivation? So, rather than talking about a "simply malicious" or > "conspiring" log, say instead something like, "a log which does not > faithfully report all submitted entries, and/or presents different views of > the log to different observers". the text above seems like a good way to characterize bad log behavior. we will still include comments about motivation (that's a common aspect of a threat model), but I agree that externally observed behavior is the best way to characterize this. >> Note that a malicious log also could create and report entries for >> bogus certificates that have not been issued by the indicated CA. >> These could cause the Monitor to report non-existent semantic >> problems to the Subject who would in turn report them to the >> (apparently) issuing CA. This might cause the CA to do needless >> investigative work or perhaps incorrectly revoke and re-issue the >> Subject's certificate. > How is a malicious log going to be able to report bogus certificates? The > closest a malicious log could come is to whack together a cert chain that > has the same issuer names, etc, but that won't validate to the CA's *actual* > root certificate. Is the point of this section, then, to indicate that > reporters of bogus certificates (or the CAs that receive them) should > validate the cert chain before taking action? good point. There has been some ambiguity about whether every log will always verify complete cert chains to one of the roots it accepts, in part of the question of what level of cert path processing one can expect of a log. If we're clear that (good) logs will do this, always, then creating a bogus log entry for a cert will mark a log as misbehaving. In that case, checking the cert chain for a log entry will detect such misbehavior. We'll add text to this end. Thanks. > >From Note 5: > >> Absent a ''gossip'' mechanism that enables Monitors to verify that >> data from logs are reported in a consistent fashion, CT cannot claim >> to provide protection against logs that are malicious or may >> conspire with, or are victims of, attackers effecting certificate >> mis-issuance. Developing such a mechanism is not easy. The mechanism >> SHOULD protect the privacy of users (with respect to which web sites >> they visit). It needs to scale to accommodate a potentially large >> number of self-monitoring Subjects and a vast number of browsers (if >> browsers are part of the mechanism). Even when a gossip mechanism is >> defined, it will be necessary to describe how the CT system will >> deal with a mis-behaving or compromised log. For example, will there >> be a mechanism to alert all TLS clients to reject SCTs issued by >> such a log? Absent a description of a mitigation strategy to deal >> with mis-behaving or compromised logs, CT cannot ensure detection of >> mis-issuance in a wide range of scenarios. > This doesn't seem so much an issue of threat model, as it is a commentary on > the current state of CT, and I don't think it belongs in this document. I agree that this note is not in the same style as most of the rest of the analysis. However, I am concerned that we don't have agreement on how a gossip mechanism can work, while meeting legitimate privacy concerns and the larger goals ascribed to it. So I think it's appropriate to retain this note for now, as a reminder of what needs to be addressed as part of the overall CT architecture. I have analogous comments, elsewhere in the doc, that mention the issue of the role of browsers in CT and the problem of incremental deployment. The same arguments probably apply to those comments. Steve From nobody Mon Jun 8 07:08:36 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 A67591A8889 for ; Mon, 8 Jun 2015 07:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 hbJUQGSbt8nN for ; Mon, 8 Jun 2015 07:08:29 -0700 (PDT) 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 819C61A88A4 for ; Mon, 8 Jun 2015 07:07:53 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:56808 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z1xiR-000L1i-Vu for trans@ietf.org; Mon, 08 Jun 2015 10:07:52 -0400 Message-ID: <5575A1B7.8030707@bbn.com> Date: Mon, 08 Jun 2015 10:07:51 -0400 From: Stephen Kent 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: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> <556F6FF4.2000300@gmail.com> In-Reply-To: <556F6FF4.2000300@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 08 Jun 2015 14:08:35 -0000 Melinda, > The initial draft of the threat analysis document is out. > Please give it a careful read and post comments to the mailing > list. > > Steve, if you could highlight issues that need particular > attention, that can get working group discussion off to a > strong start. > > Melinda the comments I received from Rob and Matt represent the sort of feedback I'm looking for, e.g., terminology and definitions, specific cases that may be erroneously stated, etc. We'll reissue the doc with edits based on feedback in another week or so. I hope to include an ASCII art diagram of the system, derived from DKG's nice slides from IETF 92. Steve From nobody Mon Jun 8 07:11:57 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 A5C4C1A88B0 for ; Mon, 8 Jun 2015 07:11:56 -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 JkkFjvyjGUnM for ; Mon, 8 Jun 2015 07:11:52 -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 6E2D81A88AD for ; Mon, 8 Jun 2015 07:11:52 -0700 (PDT) Received: (qmail 12517 invoked by uid 1004); 8 Jun 2015 14:11:50 -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; Mon, 08 Jun 2015 15:11:50 +0100 Received: (qmail 12303 invoked by uid 1000); 8 Jun 2015 14:11:50 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 08 Jun 2015 15:11:50 +0100 Message-ID: <5575A2A6.3040007@comodo.com> Date: Mon, 08 Jun 2015 15:11:50 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , "trans@ietf.org" References: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> <556F6FF4.2000300@gmail.com> <5575A1B7.8030707@bbn.com> In-Reply-To: <5575A1B7.8030707@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 08 Jun 2015 14:11:56 -0000 On 08/06/15 15:07, Stephen Kent wrote: > Melinda, >> The initial draft of the threat analysis document is out. >> Please give it a careful read and post comments to the mailing >> list. >> >> Steve, if you could highlight issues that need particular >> attention, that can get working group discussion off to a >> strong start. >> >> Melinda > > the comments I received from Rob s/Rob/Rick/ > and Matt represent the sort of feedback I'm > looking for, e.g., terminology and definitions, specific cases that may > be erroneously stated, etc. > > We'll reissue the doc with edits based on feedback in another week or > so. I hope > to include an ASCII art diagram of the system, derived from DKG's nice > slides > from IETF 92. > > Steve -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Jun 8 08:33:25 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 DF39A1B2F40 for ; Mon, 8 Jun 2015 08:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 rRRC1OLD0_2Y for ; Mon, 8 Jun 2015 08:33:22 -0700 (PDT) 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 B56CF1B2EEF for ; Mon, 8 Jun 2015 08:33:22 -0700 (PDT) Received: from localhost ([::1]:43450 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z1z38-0006Mg-Qc; Mon, 08 Jun 2015 08:33:18 -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: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 08 Jun 2015 15:33:18 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/79#comment:4 Message-ID: <079.491c4317c846cd9367360691f0058d44@tools.ietf.org> References: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signature must be over something other than just the TBSCertificate 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, 08 Jun 2015 15:33:24 -0000 #79: Precertificate signature must be over something other than just the TBSCertificate Comment (by benl@google.com): I don't think any action is required. The I-D already says: "A precertificate is a CMS signed-data object that contains a TBSCertificate in its SignedData.encapContentInfo.eContent field, identified by the OID in the SignedData.encapContentInfo.eContentType field." In other words: option 2 is what the I-D already propose. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Jun 8 10:25:42 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 68CCA1AC3EC for ; Mon, 8 Jun 2015 10:25:40 -0700 (PDT) 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=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 SbeF6EmOTbVT for ; Mon, 8 Jun 2015 10:25:39 -0700 (PDT) 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 6CE311AC3E4 for ; Mon, 8 Jun 2015 10:25:39 -0700 (PDT) Received: from localhost ([::1]:48957 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z20nn-0005xv-RQ; Mon, 08 Jun 2015 10:25:35 -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, benl@google.com X-Trac-Project: trans Date: Mon, 08 Jun 2015 17:25:34 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/41#comment:1 Message-ID: <067.011bdb4aec1d183e43f52b67dfdd037a@tools.ietf.org> References: <052.2ededd6e74f7a9abad41fa0d14b8ee3f@tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <052.2ededd6e74f7a9abad41fa0d14b8ee3f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@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: <20150608172539.6CE311AC3E4@ietfa.amsl.com> Resent-Date: Mon, 8 Jun 2015 10:25:39 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #41 (rfc6962-bis): missing threat model and security analysis 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, 08 Jun 2015 17:25:40 -0000 #41: missing threat model and security analysis Changes (by benl@google.com): * milestone: => review Comment: This is presumably resolved by the new threat model I-D. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jun 8 10:53: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 1BEBF1AC3E9 for ; Mon, 8 Jun 2015 10:53:53 -0700 (PDT) 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=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 WxADaNBXyUYS for ; Mon, 8 Jun 2015 10:53:52 -0700 (PDT) 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 02F8C1A9125 for ; Mon, 8 Jun 2015 10:53:51 -0700 (PDT) Received: from localhost ([::1]:50144 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z21F9-0005Vp-Ci; Mon, 08 Jun 2015 10:53: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, eranm@google.com, benl@google.com X-Trac-Project: trans Date: Mon, 08 Jun 2015 17:53:51 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/55#comment:2 Message-ID: <071.952340865fa2c9b67595e4bc4683b6c1@tools.ietf.org> References: <056.2fc4b44b6a5b5ab72302815f8c9d80c1@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <056.2fc4b44b6a5b5ab72302815f8c9d80c1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@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: <20150608175352.02F8C1A9125@ietfa.amsl.com> Resent-Date: Mon, 8 Jun 2015 10:53:51 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks 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, 08 Jun 2015 17:53:53 -0000 #55: Security Considerations: Describe the implications of clients *not* doing certain optional checks Changes (by benl@google.com): * milestone: => review Comment: I presume this should become part of the threat analysis I-D. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jun 8 10:59:35 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 86B821AC3FD for ; Mon, 8 Jun 2015 10:59:33 -0700 (PDT) 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=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 6SZ-CNImOIMQ for ; Mon, 8 Jun 2015 10:59:32 -0700 (PDT) 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 B5E301AC3FE for ; Mon, 8 Jun 2015 10:59:32 -0700 (PDT) Received: from localhost ([::1]:50374 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z21Kc-0006rv-T4; Mon, 08 Jun 2015 10:59:30 -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, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 08 Jun 2015 17:59:30 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/41#comment:2 Message-ID: <067.cfba1675506a662d001f8c04c4269af6@tools.ietf.org> References: <052.2ededd6e74f7a9abad41fa0d14b8ee3f@tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <052.2ededd6e74f7a9abad41fa0d14b8ee3f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, melinda.shore@gmail.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: <20150608175932.B5E301AC3FE@ietfa.amsl.com> Resent-Date: Mon, 8 Jun 2015 10:59:32 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #41 (rfc6962-bis): missing threat model and security analysis 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, 08 Jun 2015 17:59:33 -0000 #41: missing threat model and security analysis Comment (by melinda.shore@gmail.com): The working group has adopted a threat analysis draft. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jun 8 10:59:55 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 5579A1AC402 for ; Mon, 8 Jun 2015 10:59:51 -0700 (PDT) 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=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 HdNqkyfjYyLy for ; Mon, 8 Jun 2015 10:59:45 -0700 (PDT) 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 B7B601AC3FD for ; Mon, 8 Jun 2015 10:59:45 -0700 (PDT) Received: from localhost ([::1]:50382 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z21Kq-0006tu-HO; Mon, 08 Jun 2015 10:59:44 -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, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 08 Jun 2015 17:59:44 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/41#comment:3 Message-ID: <067.1fb990d7be5e56855fee7a4eac4bdd2f@tools.ietf.org> References: <052.2ededd6e74f7a9abad41fa0d14b8ee3f@tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <052.2ededd6e74f7a9abad41fa0d14b8ee3f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, melinda.shore@gmail.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: <20150608175945.B7B601AC3FD@ietfa.amsl.com> Resent-Date: Mon, 8 Jun 2015 10:59:45 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #41 (rfc6962-bis): missing threat model and security analysis 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, 08 Jun 2015 17:59:51 -0000 #41: missing threat model and security analysis Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: critical | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jun 8 11:02:57 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 88C3C1AC40C for ; Mon, 8 Jun 2015 11:02:56 -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 OzgUqoZxtX2I for ; Mon, 8 Jun 2015 11:02:55 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (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 164321AC408 for ; Mon, 8 Jun 2015 11:02:55 -0700 (PDT) Received: by pdjn11 with SMTP id n11so72025817pdj.0 for ; Mon, 08 Jun 2015 11:02:54 -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=ciyN9lKOfN3gYUm1RK3pCuEss307fL5uzhkEGL1WjMI=; b=nP2rN0yVwf3Ie0eIcMiYMKtfcpeOG5Dz3oDZ6W0fPMluksA/1TEDrpiYbnftFP3Rex VtkDtulZ0mtE5EHdp+EMbB+jmRGmYTwWXVsU0s2G45JklKOzZVV6tmR4n+2T4xzK0kKM ZqCTrMjouHN4FaUL0Z2W2UJCOAvBlHVN+7idY3anlG2CUUipT5CM7827mwa1Yh4KOqyq DWZws8Qchj0FOwHsH00JW2mB7HzsZJB1nJ6QaLXeiDG46h3R+2vhMMgfugEpu1A5ddDU /c7D+BAzLgGhNZ3F6ouNPf2u28h3kRaT0JZz1S6C73Bj89sDZSv7IAu/tIUzISMHF265 4e4w== X-Received: by 10.68.200.69 with SMTP id jq5mr31635817pbc.111.1433786574693; Mon, 08 Jun 2015 11:02:54 -0700 (PDT) Received: from spandex.local (209-112-214-203-rb1.nwc.dsl.dynamic.acsalaska.net. [209.112.214.203]) by mx.google.com with ESMTPSA id nn6sm3214931pdb.79.2015.06.08.11.02.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2015 11:02:53 -0700 (PDT) Message-ID: <5575D8CC.8030603@gmail.com> Date: Mon, 08 Jun 2015 10:02:52 -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" References: <071.952340865fa2c9b67595e4bc4683b6c1@tools.ietf.org> In-Reply-To: <071.952340865fa2c9b67595e4bc4683b6c1@tools.ietf.org> X-Forwarded-Message-Id: <071.952340865fa2c9b67595e4bc4683b6c1@tools.ietf.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Fwd: Re: [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks 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, 08 Jun 2015 18:02:56 -0000 Thought this one should be run past the working group: should a description of the implications of clients not doing certain optional checks be moved to the threat analysis draft? Melinda -------- Forwarded Message -------- Subject: Re: [Trans] [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks Resent-Date: Mon, 8 Jun 2015 10:53:51 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Resent-To: draft-ietf-trans-rfc6962-bis@ietf.org Date: Mon, 08 Jun 2015 17:53:51 -0000 From: trans issue tracker To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com CC: trans@ietf.org #55: Security Considerations: Describe the implications of clients *not* doing certain optional checks Changes (by benl@google.com): * milestone: => review Comment: I presume this should become part of the threat analysis I-D. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Mon Jun 8 11:57: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 3F50B1B31C1 for ; Mon, 8 Jun 2015 11:57:08 -0700 (PDT) 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 vb5SmTcUsHKl for ; Mon, 8 Jun 2015 11:57:05 -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 9EB6F1B31C5 for ; Mon, 8 Jun 2015 11:57:03 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:49555 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z22EI-0002wh-B6 for trans@ietf.org; Mon, 08 Jun 2015 14:57:02 -0400 Message-ID: <5575E57D.7000707@bbn.com> Date: Mon, 08 Jun 2015 14:57:01 -0400 From: Stephen Kent 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: <056.2fc4b44b6a5b5ab72302815f8c9d80c1@tools.ietf.org> <071.952340865fa2c9b67595e4bc4683b6c1@tools.ietf.org> In-Reply-To: <071.952340865fa2c9b67595e4bc4683b6c1@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks 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, 08 Jun 2015 18:57:08 -0000 yes, this is/will be covered in the threat analysis. > #55: Security Considerations: Describe the implications of clients *not* doing > certain optional checks > > Changes (by benl@google.com): > > * milestone: => review > > > Comment: > > I presume this should become part of the threat analysis I-D. > From nobody Mon Jun 8 12:17: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 F19881A0105 for ; Mon, 8 Jun 2015 12:17:03 -0700 (PDT) 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=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 mELao9ijMvRI for ; Mon, 8 Jun 2015 12:16:58 -0700 (PDT) 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 39EA11A8AA4 for ; Mon, 8 Jun 2015 12:16:57 -0700 (PDT) Received: from localhost ([::1]:54921 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z22XX-0000FT-0D; Mon, 08 Jun 2015 12:16:55 -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, eranm@google.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Mon, 08 Jun 2015 19:16:54 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/55#comment:3 Message-ID: <071.ecf6961b0f14411569d3fa031f64eb04@tools.ietf.org> References: <056.2fc4b44b6a5b5ab72302815f8c9d80c1@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <056.2fc4b44b6a5b5ab72302815f8c9d80c1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eranm@google.com, benl@google.com, melinda.shore@gmail.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: <20150608191657.39EA11A8AA4@ietfa.amsl.com> Resent-Date: Mon, 8 Jun 2015 12:16:57 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks 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, 08 Jun 2015 19:17:04 -0000 #55: Security Considerations: Describe the implications of clients *not* doing certain optional checks Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eranm@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jun 8 12:20:40 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 8C3ED1B323F for ; Mon, 8 Jun 2015 12:20:38 -0700 (PDT) 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 1bkDMwOBgBTN for ; Mon, 8 Jun 2015 12:20:34 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262321B3238 for ; Mon, 8 Jun 2015 12:20:34 -0700 (PDT) Received: (qmail 32145 invoked by uid 1004); 8 Jun 2015 19:20:32 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 08 Jun 2015 20:20:32 +0100 Received: (qmail 8374 invoked by uid 1000); 8 Jun 2015 19:20:32 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 08 Jun 2015 20:20:32 +0100 Message-ID: <5575EAFF.8060205@comodo.com> Date: Mon, 08 Jun 2015 20:20:31 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <056.2fc4b44b6a5b5ab72302815f8c9d80c1@tools.ietf.org> <071.952340865fa2c9b67595e4bc4683b6c1@tools.ietf.org> <5575E57D.7000707@bbn.com> In-Reply-To: <5575E57D.7000707@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks 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, 08 Jun 2015 19:20:38 -0000 Future implementers will read the 6962-bis RFC. How do we ensure that these implementers are made aware that the 6962-bis Security Considerations don't give the full picture (of how to build a secure CT ecosystem)? I suggest that the 6962-bis Security Considerations should reference the threat analysis I-D. On 08/06/15 19:57, Stephen Kent wrote: > yes, this is/will be covered in the threat analysis. > > >> #55: Security Considerations: Describe the implications of clients >> *not* doing >> certain optional checks >> >> Changes (by benl@google.com): >> >> * milestone: => review >> >> >> Comment: >> >> I presume this should become part of the threat analysis I-D. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Jun 8 12:28: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 134BC1A9072 for ; Mon, 8 Jun 2015 12:28:58 -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 j28sDsFaorQt for ; Mon, 8 Jun 2015 12:28:56 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (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 910A01A9071 for ; Mon, 8 Jun 2015 12:28:56 -0700 (PDT) Received: by pdbnf5 with SMTP id nf5so111449366pdb.2 for ; Mon, 08 Jun 2015 12:28:56 -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=erjZsL405YR31KbTjn9CRhP5mrvYiibZXAcQRCBhnow=; b=aBvkhzKnBAa2tnUD6eYMuH3dGX5qp2xQjIqn3xVfZTbzAIwj5y5Y5mVtnk1UMO6MBd VZX7hWB3hv2vBqhhy/c59/SvAeOMhXHf903MYJrtrtzNwH9MR5uaLBwjiO9dPuYiNwW1 fljVsMAJI0tm4UpnPrWXB2fM7yPqb3ajcYmQaBT2ni2r+CRAwxk8AuD/3L2UX41hfCFk mUFqHWlfiGmWKCjHje1wQKYM/wtvDyAUapXLZHSZiYqhvnFsp2lq7UrYd1s0QL/3Myap erL5i1dfOBgfPWdjYJLm/YYNXaMorUq0n05b8c2aICVVQkw5m6N6OOzWUumxbiFMqO3u taPA== X-Received: by 10.68.142.42 with SMTP id rt10mr32124047pbb.27.1433791736156; Mon, 08 Jun 2015 12:28:56 -0700 (PDT) Received: from spandex.local (209-112-214-203-rb1.nwc.dsl.dynamic.acsalaska.net. [209.112.214.203]) by mx.google.com with ESMTPSA id ph4sm3340907pdb.43.2015.06.08.12.28.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2015 12:28:55 -0700 (PDT) Message-ID: <5575ECF5.8000006@gmail.com> Date: Mon, 08 Jun 2015 11:28:53 -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 References: <056.2fc4b44b6a5b5ab72302815f8c9d80c1@tools.ietf.org> <071.952340865fa2c9b67595e4bc4683b6c1@tools.ietf.org> <5575E57D.7000707@bbn.com> <5575EAFF.8060205@comodo.com> In-Reply-To: <5575EAFF.8060205@comodo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks 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, 08 Jun 2015 19:28:58 -0000 On 6/8/15 11:20 AM, Rob Stradling wrote: > Future implementers will read the 6962-bis RFC. How do we ensure that > these implementers are made aware that the 6962-bis Security > Considerations don't give the full picture (of how to build a secure CT > ecosystem)? > > I suggest that the 6962-bis Security Considerations should reference the > threat analysis I-D. It would need to in any event, I believe. Melinda From nobody Mon Jun 8 12:31:40 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 8B39B1A90E1 for ; Mon, 8 Jun 2015 12:31:39 -0700 (PDT) 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 21Hu2J4HJ47B for ; Mon, 8 Jun 2015 12:31:38 -0700 (PDT) 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 505FB1A90C1 for ; Mon, 8 Jun 2015 12:31:38 -0700 (PDT) Received: from localhost ([::1]:55855 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z22lk-0000Yb-B0; Mon, 08 Jun 2015 12:31:36 -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: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Mon, 08 Jun 2015 19:31:36 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/79#comment:5 Message-ID: <079.f0ef3839688fc60b365b967dc3b26458@tools.ietf.org> References: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signature must be over something other than just the TBSCertificate 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, 08 Jun 2015 19:31:39 -0000 #79: Precertificate signature must be over something other than just the TBSCertificate Comment (by rob.stradling@comodo.com): OK, I agree that option 2 is what the I-D already proposes. However, in the interest of helping implementers to avoid missing this requirement, I suggest we add a note to -bis along the lines of... "Note that RFC5652 requires a content-type attribute and a message-digest attribute to be included in signedAttrs." -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Mon Jun 8 12:49:08 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 27F071A9095 for ; Mon, 8 Jun 2015 12:49:07 -0700 (PDT) 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 BpiuwxD6dsgV for ; Mon, 8 Jun 2015 12:49:06 -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 16DC81A0151 for ; Mon, 8 Jun 2015 12:49:06 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:49776 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z232e-0003Ri-K0; Mon, 08 Jun 2015 15:49:04 -0400 Message-ID: <5575F1B0.2000708@bbn.com> Date: Mon, 08 Jun 2015 15:49:04 -0400 From: Stephen Kent 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: Rob Stradling , trans@ietf.org References: <056.2fc4b44b6a5b5ab72302815f8c9d80c1@tools.ietf.org> <071.952340865fa2c9b67595e4bc4683b6c1@tools.ietf.org> <5575E57D.7000707@bbn.com> <5575EAFF.8060205@comodo.com> In-Reply-To: <5575EAFF.8060205@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks 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, 08 Jun 2015 19:49:07 -0000 WFM. > Future implementers will read the 6962-bis RFC. How do we ensure that > these implementers are made aware that the 6962-bis Security > Considerations don't give the full picture (of how to build a secure > CT ecosystem)? > > I suggest that the 6962-bis Security Considerations should reference > the threat analysis I-D. > > On 08/06/15 19:57, Stephen Kent wrote: >> yes, this is/will be covered in the threat analysis. >> >> >>> #55: Security Considerations: Describe the implications of clients >>> *not* doing >>> certain optional checks >>> >>> Changes (by benl@google.com): >>> >>> * milestone: => review >>> >>> >>> Comment: >>> >>> I presume this should become part of the threat analysis I-D. > From nobody Mon Jun 8 18:37:14 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 8116C1A1B20 for ; Mon, 8 Jun 2015 18:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.591 X-Spam-Level: * X-Spam-Status: No, score=1.591 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_03_06=1.592] 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 UDS_2i2XK6wf for ; Mon, 8 Jun 2015 18:37:12 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE0F1A1A8D for ; Mon, 8 Jun 2015 18:37:12 -0700 (PDT) Received: from fifthhorseman.net (c-73-128-23-123.hsd1.md.comcast.net [73.128.23.123]) by che.mayfirst.org (Postfix) with ESMTPSA id C9C11F986; Mon, 8 Jun 2015 21:37:09 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 020421FEE9; Mon, 8 Jun 2015 16:01:18 -0400 (EDT) From: Daniel Kahn Gillmor To: Melinda Shore , "trans\@ietf.org" In-Reply-To: <5575D8CC.8030603@gmail.com> References: <071.952340865fa2c9b67595e4bc4683b6c1@tools.ietf.org> <5575D8CC.8030603@gmail.com> User-Agent: Notmuch/0.20.1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 08 Jun 2015 16:01:18 -0400 Message-ID: <87r3pmrmup.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Trans] Fwd: Re: [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks 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, 09 Jun 2015 01:37:13 -0000 On Mon 2015-06-08 14:02:52 -0400, Melinda Shore wrote: > Thought this one should be run past the working group: should > a description of the implications of clients not doing certain > optional checks be moved to the threat analysis draft? Yes, i think it belongs in the threat analysis, so that we can keep mechanism separate from more in-depth analysis. The analysis might also be more nuanced than piecemeal implications on a per-client basis: this is a sort of "herd immunity" situation, there are may be ways that the system breaks down when only some fraction of participants behave in certain ways. I don't know how to characterize this sort of tradeoff explicitly, but perhaps some of the folks modeling CT behavior can contribute details? They would certainly be good for us to understand. This analysis is important, but it might be too complex to overload 6962bis with, if we want 6962bis to be an effective implementer's reference. putting it in the threat-analysis draft would let us treat the topic in more depth, if anyone has research worth sharing with the community. --dkg From nobody Tue Jun 9 03:45:04 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 442571B2BC0 for ; Tue, 9 Jun 2015 03:44:58 -0700 (PDT) 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=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 GBPXizFsaWEy for ; Tue, 9 Jun 2015 03:44:56 -0700 (PDT) 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 199B01B2BAC for ; Tue, 9 Jun 2015 03:44:56 -0700 (PDT) Received: from localhost ([::1]:50353 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z2H1b-0003cY-BU; Tue, 09 Jun 2015 03:44:55 -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, benl@google.com X-Trac-Project: trans Date: Tue, 09 Jun 2015 10:44:55 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/81#comment:1 Message-ID: <079.26e63dbec6af5be802d3f79cc21fc814@tools.ietf.org> References: <064.3913404a0bdb950970d4d68568789f31@tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <064.3913404a0bdb950970d4d68568789f31@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@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: <20150609104456.199B01B2BAC@ietfa.amsl.com> Resent-Date: Tue, 9 Jun 2015 03:44:56 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #81 (rfc6962-bis): OIDs and IANA Considerations 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: Tue, 09 Jun 2015 10:44:58 -0000 #81: OIDs and IANA Considerations Changes (by benl@google.com): * milestone: => review Comment: I don't have any strong opinion on this. Chairs: what does the WG prefer? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Jun 9 04:09:42 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 89FF41A00CA for ; Tue, 9 Jun 2015 04:09:41 -0700 (PDT) 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=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 mlmy9xnDXjZ3 for ; Tue, 9 Jun 2015 04:09:40 -0700 (PDT) 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 202511A00DB for ; Tue, 9 Jun 2015 04:09:31 -0700 (PDT) Received: from localhost ([::1]:51950 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z2HPM-0003xX-9K; Tue, 09 Jun 2015 04:09:28 -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, benl@google.com X-Trac-Project: trans Date: Tue, 09 Jun 2015 11:09:28 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/82#comment:6 Message-ID: <073.242858617958b379a558f3d1bdc9a719@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, benl@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: <20150609110931.202511A00DB@ietfa.amsl.com> Resent-Date: Tue, 9 Jun 2015 04:09:31 -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: Tue, 09 Jun 2015 11:09:41 -0000 #82: Add a way to get the SCTs for entries returned by get-entries Comment (by benl@google.com): It is not really true that fetching over HTTPS provides integrity: for a start, HTTPS is only as good as its inputs, which could be corrupted before HTTPS gets its hands on them. -- -------------------------+------------------------------------------------- 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 Tue Jun 9 04:28:16 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 6CAF61A1A17 for ; Tue, 9 Jun 2015 04:28:15 -0700 (PDT) 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 GsMpHTIEVZrb for ; Tue, 9 Jun 2015 04:28:14 -0700 (PDT) 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 4DC121A19F8 for ; Tue, 9 Jun 2015 04:28:14 -0700 (PDT) Received: from localhost ([::1]:53667 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z2HhV-0006on-N4; Tue, 09 Jun 2015 04:28:13 -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, benl@google.com X-Trac-Project: trans Date: Tue, 09 Jun 2015 11:28:13 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/86 Message-ID: <055.e79a51ea71a962f252e762da97b30a02@tools.ietf.org> X-Trac-Ticket-ID: 86 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@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: <20150609112814.4DC121A19F8@ietfa.amsl.com> Resent-Date: Tue, 9 Jun 2015 04:28:14 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #86 (rfc6962-bis): SCTs should be returned in final format 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: Tue, 09 Jun 2015 11:28:15 -0000 #86: SCTs should be returned in final format Currently, add-chain and add-pre-chain return an SCT in its component pieces as JSON, which the client then has to assemble into the correct final structure. I'm not sure why I ever thought this was a good idea, and I certainly can't see any particularly good reason for it now. So, I propose that instead the SCT should be returned in its final format, base64 encoded. This also allows future changes to the SCT structure to be made more easily. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- benl@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 9 04:28:57 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 37F6F1A19F8 for ; Tue, 9 Jun 2015 04:28:55 -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 mPHRVV2sm0Sz for ; Tue, 9 Jun 2015 04:28:53 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (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 A87A71A1A0B for ; Tue, 9 Jun 2015 04:28:53 -0700 (PDT) Received: by vnbg129 with SMTP id g129so2141900vnb.11 for ; Tue, 09 Jun 2015 04:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BbY19UWz8q8ysvkJZRzl1JzCNB5N2Qo87U1UJXAu8Jc=; b=miDn0SGBqOe3MCEu6ZZjv+AR6Zp72LTbXS7dvecL0djS22aaLHJvRCyCg5qrcqajot Voju/rvr+3Yj9IeywdLLld9zjEOmWETgBKUCAfiC+JzR3XCyqtd2KGX/OheQhlvTPl/F 61MPXCK9zvqT6va5TnUzIEiDbnJfQzpXFMdD2JWV+6q39ewDoCUa/fvm4lapt8UvNxP6 l+FeSit5DS2xvZbO1zslAhicH/zBp/FeBn+03hOU2E3ak/UXxquWUMAqmOL70EE8FhRT Jb+dQqqVN9ibtgE3EKFC0qKzGiD7TNuBWKE/VFjAVxngyHlqDTO6VxDBQ+QJV3+TK1wJ Nv+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=BbY19UWz8q8ysvkJZRzl1JzCNB5N2Qo87U1UJXAu8Jc=; b=KjV2RZbnaI/BtsB9Lk8N4THU6GXgiecmo0YpNJoHOlPNrs6szwlwA/+W2kIx4Pb3Mw GEFf31e3/T9dFpdxUyHvUx8rKFYNaovP+pYkXg1RKfR6feR4OFx3tnxUos6jhMgsfZBB p0+B70ABONGOinCIWQin5o2LSu6hpTKlxosbhKHNhKnUoscC35MHYMjSc/9U/EitfAtm O8ggOKPZfgD7wkYstFFKiqOyofefkTcPGPFHnVn3Y2Cn9jgdCRP/KKeBruLouz/UVynE lDblPbq/PeXFnrT838Ke1XAfPhgwNe3pTDbsJ8PrP5QLptkUo0NIuAVrH20AhpTWpjwz uu2g== X-Gm-Message-State: ALoCoQnPuyGmgDv1Ln3j3AMFb15e9rpCjhf4fDZk9NxeVshbPsZGJrZ99cO73AUMMCGsk4LcGSwu MIME-Version: 1.0 X-Received: by 10.52.112.36 with SMTP id in4mr41004771vdb.3.1433849332838; Tue, 09 Jun 2015 04:28:52 -0700 (PDT) Received: by 10.52.76.6 with HTTP; Tue, 9 Jun 2015 04:28:52 -0700 (PDT) Date: Tue, 9 Jun 2015 12:28:52 +0100 Message-ID: From: Ben Laurie To: "trans@ietf.org" Content-Type: multipart/alternative; boundary=bcaec548a9f325a4ff0518141045 Archived-At: Subject: [Trans] Format of SCTs 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, 09 Jun 2015 11:28:55 -0000 --bcaec548a9f325a4ff0518141045 Content-Type: text/plain; charset=UTF-8 I'd like to draw the WG's attention to http://trac.tools.ietf.org/wg/trans/trac/ticket/86, in which I propose that we return SCTs ready-made instead of in pieces. Opinions? --bcaec548a9f325a4ff0518141045 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd like to draw the WG's attention to=C2=A0http://trac.tools.= ietf.org/wg/trans/trac/ticket/86, in which I propose that we return SCT= s ready-made instead of in pieces.

Opinions?
<= br>
--bcaec548a9f325a4ff0518141045-- From nobody Tue Jun 9 04:31:33 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 B08DC1A1A43 for ; Tue, 9 Jun 2015 04:31:31 -0700 (PDT) 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=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 43Ghr-aVRMs1 for ; Tue, 9 Jun 2015 04:31:31 -0700 (PDT) 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 957E51A1A45 for ; Tue, 9 Jun 2015 04:31:30 -0700 (PDT) Received: from localhost ([::1]:53858 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z2Hkg-0002vd-8R; Tue, 09 Jun 2015 04:31:30 -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, benl@google.com X-Trac-Project: trans Date: Tue, 09 Jun 2015 11:31:30 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/87 Message-ID: <055.7819ac8587a95086b3d5e12f7059de04@tools.ietf.org> X-Trac-Ticket-ID: 87 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@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: <20150609113130.957E51A1A45@ietfa.amsl.com> Resent-Date: Tue, 9 Jun 2015 04:31:30 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #87 (rfc6962-bis): Add reference to threat analysis document 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: Tue, 09 Jun 2015 11:31:31 -0000 #87: Add reference to threat analysis document [EOM] -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- benl@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 9 04:37:46 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 F16C31A6FED for ; Tue, 9 Jun 2015 04:37:44 -0700 (PDT) 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 ZFsMOeMg_neP for ; Tue, 9 Jun 2015 04:37:42 -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 7E4441A1AD3 for ; Tue, 9 Jun 2015 04:37:41 -0700 (PDT) Received: (qmail 4541 invoked by uid 1004); 9 Jun 2015 11:37:39 -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, 09 Jun 2015 12:37:39 +0100 Received: (qmail 12745 invoked by uid 1000); 9 Jun 2015 11:37:39 -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, 09 Jun 2015 12:37:39 +0100 Message-ID: <5576D003.2000907@comodo.com> Date: Tue, 09 Jun 2015 12:37:39 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ben Laurie , "trans@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Format of SCTs 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, 09 Jun 2015 11:37:45 -0000 On 09/06/15 12:28, Ben Laurie wrote: > I'd like to draw the WG's attention to > http://trac.tools.ietf.org/wg/trans/trac/ticket/86, in which I propose > that we return SCTs ready-made instead of in pieces. > > Opinions? Works for me. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Jun 9 07:24:13 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 5DCF01A8780 for ; Tue, 9 Jun 2015 07:24:12 -0700 (PDT) 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 rFBbSllEjYxB for ; Tue, 9 Jun 2015 07:24:10 -0700 (PDT) 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 3D7BB1A87A4 for ; Tue, 9 Jun 2015 07:24:02 -0700 (PDT) Received: from localhost ([::1]:33922 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z2KRb-0000ZC-19; Tue, 09 Jun 2015 07:23:59 -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: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Tue, 09 Jun 2015 14:23:59 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/85#comment:2 Message-ID: <079.b7ddb8240fa136048b675a133598756f@tools.ietf.org> References: <064.77ac23aa5bfca1f37014dcdb7c53be83@tools.ietf.org> X-Trac-Ticket-ID: 85 In-Reply-To: <064.77ac23aa5bfca1f37014dcdb7c53be83@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #85 (rfc6962-bis): Precertificate CMS structures MUST be DER 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: Tue, 09 Jun 2015 14:24:12 -0000 #85: Precertificate CMS structures MUST be DER Changes (by benl@google.com): * milestone: => review Comment: Fixed: https://github.com/google/certificate-transparency- rfcs/commit/4d118edb2ad4b581dda96ff46e2c26746245fcb0. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: blocker | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Jun 9 09:19:20 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 99C511A8AC3 for ; Tue, 9 Jun 2015 09:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 9rlV8HirldLS for ; Tue, 9 Jun 2015 09:19:18 -0700 (PDT) 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 EC9E91A00F7 for ; Tue, 9 Jun 2015 09:19:10 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:56647) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z2MF3-000OoE-50 for trans@ietf.org; Tue, 09 Jun 2015 12:19:09 -0400 Message-ID: <557711FD.2000001@bbn.com> Date: Tue, 09 Jun 2015 12:19:09 -0400 From: Stephen Kent 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: <055.e79a51ea71a962f252e762da97b30a02@tools.ietf.org> In-Reply-To: <055.e79a51ea71a962f252e762da97b30a02@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #86 (rfc6962-bis): SCTs should be returned in final format 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, 09 Jun 2015 16:19:19 -0000 I concur with Ben's analysis. > #86: SCTs should be returned in final format > > Currently, add-chain and add-pre-chain return an SCT in its component > pieces as JSON, which the client then has to assemble into the correct > final structure. > > I'm not sure why I ever thought this was a good idea, and I certainly > can't see any particularly good reason for it now. > > So, I propose that instead the SCT should be returned in its final format, > base64 encoded. > > This also allows future changes to the SCT structure to be made more > easily. > From nobody Tue Jun 9 09:34:34 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 8FC7B1ACE65 for ; Tue, 9 Jun 2015 09:34:32 -0700 (PDT) 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=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 UVqT0ukhJGsS for ; Tue, 9 Jun 2015 09:34:31 -0700 (PDT) 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 747901ACE62 for ; Tue, 9 Jun 2015 09:34:27 -0700 (PDT) Received: from localhost ([::1]:40949 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z2MTo-0003Xq-Qc; Tue, 09 Jun 2015 09:34:24 -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, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 09 Jun 2015 16:34:24 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/81#comment:2 Message-ID: <079.cb33e954c5ecdd66f87928a65679270b@tools.ietf.org> References: <064.3913404a0bdb950970d4d68568789f31@tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <064.3913404a0bdb950970d4d68568789f31@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, melinda.shore@gmail.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: <20150609163427.747901ACE62@ietfa.amsl.com> Resent-Date: Tue, 9 Jun 2015 09:34:27 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #81 (rfc6962-bis): OIDs and IANA Considerations 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: Tue, 09 Jun 2015 16:34:32 -0000 #81: OIDs and IANA Considerations Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-trans- rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Jun 9 09:38:10 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 651A81ACE66 for ; Tue, 9 Jun 2015 09:38:09 -0700 (PDT) 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 qXz5s1iUYNSg for ; Tue, 9 Jun 2015 09:38:08 -0700 (PDT) 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 519F61ACE65 for ; Tue, 9 Jun 2015 09:38:08 -0700 (PDT) Received: from localhost ([::1]:41171 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z2MXN-0004qh-M5; Tue, 09 Jun 2015 09:38:05 -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: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 09 Jun 2015 16:38:05 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/85#comment:3 Message-ID: <079.64db521e8ba1fe829acf7c29940aa37b@tools.ietf.org> References: <064.77ac23aa5bfca1f37014dcdb7c53be83@tools.ietf.org> X-Trac-Ticket-ID: 85 In-Reply-To: <064.77ac23aa5bfca1f37014dcdb7c53be83@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.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: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #85 (rfc6962-bis): Precertificate CMS structures MUST be DER 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: Tue, 09 Jun 2015 16:38:09 -0000 #85: Precertificate CMS structures MUST be DER Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: closed Priority: blocker | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Tue Jun 9 13:00:34 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 83D381B304D for ; Tue, 9 Jun 2015 13:00:32 -0700 (PDT) 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 txDa5GY4M0S9 for ; Tue, 9 Jun 2015 13:00:30 -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 AE5391B3037 for ; Tue, 9 Jun 2015 13:00:30 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:54672 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z2Ph8-000FeF-5T; Tue, 09 Jun 2015 16:00:22 -0400 Message-ID: <557745D5.9000705@bbn.com> Date: Tue, 09 Jun 2015 16:00:21 -0400 From: Stephen Kent 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 issue tracker , draft-ietf-trans-rfc6962-bis@tools.ietf.org, rob.stradling@comodo.com, eranm@google.com, benl@google.com References: <058.605775396b2af7a29113e5c5c8670c40@tools.ietf.org> <073.242858617958b379a558f3d1bdc9a719@tools.ietf.org> In-Reply-To: <073.242858617958b379a558f3d1bdc9a719@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 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, 09 Jun 2015 20:00:32 -0000 Fair point. It would be accurate to say that use of HTTPS provides integrity for SCTs when transmitted from a log to a log client. On 6/9/15 7:09 AM, trans issue tracker wrote: > #82: Add a way to get the SCTs for entries returned by get-entries > > > Comment (by benl@google.com): > > It is not really true that fetching over HTTPS provides integrity: for a > start, HTTPS is only as good as its inputs, which could be corrupted > before HTTPS gets its hands on them. > From nobody Wed Jun 10 01:05:55 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 EAE651ACD2B for ; Wed, 10 Jun 2015 01:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 NKjxKCUxm2rB for ; Wed, 10 Jun 2015 01:05:51 -0700 (PDT) Received: from mail.hezmatt.org (erdhenne.hezmatt.org [178.63.97.210]) by ietfa.amsl.com (Postfix) with ESMTP id 845871ACD2C for ; Wed, 10 Jun 2015 01:05:51 -0700 (PDT) Received: from mistress.home.hezmatt.org (2001-44b8-3196-7300-6021-1652-4d5a-2147.static.ipv6.internode.on.net [IPv6:2001:44b8:3196:7300:6021:1652:4d5a:2147]) by mail.hezmatt.org (Postfix) with ESMTPSA id C672C14DB7 for ; Wed, 10 Jun 2015 01:00:50 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 89BAAA0550; Wed, 10 Jun 2015 11:00:47 +1000 (AEST) Date: Wed, 10 Jun 2015 11:00:47 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20150610010047.GP17756@hezmatt.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Format of SCTs 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, 10 Jun 2015 08:05:54 -0000 On Tue, Jun 09, 2015 at 12:28:52PM +0100, Ben Laurie wrote: > I'd like to draw the WG's attention to > http://trac.tools.ietf.org/wg/trans/trac/ticket/86, in which I propose that > we return SCTs ready-made instead of in pieces. > > Opinions? Do eeeeeet. Anything that reduces the number of places where transformation can happen, and therefore introduce bugs, is a good thing. - Matt -- hut.fi has or used to have two nfs servers not-responding and still-trying... don't know if their dns server was not-found... 4o4 would be then a good name for the web server... endless hours of fun "did you get a response from 4o4?" "nah, it just 404ed" From nobody Wed Jun 10 05:49: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 637C11A0107 for ; Wed, 10 Jun 2015 05:49:27 -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 XmvJQQw0IGuT for ; Wed, 10 Jun 2015 05:49:26 -0700 (PDT) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (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 C5E8E1A00F0 for ; Wed, 10 Jun 2015 05:49:02 -0700 (PDT) Received: by vnbg62 with SMTP id g62so7733167vnb.4 for ; Wed, 10 Jun 2015 05:49:02 -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=TEB28/qjDpgNfj0+Oy0SqbXyrbiSGQccUqHjWk4AGMg=; b=nqMeVNycFMEIOS1PVpuL7CLK9ftuQkQNyKiTeyrdW45jOi6OvpjKR50gTInB1ZsWyn jSuUTwmHF/b60u3Q2RDzK0gfeEn8MQj4AUKdhk2OU+UM6/bddK8/+o1TGW3d3uRUV4Ab 5ahgwmnp9SlsxVXMjs7hwQTd3YfZS2Ovx0mF7y4HWgEhj6Q5EYDF5wXwsc9lKxZGXjNm PbJOfM1fZXx0cgfZ3q2+JaOKSRvMb+7G+gAuFm/45b3DGwmfUrMXe0oWMLqYWZyWo4hR zhUmqRr95Gpwxu3HIyBD3NqWDU0dnnOVHkRa0EAAflv34FrPAu7ZiquOv2OycEAJ1t5d ry2w== 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=TEB28/qjDpgNfj0+Oy0SqbXyrbiSGQccUqHjWk4AGMg=; b=OewSL3UgWujMS2tUP6ikPNg8yDp8TboeYyB2flbPWPTv+s0GI+uywd/QK+s8LjV2jQ 8G0Po1D/EZwirCdhV34RteC4RSQbEwy5TdCgraz9lseRu31VwYyyqV07Z+TWTCcUkfP8 jkJLofTxUibAfAdK1OXzRgPBQpDv1SHAWTYz/IDotVjtXDDUhOgj/9SXIRUbIYxEhs6z PnpS6MySGuiJDJ1GIQJ+J5I5aKfz49jHTIur62a+KmQ8i/SIG7m58tyWOdV3LsviEYEX VZGaklPkejr4m43yGB1xTdekI9Nokzl+2BdKx5SHspea1+aIUlFHeiuZNkIjOMeDo3RA R0rg== X-Gm-Message-State: ALoCoQnZPj1vOnlDbT/jZw892c70dVmf9DvcYuXI+I+JnDYJ3jm0HBGzy64aYClf1EQdaazRmJ9T MIME-Version: 1.0 X-Received: by 10.52.71.203 with SMTP id x11mr6106407vdu.48.1433940542034; Wed, 10 Jun 2015 05:49:02 -0700 (PDT) Received: by 10.52.76.6 with HTTP; Wed, 10 Jun 2015 05:49:01 -0700 (PDT) In-Reply-To: <079.cb33e954c5ecdd66f87928a65679270b@tools.ietf.org> References: <064.3913404a0bdb950970d4d68568789f31@tools.ietf.org> <079.cb33e954c5ecdd66f87928a65679270b@tools.ietf.org> Date: Wed, 10 Jun 2015 13:49:01 +0100 Message-ID: From: Ben Laurie To: trans issue tracker Content-Type: multipart/alternative; boundary=001a113637faa3319d0518294c22 Archived-At: Cc: Melinda Shore , "trans@ietf.org" , draft-ietf-trans-rfc6962-bis@tools.ietf.org Subject: Re: [Trans] [trans] #81 (rfc6962-bis): OIDs and IANA Considerations 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, 10 Jun 2015 12:49:27 -0000 --001a113637faa3319d0518294c22 Content-Type: text/plain; charset=UTF-8 Hmm. Not sure what closing this means! We should leave our existing OIDs? And continue to allocate from the Google arc? Or what? On 9 June 2015 at 17:34, trans issue tracker wrote: > #81: OIDs and IANA Considerations > > Changes (by melinda.shore@gmail.com): > > * status: new => closed > * resolution: => fixed > > > -- > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-trans- > rob.stradling@comodo.com | rfc6962-bis@tools.ietf.org > Type: defect | Status: closed > Priority: major | Milestone: review > Component: rfc6962-bis | Version: > Severity: - | Resolution: fixed > Keywords: | > -------------------------------------+------------------------------------- > > Ticket URL: > trans > > --001a113637faa3319d0518294c22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hmm. Not sure what closing this means! We should leave our= existing OIDs? And continue to allocate from the Google arc? Or what?
<= div class=3D"gmail_extra">
On 9 June 2015 at = 17:34, trans issue tracker <trac+trans@tools.ietf.org> wrote:
#81: OIDs and = IANA Considerations

Changes (by melinda.shore= @gmail.com):

=C2=A0* status:=C2=A0 new =3D> closed
=C2=A0* resolution:=C2=A0 =C2=A0=3D> fixed


--
-------------------------------------+-------------------------------------=
=C2=A0Reporter:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0Owner:=C2= =A0 draft-ietf-trans-
=C2=A0 rob.stradling@comodo.com= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 rfc6962-bis@tools.ietf.org
=C2=A0 =C2=A0 =C2=A0Type:=C2=A0 defect=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 Status:=C2= =A0 closed
=C2=A0Priority:=C2=A0 major=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Milestone:=C2=A0 review
Component:=C2=A0 rfc6962-bis=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0Version:
=C2=A0Severity:=C2=A0 -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 Resolution:=C2=A0 fixed
=C2=A0Keywords:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
-------------------------------------+-------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ti= cket/81#comment:2>
trans <http:/= /tools.ietf.org/trans/>


--001a113637faa3319d0518294c22-- From nobody Wed Jun 10 08:32:08 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 A72FE1B2BB7 for ; Wed, 10 Jun 2015 08:32:02 -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 ha3soL0WNQfO for ; Wed, 10 Jun 2015 08:31:59 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::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 359651B2B8D for ; Wed, 10 Jun 2015 08:31:59 -0700 (PDT) Received: by pdjm12 with SMTP id m12so40121333pdj.3 for ; Wed, 10 Jun 2015 08:31:59 -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 :references:in-reply-to:content-type:content-transfer-encoding; bh=j4VrD17OGtEBjTyEL/507TAIO64txEOCt67YVNSl/w0=; b=d5Kc2+xbngMV1RfKnkzX/acSh5Bpv9izjfftz6cyZjb7sDfggoNoaLLr+ZwaqYEz+O q0ATebtNTxxllk9L2dA2OZRD+oumzjfYEAUxCS3kZyym1pzjaIZqsBdx4o/xSaOnywXq oU/tAjHEAnQrj8ZRYxhNAOTjQ7iZk/IVq/ktY+MvoMqOopaN6pDRLA6+UPZEb4FR+Lml DCQiduHiSy+Hx9d/VyJOMt6i6w9Oy03O2dNWknJC/PH2M8GI3/4wco24lzBVbRZGeTeS wIuFbZfNaxy1xFE5/DMpPhc2Fgp4UYJUg3um0KF/R1pj9TcpNY9jSfrChj90eqaEqSao 6cVQ== X-Received: by 10.70.135.129 with SMTP id ps1mr6613967pdb.110.1433950318942; Wed, 10 Jun 2015 08:31:58 -0700 (PDT) Received: from spandex.local (209-112-214-203-rb1.nwc.dsl.dynamic.acsalaska.net. [209.112.214.203]) by mx.google.com with ESMTPSA id nn6sm8983431pdb.79.2015.06.10.08.31.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2015 08:31:57 -0700 (PDT) Message-ID: <5578586C.4070206@gmail.com> Date: Wed, 10 Jun 2015 07:31:56 -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: Ben Laurie , trans issue tracker References: <064.3913404a0bdb950970d4d68568789f31@tools.ietf.org> <079.cb33e954c5ecdd66f87928a65679270b@tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , draft-ietf-trans-rfc6962-bis@tools.ietf.org Subject: Re: [Trans] [trans] #81 (rfc6962-bis): OIDs and IANA Considerations 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, 10 Jun 2015 15:32:02 -0000 On 6/10/15 4:49 AM, Ben Laurie wrote: > Hmm. Not sure what closing this means! We should leave our existing > OIDs? And continue to allocate from the Google arc? Or what? Yes and yes, and and an OID section to the IANA considerations. Melinda From nobody Thu Jun 11 04:16:10 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 22CF81A1B1B for ; Thu, 11 Jun 2015 04:16:09 -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 x5fkANLX0QX1 for ; Thu, 11 Jun 2015 04:16:06 -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 C818A1A1A58 for ; Thu, 11 Jun 2015 04:16:05 -0700 (PDT) Received: (qmail 1706 invoked by uid 1004); 11 Jun 2015 11:16:02 -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; Thu, 11 Jun 2015 12:16:02 +0100 Received: (qmail 6154 invoked by uid 1000); 11 Jun 2015 11:16:02 -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; Thu, 11 Jun 2015 12:16:02 +0100 Message-ID: <55796DF2.9050705@comodo.com> Date: Thu, 11 Jun 2015 12:16:02 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Matt Palmer Subject: [Trans] Log Monitoring API 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 Jun 2015 11:16:09 -0000 6962-bis notes that: "Those who are concerned about misissue can monitor the logs, asking them regularly for all new entries, and can thus check whether domains they are responsible for have had certificates issued that they did not expect." If you act as a monitor yourself, you can be sure that the logs you're monitoring aren't misbehaving. You don't have to trust the logs. However, if you use the services of a third-party monitor instead (which I expect most domain owners would prefer to do), then you have to trust that that third-party monitor isn't hiding any certs from you. Therefore, ISTM that some domain owners might want to be able to use the services of multiple independent monitors simultaneously. To facilitate this, it would be useful to define a standard API for querying a monitor. This API would allow callers to search for certs issued to a particular domain name/space, setup notifications of (mis-)issuance, etc. Matt Palmer and I are planning to start work on a -00 draft soon. If anyone else would like to get involved, please let us know. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Jun 11 05:18:08 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 1DC071ACDEE for ; Thu, 11 Jun 2015 05:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 iNvORmAdZP1A for ; Thu, 11 Jun 2015 05:18:04 -0700 (PDT) Received: from mail.hezmatt.org (erdhenne.hezmatt.org [178.63.97.210]) by ietfa.amsl.com (Postfix) with ESMTP id 049721ACDED for ; Thu, 11 Jun 2015 05:18:03 -0700 (PDT) Received: from mistress.home.hezmatt.org (2001-44b8-3196-7300-a0fa-e473-a53f-9557.static.ipv6.internode.on.net [IPv6:2001:44b8:3196:7300:a0fa:e473:a53f:9557]) by mail.hezmatt.org (Postfix) with ESMTPSA id 2355E15666 for ; Thu, 11 Jun 2015 12:18:01 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 7C3AFA0555; Thu, 11 Jun 2015 22:17:58 +1000 (AEST) Date: Thu, 11 Jun 2015 22:17:58 +1000 From: Matt Palmer To: "trans@ietf.org" Message-ID: <20150611121758.GN17756@hezmatt.org> References: <55796DF2.9050705@comodo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55796DF2.9050705@comodo.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 12:18:06 -0000 On Thu, Jun 11, 2015 at 12:16:02PM +0100, Rob Stradling wrote: > However, if you use the services of a third-party monitor instead (which I > expect most domain owners would prefer to do), then you have to trust that > that third-party monitor isn't hiding any certs from you. > > Therefore, ISTM that some domain owners might want to be able to use the > services of multiple independent monitors simultaneously. > > To facilitate this, it would be useful to define a standard API for querying > a monitor. This API would allow callers to search for certs issued to a > particular domain name/space, setup notifications of (mis-)issuance, etc. > > Matt Palmer and I are planning to start work on a -00 draft soon. If anyone > else would like to get involved, please let us know. Speaking for myself, I'm coming at this largely from the perspective of someone who is implementing a monitor (OSS code release imminent). It would be good to get one or more "typical users" of a third-party monitor on board this effort, to ensure that the spec provides a solid set of endpoints for users of a monitor to work with. - Matt From nobody Thu Jun 11 05:42:17 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 89A6D1ACEAE for ; Thu, 11 Jun 2015 05:42:16 -0700 (PDT) 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 vzqHb2OSUTl6 for ; Thu, 11 Jun 2015 05:42:15 -0700 (PDT) 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 379401ACEB6 for ; Thu, 11 Jun 2015 05:42:15 -0700 (PDT) Received: from localhost ([::1]:49004 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z31oA-0000qz-3z; Thu, 11 Jun 2015 05:42:10 -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: rob.stradling@comodo.com, benl@google.com X-Trac-Project: trans Date: Thu, 11 Jun 2015 12:42:10 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/79#comment:6 Message-ID: <079.727c660183267c66b37706330f6dc562@tools.ietf.org> References: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signature must be over something other than just the TBSCertificate 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, 11 Jun 2015 12:42:16 -0000 #79: Precertificate signature must be over something other than just the TBSCertificate Changes (by benl@google.com): * milestone: => review Comment: After discussion with Rob, core point is that the CMS signature is not an X509 signature. Fixed at https://github.com/google/certificate-transparency- rfcs/commit/546e6e9451186e96ddd7b54ca02f17c8d86f951e. -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: assigned Priority: blocker | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Thu Jun 11 06:00:23 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 617631A8ACB for ; Thu, 11 Jun 2015 06:00:22 -0700 (PDT) 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=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 Uv0mJthK7cfg for ; Thu, 11 Jun 2015 06:00:20 -0700 (PDT) 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 3A9201ACEE5 for ; Thu, 11 Jun 2015 06:00:19 -0700 (PDT) Received: from localhost ([::1]:50028 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z325e-0001ok-4X; Thu, 11 Jun 2015 06:00:14 -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, benl@google.com X-Trac-Project: trans Date: Thu, 11 Jun 2015 13:00:14 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/58#comment:3 Message-ID: <070.1db181111c709e79339b6c6ee5413ab8@tools.ietf.org> References: <055.b793219aebf9d4b50b2e649d13c13ebe@tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <055.b793219aebf9d4b50b2e649d13c13ebe@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, linus@nordu.net, benl@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: <20150611130019.3A9201ACEE5@ietfa.amsl.com> Resent-Date: Thu, 11 Jun 2015 06:00:19 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #58 (rfc6962-bis): Limit the number of STH's allowed to be published per time unit 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, 11 Jun 2015 13:00:22 -0000 #58: Limit the number of STH's allowed to be published per time unit Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/239e6a04ba1cbd0d5a9681d905a8104c98db874d. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- linus@nordu.net | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jun 11 06:01:20 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 D50D61A1B2A for ; Thu, 11 Jun 2015 04:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DK=1.009, RCVD_IN_DNSWL_NONE=-0.0001, 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 jSq_pgp0d1H2 for ; Thu, 11 Jun 2015 04:31:41 -0700 (PDT) Received: from spamfilter2.dtu.dk (spamfilter2.dtu.dk [130.225.73.113]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B7D1A87E9 for ; Thu, 11 Jun 2015 04:31:41 -0700 (PDT) Received: from ait-pexedg02.win.dtu.dk (ait-pexedg02.win.dtu.dk [192.38.82.192]) by spamfilter2.dtu.dk with ESMTP id t5BBUtDS004620-t5BBUtDU004620 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL); Thu, 11 Jun 2015 13:30:55 +0200 Received: from ait-pex02mbx04.win.dtu.dk (192.38.82.184) by ait-pexedg02.win.dtu.dk (192.38.82.192) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 11 Jun 2015 13:30:52 +0200 Received: from ait-pex01mbx01.win.dtu.dk ([169.254.1.56]) by ait-pex02mbx04.win.dtu.dk ([169.254.4.237]) with mapi id 14.03.0235.001; Thu, 11 Jun 2015 13:30:55 +0200 From: Hugo Maxwell Connery To: Rob Stradling , "trans@ietf.org" Thread-Topic: [Trans] Log Monitoring API Thread-Index: AQHQpDgLQLJoBQ9sb06g0uAnO0m4mZ2nKgxK Date: Thu, 11 Jun 2015 11:30:54 +0000 Message-ID: <6CB05D82CE245B4083BBF3B97E2ED470336FA3@ait-pex01mbx01.win.dtu.dk> References: <55796DF2.9050705@comodo.com> In-Reply-To: <55796DF2.9050705@comodo.com> Accept-Language: en-AU, da-DK, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.225.73.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 11 Jun 2015 06:01:18 -0700 Cc: Matt Palmer Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 11:31:44 -0000 Hi, It is not surprising to see a member of a CA propose to expand the=20 business market around CA's. (CAs and CA monitors). =20 The suggestion is reasonable, though I hazard to suggest that a=20 copylefted reference implementation of log monitoring for some set of=20 domain names would be a valuable contribution. =20 Indeed the new CA monitors could use it to make a nice profit/offer a usefu= l service: Comodo monitors Verisign who monitor GoDaddy who monitor ... You get the i= dea. -- Hugo Connery, Head of IT, DTU Environment, http://www.env.dtu.dk ________________________________________ From: Trans [trans-bounces@ietf.org] on behalf of Rob Stradling [rob.stradl= ing@comodo.com] Sent: Thursday, 11 June 2015 13:16 To: trans@ietf.org Cc: Matt Palmer Subject: [Trans] Log Monitoring API 6962-bis notes that: "Those who are concerned about misissue can monitor the logs, asking them regularly for all new entries, and can thus check whether domains they are responsible for have had certificates issued that they did not expect." If you act as a monitor yourself, you can be sure that the logs you're monitoring aren't misbehaving. You don't have to trust the logs. However, if you use the services of a third-party monitor instead (which I expect most domain owners would prefer to do), then you have to trust that that third-party monitor isn't hiding any certs from you. Therefore, ISTM that some domain owners might want to be able to use the services of multiple independent monitors simultaneously. To facilitate this, it would be useful to define a standard API for querying a monitor. This API would allow callers to search for certs issued to a particular domain name/space, setup notifications of (mis-)issuance, etc. Matt Palmer and I are planning to start work on a -00 draft soon. If anyone else would like to get involved, please let us know. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Thu Jun 11 06:55:16 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 01FFB1AD1C3 for ; Thu, 11 Jun 2015 06:55:15 -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_40=-0.001, 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 Sn_Mjl9EWYUM for ; Thu, 11 Jun 2015 06:55:13 -0700 (PDT) Received: from mail.hezmatt.org (erdhenne.hezmatt.org [178.63.97.210]) by ietfa.amsl.com (Postfix) with ESMTP id EF5D01AD1A3 for ; Thu, 11 Jun 2015 06:55:12 -0700 (PDT) Received: from mistress.home.hezmatt.org (2001-44b8-3196-7300-a0fa-e473-a53f-9557.static.ipv6.internode.on.net [IPv6:2001:44b8:3196:7300:a0fa:e473:a53f:9557]) by mail.hezmatt.org (Postfix) with ESMTPSA id 7000A156B0 for ; Thu, 11 Jun 2015 13:55:10 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id E6B28A0555; Thu, 11 Jun 2015 23:55:06 +1000 (AEST) Date: Thu, 11 Jun 2015 23:55:06 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20150611135506.GC31838@hezmatt.org> References: <55796DF2.9050705@comodo.com> <6CB05D82CE245B4083BBF3B97E2ED470336FA3@ait-pex01mbx01.win.dtu.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6CB05D82CE245B4083BBF3B97E2ED470336FA3@ait-pex01mbx01.win.dtu.dk> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 13:55:15 -0000 On Thu, Jun 11, 2015 at 11:30:54AM +0000, Hugo Maxwell Connery wrote: > It is not surprising to see a member of a CA propose to expand the > business market around CA's. (CAs and CA monitors). Not a CA here. > The suggestion is reasonable, though I hazard to suggest that a > copylefted reference implementation of log monitoring for some set of > domain names would be a valuable contribution. It's on its way. > Indeed the new CA monitors could use it to make a nice profit/offer a useful service: > Comodo monitors Verisign who monitor GoDaddy who monitor ... You get the idea. Or, one or more independent monitors keep an eye on *everyone*... - Matt -- Java. The elegant simplicity of C++. The blazing speed of Smalltalk. -- From http://c2.com/cgi/wiki?SmalltalkMinusMinus From nobody Thu Jun 11 07:00:48 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 449A21AD289 for ; Thu, 11 Jun 2015 07:00:47 -0700 (PDT) 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 7AOt7KHTgWMs for ; Thu, 11 Jun 2015 07:00:46 -0700 (PDT) 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 24CA61AD255 for ; Thu, 11 Jun 2015 07:00:46 -0700 (PDT) Received: from localhost ([::1]:53477 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z332A-00081Z-05; Thu, 11 Jun 2015 07:00:42 -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: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Thu, 11 Jun 2015 14:00:41 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/79#comment:7 Message-ID: <079.00e238c63b1d3213b22435be0780ca94@tools.ietf.org> References: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, benl@google.com, melinda.shore@gmail.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: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signature must be over something other than just the TBSCertificate 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, 11 Jun 2015 14:00:47 -0000 #79: Precertificate signature must be over something other than just the TBSCertificate Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: rob.stradling@comodo.com | rob.stradling@comodo.com Type: defect | Status: closed Priority: blocker | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: trans From nobody Thu Jun 11 07:02: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 69BD41AD34E for ; Thu, 11 Jun 2015 07:02:36 -0700 (PDT) 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=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 SAr7wUe5AxIL for ; Thu, 11 Jun 2015 07:02:34 -0700 (PDT) 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 944BE1AD35D for ; Thu, 11 Jun 2015 07:01:47 -0700 (PDT) Received: from localhost ([::1]:53545 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z333A-0008Mo-Cr; Thu, 11 Jun 2015 07:01:44 -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, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Thu, 11 Jun 2015 14:01:44 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/58#comment:4 Message-ID: <070.8244527a812cd7126f024ad4112f45bf@tools.ietf.org> References: <055.b793219aebf9d4b50b2e649d13c13ebe@tools.ietf.org> X-Trac-Ticket-ID: 58 In-Reply-To: <055.b793219aebf9d4b50b2e649d13c13ebe@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, linus@nordu.net, benl@google.com, melinda.shore@gmail.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: <20150611140147.944BE1AD35D@ietfa.amsl.com> Resent-Date: Thu, 11 Jun 2015 07:01:47 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #58 (rfc6962-bis): Limit the number of STH's allowed to be published per time unit 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, 11 Jun 2015 14:02:36 -0000 #58: Limit the number of STH's allowed to be published per time unit Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- linus@nordu.net | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Thu Jun 11 08:20:46 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 59A151B2A7E for ; Thu, 11 Jun 2015 08:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 NYAh70yprgcp for ; Thu, 11 Jun 2015 08:20:44 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F121AD06A for ; Thu, 11 Jun 2015 08:20:44 -0700 (PDT) From: Jeremy Rowley To: Rob Stradling , "trans@ietf.org" Thread-Topic: [Trans] Log Monitoring API Thread-Index: AQHQpDgHh+RdYKqihUqpQ1hjsuWTHp2nazuQ Date: Thu, 11 Jun 2015 15:20:41 +0000 Message-ID: References: <55796DF2.9050705@comodo.com> In-Reply-To: <55796DF2.9050705@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.166.110.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Matt Palmer Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 15:20:45 -0000 Hi Rob - we'd like to get involved as we already have an API for our cert m= onitoring software.=20 -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Rob Stradling Sent: Thursday, June 11, 2015 5:16 AM To: trans@ietf.org Cc: Matt Palmer Subject: [Trans] Log Monitoring API 6962-bis notes that: "Those who are concerned about misissue can monitor the logs, asking them regularly for all new entries, and can thus check whether domains they are responsible for have had certificates issued that they did not expect." If you act as a monitor yourself, you can be sure that the logs you're moni= toring aren't misbehaving. You don't have to trust the logs. However, if you use the services of a third-party monitor instead (which I = expect most domain owners would prefer to do), then you have to trust that = that third-party monitor isn't hiding any certs from you. Therefore, ISTM that some domain owners might want to be able to use the se= rvices of multiple independent monitors simultaneously. To facilitate this, it would be useful to define a standard API for queryin= g a monitor. This API would allow callers to search for certs issued to a = particular domain name/space, setup notifications of (mis-)issuance, etc. Matt Palmer and I are planning to start work on a -00 draft soon. If anyon= e else would like to get involved, please let us know. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Thu Jun 11 08:27:53 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 A9F521B2AE2 for ; Thu, 11 Jun 2015 08:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 kFZZ753Tc0Xn for ; Thu, 11 Jun 2015 08:27:50 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B57E1B2B32 for ; Thu, 11 Jun 2015 08:27:50 -0700 (PDT) From: Jeremy Rowley To: Matt Palmer , "trans@ietf.org" Thread-Topic: [Trans] Log Monitoring API Thread-Index: AQHQpDgHh+RdYKqihUqpQ1hjsuWTHp2nkEwAgAAoSgD//7U2UA== Date: Thu, 11 Jun 2015 15:27:47 +0000 Message-ID: References: <55796DF2.9050705@comodo.com> <6CB05D82CE245B4083BBF3B97E2ED470336FA3@ait-pex01mbx01.win.dtu.dk> <20150611135506.GC31838@hezmatt.org> In-Reply-To: <20150611135506.GC31838@hezmatt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.166.110.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 15:27:51 -0000 Also, both monitoring services already out there (DigiCert and Comodo) are = both free... -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Matt Palmer Sent: Thursday, June 11, 2015 7:55 AM To: trans@ietf.org Subject: Re: [Trans] Log Monitoring API On Thu, Jun 11, 2015 at 11:30:54AM +0000, Hugo Maxwell Connery wrote: > It is not surprising to see a member of a CA propose to expand the=20 > business market around CA's. (CAs and CA monitors). Not a CA here. > The suggestion is reasonable, though I hazard to suggest that a=20 > copylefted reference implementation of log monitoring for some set of=20 > domain names would be a valuable contribution. It's on its way. > Indeed the new CA monitors could use it to make a nice profit/offer a use= ful service: > Comodo monitors Verisign who monitor GoDaddy who monitor ... You get the= idea. Or, one or more independent monitors keep an eye on *everyone*... - Matt -- Java. The elegant simplicity of C++. The blazing speed of Smalltalk. -- From http://c2.com/cgi/wiki?SmalltalkMinusMinus _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Thu Jun 11 08:29:01 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 09FF41A1A0B for ; Thu, 11 Jun 2015 08:29:00 -0700 (PDT) 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 Y2VEdYZ0i3H3 for ; Thu, 11 Jun 2015 08:28:57 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8031B2B32 for ; Thu, 11 Jun 2015 08:28:56 -0700 (PDT) Received: (qmail 12206 invoked by uid 1004); 11 Jun 2015 15:28:55 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 11 Jun 2015 16:28:55 +0100 Received: (qmail 25918 invoked by uid 1000); 11 Jun 2015 15:28:54 -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; Thu, 11 Jun 2015 16:28:54 +0100 Message-ID: <5579A936.1020606@comodo.com> Date: Thu, 11 Jun 2015 16:28:54 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: trans@ietf.org References: <55796DF2.9050705@comodo.com><6CB05D82CE245B4083BBF3B97E2ED470336FA3@ait-pex01mbx01.win.dtu.dk> <20150611135506.GC31838@hezmatt.org> In-Reply-To: <20150611135506.GC31838@hezmatt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 15:29:00 -0000 On 11/06/15 14:55, Matt Palmer wrote: > On Thu, Jun 11, 2015 at 11:30:54AM +0000, Hugo Maxwell Connery wrote: >> It is not surprising to see a member of a CA propose to expand the >> business market around CA's. (CAs and CA monitors). Business market? Not my area of expertise. I just sit in the corner and write code. :-) I'm not sure if it'll be viable to monetize a monitoring service directly, especially if there are free monitoring services available. I wouldn't be surprised to see CAs choosing to bundle monitoring for free with their certificate products. But anyway, this list probably isn't the right place to discuss business models. :-) > Not a CA here. > >> The suggestion is reasonable, though I hazard to suggest that a >> copylefted reference implementation of log monitoring for some set of >> domain names would be a valuable contribution. > > It's on its way. Ditto (hopefully). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Jun 11 08:33:01 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 5D95D1B2A6C for ; Thu, 11 Jun 2015 08:33:00 -0700 (PDT) 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 p3HMb4M0xRt4 for ; Thu, 11 Jun 2015 08:32:59 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A3F1B2A62 for ; Thu, 11 Jun 2015 08:32:58 -0700 (PDT) Received: (qmail 12277 invoked by uid 1004); 11 Jun 2015 15:32:57 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Thu, 11 Jun 2015 16:32:57 +0100 Received: (qmail 11653 invoked by uid 1000); 11 Jun 2015 15:32:57 -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; Thu, 11 Jun 2015 16:32:57 +0100 Message-ID: <5579AA29.80308@comodo.com> Date: Thu, 11 Jun 2015 16:32:57 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jeremy Rowley , "trans@ietf.org" References: <55796DF2.9050705@comodo.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Matt Palmer Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 15:33:00 -0000 On 11/06/15 16:20, Jeremy Rowley wrote: > Hi Rob - we'd like to get involved Great. I thought you might. Thanks Jeremy. > as we already have an API for our cert monitoring software. Can you share any documentation? This would be a useful input to our initial discussions. > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Rob Stradling > Sent: Thursday, June 11, 2015 5:16 AM > To: trans@ietf.org > Cc: Matt Palmer > Subject: [Trans] Log Monitoring API > > 6962-bis notes that: > "Those who are concerned about misissue can monitor the logs, asking > them regularly for all new entries, and can thus check whether > domains they are responsible for have had certificates issued that > they did not expect." > > If you act as a monitor yourself, you can be sure that the logs you're monitoring aren't misbehaving. You don't have to trust the logs. > > However, if you use the services of a third-party monitor instead (which I expect most domain owners would prefer to do), then you have to trust that that third-party monitor isn't hiding any certs from you. > > Therefore, ISTM that some domain owners might want to be able to use the services of multiple independent monitors simultaneously. > > To facilitate this, it would be useful to define a standard API for querying a monitor. This API would allow callers to search for certs issued to a particular domain name/space, setup notifications of (mis-)issuance, etc. > > Matt Palmer and I are planning to start work on a -00 draft soon. If anyone else would like to get involved, please let us know. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Jun 11 08:34: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 8A8B41A874E for ; Thu, 11 Jun 2015 08:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009, RCVD_IN_DNSWL_NONE=-0.0001, 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 4hLlHsOK-i8w for ; Thu, 11 Jun 2015 08:34:04 -0700 (PDT) Received: from spamfilter2.dtu.dk (spamfilter2.dtu.dk [130.225.73.113]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C985A1A0076 for ; Thu, 11 Jun 2015 08:34:03 -0700 (PDT) Received: from ait-pexedg01.win.dtu.dk (ait-pexedg01.win.dtu.dk [192.38.82.191]) by spamfilter2.dtu.dk with ESMTP id t5BFXEYL007815-t5BFXEYO007815 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL); Thu, 11 Jun 2015 17:33:21 +0200 Received: from ait-pex01mbx03.win.dtu.dk (192.38.80.17) by ait-pexedg01.win.dtu.dk (192.38.82.191) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 11 Jun 2015 17:33:21 +0200 Received: from ait-pex01mbx01.win.dtu.dk ([169.254.1.56]) by ait-pex01mbx03.win.dtu.dk ([169.254.3.151]) with mapi id 14.03.0235.001; Thu, 11 Jun 2015 17:33:17 +0200 From: Hugo Maxwell Connery To: Jeremy Rowley , Matt Palmer , "trans@ietf.org" Thread-Topic: [Trans] Log Monitoring API Thread-Index: AQHQpDgLQLJoBQ9sb06g0uAnO0m4mZ2nKgxKgAAIbgCAABnlgIAAInCE Date: Thu, 11 Jun 2015 15:33:16 +0000 Message-ID: <6CB05D82CE245B4083BBF3B97E2ED4703370C0@ait-pex01mbx01.win.dtu.dk> References: <55796DF2.9050705@comodo.com> <6CB05D82CE245B4083BBF3B97E2ED470336FA3@ait-pex01mbx01.win.dtu.dk> <20150611135506.GC31838@hezmatt.org>, In-Reply-To: Accept-Language: en-AU, da-DK, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.225.73.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 15:34:05 -0000 From: Trans [trans-bounces@ietf.org] on behalf of Jeremy Rowley [jeremy.row= ley@digicert.com] Sent: Thursday, 11 June 2015 17:27 To: Matt Palmer; trans@ietf.org Subject: Re: [Trans] Log Monitoring API Also, both monitoring services already out there (DigiCert and Comodo) are = both free... # Okay. I shut up now. But, the reference implementation is important bec= ause it enables other services to be gratis if those deployed change their = status. # # Hats off to all for their efforts in this essential area/service/work. # # With respect, Hugo Connery [snip].= From nobody Thu Jun 11 08:35:19 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 D1AD91AD333 for ; Thu, 11 Jun 2015 08:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 69n-U0j-SdZs for ; Thu, 11 Jun 2015 08:35:14 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B45E1A891E for ; Thu, 11 Jun 2015 08:35:14 -0700 (PDT) From: Jeremy Rowley To: Rob Stradling , "trans@ietf.org" Thread-Topic: [Trans] Log Monitoring API Thread-Index: AQHQpDgHh+RdYKqihUqpQ1hjsuWTHp2nazuQgABosoD//5v00A== Date: Thu, 11 Jun 2015 15:35:12 +0000 Message-ID: References: <55796DF2.9050705@comodo.com> <5579AA29.80308@comodo.com> In-Reply-To: <5579AA29.80308@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [67.166.110.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Matt Palmer Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 15:35:19 -0000 Yes - the API isn't public yet, but I'll see if I can share the documentati= on.=20 Thanks Rob! -----Original Message----- From: Rob Stradling [mailto:rob.stradling@comodo.com]=20 Sent: Thursday, June 11, 2015 9:33 AM To: Jeremy Rowley; trans@ietf.org Cc: Matt Palmer Subject: Re: [Trans] Log Monitoring API On 11/06/15 16:20, Jeremy Rowley wrote: > Hi Rob - we'd like to get involved Great. I thought you might. Thanks Jeremy. > as we already have an API for our cert monitoring software. Can you share any documentation? This would be a useful input to our initi= al discussions. > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Rob Stradling > Sent: Thursday, June 11, 2015 5:16 AM > To: trans@ietf.org > Cc: Matt Palmer > Subject: [Trans] Log Monitoring API > > 6962-bis notes that: > "Those who are concerned about misissue can monitor the logs, asking > them regularly for all new entries, and can thus check whether > domains they are responsible for have had certificates issued that > they did not expect." > > If you act as a monitor yourself, you can be sure that the logs you're mo= nitoring aren't misbehaving. You don't have to trust the logs. > > However, if you use the services of a third-party monitor instead (which = I expect most domain owners would prefer to do), then you have to trust tha= t that third-party monitor isn't hiding any certs from you. > > Therefore, ISTM that some domain owners might want to be able to use the = services of multiple independent monitors simultaneously. > > To facilitate this, it would be useful to define a standard API for query= ing a monitor. This API would allow callers to search for certs issued to = a particular domain name/space, setup notifications of (mis-)issuance, etc. > > Matt Palmer and I are planning to start work on a -00 draft soon. If any= one else would like to get involved, please let us know. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Jun 11 08:44:33 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 239861A87A3 for ; Thu, 11 Jun 2015 08:44:32 -0700 (PDT) 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 c50H7DE0S8of for ; Thu, 11 Jun 2015 08:44:30 -0700 (PDT) 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 EF38C1A8777 for ; Thu, 11 Jun 2015 08:44:29 -0700 (PDT) Received: from localhost ([::1]:58803 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z34eX-0006uY-IB; Thu, 11 Jun 2015 08:44:25 -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: rob.stradling@comodo.com, eranm@google.com X-Trac-Project: trans Date: Thu, 11 Jun 2015 15:44:25 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/4#comment:5 Message-ID: <071.d7c2d7de61df1a6914901e693c02e4e5@tools.ietf.org> References: <056.5caee88c050c0996b0fcac0e32e5cb51@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <056.5caee88c050c0996b0fcac0e32e5cb51@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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 Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #4 (rfc6962-bis): Should we sign TBS for Certificates? 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, 11 Jun 2015 15:44:32 -0000 #4: Should we sign TBS for Certificates? Changes (by rob.stradling@comodo.com): * owner: benl@google.com => rob.stradling@comodo.com * status: new => assigned * milestone: => review Comment: Fixed: https://github.com/google/certificate-transparency- rfcs/commit/81e3c1903b39bfa4b9d4a041ec1e55fba69e41a4. -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Thu Jun 11 08:47:13 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 B78781A88C3 for ; Thu, 11 Jun 2015 08:47:11 -0700 (PDT) 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 nVZ22q4elMGj for ; Thu, 11 Jun 2015 08:47:10 -0700 (PDT) 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 8CC691A87CC for ; Thu, 11 Jun 2015 08:47:10 -0700 (PDT) Received: from localhost ([::1]:58964 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z34h6-0000gF-Ll; Thu, 11 Jun 2015 08:47:04 -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: rob.stradling@comodo.com, eranm@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Thu, 11 Jun 2015 15:47:04 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/4#comment:6 Message-ID: <071.f02961bdd54ffb31b25c2d9893808f74@tools.ietf.org> References: <056.5caee88c050c0996b0fcac0e32e5cb51@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <056.5caee88c050c0996b0fcac0e32e5cb51@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: rob.stradling@comodo.com, eranm@google.com, melinda.shore@gmail.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: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #4 (rfc6962-bis): Should we sign TBS for Certificates? 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, 11 Jun 2015 15:47:11 -0000 #4: Should we sign TBS for Certificates? Changes (by melinda.shore@gmail.com): * status: assigned => closed * resolution: => fixed -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Thu Jun 11 14:41: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 4790B1B31A3 for ; Thu, 11 Jun 2015 14:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-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 B-TIMgfaPADM for ; Thu, 11 Jun 2015 14:40:58 -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 46C671B31A5 for ; Thu, 11 Jun 2015 14:40:57 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:34665 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z3ADX-000FOl-SB for trans@ietf.org; Thu, 11 Jun 2015 17:40:56 -0400 Message-ID: <557A0067.1060003@bbn.com> Date: Thu, 11 Jun 2015 17:40:55 -0400 From: Stephen Kent 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: <55796DF2.9050705@comodo.com> In-Reply-To: <55796DF2.9050705@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 21:41:01 -0000 Rob, > 6962-bis notes that: > "Those who are concerned about misissue can monitor the logs, asking > them regularly for all new entries, and can thus check whether > domains they are responsible for have had certificates issued that > they did not expect." > > If you act as a monitor yourself, you can be sure that the logs you're > monitoring aren't misbehaving. You don't have to trust the logs. I'm not sure I follow your argument above. If I act as my own monitor, I will see the cert issued to me, I can verify that it has one or more SCTs, and I could go to each log for which there is an SCT, to verify that the entry in in the log. But, how do I know that the logs that I contact are not misbehaving? They could show me entries other than ones that might conflict with my name space. Detection of that behavior is the job of the audit function, not a Monitor, right? > However, if you use the services of a third-party monitor instead > (which I expect most domain owners would prefer to do), then you have > to trust that that third-party monitor isn't hiding any certs from you. agreed, but that's not the same as log misbehavior; it's Monitor misbehavior. > Therefore, ISTM that some domain owners might want to be able to use > the services of multiple independent monitors simultaneously. sure. > To facilitate this, it would be useful to define a standard API for > querying a monitor. This API would allow callers to search for certs > issued to a particular domain name/space, setup notifications of > (mis-)issuance, etc. I'm always in favor of interface standards, but this is not the sort of API I would have imagined. I've thought that one might want a standard way for a client of a Monitor to submit the info needed for the Monitor to "protect" the client: a set Subject names/SANs, a set of public keys associated with each Subject/SAN, and a way to inform the client when a cert is logged that does not match the supplied info. One also should be able to include an indication of what cert profile these certs are supposed to match, e.g., DV, EV, SMIME, IPsec, ... Consider this my contribution to your draft. Steve From nobody Thu Jun 11 14:42:04 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 E26261B31A8 for ; Thu, 11 Jun 2015 14:42:03 -0700 (PDT) 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 89zJ7MQi9J3i for ; Thu, 11 Jun 2015 14:42:02 -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 CAAEF1B31A5 for ; Thu, 11 Jun 2015 14:42:02 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:34668 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z3AEb-000FPC-Ri for trans@ietf.org; Thu, 11 Jun 2015 17:42:01 -0400 Message-ID: <557A00A9.5010906@bbn.com> Date: Thu, 11 Jun 2015 17:42:01 -0400 From: Stephen Kent 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: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> <079.727c660183267c66b37706330f6dc562@tools.ietf.org> In-Reply-To: <079.727c660183267c66b37706330f6dc562@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signature must be over something other than just the TBSCertificate 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 Jun 2015 21:42:04 -0000 what does it mean to not be "an X509 signature"? I thought the intent was to use a CMS object, and thus the signature would be defined by that (profiled) CMS object. > #79: Precertificate signature must be over something other than just the > TBSCertificate > > Changes (by benl@google.com): > > * milestone: => review > > > Comment: > > After discussion with Rob, core point is that the CMS signature is not an > X509 signature. > > Fixed at https://github.com/google/certificate-transparency- > rfcs/commit/546e6e9451186e96ddd7b54ca02f17c8d86f951e. > From nobody Fri Jun 12 02:05:14 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 34D741A89B1 for ; Fri, 12 Jun 2015 02:05:13 -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_05=-0.5, 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 UHZOFjSnGy6v for ; Fri, 12 Jun 2015 02:05:06 -0700 (PDT) Received: from mail.hezmatt.org (minotaur.hezmatt.org [IPv6:2a01:4f8:121:440f:e2e4:22bb:25f5:6cad]) by ietfa.amsl.com (Postfix) with ESMTP id 049FB1A89BB for ; Fri, 12 Jun 2015 02:04:47 -0700 (PDT) Received: from mistress.home.hezmatt.org (2001-44b8-3196-7300-7136-1598-d4b9-4871.static.ipv6.internode.on.net [IPv6:2001:44b8:3196:7300:7136:1598:d4b9:4871]) by mail.hezmatt.org (Postfix) with ESMTPSA id 730D8159A2 for ; Fri, 12 Jun 2015 09:04:45 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 6409FA04EA; Fri, 12 Jun 2015 19:05:07 +1000 (AEST) Date: Fri, 12 Jun 2015 19:05:07 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20150612090507.GL31838@hezmatt.org> References: <55796DF2.9050705@comodo.com> <557A0067.1060003@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <557A0067.1060003@bbn.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 09:05:13 -0000 Hi Stephen, On Thu, Jun 11, 2015 at 05:40:55PM -0400, Stephen Kent wrote: > Rob, > >To facilitate this, it would be useful to define a standard API for > >querying a monitor. This API would allow callers to search for certs > >issued to a particular domain name/space, setup notifications of > >(mis-)issuance, etc. > > I'm always in favor of interface standards, but this is not the sort of > API I would have imagined. I've thought that one might want a standard > way for a client of a Monitor to submit the info needed for the Monitor to > "protect" the client: a set Subject names/SANs, a set of public keys > associated with each Subject/SAN, and a way to inform the client when a > cert is logged that does not match the supplied info. One also should be > able to include an indication of what cert profile these certs are > supposed to match, e.g., DV, EV, SMIME, IPsec, ... I believe that comes under Rob's very general point of "setup notifications for (mis-)issuance". I certainly intend to try and provide means for specifying as much detail as possible to assist in detecting misissuance. > Consider this my contribution to your draft. Thanks for your input. It's good to know that someone else thinks it would be useful to be able to manipulate notifications programmatically. - Matt -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There's nothing user-friendly about learning to read." -- Alan Kay From nobody Fri Jun 12 02:49: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 C99891A8AEA for ; Fri, 12 Jun 2015 02:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 VcPq5IXV1lAb for ; Fri, 12 Jun 2015 02:49:49 -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 E9FE41A8AE8 for ; Fri, 12 Jun 2015 02:49:48 -0700 (PDT) Received: (qmail 28977 invoked by uid 1004); 12 Jun 2015 09:49:46 -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 Jun 2015 10:49:46 +0100 Received: (qmail 24871 invoked by uid 1000); 12 Jun 2015 09:49:46 -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 Jun 2015 10:49:46 +0100 Message-ID: <557AAB39.4000109@comodo.com> Date: Fri, 12 Jun 2015 10:49:45 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Matt Palmer , trans@ietf.org References: <55796DF2.9050705@comodo.com><557A0067.1060003@bbn.com> <20150612090507.GL31838@hezmatt.org> In-Reply-To: <20150612090507.GL31838@hezmatt.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 09:49:53 -0000 On 12/06/15 10:05, Matt Palmer wrote: > Hi Stephen, > > On Thu, Jun 11, 2015 at 05:40:55PM -0400, Stephen Kent wrote: >> Rob, > >>> To facilitate this, it would be useful to define a standard API for >>> querying a monitor. This API would allow callers to search for certs >>> issued to a particular domain name/space, setup notifications of >>> (mis-)issuance, etc. >> >> I'm always in favor of interface standards, but this is not the sort of >> API I would have imagined. I've thought that one might want a standard >> way for a client of a Monitor to submit the info needed for the Monitor to >> "protect" the client: a set Subject names/SANs, a set of public keys >> associated with each Subject/SAN, and a way to inform the client when a >> cert is logged that does not match the supplied info. One also should be >> able to include an indication of what cert profile these certs are >> supposed to match, e.g., DV, EV, SMIME, IPsec, ... > > I believe that comes under Rob's very general point of "setup notifications > for (mis-)issuance". Yep. Thanks Matt. > I certainly intend to try and provide means for > specifying as much detail as possible to assist in detecting misissuance. > >> Consider this my contribution to your draft. > > Thanks for your input. It's good to know that someone else thinks it would > be useful to be able to manipulate notifications programmatically. > > - Matt > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Fri Jun 12 02:57:55 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 6D2221A8BC2 for ; Fri, 12 Jun 2015 02:57:53 -0700 (PDT) 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 O_6HJD78eDPV for ; Fri, 12 Jun 2015 02:57:44 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F301A8AF9 for ; Fri, 12 Jun 2015 02:57:43 -0700 (PDT) Received: (qmail 19666 invoked by uid 1004); 12 Jun 2015 09:57:42 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 12 Jun 2015 10:57:42 +0100 Received: (qmail 29481 invoked by uid 1000); 12 Jun 2015 09:57:42 -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 Jun 2015 10:57:42 +0100 Message-ID: <557AAD15.8060001@comodo.com> Date: Fri, 12 Jun 2015 10:57:41 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <55796DF2.9050705@comodo.com> <557A0067.1060003@bbn.com> In-Reply-To: <557A0067.1060003@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 09:57:53 -0000 On 11/06/15 22:40, Stephen Kent wrote: > Rob, > >> 6962-bis notes that: >> "Those who are concerned about misissue can monitor the logs, asking >> them regularly for all new entries, and can thus check whether >> domains they are responsible for have had certificates issued that >> they did not expect." >> >> If you act as a monitor yourself, you can be sure that the logs you're >> monitoring aren't misbehaving. You don't have to trust the logs. > > I'm not sure I follow your argument above. Hi Steve. I was aiming for a quick summary rather than a fully-specified problem statement. You're correct that the audit role is vital too. If the CT ecosystem is functioning as intended, then a monitor can be sure that they've seen every logged cert, without having to trust the log. But a client of a monitor has to trust the monitor. Is that any clearer? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jun 12 06:31:05 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 E6B1D1AC39E for ; Fri, 12 Jun 2015 06:31:04 -0700 (PDT) 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 6EDBnZ51zviB for ; Fri, 12 Jun 2015 06:30:57 -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 1DFBA1AC39D for ; Fri, 12 Jun 2015 06:30:56 -0700 (PDT) Received: (qmail 5608 invoked by uid 1004); 12 Jun 2015 13:30:54 -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 Jun 2015 14:30:54 +0100 Received: (qmail 7318 invoked by uid 1000); 12 Jun 2015 13:30:53 -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 Jun 2015 14:30:53 +0100 Message-ID: <557ADF0D.4060801@comodo.com> Date: Fri, 12 Jun 2015 14:30:53 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org><079.727c660183267c66b37706330f6dc562@tools.ietf.org> <557A00A9.5010906@bbn.com> In-Reply-To: <557A00A9.5010906@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signaturemust be over something other than just the TBSCertificate 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 Jun 2015 13:31:05 -0000 On 11/06/15 22:42, Stephen Kent wrote: > what does it mean to not be "an X509 signature"? > > I thought the intent was to use a CMS object, and thus the signature > would be defined by that (profiled) CMS object. Hi Steve. That's correct. At the top of ticket #79 I wrote: "If I understand the CMS spec correctly, then we're currently defining a Precertificate to be a CMS structure that contains a TBSCertificate and a signature over just that TBSCertificate. That means that the components of a Precertificate can be trivially rearranged into an X.509 certificate with a valid signature!" It turns out that I didn't understand correctly. :-) Ben added some text to help clarify the situation: "Note that, because of the structure of CMS, the signature on the CMS object will not be a valid X.509v3 signature and so cannot be used to construct a certificate from the precertificate." >> #79: Precertificate signature must be over something other than just the >> TBSCertificate >> >> Changes (by benl@google.com): >> >> * milestone: => review >> >> >> Comment: >> >> After discussion with Rob, core point is that the CMS signature is >> not an X509 signature. >> >> Fixed at https://github.com/google/certificate-transparency- >> rfcs/commit/546e6e9451186e96ddd7b54ca02f17c8d86f951e. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Jun 12 08:28: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 D91BC1A0395 for ; Fri, 12 Jun 2015 08:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrmmJEyF-7fB for ; Fri, 12 Jun 2015 08:27:58 -0700 (PDT) Received: from mail-vn0-x244.google.com (mail-vn0-x244.google.com [IPv6:2607:f8b0:400c:c0f::244]) (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 BCAF01A020B for ; Fri, 12 Jun 2015 08:27:58 -0700 (PDT) Received: by vnbf190 with SMTP id f190so5463664vnb.3 for ; Fri, 12 Jun 2015 08:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SOMCoqEfZ3553Lo1jBEbpHCkvAZwjKHZANTQRqNuV+I=; b=slZuLfVdRETxbNRGJGb4KtepUmbojeDlnLFN1Su/KOGxx3CJjUzD7VpXvLBKYzgbYj Ru8QeFHVtGfqACz0SMsb9LhikfUKssBC7qgqKGgFrxM8UxK6P/Czh6NvbiWNVMV9qHoa JPCF4qIM5XFhjg1kefeKPIWk35FMxMe7178aSlL12tYi42huheQZkRTsed06HzWmg7Qk Z1H6iXdiC2C+kzS5C4sswO7iw0kUy+oTAmDzut3aYajwAEoz0LqcHrmzVZa36ESCwUDV O/A9X4seGaFdPctmrqQzGUtCMn7GAlAQSp7Z11rbfuw6HidUetyrOVUK+Yj59UPYtZOt 3Baw== MIME-Version: 1.0 X-Received: by 10.52.35.107 with SMTP id g11mr26600279vdj.37.1434122877820; Fri, 12 Jun 2015 08:27:57 -0700 (PDT) Received: by 10.52.110.2 with HTTP; Fri, 12 Jun 2015 08:27:57 -0700 (PDT) In-Reply-To: <557ADF0D.4060801@comodo.com> References: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org> <079.727c660183267c66b37706330f6dc562@tools.ietf.org> <557A00A9.5010906@bbn.com> <557ADF0D.4060801@comodo.com> Date: Fri, 12 Jun 2015 17:27:57 +0200 Message-ID: From: Erwann Abalea To: Rob Stradling Content-Type: multipart/alternative; boundary=20cf3079c0a4b262ff051853c09e Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signaturemust be over something other than just the TBSCertificate 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 Jun 2015 15:28:01 -0000 --20cf3079c0a4b262ff051853c09e Content-Type: text/plain; charset=UTF-8 Bonjour, 2015-06-12 15:30 GMT+02:00 Rob Stradling : > On 11/06/15 22:42, Stephen Kent wrote: > >> what does it mean to not be "an X509 signature"? >> >> I thought the intent was to use a CMS object, and thus the signature >> would be defined by that (profiled) CMS object. >> > > Hi Steve. That's correct. > > At the top of ticket #79 I wrote: > "If I understand the CMS spec correctly, then we're currently defining a > Precertificate to be a CMS structure that contains a TBSCertificate and a > signature over just that TBSCertificate. > That means that the components of a Precertificate can be trivially > rearranged into an X.509 certificate with a valid signature!" > > It turns out that I didn't understand correctly. :-) > > Ben added some text to help clarify the situation: > "Note that, because of the structure of CMS, the signature on the CMS > object will not be a valid X.509v3 signature and so cannot be used to > construct a certificate from the precertificate." > And this is true if and only if the SignedData.encapContentInfo.eContentType field is set to a value different from id-data (id-data is the OID { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }). If the eContentType is set to id-data, the CMS producer can omit the SignedAttributes, the signature is performed over the eContent (which contains the TBSCertificate), and the resulting signed precertificate can be manipulated to become a valid certificate: - take the TBSCertificate and the signature from the CMS/precertificate, - build a SEQUENCE containing the TBSCertificate, a properly formatted SignatureAlgorithm, and the signature (reencode it from OCTET STRING to BIT STRING) - you have a valid certificate To avoid this, just make sure that the TBD in the current rfc6962-bis is NOT id-data. Or require the presence of the SignedAttributes. #79: Precertificate signature must be over something other than just the >>> TBSCertificate >>> >>> Changes (by benl@google.com): >>> >>> * milestone: => review >>> >>> >>> Comment: >>> >>> After discussion with Rob, core point is that the CMS signature is >>> not an X509 signature. >>> >>> Fixed at https://github.com/google/certificate-transparency- >>> rfcs/commit/546e6e9451186e96ddd7b54ca02f17c8d86f951e. >>> >> This commit has nothing to do with the ticket ;) --20cf3079c0a4b262ff051853c09e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bonjour,

2015-06-12 15:30 GMT+02:00 Rob Stradling <rob.stradling@com= odo.com>:
On 11/06/15 22= :42, Stephen Kent wrote:
what does it mean to not be "an X509 signature"?

I thought the intent was to use a CMS object, and thus the signature
would be defined by that (profiled) CMS object.

 Hi Steve.=C2=A0 That's correct.

At the top of ticket #79 I wrote:
"If I understand the CMS spec correctly, then we're currently defi= ning a Precertificate to be a CMS structure that contains a TBSCertificate = and a signature over just that TBSCertificate.
That means that the components of a Precertificate can be trivially rearran= ged into an X.509 certificate with a valid signature!"

 It turns out that I didn't understand correctly.=C2=A0 :-)

Ben added some text to help clarify the situation:
"Note that, because of the structure of CMS, the signature on the CMS = object will not be a valid X.509v3 signature and so cannot be used to const= ruct a certificate from the precertificate."

And this is true if and only if the Si= gnedData.encapContentInfo.eContentType field is set to a value different fr= om id-data (id-data is the OID { iso(1) member-body(2) us(840) rsadsi(11354= 9) pkcs(1) pkcs7(7) 1 }).

If the eContentType is s= et to id-data, the CMS producer can omit the SignedAttributes, the signatur= e is performed over the eContent (which contains the TBSCertificate), and t= he resulting signed precertificate can be manipulated to become a valid cer= tificate:
=C2=A0 - take the TBSCertificate and the signature from= the CMS/precertificate,
=C2=A0 - build a SEQUENCE containing the= TBSCertificate, a properly formatted SignatureAlgorithm, and the signature= (reencode it from OCTET STRING to BIT STRING)
=C2=A0 - you have = a valid certificate

To avoid this, just make sure = that the TBD in the current rfc6962-bis is NOT id-data. Or require the pres= ence of the SignedAttributes.

#79: Precertificate signature must be over something other than just the TBSCertificate

Changes (by benl@googl= e.com):

=C2=A0 * milestone:=C2=A0 =C2=A0=3D> review


Comment:

=C2=A0 After discussion with Rob, core point is that the CMS signature is not an X509 signature.

=C2=A0 Fixed at https://github.com/google/certifi= cate-transparency-
=C2=A0 rfcs/commit/546e6e9451186e96ddd7b54ca02f17c8d86f951e.

This commit has nothing to do with = the ticket ;)

--20cf3079c0a4b262ff051853c09e-- From nobody Fri Jun 12 08:45:48 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 211AC1A0338 for ; Fri, 12 Jun 2015 08:45:41 -0700 (PDT) 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 RG-AmkualIXp for ; Fri, 12 Jun 2015 08:45:33 -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 08A4B1A1A7F for ; Fri, 12 Jun 2015 08:45:10 -0700 (PDT) Received: (qmail 19044 invoked by uid 1004); 12 Jun 2015 15:45:07 -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 Jun 2015 16:45:07 +0100 Received: (qmail 29596 invoked by uid 1000); 12 Jun 2015 15:45:07 -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 Jun 2015 16:45:07 +0100 Message-ID: <557AFE82.9000405@comodo.com> Date: Fri, 12 Jun 2015 16:45:06 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Erwann Abalea , Ben Laurie References: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org><079.727c660183267c66b37706330f6dc562@tools.ietf.org><557A00A9.5010906@bbn.com><557ADF0D.4060801@comodo.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signaturemustbe over something other than just the TBSCertificate 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 Jun 2015 15:45:41 -0000 On 12/06/15 16:27, Erwann Abalea wrote: > If the eContentType is set to id-data, the CMS producer can omit the > SignedAttributes, the signature is performed over the eContent (which > contains the TBSCertificate), and the resulting signed precertificate > can be manipulated to become a valid certificate: > - take the TBSCertificate and the signature from the CMS/precertificate, > - build a SEQUENCE containing the TBSCertificate, a properly > formatted SignatureAlgorithm, and the signature (reencode it from OCTET > STRING to BIT STRING) > - you have a valid certificate Indeed. > To avoid this, just make sure that the TBD in the current rfc6962-bis is > NOT id-data. Or require the presence of the SignedAttributes. Ben, do you want to allocate an OID from the Google arc for this? > After discussion with Rob, core point is that the CMS > signature is > not an X509 signature. > > Fixed at https://github.com/google/certificate-transparency- > rfcs/commit/546e6e9451186e96ddd7b54ca02f17c8d86f951e. > > This commit has nothing to do with the ticket ;) It was a series of several commits. That was the final one. Click the link just to the right of "1 parent". Then do the same again, and you should arrive at... https://github.com/google/certificate-transparency-rfcs/commit/c62061213c5085cf4d0f266dc8aa2c803bcf4c8f -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Fri Jun 12 09:36:50 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 C9F5B1A923E for ; Fri, 12 Jun 2015 09:36:49 -0700 (PDT) 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=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 MS3VoF74LZ7S for ; Fri, 12 Jun 2015 09:36:48 -0700 (PDT) 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 CD1841A923D for ; Fri, 12 Jun 2015 09:36:48 -0700 (PDT) Received: from localhost ([::1]:55787 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z3Rwm-0003xy-23; Fri, 12 Jun 2015 09:36:48 -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, pphaneuf@gmail.com X-Trac-Project: trans Date: Fri, 12 Jun 2015 16:36:47 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/88 Message-ID: <058.a978a1b85df450a3b12c330a07fecb4e@tools.ietf.org> X-Trac-Ticket-ID: 88 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, pphaneuf@gmail.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: <20150612163648.CD1841A923D@ietfa.amsl.com> Resent-Date: Fri, 12 Jun 2015 09:36:48 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #88 (client-behavior): get-entries: "end" should be greater-than-or-equal to "start" 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: Fri, 12 Jun 2015 16:36:50 -0000 #88: get-entries: "end" should be greater-than-or-equal to "start" In section 4.7 ("Retrieve Entries from Log"), valid values for "start" and "end" are expressed in painstaking details... But never is it mentioned that "start <= end". It does seem obvious, but should be written down, I think. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: client- | Version: behavior | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jun 12 09:37:16 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 041811A92B9 for ; Fri, 12 Jun 2015 09:37:15 -0700 (PDT) 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=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 OkhGRQQKyAGi for ; Fri, 12 Jun 2015 09:37:14 -0700 (PDT) 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 0859A1A923E for ; Fri, 12 Jun 2015 09:37:14 -0700 (PDT) Received: from localhost ([::1]:55799 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z3RxB-00042m-QK; Fri, 12 Jun 2015 09:37:13 -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, pphaneuf@gmail.com X-Trac-Project: trans Date: Fri, 12 Jun 2015 16:37:13 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/88#comment:1 Message-ID: <073.5653446215e792f8ad961cbbe492bfe1@tools.ietf.org> References: <058.a978a1b85df450a3b12c330a07fecb4e@tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <058.a978a1b85df450a3b12c330a07fecb4e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, pphaneuf@gmail.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: <20150612163714.0859A1A923E@ietfa.amsl.com> Resent-Date: Fri, 12 Jun 2015 09:37:14 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #88 (rfc6962-bis): get-entries: "end" should be greater-than-or-equal to "start" 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: Fri, 12 Jun 2015 16:37:15 -0000 #88: get-entries: "end" should be greater-than-or-equal to "start" Changes (by pphaneuf@gmail.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jun 12 09:41:22 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 8844B1A92FF for ; Fri, 12 Jun 2015 09:41:20 -0700 (PDT) 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=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 ZY20LKZKPRE1 for ; Fri, 12 Jun 2015 09:41:19 -0700 (PDT) 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 B087A1A92DD for ; Fri, 12 Jun 2015 09:41:19 -0700 (PDT) Received: from localhost ([::1]:55989 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z3S17-0006JB-RV; Fri, 12 Jun 2015 09:41:17 -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, pphaneuf@gmail.com, benl@google.com X-Trac-Project: trans Date: Fri, 12 Jun 2015 16:41:17 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/88#comment:2 Message-ID: <073.4a26175b41434e1742ee98c85bc5a83b@tools.ietf.org> References: <058.a978a1b85df450a3b12c330a07fecb4e@tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <058.a978a1b85df450a3b12c330a07fecb4e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, pphaneuf@gmail.com, benl@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: <20150612164119.B087A1A92DD@ietfa.amsl.com> Resent-Date: Fri, 12 Jun 2015 09:41:19 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #88 (rfc6962-bis): get-entries: "end" should be greater-than-or-equal to "start" 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: Fri, 12 Jun 2015 16:41:20 -0000 #88: get-entries: "end" should be greater-than-or-equal to "start" Comment (by benl@google.com): In the same area, I suspect that end > tree_size MUST be permitted, to allow for skew. As it stands, its not really compatible with the final paragraph: 'Because of skew, it is possible the log server will not have any entries between "start" and "end". In this case it MUST return an empty "entries" array.' -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jun 12 10:27:31 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 E347D1ACDC4 for ; Fri, 12 Jun 2015 10:27:29 -0700 (PDT) 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=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 W5rydIvzdy-6 for ; Fri, 12 Jun 2015 10:27:28 -0700 (PDT) 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 A42F11ACDC2 for ; Fri, 12 Jun 2015 10:27:28 -0700 (PDT) Received: from localhost ([::1]:60410 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z3Sjo-0004aI-4Q; Fri, 12 Jun 2015 10:27:28 -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, pphaneuf@gmail.com X-Trac-Project: trans Date: Fri, 12 Jun 2015 17:27:28 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/89 Message-ID: <058.a3b286b289bea15e728f874a714d34be@tools.ietf.org> X-Trac-Ticket-ID: 89 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, pphaneuf@gmail.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: <20150612172728.A42F11ACDC2@ietfa.amsl.com> Resent-Date: Fri, 12 Jun 2015 10:27:28 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #89 (rfc6962-bis): get-entries: "end" greater than "tree_size" should be allowed 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: Fri, 12 Jun 2015 17:27:30 -0000 #89: get-entries: "end" greater than "tree_size" should be allowed There could be skew between frontends of a log server that uses a distributed implementation, which means that a get-sth request could return a certain tree size, but that a follow up get-entries request could go to another frontend that is slightly behind, and not have all the entries necessary. At the minimum, this bit of section 4.7 should be removed: > The "start" and "end" parameters SHOULD be within the range 0 <= x < "tree_size" as returned by "get-sth" in Section 4.3. That paragraph already somewhat conflicts with this later paragraph in the same section: > Because of skew, it is possible the log server will not have any entries between "start" and "end". In this case it MUST return an empty "entries" array. This should be clarified that a log server might not have *all* the entries (it might still have some of them). If a subset is returned, I feel that the entries should still be sequential and begin with the entry specified by "start", of course. Looking at some of the new methods designed to work reduce the impact of possible skew (like "get-all-by-hash"), one could imagine a new method that returns both entries and the latest STH, so that whatever is obtained can be verified. For example, if "get-sth" gave a tree size of 10, and the client then issues a "get-entries" with a "start" of 5, and an "end" of 9, but the frontend this request goes to only has a tree size of 8, it could return entries 5 to 7, as well as an STH with a tree size of 8, so that those entries could be verified. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jun 12 10:28:14 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 3DA9B1ACDC2 for ; Fri, 12 Jun 2015 10:28:13 -0700 (PDT) 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=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 mGEOrL8TPgSV for ; Fri, 12 Jun 2015 10:28:12 -0700 (PDT) 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 6CF111ACDC0 for ; Fri, 12 Jun 2015 10:28:12 -0700 (PDT) Received: from localhost ([::1]:60449 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z3SkU-0007Yv-1s; Fri, 12 Jun 2015 10:28:10 -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, pphaneuf@gmail.com, benl@google.com X-Trac-Project: trans Date: Fri, 12 Jun 2015 17:28:10 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/88#comment:3 Message-ID: <073.543bc65719bf7594f6828075b24437f9@tools.ietf.org> References: <058.a978a1b85df450a3b12c330a07fecb4e@tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <058.a978a1b85df450a3b12c330a07fecb4e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, pphaneuf@gmail.com, benl@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: <20150612172812.6CF111ACDC0@ietfa.amsl.com> Resent-Date: Fri, 12 Jun 2015 10:28:12 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #88 (rfc6962-bis): get-entries: "end" should be greater-than-or-equal to "start" 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: Fri, 12 Jun 2015 17:28:13 -0000 #88: get-entries: "end" should be greater-than-or-equal to "start" Comment (by pphaneuf@gmail.com): This issue with skew is correct, but separate, I'd say. I filed #89 to track it. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jun 12 10:34:49 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 D7D261ACDCC for ; Fri, 12 Jun 2015 10:34:47 -0700 (PDT) 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 EyvAiNWDjD1J for ; Fri, 12 Jun 2015 10:34:46 -0700 (PDT) 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 828B01ACDD4 for ; Fri, 12 Jun 2015 10:34:46 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:46097 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z3Sqq-0000oW-Ve for trans@ietf.org; Fri, 12 Jun 2015 13:34:45 -0400 Message-ID: <557B1834.8040706@bbn.com> Date: Fri, 12 Jun 2015 13:34:44 -0400 From: Stephen Kent 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: <55796DF2.9050705@comodo.com> <557A0067.1060003@bbn.com> <557AAD15.8060001@comodo.com> In-Reply-To: <557AAD15.8060001@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Log Monitoring API 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 Jun 2015 17:34:48 -0000 Rob, > On 11/06/15 22:40, Stephen Kent wrote: >> Rob, >> >>> 6962-bis notes that: >>> "Those who are concerned about misissue can monitor the logs, asking >>> them regularly for all new entries, and can thus check whether >>> domains they are responsible for have had certificates issued that >>> they did not expect." >>> >>> If you act as a monitor yourself, you can be sure that the logs you're >>> monitoring aren't misbehaving. You don't have to trust the logs. >> >> I'm not sure I follow your argument above. > > > Hi Steve. I was aiming for a quick summary rather than a > fully-specified problem statement. You're correct that the audit role > is vital too. > > If the CT ecosystem is functioning as intended, then a monitor can be > sure that they've seen every logged cert, without having to trust the > log. yes. > > But a client of a monitor has to trust the monitor. agreed. > > Is that any clearer? yes. From nobody Fri Jun 12 10:38:24 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 9615E1ACDEC for ; Fri, 12 Jun 2015 10:38:22 -0700 (PDT) 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 X4K2z5bS-j4t for ; Fri, 12 Jun 2015 10:38:20 -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 D9D1D1ACDE7 for ; Fri, 12 Jun 2015 10:38:19 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:37695 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z3SuI-000ObG-R1 for trans@ietf.org; Fri, 12 Jun 2015 13:38:18 -0400 Message-ID: <557B190A.8090300@bbn.com> Date: Fri, 12 Jun 2015 13:38:18 -0400 From: Stephen Kent 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: <064.abd6b6595a6018105f8527089cb573db@tools.ietf.org><079.727c660183267c66b37706330f6dc562@tools.ietf.org> <557A00A9.5010906@bbn.com> <557ADF0D.4060801@comodo.com> In-Reply-To: <557ADF0D.4060801@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signaturemust be over something other than just the TBSCertificate 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 Jun 2015 17:38:22 -0000 Rob, > On 11/06/15 22:42, Stephen Kent wrote: >> what does it mean to not be "an X509 signature"? >> >> I thought the intent was to use a CMS object, and thus the signature >> would be defined by that (profiled) CMS object. > > Hi Steve. That's correct. > > At the top of ticket #79 I wrote: > "If I understand the CMS spec correctly, then we're currently defining > a Precertificate to be a CMS structure that contains a TBSCertificate > and a signature over just that TBSCertificate. > That means that the components of a Precertificate can be trivially > rearranged into an X.509 certificate with a valid signature!" > > It turns out that I didn't understand correctly. :-) happens to all of us ;-) > > Ben added some text to help clarify the situation: > "Note that, because of the structure of CMS, the signature on the CMS > object will not be a valid X.509v3 signature and so cannot be used to > construct a certificate from the precertificate." I might say: "The signature on the CMS structure used to convey a pre-certificate is not the same as the signature that appears in the X.509 certificate, per se." Steve From dorothy.e.cooley6.civ@mail.mil Tue Jun 16 11:34:45 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 4FF281A907B for ; Tue, 16 Jun 2015 11:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 EuPK4nlt78MZ for ; Tue, 16 Jun 2015 11:34:43 -0700 (PDT) Received: from ukel19pa18.eemsg.mail.mil (ukel19pa18.eemsg.mail.mil [214.24.22.86]) by ietfa.amsl.com (Postfix) with ESMTP id 1192F1A9077 for ; Tue, 16 Jun 2015 11:34:42 -0700 (PDT) Received: from edge-mech01.mail.mil ([214.21.130.102]) by ukel19pa18.eemsg.mail.mil with ESMTP; 16 Jun 2015 18:34:32 +0000 Received: from UMECHPAOF.easf.csd.disa.mil (214.21.130.33) by edge-mech01.mail.mil (214.21.130.102) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 16 Jun 2015 18:34:31 +0000 Received: from UMECHPAO0.easf.csd.disa.mil ([169.254.4.60]) by umechpaof.easf.csd.disa.mil ([214.21.130.33]) with mapi id 14.03.0224.002; Tue, 16 Jun 2015 18:34:31 +0000 From: "Cooley, Dorothy E CIV (US)" To: "trans@ietf.org" Thread-Topic: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt Thread-Index: AdCoYxdIZ5ANHNmMSIy6C660aXNahw== Content-Class: urn:content-classes:message Date: Tue, 16 Jun 2015 18:34:30 +0000 Message-ID: <91BAAC47CA9DAE4BA6E71BA256326D9605A3EAB8@umechpao0.easf.csd.disa.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [214.21.97.84] Content-Type: multipart/alternative; boundary="_000_91BAAC47CA9DAE4BA6E71BA256326D9605A3EAB8umechpao0easfcs_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 16 Jun 2015 11:37:57 -0700 Cc: "kent@bbn.com" Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 16 Jun 2015 18:37:11 -0000 --_000_91BAAC47CA9DAE4BA6E71BA256326D9605A3EAB8umechpao0easfcs_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, This is my first post on list ever, so be gentle :) General: This is actually an attack model with an analysis of detection an= d consequence. Perhaps the name could be changed to reflect that. General: 2.2=92s outline should follow 2.1=92s outline. Move =91Malicious= or conspiring third party Monitor=92 to section 2.2.1.3 and remove it from= 2.2.1.1.3 and 2.2.1.2.1. It may be complete either way, but it is more li= kely to look complete if it is symmetric. General: Remove the references to the Notes in Sections 2 and 3. They wil= l stand alone. Section 2.1.1.1.1: Change to: =93If a Subject is tracking the log(s) to which a certificate was submitted= , and is performing self-monitoring, then it will be able to detect a bogus= (pre-) certificate and request revocation. In this case, the CA will make = use of the log entry, supplied by the Subject to determine the serial numbe= r of the mis-issued certificate, and investigate/revoke it.=94 Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 : Make the =93If there = are many logs, it may not be feasible for a Subject to track all of them=94= a note in Section 4 (it is sort of Note 1 currently). Section 2.1.1.1.2: Change this in a similar manner to 2.1.1.1.1, for the s= ame reasons. Section 2.1.1.2.2: How will gossiping detect this? The Log owner issues t= he SCT, but doesn=92t actually put the certificate into the log. How is th= is detectable by gossiping? Not like an attacker is going to submit that c= ertificate to multiple logs. He just wants the SCT. Section 2.1.2: Does the 3rd party monitor have a role in the case where th= e certificate isn=92t logged? Should that fact be stated? Perhaps a sente= nce to that effect in Section 2.1.2.3 would be in order? Section 2.1.2.1: Either remove the last sentence in the parenthetical, or = work it into the paragraph without the parenthetical. Section 2.2.1.2: Add a section on Self-monitoring Subject and a section on= benign third party Monitor. Section 2.2.1.1.3 and 2.2.1.2.1: Combine these into Section 2.2.1.3 called= malicious or conspiring third party monitor. Section 3, Syntactic checks: We need to think about whether this makes sen= se. This paper gets much simpler w/out it. Currently not included in rfc6= 962bis. Section 4, Notes: These are issues that will need to be addressed. I woul= d make a more descriptive name and keep them numbered. Section 4, Note 1: Make this two items. First: How are new logs discover= ed by monitors? Second: how does a subject know which logs the monitor is= checking? Deb Cooley dorothy.e.cooley6.civ@mail.mil 410-854-6888 --_000_91BAAC47CA9DAE4BA6E71BA256326D9605A3EAB8umechpao0easfcs_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8A027BAE11603E459757ACE0223BABA5@easf.csd.disa.mil> Content-Transfer-Encoding: quoted-printable

All,

 

This is my first post on list ever, so be gentle :)

 

 

General:  This is actually an attack model with an analysis of dete= ction and consequence.  Perhaps the name could be changed to reflect t= hat.


General:  2.2=92s outline should follow 2.1=92s outline.  Move = =91Malicious or conspiring third party Monitor=92 to section 2.2.1.3 and re= move it from 2.2.1.1.3 and 2.2.1.2.1.  It may be complete either way, = but it is more likely to look complete if it is symmetric.


General:  Remove the references to the Notes in Sections 2 and 3. = ; They will stand alone.


Section 2.1.1.1.1:  Change to:
=93If a Subject is tracking the log(s) to which a certificate was submitted= , and is performing self-monitoring, then it will be able to detect a bogus= (pre-) certificate and request revocation. In this case, the CA will make = use of the log entry, supplied by the Subject to determine the serial number of the mis-issued certificate, = and investigate/revoke it.=94


Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 :  Make the =93If t= here are many logs, it may not be feasible for a Subject to track all of th= em=94 a note in Section 4 (it is sort of Note 1 currently).


Section 2.1.1.1.2:  Change this in a similar manner to 2.1.1.1.1, for = the same reasons.

Section 2.1.1.2.2:  How will gossiping detect this?  The Log o= wner issues the SCT, but doesn=92t actually put the certificate into the lo= g.  How is this detectable by gossiping?  Not like an attacker is= going to submit that certificate to multiple logs.  He just wants the SCT.


Section 2.1.2:  Does the 3rd party monitor have a role in the case whe= re the certificate isn=92t logged?  Should that fact be stated?  = Perhaps a sentence to that effect in Section 2.1.2.3 would be in order?


Section 2.1.2.1:  Either remove the last sentence in the parenthetical= , or work it into the paragraph without the parenthetical.

 
Section 2.2.1.2:  Add a section on Self-monitoring Subject and a secti= on on benign third party Monitor.


Section 2.2.1.1.3 and 2.2.1.2.1:  Combine these into Section 2.2.1.3 c= alled malicious or conspiring third party monitor.


Section 3, Syntactic checks:  We need to think about whether this make= s sense.  This paper gets much simpler w/out it.  Currently not i= ncluded in rfc6962bis.


Section 4, Notes:  These are issues that will need to be addressed.&nb= sp; I would make a more descriptive name and keep them numbered.

 
Section 4, Note 1:  Make this two items.  First:  How are ne= w logs discovered by monitors?  Second:  how does a subject know = which logs the monitor is checking?

 

Deb Cooley

doro= thy.e.cooley6.civ@mail.mil

410-854-6888

--_000_91BAAC47CA9DAE4BA6E71BA256326D9605A3EAB8umechpao0easfcs_-- From nobody Tue Jun 16 21:52:50 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 C3A561B3BDF for ; Tue, 16 Jun 2015 21:52:47 -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 is0b8VXqPZn4 for ; Tue, 16 Jun 2015 21:52:45 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 958921B3BC2 for ; Tue, 16 Jun 2015 21:52:45 -0700 (PDT) Received: by padev16 with SMTP id ev16so26364775pad.0 for ; Tue, 16 Jun 2015 21:52:45 -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 :references:in-reply-to:content-type:content-transfer-encoding; bh=MBP0eWhCWXNIonbd9RFoqv/8nwJ6P7yV8cuLrh3IHEw=; b=M4h6UROhb6fiksHt56jdxnxlZoiIwE1YMppxO5NhoxvPp4LA29E5QHdOPZ81hwMgJr PonyGWg6p2Nsui0a2xcLTWnRCFf/vUns4YbecOGuRiy55/sukbTATaHmf1/OBMTaF2eS nDEpPVoguk+TnZ3p2jhTMlagY/2J9eIYzQfG207FmkdEF10Ag/15xglv9Te46r97s6kv CDtuWwga9JTYSrHK+AdLDpkIbN2Z2qDQVhi2oc7fESww2L9El14yrnwWZqha4yDTa94I JlNDenCE/HiHp+GL05iBQzpvULTrcmKl2vJbbP/LM4Qb5u+dRbCsu45NMnn4WoXHiqis yq4A== X-Received: by 10.66.139.234 with SMTP id rb10mr7112061pab.118.1434516765340; Tue, 16 Jun 2015 21:52:45 -0700 (PDT) Received: from spandex.local (216-67-4-2-rb2.nwc.dsl.dynamic.acsalaska.net. [216.67.4.2]) by mx.google.com with ESMTPSA id ng13sm3059307pdb.82.2015.06.16.21.52.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2015 21:52:44 -0700 (PDT) Message-ID: <5580FD1A.9070207@gmail.com> Date: Tue, 16 Jun 2015 20:52:42 -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: Catherine Chapman , "paul@nohats.ca" , "stephen.farrell@cs.tcd.ie" References: , In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] direction for article 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 Jun 2015 04:52:47 -0000 To be honest I'm not sure exactly who's deployed what at this point, although we have been tracking implementations of the protocol (see: http://trac.tools.ietf.org/wg/trans/trac/wiki). But this is very different from what Amazon is doing. They're basically creating an additional certification authority (nit: Bishop's article calls it a "certificate authority"; it's actually "certification authority"). What CT does is provide an auditing mechanism to detect bogus certificates in the wild and is a response to known compromises and operational errors at CAs, broadly known as "misissuance." "Misissuance" includes things like CAs issuing certificates for a domain to another party without the domain's knowledge (for example, if I trick someone into issuing me a certificate for microsoft.com, or a rogue or compromised CA issues one). The Amazon move is probably interesting from a business perspective but probably not particularly from a technical one. The IETF is ramping up an effort to automate certificate management and issuance and there's a parallel implementation project out of Mozilla, and you might find that interesting (and possibly relevant). With the push to deploy HTTPS everywhere, certificates really need to be a lot easier to manage. It seems possible that Amazon is getting into the CA business for similar reasons - growth in the certificate business from the drive towards ubiquitous HTTPS. Melinda From nobody Thu Jun 18 07:07: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 99D231B31FF for ; Thu, 18 Jun 2015 07:07:41 -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 3g37mEJ7_GxW for ; Thu, 18 Jun 2015 07:07:38 -0700 (PDT) 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 668311B31EF for ; Thu, 18 Jun 2015 07:07:38 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:40101 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z5aTf-000JDA-Q9; Thu, 18 Jun 2015 10:07:36 -0400 Message-ID: <5582D0A7.8010806@bbn.com> Date: Thu, 18 Jun 2015 10:07:35 -0400 From: Stephen Kent 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: "Cooley, Dorothy E CIV (US)" , "trans@ietf.org" References: <91BAAC47CA9DAE4BA6E71BA256326D9605A3EAB8@umechpao0.easf.csd.disa.mil> In-Reply-To: <91BAAC47CA9DAE4BA6E71BA256326D9605A3EAB8@umechpao0.easf.csd.disa.mil> Content-Type: multipart/alternative; boundary="------------090905040201040502070105" Archived-At: Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 18 Jun 2015 14:07:41 -0000 This is a multi-part message in MIME format. --------------090905040201040502070105 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Deb, Thanks for reading the doc and providing comments prior to our next planned rev. My responses are inline below. Steve > All, > > This is my first post on list ever, so be gentle :) > > General: This is actually an attack model with an analysis of > detection and consequence. Perhaps the name could be changed to > reflect that. > I agree. We'll change it for the next rev. > > General: 2.2’s outline should follow 2.1’s outline. Move ‘Malicious > or conspiring third party Monitor’ to section 2.2.1.3 and remove it > from 2.2.1.1.3 and 2.2.1.2.1. It may be complete either way, but it > is more likely to look complete if it is symmetric. > We'll try to better align the outlines between 2.1 and 2.2. But, because the CA assummptions differ, it may not be possible to make the outlines completely parallel (without introducing redundant sections that may make reading harder in a different way). We'll review the placement of 2.2.1.1.3 and 2.2.1.2.1 in the context of outline realignment. > > General: Remove the references to the Notes in Sections 2 and 3. > They will stand alone. > do you mean the notes will stand alone? I agree that the notes can stand alone, but I worry that folks reading the sections that now contain those forward references may not tie them back to the relevant sections without the forward references. > > Section 2.1.1.1.1: Change to: > “If a Subject is tracking the log(s) to which a certificate was > submitted, and is performing self-monitoring, then it will be able to > detect a bogus (pre-) certificate and request revocation. In this > case, the CA will make use of the log entry, supplied by the Subject > to determine the serial number of the mis-issued certificate, and > investigate/revoke it.” > We'll make the suggested change. > > Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 : Make the “If > there are many logs, it may not be feasible for a Subject to track all > of them” a note in Section 4 (it is sort of Note 1 currently). > we can add text to state this potential problem, in the indicated sections. However, it is the Monitor function that tracks logs. Only when a Subject self-monitors is the specific text you cited correct. So, we'll substitute Monitor for Subject in your text, OK? > > > Section 2.1.1.1.2: Change this in a similar manner to 2.1.1.1.1, for > the same reasons. > OK. > > Section 2.1.1.2.2: How will gossiping detect this? The Log owner > issues the SCT, but doesn’t actually put the certificate into the > log. How is this detectable by gossiping? Not like an attacker is > going to submit that certificate to multiple logs. He just wants the SCT. > I based this comment on the projected capabilities of a gossip mechanism, the details of which are yet to be agreed upon. I think the notion is that multiple Auditors query log(s) to determine if the returned log entries and STHs represent consistent views. I'll try to generate some better text here, and to discuss the Audit function in the intro, to help clarify. > > > Section 2.1.2: Does the 3rd party monitor have a role in the case > where the certificate isn’t logged? Should that fact be stated? > Perhaps a sentence to that effect in Section 2.1.2.3 would be in order? > When a cert is not logged, no Monitor, even a self-monitoring Subject, will detect issuance of a bogus cert based on Monitor functions. That's what this section is intended to convey, but we can try to improve the wording. > > Section 2.1.2.1: Either remove the last sentence in the > parenthetical, or work it into the paragraph without the parenthetical. > OK. > > Section 2.2.1.2: Add a section on Self-monitoring Subject and a > section on benign third party Monitor. > > > Section 2.2.1.1.3 and 2.2.1.2.1: Combine these into Section 2.2.1.3 > called malicious or conspiring third party monitor. > I don't follow your comment above. it doesn't match the outline for section 2.1. I think 2.2.1.2.1 should be subsumed under 2.2.1.2, but 2.2.1.1.1 seems appropriate as an enumeration of cases under 2.2.1.1. > > > Section 3, Syntactic checks: We need to think about whether this > makes sense. This paper gets much simpler w/out it. Currently not > included in rfc6962bis. > 6962bis failed to define what a mis-issued cert is, even though the term is the focus of the CT effort. When I asked Ben about this last year I initially thought that only bogus certs (as we now define them) were mis-issued. But, Ben stated that a failure to adhere to the DV or EV cert profiles would be considered mis-issuance for certs of that genre. I agree that this should counted as mis-issuance, and if we intend to expand CT beyond Web PKI certs, then syntactic mis-issuance is even more important. That's why we have two candidate syntactic cert profiles posted, and why I proposed a mechanism to allow a submitter to declare what type of cert is being submitted to a log. I also suggest that logs be allowed to optionally check submitted (pre-) certs against an declared type, perform appropriate checks if they can (and are willing) and record the results in the SCT. > > Section 4, Notes: These are issues that will need to be addressed. I > would make a more descriptive name and keep them numbered. > OK. We'll add more text for each note and use outline numbering for them. > > Section 4, Note 1: Make this two items. First: How are new logs > discovered by monitors? Second: how does a subject know which logs > the monitor is checking? > Good point. we'll do that. --------------090905040201040502070105 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Deb,

Thanks for reading the doc and providing comments prior to our next planned rev.

My responses are inline below.

Steve


All,

 

This is my first post on list ever, so be gentle :)

 

 

General:  This is actually an attack model with an analysis of detection and consequence.  Perhaps the name could be changed to reflect that.

I agree. We'll change it for the next rev.

General:  2.2’s outline should follow 2.1’s outline.  Move ‘Malicious or conspiring third party Monitor’ to section 2.2.1.3 and remove it from 2.2.1.1.3 and 2.2.1.2.1.  It may be complete either way, but it is more likely to look complete if it is symmetric.

We'll try to better align the outlines between 2.1 and 2.2. But, because the CA assummptions
differ, it may not be possible to make the outlines completely parallel (without introducing
redundant sections that may make reading harder in a different way). We'll review the placement of 2.2.1.1.3 and 2.2.1.2.1 in the context of outline realignment.

General:  Remove the references to the Notes in Sections 2 and 3.  They will stand alone.

do you mean the notes will stand alone? I agree that the notes can stand alone, but I worry that
folks reading the sections that now contain those forward references may not tie them back to
the relevant sections without the forward references.

Section 2.1.1.1.1:  Change to:
“If a Subject is tracking the log(s) to which a certificate was submitted, and is performing self-monitoring, then it will be able to detect a bogus (pre-) certificate and request revocation. In this case, the CA will make use of the log entry, supplied by the Subject to determine the serial number of the mis-issued certificate, and investigate/revoke it.”

We'll make the suggested change.

Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 :  Make the “If there are many logs, it may not be feasible for a Subject to track all of them” a note in Section 4 (it is sort of Note 1 currently).

we can add text to state this potential problem, in the indicated sections. However, it is
the Monitor function that tracks logs. Only when a Subject self-monitors is the specific
text you cited correct. So, we'll substitute Monitor for Subject in your text, OK?


Section 2.1.1.1.2:  Change this in a similar manner to 2.1.1.1.1, for the same reasons.

OK.

Section 2.1.1.2.2:  How will gossiping detect this?  The Log owner issues the SCT, but doesn’t actually put the certificate into the log.  How is this detectable by gossiping?  Not like an attacker is going to submit that certificate to multiple logs.  He just wants the SCT.

I based this comment on the projected capabilities of a gossip mechanism, the details of which
are yet to be agreed upon.  I think the notion is that multiple Auditors query log(s) to determine
if the returned log entries and STHs represent consistent views. I'll try to generate some better
text here, and to discuss the Audit function in the intro, to help clarify.


Section 2.1.2:  Does the 3rd party monitor have a role in the case where the certificate isn’t logged?  Should that fact be stated?  Perhaps a sentence to that effect in Section 2.1.2.3 would be in order?

When a cert is not logged, no Monitor, even a self-monitoring Subject, will detect issuance of a
bogus cert based on Monitor functions. That's what this section is intended to convey, but we can
try to improve the wording.

Section 2.1.2.1:  Either remove the last sentence in the parenthetical, or work it into the paragraph without the parenthetical.

OK.

  Section 2.2.1.2:  Add a section on Self-monitoring Subject and a section on benign third party Monitor.


Section 2.2.1.1.3 and 2.2.1.2.1:  Combine these into Section 2.2.1.3 called malicious or conspiring third party monitor.

I don't follow your comment above. it doesn't match the outline for section 2.1. I think
2.2.1.2.1 should be subsumed under 2.2.1.2, but 2.2.1.1.1 seems appropriate as an enumeration
of cases under 2.2.1.1.


Section 3, Syntactic checks:  We need to think about whether this makes sense.  This paper gets much simpler w/out it.  Currently not included in rfc6962bis.

6962bis failed to define what a mis-issued cert is, even though the term is the focus of the
CT effort. When I asked Ben about this last year I initially thought that only bogus certs
(as we now define them) were mis-issued. But, Ben stated that a failure to adhere to the DV
or EV cert profiles would be considered mis-issuance for certs of that genre. I agree that
this should counted as mis-issuance, and if we intend to expand CT beyond Web PKI certs,
then syntactic mis-issuance is even more important. That's why we have two candidate syntactic
cert profiles posted, and why I proposed a mechanism to allow a submitter to declare what
type of cert is being submitted to a log. I also suggest that logs be allowed to optionally
check submitted (pre-) certs against an declared type, perform appropriate checks if they
can (and are willing) and record the results in the SCT.

Section 4, Notes:  These are issues that will need to be addressed.  I would make a more descriptive name and keep them numbered.

OK. We'll add more text for each note and use outline numbering for them.

 Section 4, Note 1:  Make this two items.  First:  How are new logs discovered by monitors?  Second:  how does a subject know which logs the monitor is checking?

Good point. we'll do that.
--------------090905040201040502070105-- From nobody Thu Jun 18 13:00: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 51DDA1B3413 for ; Thu, 18 Jun 2015 13:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 RGoja9M9v2qA for ; Thu, 18 Jun 2015 13:00:26 -0700 (PDT) Received: from prodomx02.usaa.com (prodomx02.usaa.com [167.24.25.92]) (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 8B1101B2D5E for ; Thu, 18 Jun 2015 13:00:26 -0700 (PDT) Received: from pps.filterd (prodomx02.usaa.com [127.0.0.1]) by prodomx02.usaa.com (8.14.7/8.14.7) with SMTP id t5IJvmwP022338; Thu, 18 Jun 2015 15:00:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=usaa.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=201408; bh=zGGm/ZR4OGxulh8zqs5tGnSGqaZOLAJWSUxCGnWpwAo=; b=p8ljpo+pdEBCCph3oOTZtUfFwSp9YPq8l2HVXVIgMMXzb+frSK9W3Lff3N8c14gyhMoH pq+1BJINoCFLNrl57L/1FV4OJSP+S41cLZoJ8RE6bLjpL9fu9s9xfRnAB6dWLDUpIJdA v66oKcLGLj31zvEgcbfPSCv+pB6gv2VUQGk70tdZ4IyBkbSGcEIyV/C4zEhJK19ut4FO spJu506bjTLoovtAoaRrfLrO4i7kAiJZQZNgm4XYj5twbhBd2OZHZq9+medeV06j55pC 43N/loSxTT/4sRc9IWttti+H0vj1E5OMzB6qzdYV2dXsj2Id+GuXu6eHF5jwBNqVdvY1 5g== Received: from prodexch06w.eagle.usaa.com (prodexch06w.eagle.usaa.com [10.170.40.22]) by prodomx02.usaa.com with ESMTP id 1uyhr2n2cf-1; Thu, 18 Jun 2015 15:00:22 -0500 Received: from PRODEXCH10W.eagle.usaa.com (10.170.40.32) by PRODEXCH06W.eagle.usaa.com (10.170.40.22) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 18 Jun 2015 15:00:22 -0500 Received: from PRODEXMB01W.eagle.usaa.com ([169.254.1.172]) by PRODEXCH10W.eagle.usaa.com ([10.170.40.32]) with mapi id 14.03.0210.002; Thu, 18 Jun 2015 15:00:22 -0500 From: "Mehner, Carl" To: "trans@ietf.org" , Stephen Kent Thread-Topic: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt Thread-Index: AQHQqgFoWtPa/HbzekOg09N2POLwEQ== Date: Thu, 18 Jun 2015 20:00:21 +0000 Message-ID: <19075EB00EA7FE49AFF87E5818D673D4115AFEAA@PRODEXMB01W.eagle.usaa.com> References: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> <556F6FF4.2000300@gmail.com> In-Reply-To: <556F6FF4.2000300@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.15.114] x-c2processedorg: b8bcc573-fb52-4e08-924e-ca559c360d81 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Direction: FromExch X-Proofpoint-Direction: Internet X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-18_05:2015-06-18,2015-06-18,1970-01-01 signatures=0 Archived-At: Subject: Re: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 18 Jun 2015 20:00:29 -0000 Hello Stephen, thanks for writing this up. I only had a few comments (first= grammatical/flow, then on the content): Is the missing the 2119 boilerplate intentional? In the Status section, there is a missing double quote: > work in progress." should be "work in progress." I think the 'So' is extraneous here: >1. Introduction >Certificates are issued by CAs. So the top level differentiation in > this analysis is whether the CA that mis-issued a certificate did so > maliciously or not. How about: Because CAs issue certificates, the top level differentiation in this analy= sis is whether the CA that mis-issued a certificate did so maliciously or n= ot. You are missing a period at the end of the last sentence in 2.1.1.1. There is a double comma in 2.2.1.2 (and not to get into the finer points of= RFC Grammar, there is a mix of double single-quotes and single double-quot= es throughout (with the count tilting higher towards the former); Was that = intentional?) There appears to be a nested note in Note 5; this strikes me as odd, but no= t necessarily bad. --------------------------------------- On the subject of semantic mis-issuance in a non-malicious Web PKI Context = (Section 2.1): A non-malicious Web PKI CA may issue certificates for which it is authorize= d by the CA CPS yet, is unauthorized by the Subject. This is very similar t= o 2.2.1.1.1, except that the party receiving the certificate is "authorized= " (thus not quite fitting your description of bogus). A specific case of th= is is where the Subject has set up a CAA record clearly stating the Subject= 's policy towards certificate issuance and a non-malicious CA whose CPS sta= tes that it does not respect CAA records (in accordance with CABF BRs) issu= es a certificate anyway. An additional example are certificates issued when= validated simply using email addresses such as the live.fi [1] cert from e= arlier this year, or a number of other email domains as described here->[2]= . If this type of per-company policy distinction ought to earn a mention in t= his document, I believe that it would fit under 2.1.1. Here is my suggested= text: -----BEGIN----- 2.1.1.1 > ... all clients. The Log, when receiving a recently signed pre-certificate SHOULD assist in = detection of bogus certificates by checking CAA records [rfc6844] and sendi= ng a report to the URL as specified in the iodef property. > ... If a bogus ... 2.1.1.1.2. Benign third party Monitor ... When the Monitor receives a recently signed pre-certificate it MAY then che= ck the CAA [rfc6844] record and send a report to the URL as specified in th= e iodef property. A Monitor MAY also check certificates for compliance with= the HPKP header [rfc7469] of a Subject site or browser HPKP headers, misma= tches SHOULD be reported to the Subject, if the Subject has a relationship = with the Monitor, or as specified in the report-uri directive of the HPKP h= eader. -----END----- I put the CAA validation on the log more strongly than the monitor because = individual logs ought to be getting the SCTs right before the time of issua= nce (in a matter of seconds or minutes) rather than such a time as when a M= onitor asks which may be at a much later time (e.g. "recently signed"). Alternatively, these additional checks for semantic correctness may belong = better in the set of kent-trans-*-validation-cert-checks documents? Perhaps= in new text as section 3.3? Slightly off topic, but since it's referenced in this threat doc: draft-kent-trans-domain-validation-cert-checks-00 2.1.6.B refers to section= 9.2.6 of the CABF-DV BRv1.2.3; such a section of the BRs does not exist. [1] ars.to/1Ftrljf || http://arstechnica.com/security/2015/03/man-who-obtai= ned-windows-live-cert-said-his-warnings-went-unanswered [2] https://www.cem.me/papers/emailcerts.html > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Melinda Shore > Sent: Wednesday, June 03, 2015 4:22 PM > To: trans@ietf.org > Cc: Stephen Kent > Subject: [Trans] Fwd: I-D Action: draft-ietf-trans-threat- > analysis-00.txt > > The initial draft of the threat analysis document is out. > Please give it a careful read and post comments to the mailing > list. > > Steve, if you could highlight issues that need particular > attention, that can get working group discussion off to a > strong start. > > Melinda > > > -------- Forwarded Message -------- > Subject: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt > Date: Wed, 03 Jun 2015 14:00:30 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: trans@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Public Notary Transparency Working > Group of the IETF. > > Title : Threat Analysis for Certificate Transparency > Author : Stephen Kent > Filename : draft-ietf-trans-threat-analysis-00.txt > Pages : 18 > Date : 2015-06-02 > > Abstract: > This document describes a threat model for the Web PKI context in > which security mechanisms to detect mis-issuance of web site > certificates will be developed. The threat model covers both > syntactic and semantic mis-issuance, using a taxonomy of threats > starting with whether the mis-issuance was done by the CA > maliciously or not; then whether or not the certificate was logged; > and then whether the log(s) or monitor(s) are benign or malicious, > whether the certificate subject is self-monitoring and whether a > client is doing any checks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 Fri Jun 19 10:27:40 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 02E5B1AC3AC for ; Fri, 19 Jun 2015 10:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=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 xDitbfj6xSHg for ; Fri, 19 Jun 2015 10:27:35 -0700 (PDT) Received: from ucol19pa13.eemsg.mail.mil (ucol19pa13.eemsg.mail.mil [214.24.24.86]) by ietfa.amsl.com (Postfix) with ESMTP id 915861ABD38 for ; Fri, 19 Jun 2015 10:27:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,644,1427760000"; d="scan'208,217";a="178770857" Received: from edge-mech01.mail.mil ([214.21.130.101]) by ucol19pa13.eemsg.mail.mil with ESMTP; 19 Jun 2015 17:27:32 +0000 Received: from UMECHPAOE.easf.csd.disa.mil (214.21.130.32) by edge-mech01.mail.mil (214.21.130.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 19 Jun 2015 17:27:32 +0000 Received: from UMECHPAO0.easf.csd.disa.mil ([169.254.4.60]) by UMECHPAOE.easf.csd.disa.mil ([214.21.130.32]) with mapi id 14.03.0224.002; Fri, 19 Jun 2015 17:27:32 +0000 From: "Cooley, Dorothy E CIV (US)" To: Stephen Kent , "trans@ietf.org" Thread-Topic: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt Thread-Index: AQHQqdA0mECCXwhLx0yehj17OmNMap20FbZOgAABJzc= Date: Fri, 19 Jun 2015 17:27:32 +0000 Message-ID: <91BAAC47CA9DAE4BA6E71BA256326D9605A4BF62@umechpao0.easf.csd.disa.mil> References: <91BAAC47CA9DAE4BA6E71BA256326D9605A3EAB8@umechpao0.easf.csd.disa.mil>, <5582D0A7.8010806@bbn.com> In-Reply-To: <5582D0A7.8010806@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [214.21.97.85] Content-Type: multipart/alternative; boundary="_000_91BAAC47CA9DAE4BA6E71BA256326D9605A4BF62umechpao0easfcs_" MIME-Version: 1.0 Archived-At: Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 19 Jun 2015 17:27:38 -0000 --_000_91BAAC47CA9DAE4BA6E71BA256326D9605A4BF62umechpao0easfcs_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable [debc] I=92ve cut anything that I agreed with. General: Remove the references to the Notes in Sections 2 and 3. They wil= l stand alone. [sk] do you mean the notes will stand alone? I agree that the notes can sta= nd alone, but I worry that folks reading the sections that now contain those forward references may no= t tie them back to the relevant sections without the forward references. [debc] I did mean that the notes should/will stand alone. Maybe once thos= e notes have real section numbers it will flow better with the forward refe= rences. Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 : Make the =93If there = are many logs, it may not be feasible for a Subject to track all of them=94= a note in Section 4 (it is sort of Note 1 currently). [sk] we can add text to state this potential problem, in the indicated sect= ions. However, it is the Monitor function that tracks logs. Only when a Subject self-monitors is= the specific text you cited correct. So, we'll substitute Monitor for Subject in your te= xt, OK? [debc] yes, subject or monitor will both have this problem. Section 2.2.1.2: Add a section on Self-monitoring Subject and a section on= benign third party Monitor. [debc] not sure what happened to this one... Section 2.2.1.1.3 and 2.2.1.2.1: Combine these into Section 2.2.1.3 called= malicious or conspiring third party monitor. [sk] I don't follow your comment above. it doesn't match the outline for se= ction 2.1. I think 2.2.1.2.1 should be subsumed under 2.2.1.2, but 2.2.1.1.1 seems appropriate= as an enumeration of cases under 2.2.1.1. [debc] no worries if this doesn=92t make sense. This is just a second comm= ent looking to make 2.1 and 2.2 outlines the same-ish. Section 3, Syntactic checks: We need to think about whether this makes sen= se. This paper gets much simpler w/out it. Currently not included in rfc6= 962bis. [sk] 6962bis failed to define what a mis-issued cert is, even though the te= rm is the focus of the CT effort. When I asked Ben about this last year I initially thought that o= nly bogus certs (as we now define them) were mis-issued. But, Ben stated that a failure to = adhere to the DV or EV cert profiles would be considered mis-issuance for certs of that genr= e. I agree that this should counted as mis-issuance, and if we intend to expand CT beyond W= eb PKI certs, then syntactic mis-issuance is even more important. That's why we have two = candidate syntactic cert profiles posted, and why I proposed a mechanism to allow a submitter t= o declare what type of cert is being submitted to a log. I also suggest that logs be allow= ed to optionally check submitted (pre-) certs against an declared type, perform appropriate = checks if they can (and are willing) and record the results in the SCT. [debc] it will be interesting to see how this evolves. Deb Cooley dorothy.e.cooley6.civ@mail.mil ________________________________ From: Stephen Kent [kent@bbn.com] Sent: Thursday, June 18, 2015 10:07 AM To: Cooley, Dorothy E CIV (US); trans@ietf.org Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt Deb, Thanks for reading the doc and providing comments prior to our next planned= rev. My responses are inline below. Steve --_000_91BAAC47CA9DAE4BA6E71BA256326D9605A4BF62umechpao0easfcs_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

[debc]  I=92ve cut anything that I agreed with.


General:  Remove the references to the Notes in Sections 2 and 3. = ; They will stand alone.


[sk] do you mean the notes will stand alone? I agree that the notes can sta= nd alone, but I worry that
folks reading the sections that now contain those forward references may no= t tie them back to
the relevant sections without the forward references.

 

[debc]  I did mean that the notes should/will stand alone.  Ma= ybe once those notes have real section numbers it will flow better with the= forward references.


Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 :  Make the =93If t= here are many logs, it may not be feasible for a Subject to track all of th= em=94 a note in Section 4 (it is sort of Note 1 currently).


[sk] we can add text to state this potential problem, in the indicated sect= ions. However, it is
the Monitor function that tracks logs. Only when a Subject self-monitors is= the specific
text you cited correct. So, we'll substitute Monitor for Subject in your te= xt, OK?

 

[debc]  yes, subject or monitor will both have this problem.


Section 2.2.1.2:  Add a section on Self-monitoring Subject and a secti= on on benign third party Monitor.

 

[debc] not sure what happened to this one...

 

Section 2.2.1.1.3 and 2.2.1.2.1:  Combine these into Section 2.2.1.= 3 called malicious or conspiring third party monitor.

[sk] I don't follow your comment above. it doesn't match the outline for= section 2.1. I think
2.2.1.2.1 should be subsumed under 2.2.1.2, but 2.2.1.1.1 seems appropriate= as an enumeration
of cases under 2.2.1.1.

 

[debc] no worries if this doesn=92t make sense.  This is just a sec= ond comment looking to make 2.1 and 2.2 outlines the same-ish.

 

Section 3, Syntactic checks:  We need to think about whether this m= akes sense.  This paper gets much simpler w/out it.  Currently no= t included in rfc6962bis.

 

[sk] 6962bis failed to define what a mis-issued cert is, even though the= term is the focus of the
CT effort. When I asked Ben about this last year I initially thought that o= nly bogus certs
(as we now define them) were mis-issued. But, Ben stated that a failure to = adhere to the DV
or EV cert profiles would be considered mis-issuance for certs of that genr= e. I agree that
this should counted as mis-issuance, and if we intend to expand CT beyond W= eb PKI certs,
then syntactic mis-issuance is even more important. That's why we have two = candidate syntactic
cert profiles posted, and why I proposed a mechanism to allow a submitter t= o declare what
type of cert is being submitted to a log. I also suggest that logs be allow= ed to optionally
check submitted (pre-) certs against an declared type, perform appropriate = checks if they
can (and are willing) and record the results in the SCT.

 

[debc] it will be interesting to see how this evolves.

From: Stephen Kent [kent@bbn.com]
Sent: Thursday, June 18, 2015 10:07 AM
To: Cooley, Dorothy E CIV (US); trans@ietf.org
Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00= .txt

Deb,

Thanks for reading the doc and providing comments prior to our next planned= rev.

My responses are inline below.

Steve



 
--_000_91BAAC47CA9DAE4BA6E71BA256326D9605A4BF62umechpao0easfcs_-- From nobody Mon Jun 22 13:12:29 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 8A1471ACF1C for ; Mon, 22 Jun 2015 13:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0aKCDhPRLLHB for ; Mon, 22 Jun 2015 13:12:26 -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 826E01ACF1B for ; Mon, 22 Jun 2015 13:12:26 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:44806 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z784v-000NmS-4t; Mon, 22 Jun 2015 16:12:25 -0400 Message-ID: <55886C28.50307@bbn.com> Date: Mon, 22 Jun 2015 16:12:24 -0400 From: Stephen Kent 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: <20150603210030.10039.59184.idtracker@ietfa.amsl.com> <556F6FF4.2000300@gmail.com> <19075EB00EA7FE49AFF87E5818D673D4115AFEAA@PRODEXMB01W.eagle.usaa.com> In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D4115AFEAA@PRODEXMB01W.eagle.usaa.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 22 Jun 2015 20:12:28 -0000 Carl, thanks for the review and comments. responses inline below. Steve > Hello Stephen, thanks for writing this up. I only had a few comments (first grammatical/flow, then on the content): > > > Is the missing the 2119 boilerplate intentional? no, fixed. > In the Status section, there is a missing double quote: >> work in progress." > should be > "work in progress." fixed. > > > I think the 'So' is extraneous here: >> 1. Introduction >> Certificates are issued by CAs. So the top level differentiation in >> this analysis is whether the CA that mis-issued a certificate did so >> maliciously or not. > How about: > Because CAs issue certificates, the top level differentiation in this analysis is whether the CA that mis-issued a certificate did so maliciously or not. done > You are missing a period at the end of the last sentence in 2.1.1.1. fixed. > There is a double comma in 2.2.1.2 (and not to get into the finer points of RFC Grammar, there is a mix of double single-quotes and single double-quotes throughout (with the count tilting higher towards the former); Was that intentional?) not intentional, fixed. > There appears to be a nested note in Note 5; this strikes me as odd, but not necessarily bad. fixed. > --------------------------------------- > > On the subject of semantic mis-issuance in a non-malicious Web PKI Context (Section 2.1): > > A non-malicious Web PKI CA may issue certificates for which it is authorized by the CA CPS yet, is unauthorized by the Subject. This is very similar to 2.2.1.1.1, except that the party receiving the certificate is "authorized" (thus not quite fitting your description of bogus). A specific case of this is where the Subject has set up a CAA record clearly stating the Subject's policy towards certificate issuance and a non-malicious CA whose CPS states that it does not respect CAA records (in accordance with CABF BRs) issues a certificate anyway. An additional example are certificates issued when validated simply using email addresses such as the live.fi [1] cert from earlier this year, or a number of other email domains as described here->[2]. > If this type of per-company policy distinction ought to earn a mention in this document, I believe that it would fit under 2.1.1. Here is my suggested text: > -----BEGIN----- > 2.1.1.1 >> ... all clients. > The Log, when receiving a recently signed pre-certificate SHOULD assist in detection of bogus certificates by checking CAA records [rfc6844] and sending a report to the URL as specified in the iodef property. we'll have to think more about our examples. I'm not sure that 6844 has gained enough traction to cite it here, but I'll defer to others on this issue. >> ... If a bogus ... > 2.1.1.1.2. Benign third party Monitor > ... > When the Monitor receives a recently signed pre-certificate it MAY then check the CAA [rfc6844] record and send a report to the URL as specified in the iodef property. A Monitor MAY also check certificates for compliance with the HPKP header [rfc7469] of a Subject site or browser HPKP headers, mismatches SHOULD be reported to the Subject, if the Subject has a relationship with the Monitor, or as specified in the report-uri directive of the HPKP header. > -----END----- I think the cert pinning checks are good ones to add as additional actions by a Monitor. We'll include them in a future rev. > I put the CAA validation on the log more strongly than the monitor because individual logs ought to be getting the SCTs right before the time of issuance (in a matter of seconds or minutes) rather than such a time as when a Monitor asks which may be at a much later time (e.g. "recently signed"). if CAA records are widely used, then I agree with your prioritization, but ??? > Alternatively, these additional checks for semantic correctness may belong better in the set of kent-trans-*-validation-cert-checks documents? Perhaps in new text as section 3.3? those docs try to enumerate the checks required by the DV and EV docs. these added checks are not mentioned in those CABF specs, so I think it will be better to consider adding text about cert pinning (and, maybe, CAA records) to this doc instead. > Slightly off topic, but since it's referenced in this threat doc: > draft-kent-trans-domain-validation-cert-checks-00 2.1.6.B refers to section 9.2.6 of the CABF-DV BRv1.2.3; such a section of the BRs does not exist. Whoops. we'll have to fix that next time, thanks for the note. Steve From nobody Mon Jun 22 13:26:47 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 C33031AD08F for ; Mon, 22 Jun 2015 13:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 GKIKUR7Yg3p9 for ; Mon, 22 Jun 2015 13:26:45 -0700 (PDT) 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 5F2671AD06D for ; Mon, 22 Jun 2015 13:26:45 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:53308 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z78Il-0005tO-S4; Mon, 22 Jun 2015 16:26:43 -0400 Message-ID: <55886F83.1020205@bbn.com> Date: Mon, 22 Jun 2015 16:26:43 -0400 From: Stephen Kent 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: "Cooley, Dorothy E CIV (US)" , "trans@ietf.org" References: <91BAAC47CA9DAE4BA6E71BA256326D9605A3EAB8@umechpao0.easf.csd.disa.mil>, <5582D0A7.8010806@bbn.com> <91BAAC47CA9DAE4BA6E71BA256326D9605A4BF62@umechpao0.easf.csd.disa.mil> In-Reply-To: <91BAAC47CA9DAE4BA6E71BA256326D9605A4BF62@umechpao0.easf.csd.disa.mil> Content-Type: multipart/alternative; boundary="------------080803020706040702080609" Archived-At: Subject: Re: [Trans] I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 22 Jun 2015 20:26:46 -0000 This is a multi-part message in MIME format. --------------080803020706040702080609 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Deb, > General: Remove the references to the Notes in Sections 2 and 3. > They will stand alone. > > > [sk] do you mean the notes will stand alone? I agree that the notes > can stand alone, but I worry that > folks reading the sections that now contain those forward references > may not tie them back to > the relevant sections without the forward references. > > [debc] I did mean that the notes should/will stand alone. Maybe once > those notes have real section numbers it will flow better with the > forward references. > we have made that change. > > > Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 : Make the “If > there are many logs, it may not be feasible for a Subject to track all > of them” a note in Section 4 (it is sort of Note 1 currently). > > > [sk] we can add text to state this potential problem, in the indicated > sections. However, it is > the Monitor function that tracks logs. Only when a Subject > self-monitors is the specific > text you cited correct. So, we'll substitute Monitor for Subject in > your text, OK? > > [debc] yes, subject or monitor will both have this problem. > OK. > > Section 2.2.1.2: Add a section on Self-monitoring Subject and a > section on benign third party Monitor. > > [debc] not sure what happened to this one... > I think we addressed that in our next rev. Steve --------------080803020706040702080609 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Deb,

General:  Remove the references to the Notes in Sections 2 and 3.  They will stand alone.


[sk] do you mean the notes will stand alone? I agree that the notes can stand alone, but I worry that
folks reading the sections that now contain those forward references may not tie them back to
the relevant sections without the forward references.

 

[debc]  I did mean that the notes should/will stand alone.  Maybe once those notes have real section numbers it will flow better with the forward references.

we have made that change.


Section 2.1.1.1.1, 2.1.1.1.2, 2.2.1.1.1, 2.2.1.1.2 :  Make the “If there are many logs, it may not be feasible for a Subject to track all of them” a note in Section 4 (it is sort of Note 1 currently).


[sk] we can add text to state this potential problem, in the indicated sections. However, it is
the Monitor function that tracks logs. Only when a Subject self-monitors is the specific
text you cited correct. So, we'll substitute Monitor for Subject in your text, OK?

 

[debc]  yes, subject or monitor will both have this problem.

OK.

Section 2.2.1.2:  Add a section on Self-monitoring Subject and a section on benign third party Monitor.

 

[debc] not sure what happened to this one...

I think we addressed that in our next rev.

Steve
--------------080803020706040702080609-- From nobody Mon Jun 22 13:53:24 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 C86E91AD072 for ; Mon, 22 Jun 2015 13:53:16 -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 esxNQww79v_U for ; Mon, 22 Jun 2015 13:53:12 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE4C1ACF18 for ; Mon, 22 Jun 2015 13:53:12 -0700 (PDT) Received: (qmail 31648 invoked by uid 1004); 22 Jun 2015 20:53:10 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Mon, 22 Jun 2015 21:53:10 +0100 Received: (qmail 11198 invoked by uid 1000); 22 Jun 2015 20:53: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; Mon, 22 Jun 2015 21:53:09 +0100 Message-ID: <558875B5.7090301@comodo.com> Date: Mon, 22 Jun 2015 21:53:09 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <20150603210030.10039.59184.idtracker@ietfa.amsl.com><556F6FF4.2000300@gmail.com><19075EB00EA7FE49AFF87E5818D673D4115AFEAA@PRODEXMB01W.eagle.usaa.com> <55886C28.50307@bbn.com> In-Reply-To: <55886C28.50307@bbn.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt 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, 22 Jun 2015 20:53:16 -0000 On 22/06/15 21:12, Stephen Kent wrote: >> The Log, when receiving a recently signed pre-certificate SHOULD >> assist in detection of bogus certificates by checking CAA records >> [rfc6844] and sending a report to the URL as specified in the iodef >> property. > we'll have to think more about our examples. I'm not sure that 6844 has > gained enough traction to cite it here, but I'll defer to others on > this issue. > if CAA records are widely used, then I agree with your prioritization, > but ??? We've been doing CAA checks on all server cert requests for the last couple of months. So far we've only encountered CAA records for 2 domains, both of which belong to us! So I think it's fair to say that CAA records are not yet widely used! -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Jun 23 06:40:37 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 765E91B2C09 for ; Tue, 23 Jun 2015 06:40:33 -0700 (PDT) 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 sZahU37UXAxJ for ; Tue, 23 Jun 2015 06:40:29 -0700 (PDT) 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 1BDCC1B2C07 for ; Tue, 23 Jun 2015 06:40:28 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:57567 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z7OR9-0001SL-Ik for trans@ietf.org; Tue, 23 Jun 2015 09:40:27 -0400 Message-ID: <558961CB.6030402@bbn.com> Date: Tue, 23 Jun 2015 09:40:27 -0400 From: Stephen Kent 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: <20150603210030.10039.59184.idtracker@ietfa.amsl.com><556F6FF4.2000300@gmail.com><19075EB00EA7FE49AFF87E5818D673D4115AFEAA@PRODEXMB01W.eagle.usaa.com> <55886C28.50307@bbn.com> <558875B5.7090301@comodo.com> In-Reply-To: <558875B5.7090301@comodo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt 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 Jun 2015 13:40:33 -0000 Rob, Thanks for the feedback based on real world observables. Steve > On 22/06/15 21:12, Stephen Kent wrote: > >>> The Log, when receiving a recently signed pre-certificate SHOULD >>> assist in detection of bogus certificates by checking CAA records >>> [rfc6844] and sending a report to the URL as specified in the iodef >>> property. >> we'll have to think more about our examples. I'm not sure that 6844 has >> gained enough traction to cite it here, but I'll defer to others on >> this issue. > >> if CAA records are widely used, then I agree with your prioritization, >> but ??? > > We've been doing CAA checks on all server cert requests for the last > couple of months. So far we've only encountered CAA records for 2 > domains, both of which belong to us! > > So I think it's fair to say that CAA records are not yet widely used! > From nobody Tue Jun 23 14:38: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 D30631A21A7 for ; Tue, 23 Jun 2015 14:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 T8cjcMfuuE4O for ; Tue, 23 Jun 2015 14:38:28 -0700 (PDT) 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 AC7C21A21A3 for ; Tue, 23 Jun 2015 14:38:28 -0700 (PDT) Received: from localhost ([::1]:38486 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z7Vtk-0002cn-2l; Tue, 23 Jun 2015 14:38:28 -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, eijdenberg@google.com X-Trac-Project: trans Date: Tue, 23 Jun 2015 21:38:28 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/90 Message-ID: <061.6c57439d9835c35d408ea3940c9d0efe@tools.ietf.org> X-Trac-Ticket-ID: 90 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, eijdenberg@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: <20150623213828.AC7C21A21A3@ietfa.amsl.com> Resent-Date: Tue, 23 Jun 2015 14:38:28 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #90 (rfc6962-bis): Clarify how to turn a MerkleTreeLeaf into a leaf hash 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: Tue, 23 Jun 2015 21:38:30 -0000 #90: Clarify how to turn a MerkleTreeLeaf into a leaf hash Section 3.5 "Merkle Tree" which is cross-referenced from "Log Client Messages" (sections 4.5 and 4.6) describes how 'the "hash" must be calculated'. Section 3.5 first describes the data structure and then finishes with: 'The leaves of the Merkle Tree are the leaf hashes of the corresponding "!MerkleTreeLeaf" structures.' At least two client implementers have incorrectly assumed that meant that the hash should be calculated as: {{{HASH(MerkleTreeLeaf)}}} If the implementer noticed the word "leaf" before hash, and carefully read section 2.1 they would realize that what they really need is: {{{HASH(0x00 || MerkleTreeLeaf)}}} I propose we add the following line to the last paragraph in Section 3.5 to make this clearer: {{{Note that leaf hashes are calculated as HASH(0x00 || MerkleTreeLeaf). See Section 2.1 for further details.}}} Confused users: 1. http://comments.gmane.org/gmane.comp.security.ssl.certificate- transparency.general/1204 2. Me, independently doing exactly the same, first calling get-entries and then hashing the result leaf_input and sending to get-proof-by-hash. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- eijdenberg@google.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: trans From nobody Fri Jun 26 07:30: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 EB48A1B2FAE for ; Fri, 26 Jun 2015 07:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.261 X-Spam-Level: X-Spam-Status: No, score=-4.261 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, 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 CSMfZCfyO5Xu for ; Fri, 26 Jun 2015 07:30:06 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBA01B2FAB for ; Fri, 26 Jun 2015 07:30:05 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:5528:1a54:e8e2:c252] (unknown [IPv6:2001:1488:fffe:6:5528:1a54:e8e2:c252]) by mail.nic.cz (Postfix) with ESMTPSA id 490AB180D29 for ; Fri, 26 Jun 2015 16:30:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1435329003; bh=j35orgF7mJ1IodDX3z2IXwCZje3+uUVUEPsXkOgw3F0=; h=Date:From:To; b=MrfS6G4IB86obUmNX1bHRTsBNNahO871Njy9OJXeZM97NNNdjCjLhknWaobgTrImq 4ikFqlBFjLKPh7EebfuGrZ0OYeT9nsDEmaRiApjL6hHOm/V8jQ35YINAKL/lNdiRmO c5gW+0lHJJJ7izxNCNYzEM3QTjmEGtTvobqGUBIw= Message-ID: <558D61DE.8020402@nic.cz> Date: Fri, 26 Jun 2015 16:29:50 +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.7 at mail X-Virus-Status: Clean Archived-At: Subject: [Trans] Verifying inclusion proof 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, 26 Jun 2015 14:30:08 -0000 Pardon me if I am asking something obvious, but I'm missing one piece of information for inclusion proof verification - the "placement" of each node returned from "get-proof-by-hash" method in audit_path list (whether it's left subtree or right subtree). Since the hashing of concatenation of strings is not commutative, the auditor needs to put the two partial tree hashes in correct order to get to the correct root hash. I'd guess the placement of the missing nodes from audit_path could be derived from leaf_index and tree_size, but can't see a straightforward way to do it. The reference client does not implement this verification either. Ondrej From nobody Fri Jun 26 09:02:36 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 688AF1A888E for ; Fri, 26 Jun 2015 09:02:35 -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 ahBGov4QygXI for ; Fri, 26 Jun 2015 09:02:33 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::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 6807D1A88A6 for ; Fri, 26 Jun 2015 09:02:32 -0700 (PDT) Received: by ykdr198 with SMTP id r198so62383060ykd.3 for ; Fri, 26 Jun 2015 09:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=rcJix56m666U/oGL+Ep7uxWmHMsgjWYiGV8nsO8hBEs=; b=aU4sjBmPF2u9roGBidEM28314jPxP6k4LgVBSdjn5BW4Zuc/Fs144A4ZXYhnljctEy 3di9N2JCky+SO4O4rwkFzpDux6vnYLqsPXk4bGNSYMExtcOMwEYDRUk2AaVnx6fak5LR C8nnwG03PFCcVtbcTmLxkM/KianCIqnyhrFg/KFUl3osHS3qXi6MA/7svCqocJPH7E1g hIcuBZQuSay9io3I3uJrqgoQAnxx6qiooig6m+3wbbaGw8PCwmpCmQNaB30VOXVqDDZq +G/7MKGX0repUmLnGNPDvTjnNMgcwVOuUN0M4VfV5tkhUREI7sDo8viXKdMTs23ohACZ uJ4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=rcJix56m666U/oGL+Ep7uxWmHMsgjWYiGV8nsO8hBEs=; b=RQ7LQ6CZ8kwotgf1OpCCo/9l9iOr1TOsmVIJJ+vPS2poVTL5osGkJff83/PEc9qGy1 XZz2RMiHHgfhf5sOi+9q4CB8P9mfrlKu6skxCB1tIhzGKPQz9uF2tOx9uf1hDsYjpNwA epDNYa50ldQPwLZzO/T3daRmWQ5gdhxCgQOhqxFZjSUFI0CTGZAU2bHujaY1GYvRm40h g4gru0o383AmUs6aT+Oz9mwA10UdXi3RS13XQw0fUAUKi6SJg3fXdJGmFUZB0YsDgeWE DxxXliePlpTKlOIQKzTl1ZtMwIq3oFJSF68r1Rp1wT0FsDknHtii7X8S6LUbws0LYVa0 z/xg== X-Gm-Message-State: ALoCoQnNgnpJ0frsCt8uPYfGqE7T5IXaByA7ONIltISoYjEig5OtpIeF1Z+pMhGcr4BzVq/wNrv/ X-Received: by 10.129.32.4 with SMTP id g4mr3014179ywg.94.1435334551702; Fri, 26 Jun 2015 09:02:31 -0700 (PDT) MIME-Version: 1.0 References: <558D61DE.8020402@nic.cz> In-Reply-To: <558D61DE.8020402@nic.cz> From: Adam Eijdenberg Date: Fri, 26 Jun 2015 16:02:22 +0000 Message-ID: To: Ondrej Mikle , trans@ietf.org Content-Type: multipart/alternative; boundary=001a1141384c16b3b805196dde49 Archived-At: Subject: Re: [Trans] Verifying inclusion proof 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, 26 Jun 2015 16:02:35 -0000 --001a1141384c16b3b805196dde49 Content-Type: text/plain; charset=UTF-8 Hi Ondrej, I had the exact same question last week when I started wanted to verify get-proof-by-hash. It turns out that you actually can figure out which is applied to the left and the right by looking the bits in the index of the log entry that you are requesting proof for. I found it easier to describe in code than words. Take a look at the following Python that fetches an arbitrary entry from an arbitrary log, then fetches the current STH, then requests an inclusion proof and finally verifies that proof. I hope that helps. Cheers, Adam import urllib, urllib2, json, base64, hashlib # Entry to play with log_entry = 438942 log = 'ct.googleapis.com/pilot' # Get the merkle tree leaf and b64 decode it entries = json.loads(urllib2.urlopen('https://%s/ct/v1/get-entries?%s' % (log, urllib.urlencode({'start': log_entry, 'end': log_entry}))).read()) mtl = base64.b64decode(entries['entries'][0]['leaf_input']) # Get current STH sth = json.loads(urllib2.urlopen('https://%s/ct/v1/get-sth' % log).read()) # Create the leaf hash leaf_hash = hashlib.sha256(chr(0) + mtl).digest() # Fetch proof that the leaft hash is included in the current STH url = 'https://%s/ct/v1/get-proof-by-hash?%s' % (log, urllib.urlencode({'hash': base64.b64encode(leaf_hash), 'tree_size': sth['tree_size']})) proof = json.loads(urllib2.urlopen(url).read()) # Derive the sha256 root hash based on the leaf_hash and the audit_proof node = leaf_hash idx = log_entry for p in proof['audit_path']: if idx & 1: node = hashlib.sha256(chr(1) + base64.b64decode(p) + node).digest() else: node = hashlib.sha256(chr(1) + node + base64.b64decode(p)).digest() idx >>= 1 if node == base64.b64decode(sth['sha256_root_hash']): print 'Log proved inclusion' else: print 'Fail.' On Fri, Jun 26, 2015 at 7:30 AM Ondrej Mikle wrote: > Pardon me if I am asking something obvious, but I'm missing one piece of > information for inclusion proof verification - the "placement" of each > node returned from "get-proof-by-hash" method in audit_path list > (whether it's left subtree or right subtree). > > Since the hashing of concatenation of strings is not commutative, the > auditor needs to put the two partial tree hashes in correct order to get > to the correct root hash. > > I'd guess the placement of the missing nodes from audit_path could be > derived from leaf_index and tree_size, but can't see a straightforward > way to do it. The reference client does not implement this verification > either. > > Ondrej > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a1141384c16b3b805196dde49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ondrej,

I had the exact same questio= n last week when I started wanted to verify get-proof-by-hash.=C2=A0 It tur= ns out that you actually can figure out which is applied to the left and th= e right by looking the bits in the index of the log entry that you are requ= esting proof for.=C2=A0 I found it easier to describe in code than words.= =C2=A0 Take a look at the following Python that fetches an arbitrary entry = from an arbitrary log, then fetches the current STH, then requests an inclu= sion proof and finally verifies that proof.

I hope= that helps.

Cheers, Adam


import urllib, urllib2, json, base64, hashlib

# Entry to play with
log_entry =3D 438942
<= div>log =3D 'ct.googleapis.c= om/pilot'

# Get the merkle tree leaf and b= 64 decode it
entries =3D json.loads(urllib2.urlopen('https://= %s/ct/v1/get-entries?%s' % (log, urllib.urlencode({'start': log= _entry, 'end': log_entry}))).read())
mtl =3D base64.b64de= code(entries['entries'][0]['leaf_input'])

# Get current STH
sth =3D json.loads(urllib2.urlopen('= ;https://%s/ct/v1/get-sth' % log).read())

# Cr= eate the leaf hash
leaf_hash =3D hashlib.sha256(chr(0) + mtl).dig= est()

# Fetch proof that the leaft hash is include= d in the current STH
url =3D 'https://%s/ct/v1/get-proof-by-h= ash?%s' % (log, urllib.urlencode({'hash': base64.b64encode(leaf= _hash), 'tree_size': sth['tree_size']}))
proof = =3D json.loads(urllib2.urlopen(url).read())

# Deri= ve the sha256 root hash based on the leaf_hash and the audit_proof
node =3D leaf_hash
idx =3D log_entry
for p in proof[&= #39;audit_path']:
=C2=A0 if idx & 1:
=C2=A0 =C2= =A0 node =3D hashlib.sha256(chr(1) + base64.b64decode(p) + node).digest()
=C2=A0 else:
=C2=A0 =C2=A0 node =3D hashlib.sha256(chr(1= ) + node + base64.b64decode(p)).digest()
=C2=A0 idx >>=3D 1=

if node =3D=3D base64.b64decode(sth['sha256_r= oot_hash']):
=C2=A0 print 'Log proved inclusion'
else:
=C2=A0 print 'Fail.'



On Fri, Ju= n 26, 2015 at 7:30 AM Ondrej Mikle <ondrej.mikle@nic.cz> wrote:
Pardon me if I am asking something obvious, but I'= m missing one piece of
information for inclusion proof verification - the "placement" of= each
node returned from "get-proof-by-hash" method in audit_path list<= br> (whether it's left subtree or right subtree).

Since the hashing of concatenation of strings is not commutative, the
auditor needs to put the two partial tree hashes in correct order to get to the correct root hash.

I'd guess the placement of the missing nodes from audit_path could be derived from leaf_index and tree_size, but can't see a straightforward<= br> way to do it. The reference client does not implement this verification
either.

Ondrej

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--001a1141384c16b3b805196dde49-- From nobody Fri Jun 26 17:52:40 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 4E18F1A1A07 for ; Fri, 26 Jun 2015 08:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 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, J_CHICKENPOX_21=0.6, 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 cyHt6B3X_AoC for ; Fri, 26 Jun 2015 08:27:38 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::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 D56061A0095 for ; Fri, 26 Jun 2015 08:27:37 -0700 (PDT) Received: by iebrt9 with SMTP id rt9so78030080ieb.2 for ; Fri, 26 Jun 2015 08:27:37 -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=7n76ulBXZrk/P+LhrjzPd4Vp9Ts2kQReqbUbyqVna3Y=; b=k8Kf+iff1k20lnf4wZ68HfpWbQsrL0pSYyqrLVr+KzAGempj6eAXb/og7cW44sIafM k7+3S7LRHyWD9kKu6lJn3mHJCnBC+GH/MMTkWwsh3N/Kj+IkXxXOkpg961COUlZNpaat C11SL+rb4iM9x+KlHHN/aKTq9lanHVUHwmlo/n73qCXhtLHUQe+eFgvjz32f0BnmNEg+ R8bMkfCBEhCQtaAEYpCTQLldHBOvivcvX+4A27r8N4xxorO4IfWf2exDgJd/ZFWLE58G SJEAfKbtpldKCtrdXDwg8uOKbzsoa+swarOfg6+sNYB0TKsK3336wjOIU6bsVZKlwsO8 NW9w== 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=7n76ulBXZrk/P+LhrjzPd4Vp9Ts2kQReqbUbyqVna3Y=; b=eBn5Q6ayVks5F2Rw5KGNTiUc9NJ8EhkMl2hxtJ2IT94IgvCbt2qrOVgkBIzyZooY1N RqC0sWlwOSn7WujPV4JLIQEkXbmCHtDB+2MMFjVll1mwggY4kkqX7T8ApAFf8xilHIsL YqDaAtenaq0BmdF4Hglj7fumS1LNB3lUK4HPT3En/G9SZ3n1TMpPD8dIoduVgWj8GVnY kxLOx+tTq31gG1X3iupjiMXnhMPsJKFDTff+xurRyvPHyMVhg2GHexSs6A5JDMVkc0WO ReZEkMRA3Ua+2YXoDyYrLqfwy8zjcBiXXTwcRjnGS9o2CQcvPCor4ndLuQv26ya1wY8W ZtZQ== X-Gm-Message-State: ALoCoQkSS/uX+RnVwVoP5CZGmGmeEcTuzcEBA8BL+EbsznPdhLnMxIFviYWnILgVAZj7CuR+OuYm MIME-Version: 1.0 X-Received: by 10.42.85.207 with SMTP id r15mr4132906icl.94.1435332457248; Fri, 26 Jun 2015 08:27:37 -0700 (PDT) Received: by 10.36.54.68 with HTTP; Fri, 26 Jun 2015 08:27:37 -0700 (PDT) In-Reply-To: <558D61DE.8020402@nic.cz> References: <558D61DE.8020402@nic.cz> Date: Fri, 26 Jun 2015 16:27:37 +0100 Message-ID: From: Al Cutter To: Ondrej Mikle Content-Type: multipart/alternative; boundary=20cf303349653fe99405196d61f1 Archived-At: X-Mailman-Approved-At: Fri, 26 Jun 2015 17:52:40 -0700 Cc: trans@ietf.org Subject: Re: [Trans] Verifying inclusion proof 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, 26 Jun 2015 15:27:39 -0000 --20cf303349653fe99405196d61f1 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 26, 2015 at 3:29 PM, Ondrej Mikle wrote: > Pardon me if I am asking something obvious, but I'm missing one piece of > information for inclusion proof verification - the "placement" of each > node returned from "get-proof-by-hash" method in audit_path list > (whether it's left subtree or right subtree). > > Since the hashing of concatenation of strings is not commutative, the > auditor needs to put the two partial tree hashes in correct order to get > to the correct root hash. > Yes, you're quite right. > > I'd guess the placement of the missing nodes from audit_path could be > derived from leaf_index and tree_size, but can't see a straightforward > way to do it. The reference client does not implement this verification > either. > > There are a couple of implementations of this in the o/s code base: C++ is in cpp/merkletree/merkle_verifier.cc (see VerifyPath()) Python is in python/ct/crypto/merkle.py (see verify_leaf_inclusion()) HTH. Cheers, Al. > Ondrej > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Google UK Ltd | 123 Buckingham Palace Road | London SW1W 9SH | Registered in England Number: 3977902 --20cf303349653fe99405196d61f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 26, 2015 at 3:29 PM, Ondrej Mikle <ondrej.mikle@nic.cz> wrote:
Pardon me if I am asking something= obvious, but I'm missing one piece of
information for inclusion proof verification - the "placement" of= each
node returned from "get-proof-by-hash" method in audit_path list<= br> (whether it's left subtree or right subtree).

Since the hashing of concatenation of strings is not commutative, the
auditor needs to put the two partial tree hashes in correct order to get to the correct root hash.

Yes, you'= re quite right.
=C2=A0

I'd guess the placement of the missing nodes from audit_path could be derived from leaf_index and tree_size, but can't see a straightforward<= br> way to do it. The reference client does not implement this verification
either.

=C2=A0
There are a couple of implementation= s of this in the o/s code base:
Python is in=C2=A0python/ct/crypto/merkle.py=C2=A0(see=C2=A0verify_leaf_inclusion())

<= /div>
HTH.

Cheers,
Al.
=C2=A0
Ondrej

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



--
Google UK Ltd | 123 Buckingham Palace Road |=C2=A0L= ondon=C2=A0SW1W 9SH=C2=A0| Registe= red in England Number: 3977902
--20cf303349653fe99405196d61f1-- From nobody Sun Jun 28 08:05:07 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 6F9061B2ED0 for ; Sun, 28 Jun 2015 08:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, 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 I25uzb9xJocf for ; Sun, 28 Jun 2015 08:05:03 -0700 (PDT) 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 698D91B2EC6 for ; Sun, 28 Jun 2015 08:05:03 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:49194 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z9E8j-000C6Y-Mc for trans@ietf.org; Sun, 28 Jun 2015 11:05:01 -0400 Message-ID: <55900D1D.2030009@bbn.com> Date: Sun, 28 Jun 2015 11:05:01 -0400 From: Stephen Kent 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: <558D61DE.8020402@nic.cz> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060009060405070903080204" Archived-At: Subject: Re: [Trans] Verifying inclusion proof 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, 28 Jun 2015 15:05:05 -0000 This is a multi-part message in MIME format. --------------060009060405070903080204 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit IETF standards need to be unambiguous. Code is very helpful, but it is not a substitute for a rigorous description of how to resolve the issue that Onderj raised. Steve > > On Fri, Jun 26, 2015 at 3:29 PM, Ondrej Mikle > wrote: > > Pardon me if I am asking something obvious, but I'm missing one > piece of > information for inclusion proof verification - the "placement" of each > node returned from "get-proof-by-hash" method in audit_path list > (whether it's left subtree or right subtree). > > Since the hashing of concatenation of strings is not commutative, the > auditor needs to put the two partial tree hashes in correct order > to get > to the correct root hash. > > > Yes, you're quite right. > > > I'd guess the placement of the missing nodes from audit_path could be > derived from leaf_index and tree_size, but can't see a straightforward > way to do it. The reference client does not implement this > verification > either. > > There are a couple of implementations of this in the o/s code base: > C++ is in cpp/merkletree/merkle_verifier.cc > (see > VerifyPath()) > Python is in python/ct/crypto/merkle.py > (see > verify_leaf_inclusion()) > > HTH. > > Cheers, > Al. > > Ondrej > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > > > > -- > Google UK Ltd | 123 Buckingham Palace Road | London SW1W 9SH | > Registered in England Number: 3977902 > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --------------060009060405070903080204 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit IETF standards need to be unambiguous. Code is very helpful, but it is not a substitute
for a rigorous description of how to resolve the issue that Onderj raised.

Steve

On Fri, Jun 26, 2015 at 3:29 PM, Ondrej Mikle <ondrej.mikle@nic.cz> wrote:
Pardon me if I am asking something obvious, but I'm missing one piece of
information for inclusion proof verification - the "placement" of each
node returned from "get-proof-by-hash" method in audit_path list
(whether it's left subtree or right subtree).

Since the hashing of concatenation of strings is not commutative, the
auditor needs to put the two partial tree hashes in correct order to get
to the correct root hash.

Yes, you're quite right.
 

I'd guess the placement of the missing nodes from audit_path could be
derived from leaf_index and tree_size, but can't see a straightforward
way to do it. The reference client does not implement this verification
either.

 
There are a couple of implementations of this in the o/s code base:
C++ is in cpp/merkletree/merkle_verifier.cc (see VerifyPath())
Python is in python/ct/crypto/merkle.py (see verify_leaf_inclusion())

HTH.

Cheers,
Al.

 
Ondrej

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



--
Google UK Ltd | 123 Buckingham Palace Road | London SW1W 9SH | Registered in England Number: 3977902


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

--------------060009060405070903080204-- From nobody Sun Jun 28 08:26:53 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 404FA1A8827 for ; Sun, 28 Jun 2015 08:26:53 -0700 (PDT) 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 rNADQbfbKi5o for ; Sun, 28 Jun 2015 08:26:52 -0700 (PDT) Received: from mail-vn0-x229.google.com (mail-vn0-x229.google.com [IPv6:2607:f8b0:400c:c0f::229]) (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 4261B1A8824 for ; Sun, 28 Jun 2015 08:26:52 -0700 (PDT) Received: by vnbf129 with SMTP id f129so6488908vnb.5 for ; Sun, 28 Jun 2015 08:26:51 -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=pvGIxNCXpZ8F62LE7oVZbGf2sFhKk4M4YnAWClUCt04=; b=Mi+/BsbiiS2I7q9vjRRRElHM82VBIQgFBsZGxbs+gWv/Bm7wxcXQ/aBHwGNkqB0P0x 0J/IPw3qyS9jNArAS2Sj/5jrp5kXnFC1hafgccYrH/XNW62S5w6tVbC2e+Gl5M8ZXBsn mL5UACiTCt5F+Zba5v+/hoUPqnVG4xOGH1eUyGe8TPWTcfvIKLU74qAg8lqDyyxjolUO asFHE4Xdl3xkgaZQs+WO8DILb3Kn/t6bxIXFcjxWXFVeVOSetkRcA64MPYF9O2BtYwE8 kxbHBEPts6yoJUR2mJFRiA65d1ibxVAVsA8ehnUqYSaMIsFwrrsOFEH/hZnxvMinCQxu MMAA== 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=pvGIxNCXpZ8F62LE7oVZbGf2sFhKk4M4YnAWClUCt04=; b=Bo/osrFwIdGU9LbC6ye8/CcTnQLREvs6npSeMKlqqo1QWi2vJJnPTJiXDRQSYBMra8 c1VT66MIWE6lDHc2j8CFzt6F1ehVft268YhID1UksZJ8KwlaPnFD/Zweh23mXCxnStPq xr/fSsC4oDqxSQJMjGXt8d+OGRwLmd8wqsAvItdypd8eq2sRjp3u2eIH2Xj7ROY71CFA CWJFMFkk24vaOtL3Jv+0EXmly5DbzSWqkWVuadAvEsG0W1daEJkC628TcjHRT0Egzd2h /+UvvFyGUdnlbt6QeO6r2MCKxBAWPxZ4i5LbfrhYny0qWPXzGeqzKCO0r8FUTHxhtUsl U8NA== X-Gm-Message-State: ALoCoQnHLpK/kvlsT5YboLSFYAWfYVvf50UV1YbHeM3zsd2Ss8Z7/b156Du7Sj4zPiwrt8WJG/az MIME-Version: 1.0 X-Received: by 10.52.75.201 with SMTP id e9mr9279683vdw.33.1435505211412; Sun, 28 Jun 2015 08:26:51 -0700 (PDT) Received: by 10.52.76.6 with HTTP; Sun, 28 Jun 2015 08:26:51 -0700 (PDT) In-Reply-To: <55900D1D.2030009@bbn.com> References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> Date: Sun, 28 Jun 2015 16:26:51 +0100 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Verifying inclusion proof 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, 28 Jun 2015 15:26:53 -0000 On 28 June 2015 at 16:05, Stephen Kent wrote: > IETF standards need to be unambiguous. Code is very helpful, but it is not a > substitute > for a rigorous description of how to resolve the issue that Onderj raised. Whilst I am not necessarily opposed to that, there has to be a point at which you stop explaining what can be worked out given existing information. The RFC does state how the hash is calculated, from which it is clear what the placement of each node is in the hash calculation. From nobody Sun Jun 28 15:06:57 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 683811B2F66 for ; Sun, 28 Jun 2015 15:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.455 X-Spam-Level: * X-Spam-Status: No, score=1.455 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_SOFTFAIL=0.665, 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 bColt06ek4WA for ; Sun, 28 Jun 2015 15:06:54 -0700 (PDT) Received: from mail.hezmatt.org (minotaur.hezmatt.org [IPv6:2a01:4f8:121:3431:e2e4:22bb:25f5:6cad]) by ietfa.amsl.com (Postfix) with ESMTP id 77E8A1B2F5C for ; Sun, 28 Jun 2015 15:06:54 -0700 (PDT) Received: from mistress.home.hezmatt.org (2001-44b8-3196-7300-e055-d787-231a-c54b.static.ipv6.internode.on.net [IPv6:2001:44b8:3196:7300:e055:d787:231a:c54b]) by mail.hezmatt.org (Postfix) with ESMTPSA id 73886686EA for ; Sun, 28 Jun 2015 22:06:51 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 9B6A09FE13; Mon, 29 Jun 2015 08:06:48 +1000 (AEST) Date: Mon, 29 Jun 2015 08:06:48 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20150628220648.GI13302@hezmatt.org> References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Verifying inclusion proof 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, 28 Jun 2015 22:06:56 -0000 On Sun, Jun 28, 2015 at 04:26:51PM +0100, Ben Laurie wrote: > On 28 June 2015 at 16:05, Stephen Kent wrote: > > IETF standards need to be unambiguous. Code is very helpful, but it is not a > > substitute > > for a rigorous description of how to resolve the issue that Onderj raised. > > Whilst I am not necessarily opposed to that, there has to be a point > at which you stop explaining what can be worked out given existing > information. The RFC does state how the hash is calculated, from which > it is clear what the placement of each node is in the hash > calculation. s/it is clear/it is possible to determine/ I would be in favour of more clarity around exactly how the inclusion proof is represented; I recall having significant trouble comprehending how inclusion proofs "worked", and ended up examining existing operational logs and using trial and error to determine how the inclusion proof was presented. - Matt From nobody Sun Jun 28 17:16: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 4E3501B30BE for ; Sun, 28 Jun 2015 17:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.455 X-Spam-Level: * X-Spam-Status: No, score=1.455 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_SOFTFAIL=0.665, 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 912hAEhLecPU for ; Sun, 28 Jun 2015 17:16:12 -0700 (PDT) Received: from mail.hezmatt.org (minotaur.hezmatt.org [IPv6:2a01:4f8:121:3431:e2e4:22bb:25f5:6cad]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4421B30BC for ; Sun, 28 Jun 2015 17:16:11 -0700 (PDT) Received: from mistress.home.hezmatt.org (eth1372.nsw.adsl.internode.on.net [150.101.203.91]) by mail.hezmatt.org (Postfix) with ESMTPSA id 2753168730; Mon, 29 Jun 2015 00:16:09 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 853659FE13; Mon, 29 Jun 2015 10:16:05 +1000 (AEST) Date: Mon, 29 Jun 2015 10:16:05 +1000 From: Matt Palmer To: Melinda Shore Message-ID: <20150629001605.GR13302@hezmatt.org> References: <53D9600C.6040805@gmail.com> <556F0EB1.1060400@comodo.com> <556F4055.6040609@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556F4055.6040609@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Tracking implementations 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, 29 Jun 2015 00:16:14 -0000 On Wed, Jun 03, 2015 at 09:58:45AM -0800, Melinda Shore wrote: > Excellent - thanks! I've updated the wiki: > http://trac.tools.ietf.org/wg/trans/trac/wiki > > If there are other implementations underway, > please let us know. I've recently released an open-source (GPLv3) RFC6962-compliant log monitoring framework, for retrieving and validating STHs, entries, etc: https://github.com/tobermorytech/certificate-transparency-monitor I've also released several supporting Ruby gems: * merkle-hash-tree -- build and verify merkle hash trees; * certificate-transparency -- RFC6962 data structures; * certificate-transparency-client -- interact with an RFC6962 log over HTTP. I'd add all of these to the wiki page, except that I can't seem to get a Trac login (I'm following up that with webmaster@tools). - Matt From nobody Sun Jun 28 18:08:45 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 B78781ACEE3 for ; Sun, 28 Jun 2015 18:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 R_saA5X1Wj_h for ; Sun, 28 Jun 2015 18:08:42 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 BFD731ACEE4 for ; Sun, 28 Jun 2015 18:08:42 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so96456197pab.1 for ; Sun, 28 Jun 2015 18:08:42 -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 :references:in-reply-to:content-type:content-transfer-encoding; bh=8iUWY57LubgCa0H30elmjYuqxcTgGeLX1WxJGQMPGRQ=; b=yVulZzGw4QWzG5XI/WY3qHXYtP4RhfXBRsoqL2f4lTPEkqXr1ZWUUvQM8qo1OBr5ZK VyRxIeZBiDTwaL7vXX2JS/n52OP/6sbptRRbKrwtH2tBON4rA15NB8J1rLnvoIWH1IEF kWTEp7rqV/8thZR3CJgGNPKZutfYFKeOE/CByY8N+InLiUnpkIYVArBfWB+bBvZooyBo olXoDjdHnKP47kK7gexneDjjvuI4vcNMwE1Jl+VcNaZiVVTVqDSuY/2ky+yktgjd22q7 VhctOY58G7uqMr/2FDxt5V4+evppCryPLavhzuCGR7pTcsM9mASA4AoD1qoJfeKw3Qdh XhVQ== X-Received: by 10.70.62.66 with SMTP id w2mr26257000pdr.106.1435540122404; Sun, 28 Jun 2015 18:08:42 -0700 (PDT) Received: from spandex.local (216-67-117-38-rb3.fai.dsl.dynamic.acsalaska.net. [216.67.117.38]) by mx.google.com with ESMTPSA id cc5sm22661440pac.24.2015.06.28.18.08.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Jun 2015 18:08:41 -0700 (PDT) Message-ID: <55909A97.8020502@gmail.com> Date: Sun, 28 Jun 2015 17:08:39 -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: Matt Palmer References: <53D9600C.6040805@gmail.com> <556F0EB1.1060400@comodo.com> <556F4055.6040609@gmail.com> <20150629001605.GR13302@hezmatt.org> In-Reply-To: <20150629001605.GR13302@hezmatt.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Tracking implementations 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, 29 Jun 2015 01:08:44 -0000 Great, Matt - thanks. Sorry about the Trac problem - small consolation but this does happen unfortunately often. Melinda From nobody Mon Jun 29 04:03:37 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 0131D1A8BAF for ; Mon, 29 Jun 2015 04:03:36 -0700 (PDT) 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=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 G0VQSpzAkukC for ; Mon, 29 Jun 2015 04:03:35 -0700 (PDT) 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 2D96B1A8B84 for ; Mon, 29 Jun 2015 04:03:35 -0700 (PDT) Received: from localhost ([::1]:39495 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z9WqY-00080v-A6; Mon, 29 Jun 2015 04:03:30 -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, pphaneuf@gmail.com, benl@google.com X-Trac-Project: trans Date: Mon, 29 Jun 2015 11:03:30 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/88#comment:4 Message-ID: <073.abdc5b2e9dc21735d6a279165985c44a@tools.ietf.org> References: <058.a978a1b85df450a3b12c330a07fecb4e@tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <058.a978a1b85df450a3b12c330a07fecb4e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, pphaneuf@gmail.com, benl@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: <20150629110335.2D96B1A8B84@ietfa.amsl.com> Resent-Date: Mon, 29 Jun 2015 04:03:35 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #88 (rfc6962-bis): get-entries: "end" should be greater-than-or-equal to "start" 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, 29 Jun 2015 11:03:36 -0000 #88: get-entries: "end" should be greater-than-or-equal to "start" Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/b94e659e6501bd0d01c797965f69ab5d3223add1 -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jun 29 04:04: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 A38821A8BB5 for ; Mon, 29 Jun 2015 04:04:00 -0700 (PDT) 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 xs4-tbUy_pXA for ; Mon, 29 Jun 2015 04:03:59 -0700 (PDT) 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 F2C4D1A8B84 for ; Mon, 29 Jun 2015 04:03:58 -0700 (PDT) Received: from localhost ([::1]:39513 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z9Wr0-00084k-LM; Mon, 29 Jun 2015 04:03:58 -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, benl@google.com X-Trac-Project: trans Date: Mon, 29 Jun 2015 11:03:58 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/89#comment:1 Message-ID: <073.dc2f957801da5e70ca34f5a47838a9b1@tools.ietf.org> References: <058.a3b286b289bea15e728f874a714d34be@tools.ietf.org> X-Trac-Ticket-ID: 89 In-Reply-To: <058.a3b286b289bea15e728f874a714d34be@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@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: <20150629110358.F2C4D1A8B84@ietfa.amsl.com> Resent-Date: Mon, 29 Jun 2015 04:03:58 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #89 (rfc6962-bis): get-entries: "end" greater than "tree_size" should be allowed 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, 29 Jun 2015 11:04:00 -0000 #89: get-entries: "end" greater than "tree_size" should be allowed Changes (by benl@google.com): * milestone: => review Comment: Fixed at https://github.com/google/certificate-transparency- rfcs/commit/b94e659e6501bd0d01c797965f69ab5d3223add1. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jun 29 04:29:51 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 E6A791A9006 for ; Mon, 29 Jun 2015 04:29:49 -0700 (PDT) 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 sgQje4sEgCld for ; Mon, 29 Jun 2015 04:29:48 -0700 (PDT) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::22f]) (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 AB6B91A8FD3 for ; Mon, 29 Jun 2015 04:29:48 -0700 (PDT) Received: by vnbf190 with SMTP id f190so23647870vnb.0 for ; Mon, 29 Jun 2015 04:29:48 -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=lseCfCd95Q1Pt53ssTIgNDfOsh43mgWTW+Rqg/S8HIw=; b=Cd41fUg/uF3+9ymhZ4GJEwQhotCqeCv6pw4WSNKpTwazq/ibvt6nukhukyRkPBNJVx w9BHeClKT4eB+93VAOWj0BkEmeWRN57rTchw4nyqreyEbooJrFXFoDcZZyxUF7gpPhm4 SQgz5C4AiW700YhUiC/WV6qLW9x5IqzXU7+C2tJhionnd89K8y1Qmdv43fD4kgTuD6vN UzeIG8ZLQQLAShBEaBlVQREwIrOY6o3X2ABEOeRKVhAUfA8xn5vJEuOkXO0SndwXNTY9 jJUp3OmQ3pwm/wV1FHHbU+5hTlbCLKm+CnIq9P9gQ/rnwGSyWZ1+iPdnc48UJ2kDlxSt DHFA== 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=lseCfCd95Q1Pt53ssTIgNDfOsh43mgWTW+Rqg/S8HIw=; b=R2iLA9D/FRQuPijxDY+pN5/HGT9TzQoXiWkEfVbTu4Y/3NE53y5xYLgGf/iTl4fGsP s5VqVEwImPavccGcuW+SLhMLACkJmB+HgJxcpJ1PgQGKap8jpZCXYsfAdshdy5XobxuY 2J2xb/wNpakryihL9rT8vjG+dV+yZFBBp50YPB0H3pzIxxWcWX+8/2Z1ShaGnGETkcoh Re8vCr1sswxs0+gfgu2uok+s5sxdTF63jTmMqjHwehEkxFCVEjDfD0ylk0ucgVHRkAgO zIcRw5lIM176NntYkC5ZxdLoQAt4AV9B3vgYIiGkqhork+ydK1+ABFAB9clu/rBi6/Df GsSQ== X-Gm-Message-State: ALoCoQnmCG6MuQ4IKhA80Y5ByMc86nmZWGaCQQEsKPdp0t5Ab93COWQ4Wgb/rao+sjh9xCbsy7gt MIME-Version: 1.0 X-Received: by 10.52.26.5 with SMTP id h5mr12376292vdg.3.1435577387932; Mon, 29 Jun 2015 04:29:47 -0700 (PDT) Received: by 10.52.76.6 with HTTP; Mon, 29 Jun 2015 04:29:47 -0700 (PDT) In-Reply-To: <20150628220648.GI13302@hezmatt.org> References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> <20150628220648.GI13302@hezmatt.org> Date: Mon, 29 Jun 2015 12:29:47 +0100 Message-ID: From: Ben Laurie To: Matt Palmer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Verifying inclusion proof 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, 29 Jun 2015 11:29:50 -0000 On 28 June 2015 at 23:06, Matt Palmer wrote: > On Sun, Jun 28, 2015 at 04:26:51PM +0100, Ben Laurie wrote: >> On 28 June 2015 at 16:05, Stephen Kent wrote: >> > IETF standards need to be unambiguous. Code is very helpful, but it is not a >> > substitute >> > for a rigorous description of how to resolve the issue that Onderj raised. >> >> Whilst I am not necessarily opposed to that, there has to be a point >> at which you stop explaining what can be worked out given existing >> information. The RFC does state how the hash is calculated, from which >> it is clear what the placement of each node is in the hash >> calculation. > > s/it is clear/it is possible to determine/ > > I would be in favour of more clarity around exactly how the inclusion proof > is represented; I recall having significant trouble comprehending how > inclusion proofs "worked", and ended up examining existing operational logs > and using trial and error to determine how the inclusion proof was > presented. Feel free to open a ticket. However, the mechanism for verifying inclusion in a Merkle tree is widely available in standard texts, for example 3.3 in http://www.emsec.rub.de/media/crypto/attachments/files/2011/04/becker_1.pdf. From nobody Mon Jun 29 04:35: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 A3D9C1A902B for ; Mon, 29 Jun 2015 04:35:10 -0700 (PDT) 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=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 KY3btAFswJXc for ; Mon, 29 Jun 2015 04:35:09 -0700 (PDT) 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 BEB4D1A9029 for ; Mon, 29 Jun 2015 04:35:09 -0700 (PDT) Received: from localhost ([::1]:41088 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z9XL7-0007Tt-6X; Mon, 29 Jun 2015 04:35:05 -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, benl@google.com X-Trac-Project: trans Date: Mon, 29 Jun 2015 11:35:05 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/82#comment:7 Message-ID: <073.1655e6f178990791942e543c264b76da@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, benl@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: <20150629113509.BEB4D1A9029@ietfa.amsl.com> Resent-Date: Mon, 29 Jun 2015 04:35:09 -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, 29 Jun 2015 11:35:10 -0000 #82: Add a way to get the SCTs for entries returned by get-entries Changes (by benl@google.com): * milestone: => review Comment: Added at https://github.com/google/certificate-transparency- rfcs/commit/9141ac77ec0b1f52c9c2c39a721aa3d46ab910ab. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Mon Jun 29 07:36:08 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 60C641ACCE2 for ; Mon, 29 Jun 2015 07:36:06 -0700 (PDT) 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 9RZJhYqdgxMa for ; Mon, 29 Jun 2015 07:36:04 -0700 (PDT) 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 9D58B1A020A for ; Mon, 29 Jun 2015 07:36:04 -0700 (PDT) Received: from localhost ([::1]:52684 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Z9aAG-000377-2T; Mon, 29 Jun 2015 07:36:04 -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: eranm@google.com X-Trac-Project: trans Date: Mon, 29 Jun 2015 14:36:03 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/91 Message-ID: <056.1a3a0b4df721b59933a4c32a232c7f3e@tools.ietf.org> X-Trac-Ticket-ID: 91 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: 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 Archived-At: Cc: trans@ietf.org Subject: [Trans] [trans] #91 (client-behavior): Clarify encoding of fields in the log client messages 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, 29 Jun 2015 14:36:06 -0000 #91: Clarify encoding of fields in the log client messages In section 4, log client messages, some fields are missing encoding. For example, the get-sth message defines the sha256_root_hash to be base64-encoded but not tree_head_signature. -- ------------------------------+------------------------------ Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: client-behavior | Version: Severity: - | Keywords: ------------------------------+------------------------------ Ticket URL: trans From nobody Mon Jun 29 11:21:22 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 E51C51A000A for ; Mon, 29 Jun 2015 11:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-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 J7EFXGYuu4Nu for ; Mon, 29 Jun 2015 11:21:19 -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 079FA1A0047 for ; Mon, 29 Jun 2015 11:21:09 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:47973 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Z9dg3-000HLi-LM for trans@ietf.org; Mon, 29 Jun 2015 14:21:07 -0400 Message-ID: <55918C93.2040805@bbn.com> Date: Mon, 29 Jun 2015 14:21:07 -0400 From: Stephen Kent 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: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Verifying inclusion proof 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, 29 Jun 2015 18:21:21 -0000 Ben, > On 28 June 2015 at 16:05, Stephen Kent wrote: >> IETF standards need to be unambiguous. Code is very helpful, but it is not a >> substitute >> for a rigorous description of how to resolve the issue that Onderj raised. > Whilst I am not necessarily opposed to that, there has to be a point > at which you stop explaining what can be worked out given existing > information. The RFC does state how the hash is calculated, from which > it is clear what the placement of each node is in the hash > calculation. My comment is based on the question that was posed by someone for whom it was not clear. If most other (independent) implementers find the text clear enough, OK. Citing a tech paper is not the preferred approach for IETF docs. We often reproduce info that is available via other means, so that RFCs are as self-contained as possible. Steve From nobody Mon Jun 29 12:17: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 E285E1B2CCB for ; Mon, 29 Jun 2015 12:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKfA4mpmKFch for ; Mon, 29 Jun 2015 12:17:35 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::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 6C9D01B2CC9 for ; Mon, 29 Jun 2015 12:17:35 -0700 (PDT) Received: by laar3 with SMTP id r3so75504427laa.0 for ; Mon, 29 Jun 2015 12:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4t1Tnh/yFnhejLwPtxVNDER8JKs6g4sTaBixPpPReaY=; b=LBrJtUs9P53MnRTkZV7vvqh0k3tjJXBFG5DE2QfNVfRoqvTxeXtjpxwHwpwFMpFVQp zcFIfv4A4PI0N6sXu0G1CEMhQ2UOf4nDSKFJVSh+DfzguaJIpY2RmxOFkb1feYaXVcT8 mIsvhaVQejxppJMfF8ll/Y7DQW9Z3qez7G50uJQXzVmkBispOZxEKgNB78yi4GaktK7A eR0lMP6JOJr496aAdXlGLAgdkirqXfPTsz5Lthi1H7W5AmqZJj5VBap5yShcVnUqMfBh lwXjBgxMP3DWY/2fZWcy2+9O1t8inClcPqBA7aOqiOKji1V/y1joetXxMCtGpuD3/ECz +c9g== MIME-Version: 1.0 X-Received: by 10.152.197.2 with SMTP id iq2mr15797485lac.103.1435605453823; Mon, 29 Jun 2015 12:17:33 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.203.163 with HTTP; Mon, 29 Jun 2015 12:17:33 -0700 (PDT) In-Reply-To: <55918C93.2040805@bbn.com> References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> <55918C93.2040805@bbn.com> Date: Mon, 29 Jun 2015 15:17:33 -0400 X-Google-Sender-Auth: QvY5tDPWRKHQFUYyTm6eMG0llus Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11340b061ce8610519acf1db Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Verifying inclusion proof 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, 29 Jun 2015 19:17:37 -0000 --001a11340b061ce8610519acf1db Content-Type: text/plain; charset=UTF-8 On Mon, Jun 29, 2015 at 2:21 PM, Stephen Kent wrote: > Ben, > > On 28 June 2015 at 16:05, Stephen Kent wrote: >> >>> IETF standards need to be unambiguous. Code is very helpful, but it is >>> not a >>> substitute >>> for a rigorous description of how to resolve the issue that Onderj >>> raised. >>> >> Whilst I am not necessarily opposed to that, there has to be a point >> at which you stop explaining what can be worked out given existing >> information. The RFC does state how the hash is calculated, from which >> it is clear what the placement of each node is in the hash >> calculation. >> > My comment is based on the question that was posed by someone for > whom it was not clear. If most other (independent) implementers find > the text clear enough, OK. > > Citing a tech paper is not the preferred approach for IETF docs. We > often reproduce info that is available via other means, so that RFCs > are as self-contained as possible. As a general rule, placement and organization does not matter. If someone gives you the apex value of the tree and the sequence of branch values and whether they are left or right, you have all the info required to verify. While the spec says 'Merkle tree', all that is required for interop is to deliver the correct branches. --001a11340b061ce8610519acf1db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jun 29, 2015 at 2:21 PM, Stephen Kent <kent@bbn.com> = wrote:
Ben,

On 28 June 2015 at 16:05, Stephen Kent<kent@bbn.com>=C2=A0 wrote:
IETF standards need to be unambiguous. Code is very helpful, but it is not = a
substitute
for a rigorous description of how to resolve the issue that Onderj raised.<= br>
Whilst I am not necessarily opposed to that, there has to be a point
at which you stop explaining what can be worked out given existing
information. The RFC does state how the hash is calculated, from which
it is clear what the placement of each node is in the hash
calculation.
 My comment is based on the question that was posed by someone for
whom it was not clear. If most other (independent) implementers find
the text clear enough, OK.

Citing a tech paper is not the preferred approach for IETF docs. We
often reproduce info that is available via other means, so that RFCs
are as self-contained as possible.

As a gen= eral rule, placement and organization does not matter.

=
If someone gives you the apex value of the tree and the sequence of br= anch values and whether they are left or right, you have all the info requi= red to verify.


While the spec says = 'Merkle tree', all that is required for interop is to deliver the c= orrect branches.

=C2=A0

--001a11340b061ce8610519acf1db-- From nobody Mon Jun 29 16:05: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 6F0A51B2E60 for ; Mon, 29 Jun 2015 16:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 yj_x2gaijUg2 for ; Mon, 29 Jun 2015 16:05:08 -0700 (PDT) Received: from mail.hezmatt.org (erdhenne.tobermorytech.com [178.63.85.14]) by ietfa.amsl.com (Postfix) with ESMTP id 81FDF1B2E53 for ; Mon, 29 Jun 2015 16:05:04 -0700 (PDT) Received: from mistress.home.hezmatt.org (2001-44b8-3196-7300-1c5b-a8f1-b591-1eef.static.ipv6.internode.on.net [IPv6:2001:44b8:3196:7300:1c5b:a8f1:b591:1eef]) by mail.hezmatt.org (Postfix) with ESMTPSA id C65B968A0A for ; Mon, 29 Jun 2015 23:05:01 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id BE9049FE66; Tue, 30 Jun 2015 09:04:58 +1000 (AEST) Date: Tue, 30 Jun 2015 09:04:58 +1000 From: Matt Palmer To: "trans@ietf.org" Message-ID: <20150629230458.GX30545@hezmatt.org> References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> <20150628220648.GI13302@hezmatt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Verifying inclusion proof 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, 29 Jun 2015 23:05:10 -0000 On Mon, Jun 29, 2015 at 12:29:47PM +0100, Ben Laurie wrote: > On 28 June 2015 at 23:06, Matt Palmer wrote: > > On Sun, Jun 28, 2015 at 04:26:51PM +0100, Ben Laurie wrote: > >> On 28 June 2015 at 16:05, Stephen Kent wrote: > >> > IETF standards need to be unambiguous. Code is very helpful, but it is not a > >> > substitute > >> > for a rigorous description of how to resolve the issue that Onderj raised. > >> > >> Whilst I am not necessarily opposed to that, there has to be a point > >> at which you stop explaining what can be worked out given existing > >> information. The RFC does state how the hash is calculated, from which > >> it is clear what the placement of each node is in the hash > >> calculation. > > > > s/it is clear/it is possible to determine/ > > > > I would be in favour of more clarity around exactly how the inclusion proof > > is represented; I recall having significant trouble comprehending how > > inclusion proofs "worked", and ended up examining existing operational logs > > and using trial and error to determine how the inclusion proof was > > presented. > > Feel free to open a ticket. However, the mechanism for verifying > inclusion in a Merkle tree is widely available in standard texts, for > example 3.3 in http://www.emsec.rub.de/media/crypto/attachments/files/2011/04/becker_1.pdf. That document doesn't appear to be referenced in 6962bis, nor would it, I assume, answer the question "how is the inclusion proof represented in the response to get-sth-consistency". - Matt From nobody Tue Jun 30 05:30:16 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 76A9E1A8785 for ; Tue, 30 Jun 2015 05:30:14 -0700 (PDT) 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 NOubzAY8y34r for ; Tue, 30 Jun 2015 05:30:13 -0700 (PDT) Received: from mail-vn0-x233.google.com (mail-vn0-x233.google.com [IPv6:2607:f8b0:400c:c0f::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 1E29D1A8A92 for ; Tue, 30 Jun 2015 05:30:13 -0700 (PDT) Received: by vnbf62 with SMTP id f62so1246870vnb.9 for ; Tue, 30 Jun 2015 05:30:12 -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=5edV8sdbYr75PUzLgeum5wf6m0P8Tr9IMB+dHiXv2Os=; b=U5qX9sE4U/dtHCyfFJqiAf36yIjjAQckbatWPjJZOt7aRnALD5lL31UjPnTiNQga4G EQOiPw0mBv42RdFc10pICp2F7Lv7bapHID2nPguKaZpU7Vi7xUppsFNBWkeK0Aj2xweH EGyLF0bMgjCQyOUgQLTVzETYstp68nwU5R1IU4lewMWTYaFmLT76iNLIC3x2jkZWSQPa TiIJv7+mL0MIPAkchNTkyKS5g+iicOj7N250zzwA+iiPDKf1R1hzcZ93TbG+GPO+JAEH LEtSo0qB65zTejurHKQPsUHC0fBFz8wdwoj6pzac8O/Pq/bflpceBNdmzU2+yg06TuST Pz2Q== 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=5edV8sdbYr75PUzLgeum5wf6m0P8Tr9IMB+dHiXv2Os=; b=mfcFGIeLnvesaltGvFB+Nl+1H+lv5wghrdu8Yu5hB68cwQ7hUnlPs7sL/qVTbLQdgx +XdiNtKomWgxrf9/9ko4uZDVO7rWWSWcuCkgyoqObaRdtc+r0SHUrlURtJXuEMioLF3i 3D7xlbW184+i0JBDa2zF4S4oAo8YZ1v1MBb4Q5/FfUb7r2DvtDyLnA1BhS6lg81DPC6M GcUitHiQGm6bM8X6TZPXrlFLEJLm+jE7n2aldUpiY792sUS/06h94rs5a3BlLobxndjz lizkpYPD5oGXe1QcJ2kCYbSQAHwMGf7GSWWM2h0OWy5AAx5bgahhWWDKEGSMYxCVrFs4 9ORw== X-Gm-Message-State: ALoCoQkyTH1OKLZ/rAB5AVg2jE4slWEN43pELQScz7rvrQKMws7A843yKCkmKuiK+vqZw4ANFqst MIME-Version: 1.0 X-Received: by 10.52.179.73 with SMTP id de9mr19435186vdc.28.1435667412250; Tue, 30 Jun 2015 05:30:12 -0700 (PDT) Received: by 10.52.76.6 with HTTP; Tue, 30 Jun 2015 05:30:12 -0700 (PDT) In-Reply-To: References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> <55918C93.2040805@bbn.com> Date: Tue, 30 Jun 2015 13:30:12 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] Verifying inclusion proof 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, 30 Jun 2015 12:30:14 -0000 On 29 June 2015 at 20:17, Phillip Hallam-Baker wrote: > > > On Mon, Jun 29, 2015 at 2:21 PM, Stephen Kent wrote: >> >> Ben, >> >>> On 28 June 2015 at 16:05, Stephen Kent wrote: >>>> >>>> IETF standards need to be unambiguous. Code is very helpful, but it is >>>> not a >>>> substitute >>>> for a rigorous description of how to resolve the issue that Onderj >>>> raised. >>> >>> Whilst I am not necessarily opposed to that, there has to be a point >>> at which you stop explaining what can be worked out given existing >>> information. The RFC does state how the hash is calculated, from which >>> it is clear what the placement of each node is in the hash >>> calculation. >> >> My comment is based on the question that was posed by someone for >> whom it was not clear. If most other (independent) implementers find >> the text clear enough, OK. >> >> Citing a tech paper is not the preferred approach for IETF docs. We >> often reproduce info that is available via other means, so that RFCs >> are as self-contained as possible. > > > As a general rule, placement and organization does not matter. > > If someone gives you the apex value of the tree and the sequence of branch > values and whether they are left or right, you have all the info required to > verify. CT does not tell you left or right, since you can work it out from the index. > While the spec says 'Merkle tree', all that is required for interop is to > deliver the correct branches. > > > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Tue Jun 30 05:30:35 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 A76A21A8785 for ; Tue, 30 Jun 2015 05:30:34 -0700 (PDT) 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 DRcipdIKF7kf for ; Tue, 30 Jun 2015 05:30:33 -0700 (PDT) Received: from mail-vn0-x234.google.com (mail-vn0-x234.google.com [IPv6:2607:f8b0:400c:c0f::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 7146A1A8AEC for ; Tue, 30 Jun 2015 05:30:33 -0700 (PDT) Received: by vnbf1 with SMTP id f1so1247180vnb.11 for ; Tue, 30 Jun 2015 05:30:32 -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=4qRItnoAE1Iai4FZaQymCeWMEAcbR1VIjVNqnTULZ9M=; b=A0jkYGK82yGrhPAz5QC1mCS+nkV2ao+jVOg1XYTo7JR5qhewohehnfON02/ls6a8bc 6TqAmEzBbUAe6E8UMagkAK58/VvgMKwuwpBM8P8zEUBHv1jNd1O0KaQyRI9eQa8Klaq9 9zmh1mlNYchtATNGpZWDsCKH8VhCy3PGezwMbLwoRZXnEkxh74k04nJ1Bw7NkAe6fqmf UeSAl93pTFp0GGzEtjOTMdaYkKzCiDmWu/UeQHWyJXzPjSoK95w2NK82+07FsVaFoD/H osnRCD4d6YcVIB1fRoF/xbxYqfd62ZJMe0P648uYmE2EH7jo/LRKeBGVWx8xurO6SwMX TuyQ== 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=4qRItnoAE1Iai4FZaQymCeWMEAcbR1VIjVNqnTULZ9M=; b=H3u/usXEMZrX0LUPUQ3zzEle3IkgEmSvlkjqYtHhKT0fZh5V5VR2rEzyXt/8xrTBJU Z7VAUrRbxT4krgU4KAHfGV0aFPwxVYKkPN3MeV0N0Z8byukP60yaFlmID0g8K9N/tbRc 0JJIKCvDhq3YF8qipJPwdvY1KEyq93Od/9q9Xx5bps5vW6N7jNWt+6jVTS5uvPnjH9/K whqnTvgs1XtKebgaLDvBt4bKolumysLUba5DC2ljvpY6v7I3Kbcu6pgPtCDznNaFeoGP yxhwz51r78bBXl2awDsUqlH3cMaHUvTrGETpnFuFalaZ415DqDsalAck7XbZSXcN6ONa eWsg== X-Gm-Message-State: ALoCoQnXYDrx+6b1lMBT2PHp7XoFvePtn+AFrwSIRlgs4OhJl2rTxn4diqmT1Qw1493GhdVhBllE MIME-Version: 1.0 X-Received: by 10.52.14.7 with SMTP id l7mr19345779vdc.82.1435667432639; Tue, 30 Jun 2015 05:30:32 -0700 (PDT) Received: by 10.52.76.6 with HTTP; Tue, 30 Jun 2015 05:30:32 -0700 (PDT) In-Reply-To: <20150629230458.GX30545@hezmatt.org> References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> <20150628220648.GI13302@hezmatt.org> <20150629230458.GX30545@hezmatt.org> Date: Tue, 30 Jun 2015 13:30:32 +0100 Message-ID: From: Ben Laurie To: Matt Palmer Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Verifying inclusion proof 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, 30 Jun 2015 12:30:34 -0000 On 30 June 2015 at 00:04, Matt Palmer wrote: > On Mon, Jun 29, 2015 at 12:29:47PM +0100, Ben Laurie wrote: >> On 28 June 2015 at 23:06, Matt Palmer wrote: >> > On Sun, Jun 28, 2015 at 04:26:51PM +0100, Ben Laurie wrote: >> >> On 28 June 2015 at 16:05, Stephen Kent wrote: >> >> > IETF standards need to be unambiguous. Code is very helpful, but it is not a >> >> > substitute >> >> > for a rigorous description of how to resolve the issue that Onderj raised. >> >> >> >> Whilst I am not necessarily opposed to that, there has to be a point >> >> at which you stop explaining what can be worked out given existing >> >> information. The RFC does state how the hash is calculated, from which >> >> it is clear what the placement of each node is in the hash >> >> calculation. >> > >> > s/it is clear/it is possible to determine/ >> > >> > I would be in favour of more clarity around exactly how the inclusion proof >> > is represented; I recall having significant trouble comprehending how >> > inclusion proofs "worked", and ended up examining existing operational logs >> > and using trial and error to determine how the inclusion proof was >> > presented. >> >> Feel free to open a ticket. However, the mechanism for verifying >> inclusion in a Merkle tree is widely available in standard texts, for >> example 3.3 in http://www.emsec.rub.de/media/crypto/attachments/files/2011/04/becker_1.pdf. > > That document doesn't appear to be referenced in 6962bis, nor would it, I > assume, answer the question "how is the inclusion proof represented in the > response to get-sth-consistency". Fair enough. Do you have proposed text? From nobody Tue Jun 30 10:05:48 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 27A5A1B3222 for ; Tue, 30 Jun 2015 10:05:40 -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 mj-0W6066DzD for ; Tue, 30 Jun 2015 10:05:37 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (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 E47381B3218 for ; Tue, 30 Jun 2015 10:05:26 -0700 (PDT) Received: by ykdv136 with SMTP id v136so14905054ykd.0 for ; Tue, 30 Jun 2015 10:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=I+ZEShX9BUlxak1om49cEmPRhbqvIxrE5zuWuML7cfk=; b=TMemiAS9tRksC5xNVWdMjCq4P82dodaUtezWRWXsP/1GnBfiT7zmixSileyvmffk6L ki0kzEY63H+X2Lj9VTyCgPZUrpoIM9wfEkl+mA2EoRlEzPm2Mzc19HHQnUJZiSDoahGT KvhCUcSPpaXis22uEMaI59O9wa+AlUG2blt6DDzAI2DpO5I2sx0mEwtaSgoZpB0fw9tj WnCXn6KR4FsvidX3BwTDEVHGuthWchf9kB2Qi3iLgCzBYd0RSmav15Z/aN8HmAIFfX0z GnZ+nIQoTKj/n24+IiG8dohZwIEGSy2ZhfNNp80ZMDzGiq2An7KG4IyjTGpoKV1NlaRJ eBRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=I+ZEShX9BUlxak1om49cEmPRhbqvIxrE5zuWuML7cfk=; b=TSJhmrunUfQx5naMb0JB5yxr8twnBwe5oOi3kKa510RVvYMPR5D/8UABI/6rx1L4XN i5mF3LCfK+iIiZfpSGD3axv+WGA8PH3x4J2JYMs7yZBW8Ufp2S42qRUM+/SLIR+0z9FA HDuDx9AGl2R/713a9O5tPeWuudl/zJpzQZoYO/xXvGIoK9J6SoiE6eFILZWoDzhj2IoE SpdFD5RvZ9TC5hcrIXOTP1nVtxyqtdbgjhhJ8UqCMzG9gc57ySntoTDSCPO4mZYFfEtm JDiLrKvv4o4GkaMkAvID+prSoFfg4PrxF/nElItSUq+HEZpNCZi9RrNSFjKYUGjJ36Hc J6QQ== X-Gm-Message-State: ALoCoQlDYF1UdBbW8R626foHWt4hMWrJgNnjLpzYiA1Q3+QRfK8gfgXifPAA14sWXKEbYIdVWAOi X-Received: by 10.170.208.81 with SMTP id z78mr26479751yke.106.1435683926018; Tue, 30 Jun 2015 10:05:26 -0700 (PDT) MIME-Version: 1.0 References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> <20150628220648.GI13302@hezmatt.org> <20150629230458.GX30545@hezmatt.org> In-Reply-To: From: Adam Eijdenberg Date: Tue, 30 Jun 2015 17:05:14 +0000 Message-ID: To: Ben Laurie , Matt Palmer Content-Type: multipart/alternative; boundary=001a114503e26bdd910519bf36a0 Archived-At: Cc: "trans@ietf.org" Subject: Re: [Trans] Verifying inclusion proof 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, 30 Jun 2015 17:05:40 -0000 --001a114503e26bdd910519bf36a0 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 30, 2015 at 5:30 AM Ben Laurie wrote: > On 30 June 2015 at 00:04, Matt Palmer wrote: > > On Mon, Jun 29, 2015 at 12:29:47PM +0100, Ben Laurie wrote: > >> On 28 June 2015 at 23:06, Matt Palmer wrote: > >> > On Sun, Jun 28, 2015 at 04:26:51PM +0100, Ben Laurie wrote: > >> >> On 28 June 2015 at 16:05, Stephen Kent wrote: > >> >> > IETF standards need to be unambiguous. Code is very helpful, but > it is not a > >> >> > substitute > >> >> > for a rigorous description of how to resolve the issue that Onderj > raised. > >> >> > >> >> Whilst I am not necessarily opposed to that, there has to be a point > >> >> at which you stop explaining what can be worked out given existing > >> >> information. The RFC does state how the hash is calculated, from > which > >> >> it is clear what the placement of each node is in the hash > >> >> calculation. > >> > > >> > s/it is clear/it is possible to determine/ > >> > > >> > I would be in favour of more clarity around exactly how the inclusion > proof > >> > is represented; I recall having significant trouble comprehending how > >> > inclusion proofs "worked", and ended up examining existing > operational logs > >> > and using trial and error to determine how the inclusion proof was > >> > presented. > >> > >> Feel free to open a ticket. However, the mechanism for verifying > >> inclusion in a Merkle tree is widely available in standard texts, for > >> example 3.3 in > http://www.emsec.rub.de/media/crypto/attachments/files/2011/04/becker_1.pdf > . > > > > That document doesn't appear to be referenced in 6962bis, nor would it, I > > assume, answer the question "how is the inclusion proof represented in > the > > response to get-sth-consistency". > > Fair enough. Do you have proposed text? > Would the following text be helpful for /get-proof-by-hash? (I realize the immediate question refers to get-sth-consistency, I'd be happy to tackle that next) To verify the Merkle Tree root hash for the tree_size provided as input, a client can use the hash provided as input combined with applying the audit_path and leaf_index returned as output in the following manner (note, all values must be base64 decoded first): 1. Set the intermediate result "r" to hash. 2. For each "i" from 0 up to LENGTH(audit_path) - 1: If the least significant bit of (leaf_index >> i) is set, then: a. Set r to HASH(0x01 || audit_path[i] || r) otherwise: b. Set r to HASH(0x01 || r || audit_path[i]) 3. Return r If "r" is equal to the root hash previously returned by /get-sth for the same tree_size that was passed as input, then the log has successfully proven the inclusion of the certificate that the Merkle tree leaf hash was constructed from. > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --001a114503e26bdd910519bf36a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 30, 2015 at 5:30 AM Ben Laurie <benl@google.com> wrot= e:
On 30= June 2015 at 00:04, Matt Palmer <mpalmer@hezmatt.org> wrote:
> On Mon, Jun 29, 2015 at 12:29:47PM +0100, Ben Laurie wrote:
>> On 28 June 2015 at 23:06, Matt Palmer <mpalmer@hezmatt.org> wrote:
>> > On Sun, Jun 28, 2015 at 04:26:51PM +0100, Ben Laurie wrote: >> >> On 28 June 2015 at 16:05, Stephen Kent <kent@bbn.com> wrote:
>> >> > IETF standards need to be unambiguous. Code is very = helpful, but it is not a
>> >> > substitute
>> >> > for a rigorous description of how to resolve the iss= ue that Onderj raised.
>> >>
>> >> Whilst I am not necessarily opposed to that, there has to= be a point
>> >> at which you stop explaining what can be worked out given= existing
>> >> information. The RFC does state how the hash is calculate= d, from which
>> >> it is clear what the placement of each node is in the has= h
>> >> calculation.
>> >
>> > s/it is clear/it is possible to determine/
>> >
>> > I would be in favour of more clarity around exactly how the i= nclusion proof
>> > is represented; I recall having significant trouble comprehen= ding how
>> > inclusion proofs "worked", and ended up examining e= xisting operational logs
>> > and using trial and error to determine how the inclusion proo= f was
>> > presented.
>>
>> Feel free to open a ticket. However, the mechanism for verifying >> inclusion in a Merkle tree is widely available in standard texts, = for
>> example 3.3 in h= ttp://www.emsec.rub.de/media/crypto/attachments/files/2011/04/becker_1.pdf<= /a>.
>
> That document doesn't appear to be referenced in 6962bis, nor woul= d it, I
> assume, answer the question "how is the inclusion proof represent= ed in the
> response to get-sth-consistency".

Fair enough. Do you have proposed text?

Would the following text be helpful for /get-proof-by-hash? (I realize the= immediate question refers to get-sth-consistency, I'd be happy to tack= le that next)

To verify the Merkle Tree root hash f= or the tree_size provided as input, a client can use the hash provided as i= nput combined with applying the audit_path and leaf_index returned as outpu= t in the following manner (note, all values must be base64 decoded first):<= /div>

1. Set the intermediate result "r" to ha= sh.

2. For each "i" from 0 up to LENGTH(= audit_path) - 1:

=C2=A0 =C2=A0If the least signifi= cant bit of (leaf_index >> i) is set, then:
=C2=A0 =C2=A0
=C2=A0 =C2=A0a. Set r to HASH(0x01 || audit_path[i] || r)
=C2=A0 =C2=A0
=C2=A0 =C2=A0otherwise:
=C2=A0 =C2=A0
=C2=A0 =C2=A0b. Set r to HASH(0x01 || r || audit_path[i])
=C2=A0=C2=A0
3. Return r

If "r&qu= ot; is equal to the root hash previously returned by /get-sth for the same = tree_size that was passed as input, then the log has successfully proven th= e inclusion of the certificate that the Merkle tree leaf hash was construct= ed from.


=C2=A0

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--001a114503e26bdd910519bf36a0-- From nobody Tue Jun 30 13:38:29 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 F12C41B2EDA for ; Tue, 30 Jun 2015 13:38:27 -0700 (PDT) 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 pvZX5N_eEbiS for ; Tue, 30 Jun 2015 13:38:26 -0700 (PDT) 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 855EB1B2ED5 for ; Tue, 30 Jun 2015 13:38:26 -0700 (PDT) Received: from localhost ([::1]:43339 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA2IU-0007d9-0p; Tue, 30 Jun 2015 13:38:26 -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: rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 30 Jun 2015 20:38:26 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/80#comment:1 Message-ID: <071.9f7fa12ea254ca63795862eef5886c19@tools.ietf.org> References: <056.7955c32a9fd14002205eaf236136fda6@tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <056.7955c32a9fd14002205eaf236136fda6@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: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer key hash into the Precertificate 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: Tue, 30 Jun 2015 20:38:28 -0000 #80: Re-introduce the issuer key hash into the Precertificate Changes (by rob.stradling@comodo.com): * owner: draft-ietf-trans-rfc6962-bis@tools.ietf.org => rob.stradling@comodo.com * status: new => assigned * component: client-behavior => rfc6962-bis -- ------------------------------+--------------------------------------- Reporter: eranm@google.com | Owner: rob.stradling@comodo.com Type: defect | Status: assigned Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+--------------------------------------- Ticket URL: trans From nobody Tue Jun 30 13:41:48 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 AE5271B2ED8 for ; Tue, 30 Jun 2015 13:41:46 -0700 (PDT) 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 aIzKdKji4EA8 for ; Tue, 30 Jun 2015 13:41:45 -0700 (PDT) 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 A3FBF1B2ED5 for ; Tue, 30 Jun 2015 13:41:45 -0700 (PDT) Received: from localhost ([::1]:43563 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA2Lh-0008IC-Ci; Tue, 30 Jun 2015 13:41:45 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 20:41:45 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/70#comment:1 Message-ID: <067.361288600af44c71dde599edef29148b@tools.ietf.org> References: <052.ecfc9a319e455c61897ed3e82e509b78@tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <052.ecfc9a319e455c61897ed3e82e509b78@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630204145.A3FBF1B2ED5@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 13:41:45 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #70 (rfc6962-bis): STH spec needs to define top-level extension syntax 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: Tue, 30 Jun 2015 20:41:46 -0000 #70: STH spec needs to define top-level extension syntax Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 13:48:10 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 02B051B30BE for ; Tue, 30 Jun 2015 13:48:10 -0700 (PDT) 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=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 hP6qVZEC_Yp1 for ; Tue, 30 Jun 2015 13:48:09 -0700 (PDT) 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 01AA71B2F09 for ; Tue, 30 Jun 2015 13:48:09 -0700 (PDT) Received: from localhost ([::1]:43820 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA2Rs-0003y3-Pl; Tue, 30 Jun 2015 13:48:08 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 20:48:08 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/75#comment:1 Message-ID: <067.019f7c40f49249e728ed3e63379f97c3@tools.ietf.org> References: <052.8c83add4a6489debc30278738f81ab1a@tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <052.8c83add4a6489debc30278738f81ab1a@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630204809.01AA71B2F09@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 13:48:09 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #75 (rfc6962-bis): run on sentence in section 3 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: Tue, 30 Jun 2015 20:48:10 -0000 #75: run on sentence in section 3 Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 13:53:24 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 192F31B3240 for ; Tue, 30 Jun 2015 13:53:22 -0700 (PDT) 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=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 SSLloLmvshVS for ; Tue, 30 Jun 2015 13:53:21 -0700 (PDT) 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 F16C71B323E for ; Tue, 30 Jun 2015 13:53:20 -0700 (PDT) Received: from localhost ([::1]:43995 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA2Wt-00029t-NO; Tue, 30 Jun 2015 13:53:19 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 20:53:19 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/74#comment:1 Message-ID: <067.93039ea41e106316e4801a4c1169d808@tools.ietf.org> References: <052.329e3339e14184dcd891ce5116d624c8@tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <052.329e3339e14184dcd891ce5116d624c8@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630205320.F16C71B323E@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 13:53:20 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #74 (rfc6962-bis): normative statement of TLS client behavior in Section 3 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: Tue, 30 Jun 2015 20:53:22 -0000 #74: normative statement of TLS client behavior in Section 3 Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis Comment: Changing component to rfc6962-bis, since this ticket requests text to be removed from that document. Clearly the client-behavior document should make this normative statement about client behavior, but presumably there should be another ticket to track that. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 14:35:31 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 888ED1A908D for ; Tue, 30 Jun 2015 14:35:30 -0700 (PDT) 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 4QVYGEzj8ABK for ; Tue, 30 Jun 2015 14:35:29 -0700 (PDT) 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 5C5D11A9077 for ; Tue, 30 Jun 2015 14:35:29 -0700 (PDT) Received: from localhost ([::1]:46119 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3Bg-0006HH-N2; Tue, 30 Jun 2015 14:35:28 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 21:35:28 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/65#comment:1 Message-ID: <067.6539a9a8c4a4574b56698d77478a9db6@tools.ietf.org> References: <052.7b8731a1601d369a3b2ae85631ff646b@tools.ietf.org> X-Trac-Ticket-ID: 65 In-Reply-To: <052.7b8731a1601d369a3b2ae85631ff646b@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630213529.5C5D11A9077@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 14:35:29 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #65 (rfc6962-bis): remove section 5.4 and reference to "Auditor" in section 3 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: Tue, 30 Jun 2015 21:35:30 -0000 #65: remove section 5.4 and reference to "Auditor" in section 3 Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis Comment: Changing component to rfc6962-bis, since this ticket requests text to be removed from that document. The client-behavior document will need to cover this topic, but presumably there should be another ticket to track that. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 14:48:08 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 C2D281B32E2 for ; Tue, 30 Jun 2015 14:48:06 -0700 (PDT) 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 BbZDE6iKHmO2 for ; Tue, 30 Jun 2015 14:48:05 -0700 (PDT) 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 7D36C1B32E1 for ; Tue, 30 Jun 2015 14:48:05 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:34375 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZA3Ns-0007h7-6O for trans@ietf.org; Tue, 30 Jun 2015 17:48:04 -0400 Message-ID: <55930E94.70702@bbn.com> Date: Tue, 30 Jun 2015 17:48:04 -0400 From: Stephen Kent 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: <052.ecfc9a319e455c61897ed3e82e509b78@tools.ietf.org> <067.361288600af44c71dde599edef29148b@tools.ietf.org> In-Reply-To: <067.361288600af44c71dde599edef29148b@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] [trans] #70 (rfc6962-bis): STH spec needs to define top-level extension syntax 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, 30 Jun 2015 21:48:06 -0000 Yes, please do. I want to publish the proposed mechanism for signalling cert type and syntax checking status and that will rely on an SCT extension. Thanks, Steve > #70: STH spec needs to define top-level extension syntax > > Changes (by rob.stradling@comodo.com): > > * component: client-behavior => rfc6962-bis > > From nobody Tue Jun 30 14:49:10 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 657461B32E5 for ; Tue, 30 Jun 2015 14:49:08 -0700 (PDT) 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=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 qTNIGAOHH8m8 for ; Tue, 30 Jun 2015 14:49:07 -0700 (PDT) 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 564341B32E0 for ; Tue, 30 Jun 2015 14:49:07 -0700 (PDT) Received: from localhost ([::1]:46581 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3Ot-000567-28; Tue, 30 Jun 2015 14:49:07 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 21:49:07 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/71#comment:1 Message-ID: <067.14883f2944d13138900d21c14e4990f6@tools.ietf.org> References: <052.d0cb10aa97a9af9a9b3ba76fe9a2b363@tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <052.d0cb10aa97a9af9a9b3ba76fe9a2b363@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630214907.564341B32E0@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 14:49:07 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #71 (rfc6962-bis): Section 1 does not define mis-issuance 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: Tue, 30 Jun 2015 21:49:08 -0000 #71: Section 1 does not define mis-issuance Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis Comment: client-behavior is clearly the wrong component for this ticket. It's true that 6962-bis does not define mis-issuance, but isn't the threat-analysis document the place for such a definition to appear? I'm changing the component to 6962-bis, but I'm inclined to resolve this ticket as a WONTFIX. Thoughts? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 14:51:34 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 8FA4E1A86FC for ; Tue, 30 Jun 2015 14:51:33 -0700 (PDT) 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=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 dZZjuCITvcjf for ; Tue, 30 Jun 2015 14:51:32 -0700 (PDT) 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 E80961B32E1 for ; Tue, 30 Jun 2015 14:51:31 -0700 (PDT) Received: from localhost ([::1]:46720 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3RD-0001WB-M6; Tue, 30 Jun 2015 14:51:31 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 21:51:31 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/73#comment:1 Message-ID: <067.b37c729c9b670adfc0efdf78055144d9@tools.ietf.org> References: <052.b3ecc6ca8b28cc47e13443079611ce86@tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <052.b3ecc6ca8b28cc47e13443079611ce86@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630215131.E80961B32E1@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 14:51:31 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log cert validation is ambiguous 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: Tue, 30 Jun 2015 21:51:33 -0000 #73: Section 3 text re log cert validation is ambiguous Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:13: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 5CE191B331B for ; Tue, 30 Jun 2015 15:13:04 -0700 (PDT) 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=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 gI5arWjVj9TT for ; Tue, 30 Jun 2015 15:13:03 -0700 (PDT) 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 0E05E1B331C for ; Tue, 30 Jun 2015 15:13:02 -0700 (PDT) Received: from localhost ([::1]:47647 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3m1-0006Mf-Ea; Tue, 30 Jun 2015 15:13:01 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:13:01 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/63#comment:1 Message-ID: <067.a06f3cbafa50b7722434f9a45dfdca0f@tools.ietf.org> References: <052.2f8736daa2848e7838235c5604063f8e@tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <052.2f8736daa2848e7838235c5604063f8e@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630221302.0E05E1B331C@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:13:02 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #63 (rfc6962-bis): remove all normative references to client behavior 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: Tue, 30 Jun 2015 22:13:04 -0000 #63: remove all normative references to client behavior Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis Comment: Clearly the client-behavior document should contain normative statements about client behavior! Changing component to rfc6962-bis. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: Active WG | Resolution: Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:14:32 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 3E9491B3326 for ; Tue, 30 Jun 2015 15:14:24 -0700 (PDT) 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=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 IJ5qabgGMVyq for ; Tue, 30 Jun 2015 15:14:18 -0700 (PDT) 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 02C031B3331 for ; Tue, 30 Jun 2015 15:14:10 -0700 (PDT) Received: from localhost ([::1]:47689 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3n7-0007OI-Lh; Tue, 30 Jun 2015 15:14:09 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:14:09 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/64#comment:1 Message-ID: <067.391fdefa35662594e1bb61eee2d6bb0a@tools.ietf.org> References: <052.21690f37c007741b7f717c5b07ad676c@tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <052.21690f37c007741b7f717c5b07ad676c@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630221410.02C031B3331@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:14:10 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #64 (rfc6962-bis): remove specification of signature and hash lags from section 2 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: Tue, 30 Jun 2015 22:14:24 -0000 #64: remove specification of signature and hash lags from section 2 Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:17:03 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 D49D71B3323 for ; Tue, 30 Jun 2015 15:17:01 -0700 (PDT) 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=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 bGj5f_5ALjaB for ; Tue, 30 Jun 2015 15:17:00 -0700 (PDT) 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 DCBF41B331D for ; Tue, 30 Jun 2015 15:17:00 -0700 (PDT) Received: from localhost ([::1]:47832 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3ps-0007W1-FA; Tue, 30 Jun 2015 15:17:00 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:17:00 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/76#comment:1 Message-ID: <067.158ec84e43687345ca4bca1b2988118c@tools.ietf.org> References: <052.0789019d9e32c9233f0440891ac5bb94@tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <052.0789019d9e32c9233f0440891ac5bb94@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630221700.DCBF41B331D@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:17:00 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #76 (rfc6962-bis): Normative client behavior specified in Section 3.4 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: Tue, 30 Jun 2015 22:17:02 -0000 #76: Normative client behavior specified in Section 3.4 Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:17:58 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 2D7AA1B332D for ; Tue, 30 Jun 2015 15:17:57 -0700 (PDT) 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=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 lx4sFN4gPjCE for ; Tue, 30 Jun 2015 15:17:56 -0700 (PDT) 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 2DA711B3329 for ; Tue, 30 Jun 2015 15:17:56 -0700 (PDT) Received: from localhost ([::1]:48381 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3ql-0003mk-UT; Tue, 30 Jun 2015 15:17:55 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:17:55 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/77#comment:1 Message-ID: <067.d112ce9f0012fc5749f50eb52d2298c1@tools.ietf.org> References: <052.9d9fc2bb25108f9681efa566967a94e3@tools.ietf.org> X-Trac-Ticket-ID: 77 In-Reply-To: <052.9d9fc2bb25108f9681efa566967a94e3@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630221756.2DA711B3329@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:17:56 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #77 (rfc6962-bis): normative client behavior specified in Section 5 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: Tue, 30 Jun 2015 22:17:57 -0000 #77: normative client behavior specified in Section 5 Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:18:45 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 D9DD01B3323 for ; Tue, 30 Jun 2015 15:18:44 -0700 (PDT) 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=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 byK9ssMkFrtu for ; Tue, 30 Jun 2015 15:18:44 -0700 (PDT) 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 8404C1B332B for ; Tue, 30 Jun 2015 15:18:42 -0700 (PDT) Received: from localhost ([::1]:48406 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3rW-0006ao-Ar; Tue, 30 Jun 2015 15:18:42 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:18:42 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/78#comment:1 Message-ID: <067.555129e93f6d06b9d69493af06c6f6d3@tools.ietf.org> References: <052.225d9e4c8d8c45e468832faf6102e815@tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <052.225d9e4c8d8c45e468832faf6102e815@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630221842.8404C1B332B@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:18:42 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #78 (rfc6962-bis): algorithm agility discussion is inadequate 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: Tue, 30 Jun 2015 22:18:45 -0000 #78: algorithm agility discussion is inadequate Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:21: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 5D3FB1B3337 for ; Tue, 30 Jun 2015 15:21:27 -0700 (PDT) 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=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 BGngKnkJ9pgo for ; Tue, 30 Jun 2015 15:21:26 -0700 (PDT) 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 933191B3332 for ; Tue, 30 Jun 2015 15:21:26 -0700 (PDT) Received: from localhost ([::1]:48832 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3u8-0002Td-TM; Tue, 30 Jun 2015 15:21:24 -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, pphaneuf@gmail.com, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:21:24 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/88#comment:5 Message-ID: <073.276556a3975bb8abf6342bf18dad7b43@tools.ietf.org> References: <058.a978a1b85df450a3b12c330a07fecb4e@tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <058.a978a1b85df450a3b12c330a07fecb4e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, pphaneuf@gmail.com, benl@google.com, melinda.shore@gmail.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: <20150630222126.933191B3332@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:21:26 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #88 (rfc6962-bis): get-entries: "end" should be greater-than-or-equal to "start" 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: Tue, 30 Jun 2015 22:21:27 -0000 #88: get-entries: "end" should be greater-than-or-equal to "start" Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:22:26 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 E8D9D1B333B for ; Tue, 30 Jun 2015 15:22:24 -0700 (PDT) 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=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 q50ArrneYB8E for ; Tue, 30 Jun 2015 15:22:20 -0700 (PDT) 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 90AAC1B3337 for ; Tue, 30 Jun 2015 15:22:20 -0700 (PDT) Received: from localhost ([::1]:48851 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3v2-0006Um-As; Tue, 30 Jun 2015 15:22:20 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:22:20 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/72#comment:1 Message-ID: <067.adde040a36ed17751eb41c69d6706f20@tools.ietf.org> References: <052.83a7720c272d768f705104c61dc38731@tools.ietf.org> X-Trac-Ticket-ID: 72 In-Reply-To: <052.83a7720c272d768f705104c61dc38731@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630222220.90AAC1B3337@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:22:20 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #72 (rfc6962-bis): Section 2.1.4 cites specific algorithms 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: Tue, 30 Jun 2015 22:22:25 -0000 #72: Section 2.1.4 cites specific algorithms Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:22:32 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 0D7D71B3335 for ; Tue, 30 Jun 2015 15:22:27 -0700 (PDT) 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=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 yDfbnC8g0yf0 for ; Tue, 30 Jun 2015 15:22:26 -0700 (PDT) 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 353881B333A for ; Tue, 30 Jun 2015 15:22:26 -0700 (PDT) Received: from localhost ([::1]:48857 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3v7-0006lF-5v; Tue, 30 Jun 2015 15:22:25 -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, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:22:25 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/89#comment:2 Message-ID: <073.09b04d109d5c50b9cc64332a9a6676a0@tools.ietf.org> References: <058.a3b286b289bea15e728f874a714d34be@tools.ietf.org> X-Trac-Ticket-ID: 89 In-Reply-To: <058.a3b286b289bea15e728f874a714d34be@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-trans-rfc6962-bis@tools.ietf.org, benl@google.com, melinda.shore@gmail.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: <20150630222226.353881B333A@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:22:26 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #89 (rfc6962-bis): get-entries: "end" greater than "tree_size" should be allowed 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: Tue, 30 Jun 2015 22:22:27 -0000 #89: get-entries: "end" greater than "tree_size" should be allowed Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:23:07 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 C6E7E1B3337 for ; Tue, 30 Jun 2015 15:23:06 -0700 (PDT) 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=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 NMntao20pQr8 for ; Tue, 30 Jun 2015 15:23:06 -0700 (PDT) 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 109B11B3335 for ; Tue, 30 Jun 2015 15:23:06 -0700 (PDT) Received: from localhost ([::1]:48876 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3vj-0000j1-Sk; Tue, 30 Jun 2015 15:23:03 -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, benl@google.com, melinda.shore@gmail.com X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:23:03 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/82#comment:8 Message-ID: <073.08fc25a0c9edfcd09443712de81a02b9@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, benl@google.com, melinda.shore@gmail.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: <20150630222306.109B11B3335@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:23:06 -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: Tue, 30 Jun 2015 22:23:06 -0000 #82: Add a way to get the SCTs for entries returned by get-entries Changes (by melinda.shore@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- pphaneuf@gmail.com | rfc6962-bis@tools.ietf.org Type: enhancement | Status: closed Priority: major | Milestone: review Component: rfc6962-bis | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:25:17 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 4EC551B333B for ; Tue, 30 Jun 2015 15:25:15 -0700 (PDT) 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=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 45tSh75GQcxa for ; Tue, 30 Jun 2015 15:25:14 -0700 (PDT) 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 17C831B2DCA for ; Tue, 30 Jun 2015 15:25:14 -0700 (PDT) Received: from localhost ([::1]:48937 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3xp-0001UZ-S7; Tue, 30 Jun 2015 15:25:13 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:25:13 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/72#comment:2 Message-ID: <067.0a654d2015a3d8bea22981c0374361e3@tools.ietf.org> References: <052.83a7720c272d768f705104c61dc38731@tools.ietf.org> X-Trac-Ticket-ID: 72 In-Reply-To: <052.83a7720c272d768f705104c61dc38731@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630222514.17C831B2DCA@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:25:14 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #72 (rfc6962-bis): Section 2.1.4 cites specific algorithms 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: Tue, 30 Jun 2015 22:25:15 -0000 #72: Section 2.1.4 cites specific algorithms Comment (by rob.stradling@comodo.com): Duplicate of ticket #64 ? -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:26:26 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 E90221B333F for ; Tue, 30 Jun 2015 15:26:24 -0700 (PDT) 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=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 yI1J7WmdtG7F for ; Tue, 30 Jun 2015 15:26:22 -0700 (PDT) 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 906311B333C for ; Tue, 30 Jun 2015 15:26:16 -0700 (PDT) Received: from localhost ([::1]:48987 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA3yq-0005fo-BB; Tue, 30 Jun 2015 15:26:16 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:26:16 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/69#comment:1 Message-ID: <067.9adbbfdae2f04618840580f4e302c7c2@tools.ietf.org> References: <052.7e80f7bf1c6616fe0bce0b76bfc16561@tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <052.7e80f7bf1c6616fe0bce0b76bfc16561@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630222616.906311B333C@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:26:16 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #69 (rfc6962-bis): old data name (sha256_root_hash) in 3.6 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: Tue, 30 Jun 2015 22:26:25 -0000 #69: old data name (sha256_root_hash) in 3.6 Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:27:44 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 0E26C1B333C for ; Tue, 30 Jun 2015 15:27:43 -0700 (PDT) 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=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 rMnXrclkx2YJ for ; Tue, 30 Jun 2015 15:27:42 -0700 (PDT) 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 1506B1B332E for ; Tue, 30 Jun 2015 15:27:42 -0700 (PDT) Received: from localhost ([::1]:49036 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA40D-0003CI-RF; Tue, 30 Jun 2015 15:27:41 -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 X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:27:41 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/68#comment:1 Message-ID: <067.fa5286f7e4bccc033759d27de69e1f35@tools.ietf.org> References: <052.b40b5491f0d964b6f2806f2262e10952@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <052.b40b5491f0d964b6f2806f2262e10952@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: draft-ietf-trans-rfc6962-bis@ietf.org Resent-Message-Id: <20150630222742.1506B1B332E@ietfa.amsl.com> Resent-Date: Tue, 30 Jun 2015 15:27:42 -0700 (PDT) Resent-From: trac+trans@tools.ietf.org Archived-At: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #68 (rfc6962-bis): specification of sha-256 for the SCT 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: Tue, 30 Jun 2015 22:27:43 -0000 #68: specification of sha-256 for the SCT Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans- kent@bbn.com | rfc6962-bis@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: trans From nobody Tue Jun 30 15:28:24 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 9BD051B333A for ; Tue, 30 Jun 2015 15:28:23 -0700 (PDT) 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 wIEJe0YPa-v0 for ; Tue, 30 Jun 2015 15:28:22 -0700 (PDT) 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 0BF9B1B3328 for ; Tue, 30 Jun 2015 15:28:22 -0700 (PDT) Received: from localhost ([::1]:49065 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZA40q-0005UC-Rz; Tue, 30 Jun 2015 15:28:20 -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: eranm@google.com, rob.stradling@comodo.com X-Trac-Project: trans Date: Tue, 30 Jun 2015 22:28:20 -0000 X-URL: http://tools.ietf.org/trans/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/trans/trac/ticket/91#comment:1 Message-ID: <071.51527327173c775d5f0199c830091392@tools.ietf.org> References: <056.1a3a0b4df721b59933a4c32a232c7f3e@tools.ietf.org> X-Trac-Ticket-ID: 91 In-Reply-To: <056.1a3a0b4df721b59933a4c32a232c7f3e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: eranm@google.com, 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: Cc: trans@ietf.org Subject: Re: [Trans] [trans] #91 (rfc6962-bis): Clarify encoding of fields in the log client messages 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: Tue, 30 Jun 2015 22:28:23 -0000 #91: Clarify encoding of fields in the log client messages Changes (by rob.stradling@comodo.com): * component: client-behavior => rfc6962-bis -- ------------------------------+------------------------------- Reporter: eranm@google.com | Owner: eranm@google.com Type: defect | Status: new Priority: major | Milestone: Component: rfc6962-bis | Version: Severity: - | Resolution: Keywords: | ------------------------------+------------------------------- Ticket URL: trans From nobody Tue Jun 30 16: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 414F21B2B93 for ; Tue, 30 Jun 2015 16:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, 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 yCwUuTH6qmmy for ; Tue, 30 Jun 2015 16:49:35 -0700 (PDT) Received: from mail.hezmatt.org (erdhenne.tobermorytech.com [178.63.85.14]) by ietfa.amsl.com (Postfix) with ESMTP id 53FE51B2B78 for ; Tue, 30 Jun 2015 16:49:35 -0700 (PDT) Received: from mistress.home.hezmatt.org (eth1372.nsw.adsl.internode.on.net [150.101.203.91]) by mail.hezmatt.org (Postfix) with ESMTPSA id BE15568D41 for ; Tue, 30 Jun 2015 23:49:32 +0000 (UTC) Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 410E79FE66; Wed, 1 Jul 2015 09:49:28 +1000 (AEST) Date: Wed, 1 Jul 2015 09:49:28 +1000 From: Matt Palmer To: trans@ietf.org Message-ID: <20150630234928.GB30545@hezmatt.org> References: <558D61DE.8020402@nic.cz> <55900D1D.2030009@bbn.com> <20150628220648.GI13302@hezmatt.org> <20150629230458.GX30545@hezmatt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Trans] Verifying inclusion proof 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, 30 Jun 2015 23:49:37 -0000 On Tue, Jun 30, 2015 at 01:30:32PM +0100, Ben Laurie wrote: > On 30 June 2015 at 00:04, Matt Palmer wrote: > > On Mon, Jun 29, 2015 at 12:29:47PM +0100, Ben Laurie wrote: > >> On 28 June 2015 at 23:06, Matt Palmer wrote: > >> > On Sun, Jun 28, 2015 at 04:26:51PM +0100, Ben Laurie wrote: > >> >> On 28 June 2015 at 16:05, Stephen Kent wrote: > >> >> > IETF standards need to be unambiguous. Code is very helpful, but it is not a > >> >> > substitute > >> >> > for a rigorous description of how to resolve the issue that Onderj raised. > >> >> > >> >> Whilst I am not necessarily opposed to that, there has to be a point > >> >> at which you stop explaining what can be worked out given existing > >> >> information. The RFC does state how the hash is calculated, from which > >> >> it is clear what the placement of each node is in the hash > >> >> calculation. > >> > > >> > s/it is clear/it is possible to determine/ > >> > > >> > I would be in favour of more clarity around exactly how the inclusion proof > >> > is represented; I recall having significant trouble comprehending how > >> > inclusion proofs "worked", and ended up examining existing operational logs > >> > and using trial and error to determine how the inclusion proof was > >> > presented. > >> > >> Feel free to open a ticket. However, the mechanism for verifying > >> inclusion in a Merkle tree is widely available in standard texts, for > >> example 3.3 in http://www.emsec.rub.de/media/crypto/attachments/files/2011/04/becker_1.pdf. > > > > That document doesn't appear to be referenced in 6962bis, nor would it, I > > assume, answer the question "how is the inclusion proof represented in the > > response to get-sth-consistency". > > Fair enough. Do you have proposed text? Not at the present time. I'll add it to the todo list. - Matt