From nobody Tue Jul 1 06:00:56 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B375C1A01EF for ; Tue, 1 Jul 2014 06:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 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, J_CHICKENPOX_24=0.6, RP_MATCHES_RCVD=-0.651, 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 gY06evRFpacm for ; Tue, 1 Jul 2014 06:00:53 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8581A01EE for ; Tue, 1 Jul 2014 06:00:52 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c9so8416408qcz.28 for ; Tue, 01 Jul 2014 06:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LWUAsFIPcsrYtE82+R51kKzuKyAKNJFloPn8iltOCZQ=; b=CRVc6H4XSc2FBaCCrtoUyldZYDcIFmSrMmZfeefayee/lg+qxt6xGgBXtMDxBxqNzY Myvd6EcNzt2PLsatUxalPU/YU3SAnHCR4XVdbkxnXKb4DJ7NeiNM5DllPmLC3uE/JnsY hdlOltpVUPdz1f7qPzLtkG9yhrjHnBaVTuKWuQVtmA60RXV/6WCpK5upQ4eokS9QAUjy xwHxDItrW+iSqpGd3SZ0eoKjaMmrLurHe7W4f8y1mVf9ppTxKtBZny2OB0RgMvcwyy9p aOxzL2O0UaqZhHwTXAhyta+8uuS1sS44Lk62DF9HFioIDmJCDX3/tTbX3Xxvrgikeb/N l/cg== 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=LWUAsFIPcsrYtE82+R51kKzuKyAKNJFloPn8iltOCZQ=; b=BG4H7XRYPuxY2BAjZ/a9NGnaeGTDwRpzGc9+2RTdvXnoBEfZXUaksn4PPUqzfMYb3G LvYga28uMTqcZ/eHXK4S10IWZMOsi9b040Zch9roOCcLPhMNxQfemLZRlfXOJvfAkt8m phlnrArJvTXQpI3iTAa08YkL08FOVyh+BOrcoT9zlPwQEwDGo7eQRyriS+ZLt11ziah9 zlN+XOCSMzy4Vgmj4lzcbV/IbIjdWAgOdRtwETjJZhRIu1ufPFhKP6fPq1BfmE903fys mSFpOFXNbXmuM6OhorawnQ9E/KcvluNxD+/Ka0qU+SECyBw2kZ7V5y/kBy3FiXnRVNqo aKcA== X-Gm-Message-State: ALoCoQlDjK+sI7JDJcFWaajH4w2JFon/1Ecn0gOplK88LYUs7ey6c3E3Uec0yf5eWiuRQWq1+aSM MIME-Version: 1.0 X-Received: by 10.224.151.135 with SMTP id c7mr67707930qaw.95.1404219651999; Tue, 01 Jul 2014 06:00:51 -0700 (PDT) Received: by 10.229.100.72 with HTTP; Tue, 1 Jul 2014 06:00:51 -0700 (PDT) In-Reply-To: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com> References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com> Date: Tue, 1 Jul 2014 14:00:51 +0100 Message-ID: From: Ben Laurie To: Doug Beattie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/8BvVFC9-JJEpIhhHeZjl0k1Py2s Cc: "trans@ietf.org" Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT 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, 01 Jul 2014 13:00:54 -0000 Sorry for the delay. On 4 June 2014 20:52, Doug Beattie wrote: > > Those CAs that want to use a Precertificate Signing Certificate need to > follow a more complicated process for signing and I don't think it's well > documented or thought out. > > 1) What chain does the Precertificate Signing Certificate need to be issued > under? > > RFC 6962 states: "The Precertificate Signing Certificate MUST be *directly > certified* by the (root or intermediate) *CA certificate that will > ultimately sign the end-entity TBScertificate* yielding the end-entity > certificate (note that the log *may* relax standard validation rules to > allow this, so long as the issued certificate will be valid)" > > Point 1.1: Normally CAs have path length set to 0, so CAs are not able to > issue CA certificates under them, and this looks like a CA certificate > because CA:TRUE. As you point out, the log can relax validation rules, which deals with this problem (and we do, indeed, do that in our implementation). > Point 1.2: The also RFC States: "If the Precertificate is not signed with > the CA certificate that will issue the final certificate, then the > TBScertificate also has its issuer changed to that of the CA that will issue > the final certificate. " > > This makes the Precertificate Signing Certificate look even less like a CA > certificate. How do we convince a compliant/certified CA application to use > an Issuer DN other than the one that was used to sign the certificate? > Compliant CAs won't. I agree that this could be troublesome, though no-one has reported it as a blocker for them. If it turns out that no-one uses this option, perhaps we should drop it? > Point 1.3: The "may" above needs to be MUST, or validation will fail due to > the Issuer DN not matching what was posted. I guess so. File a bug? > Recommendation 1: At a minimum, remove CA:true from the Certificate Signing > Certificate profile. Ideally the profile should be updated to be more like > a Document/Code signing certificate than a CA certificate. I am not sure I understand how this helps? The path length constraint is a constraint on the length of the path, surely - regardless of what bits are set in certs in the path? > The signed TBScertificates posted to the log specifies the final > certificate's issuer DN, but the cert chain for the Precertificate Signing > Certificate is supplied so the CT log can validate that chain using relaxed > validation rules. What's the relationship between the hierarchy of the > Precertificate Signing Certificate and the final certificate? I struggle to > find any relationship except they both chain to publicly trusted roots. Is > that the intent of the RFC? Yes. The intent is for a CA to state its intention to issue a particular certificate. > Recommendation 2: The Precertificate Signing Certificate used by a CA may be > issued under any one of its roots and be used to sign all entries to be > posted to the log. Unless there is a requirement to validate that the > chains use the same root/hierarchy, there is no reason to require that. The requirement is that we can track down the issuer and that we can reconstruct the precert from the cert. Its not clear to me that this meets that requirement. > 2) Does the certificate serial number need to be the same in the > TBScertificate and the final certificate? Yes. > CAs that randomly generate serial numbers during issuance can't pre-generate > serial numbers to be used in the TBScertificate, then subsequently in the > final certificate. Is the serial number *that* important that it MUST be > included in the SCT? The issuer for the TBScertificate does not match the > value of the certificate that signed it, so what's the point of the serial > number? The CN, SAN, signing algorithms and keys are the most critical > components. Can we limit the SCT to these values? Serial numbers are used for revocation, so we need to know what they are. > Recommendation 3: Don't require that the TBScertificate and the final > certificate contain the same serial number. See above. > Summary: The CT Log validation rules need to be clearly defined so that the > CAs can post valid entries to the CT logs. > > * Currently I don't believe that the RFC is implementable by compliant CAs > that want to use Precertificate Signing Certificate. This may be so, but I don't think you've found a way to fix this, if it is so. > * Compliant CAs won't issue certificates with duplicate issuer DNs and > serial numbers, so that model is also broken - the Precertificate Signing > Certificate needs to be a non-CA certificate. Surely a different CA cert is equivalent to a different CA, and therefore the issuer DN/serial is _not_ a duplicate? > * CAs that randomly generate serial numbers during issuance can't > pre-generate serial numbers to be used in the TBScertificate, then > subsequently in the final certificate, so serial numbers need to be removed > from the content hashed by the SCT. See above. From nobody Tue Jul 1 10:23:41 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695BD1B2895 for ; Tue, 1 Jul 2014 10:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 cpURC-ehkl4s for ; Tue, 1 Jul 2014 10:23:33 -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 38F091B289E for ; Tue, 1 Jul 2014 10:23:33 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54442) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X21mT-000Hqc-07 for trans@ietf.org; Tue, 01 Jul 2014 13:23:45 -0400 Message-ID: <53B2EE92.8020002@bbn.com> Date: Tue, 01 Jul 2014 13:23:30 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------060702090709080101000408" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/3xcvJCDF_LPQ2iZpnUeXpF1nf7I Subject: [Trans] comments on Sections 3.5 + 3.6 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, 01 Jul 2014 17:23:36 -0000 This is a multi-part message in MIME format. --------------060702090709080101000408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit *Section 3.5 * This section defines the hash algorithm for the Merkle Tree as SHA-256. Is there a plan for agility for this algorithm? If so, what is it? If not, why not? Also, this section contains the confusing phrasing re version number: "Future revisions of this protocol version may add new MerkleLeafType types." Presumably the intent is to say that future versions (not revisions of this version), may add new leaf types. *Section 3.6 * This section defines the Signed Tree head data structure. The data definitions don't make it clear that the version number is an integer (vs. the string "v1") not is the format of the timestamp obvious. The end of this subsection says "Each log MUST produce on demand a Signed Tree Head that is no older than the Maximum Merge Delay." This makes it sound as though a log operator has to generate an STH whenever one is requested by any client. The description in 4.3 suggests that a log operator generates STHs when it wants (within the MMD interval), and sends the most recent one in response to a request for an STH. I assumed that a log operator would generate an STH on a periodic basis, as described at the beginning of Section 3, and provide that STH to every client until a new STH is generated. Please clarify the wording here. Why isn't the MMD encoded in the STH, so that and Auditor can determine whether a log operator is adhering to its advertised MMD? Another option might be to adopt the CRL (v2) model, and have each STH include the time/date when the next STH will be published. Just a thought. --------------060702090709080101000408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Section 3.5

 

This section defines the hash algorithm for the Merkle Tree as SHA-256. Is there a plan for agility for this algorithm? If so, what is it? If not, why not? Also, this section contains the confusing phrasing re version number: “Future revisions of this protocol version may add new MerkleLeafType types.” Presumably the intent is to say that future versions (not revisions of this version), may add new leaf types.

 

 

Section 3.6

 

This section defines the Signed Tree head data structure. The data definitions don’t make it clear that the version number is an integer (vs. the string “v1”) not is the format of the timestamp obvious.

 

The end of this subsection says “Each log MUST produce on demand a Signed Tree Head that is no older than the Maximum Merge Delay.” This makes it sound as though a log operator has to generate an STH whenever one is requested by any client. The description in 4.3 suggests that a log operator generates STHs when it wants (within the MMD interval), and sends the most recent one in response to a request for an STH. I assumed that a log operator would generate an STH on a periodic basis, as described at the beginning of Section 3, and provide that STH to every client until a new STH is generated. Please clarify the wording here.

 

Why isn’t the MMD encoded in the STH, so that and Auditor can determine whether a log operator is adhering to its advertised MMD? Another option might be to adopt the CRL (v2) model, and have each STH include the time/date when the next STH will be published. Just a thought.

--------------060702090709080101000408-- From nobody Tue Jul 1 10:34:49 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2A21A03B0 for ; Tue, 1 Jul 2014 10:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 HvW0CBynttG4 for ; Tue, 1 Jul 2014 10:34:43 -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 B72C91A03A4 for ; Tue, 1 Jul 2014 10:34:43 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54443) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X21xH-000Hw5-If for trans@ietf.org; Tue, 01 Jul 2014 13:34:55 -0400 Message-ID: <53B2F131.6030606@bbn.com> Date: Tue, 01 Jul 2014 13:34:41 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: trans@ietf.org References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Jcrrmc6yWce8ouFT7SliY7Zgy1o Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT 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, 01 Jul 2014 17:34:45 -0000 Ben, > ... > As you point out, the log can relax validation rules, which deals with > this problem (and we do, indeed, do that in our implementation). My comments noted that relaxing rules in an unspecified fashion creates potential problems for those submitting pre-certs. The specific changes needed to enable acceptance oif pre-certs need to be spelled out. > ... >> CAs that randomly generate serial numbers during issuance can't pre-generate >> serial numbers to be used in the TBScertificate, then subsequently in the >> final certificate. Is the serial number *that* important that it MUST be >> included in the SCT? The issuer for the TBScertificate does not match the >> value of the certificate that signed it, so what's the point of the serial >> number? The CN, SAN, signing algorithms and keys are the most critical >> components. Can we limit the SCT to these values? > Serial numbers are used for revocation, so we need to know what they are. I understand the desire to have the serial number be submitted as part of the pre-cert, but the problem raised by Doug is a valid one that cannot be ignored. >> Recommendation 3: Don't require that the TBScertificate and the final >> certificate contain the same serial number. > See above. see my comment above as well :-). > >> Summary: The CT Log validation rules need to be clearly defined so that the >> CAs can post valid entries to the CT logs. >> >> * Currently I don't believe that the RFC is implementable by compliant CAs >> that want to use Precertificate Signing Certificate. > This may be so, but I don't think you've found a way to fix this, if it is so. The burden on fixing it is not on Doug; it is on the authors of the doc! > >> * CAs that randomly generate serial numbers during issuance can't >> pre-generate serial numbers to be used in the TBScertificate, then >> subsequently in the final certificate, so serial numbers need to be removed >> from the content hashed by the SCT. > See above. Ben, it's not reasonable to tell CAs that their extant serial number management mechanism has to change to accommodate the CT design. It is the responsibility of the CT designers to figure out how to accommodate valid CA operation models. The RFC that forms the basis of the WG effort was experimental; there is no presumption that a final, standards track doc will be the same in every detail. The pre-cert serial number problem may be one aspect of the design that needs to change. Steve From nobody Tue Jul 1 12:01:43 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AFF1B28A7 for ; Tue, 1 Jul 2014 12:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Gn0kkbAVb8df for ; Tue, 1 Jul 2014 12:01:41 -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 8FA7C1B28B1 for ; Tue, 1 Jul 2014 12:01:39 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54571) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X23JO-000M7y-Rd; Tue, 01 Jul 2014 15:01:51 -0400 Message-ID: <53B3058F.8040901@bbn.com> Date: Tue, 01 Jul 2014 15:01:35 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hill, Brad" , "trans@ietf.org" References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com> <53B2F131.6030606@bbn.com> <370C9BEB4DD6154FA963E2F79ADC6F2E5E9F3C84@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: <370C9BEB4DD6154FA963E2F79ADC6F2E5E9F3C84@DEN-EXDDA-S12.corp.ebay.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/eVHElRob-Ny8XZWyxUNJyVphgFk Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT 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, 01 Jul 2014 19:01:42 -0000 Brad, > All that is really needed is a well-defined and easily reversible transformation of the serial number that can be applied to verify the proof. > > As issuing non-randomized serial numbers is no longer an acceptable practice for CAs, it could be as simple as: > > certSerialNum = preCertSerialNum++; > I don't think I understand your suggested solution. I believe the fundamental problem is that CA software/hardware may 1 not allow a CA to assign or even predict the serial number that appears in a cert 2 prevent assignment of duplicate serial numbers by the same CA 3 provide no way to coordinate serial numbers between two distinct CA instances This suggests that the serial number assigned to a precert may not be algorithmically related to the serial number that is assigned to the real cert that will contain the SCT based on the precert. If #1 is true, then I don't think the alg you indicated in your equation can be employed. If #2 is true, the precert and cert serial numbers can't be the same unless different CAs are emplpoyed for the precet and cert issuance. If different CAs are employed because of #2, then #1 or #3 would preclude the alg you suggested. Steve From nobody Tue Jul 1 15:45:26 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7C41A0ABD for ; Tue, 1 Jul 2014 15:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.651 X-Spam-Level: X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] 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 lLHAJygPxv3v for ; Tue, 1 Jul 2014 15:45:22 -0700 (PDT) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D191A0040 for ; Tue, 1 Jul 2014 15:45:22 -0700 (PDT) X-AuditID: d80ac3f2-f79de6d000003fee-8d-53b33a01e9e1 Received: from ecl1mtahubpin01.ges.symantec.com (ecl1mtahubpin01.ges.symantec.com [10.48.69.201]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 77.41.16366.10A33B35; Tue, 1 Jul 2014 23:45:21 +0100 (BST) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1X26ng-0002dw-4M for trans@ietf.org; Tue, 01 Jul 2014 22:45:21 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Tue, 1 Jul 2014 15:45:14 -0700 From: Rick Andrews To: "trans@ietf.org" Date: Tue, 1 Jul 2014 15:45:12 -0700 Thread-Topic: Cross-certificates and log servers Thread-Index: Ac+VepBIbNsQ9PLWQ166apgWQu2f4A== Message-ID: <544B0DD62A64C1448B2DA253C011414607CCD4149A@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607CCD4149ATUS1XCHEVSPIN_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42LhMnA9qctotTnYYNlJdYu1jy+yODB6LFny kymAMYrLJiU1J7MstUjfLoEr48Dzo0wF8w0rtm3bwNzAuEGzi5GTQ0LAROLy7HksELaYxIV7 69m6GLk4hATeMUqs/z2LHcL5zyjRu+8SM4SzklHi7oyTrCAtbAJ6ElseX2EHsUUEVCU+329h ArFZBFQkbjxZywZiCwtoS6z9/B2omQOoxkDi0vdQiHI9iWf/T4CV8ApESSz78g9sJCPQFd9P rQEbwywgLnHryXwmiOsEJJbsOc8MYYtKvHwMUy8qcad9PSNEfb7Enr9zWSBmCkqcnPmEZQKj 8Cwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYpQpKS02LM4tyS8tKUit MDDSK67MTQTGTbJecn7uJkZg7NzgOvxpB+PMvY6HGAU4GJV4eCWNNwcLsSaWAVUeYpTgYFYS 4Y3nAQrxpiRWVqUW5ccXleakFh9ilOZgURLnDZ+wNlhIID2xJDU7NbUgtQgmy8TBKdXAmDH7 ThArk3ndsVezZ35JjQzv6uC/WLxMSU88/my16nnmxWciu8SdVkm/WnpSmEkiqcZTny+64feq 838Tfh5bdpBx1jqPMuspkhvY5oU/7rv66drtP8HKxf9Wvml2m79R7dWPR3mbflfGtXQsfr16 wl4hT43m93c/mTUf03bPDOOyjLqyWKKuTImlOCPRUIu5qDgRAN9Kba+ZAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/trans/WD6b2KL0wde464A9wsISYY4umvU Subject: [Trans] Cross-certificates and log servers 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, 01 Jul 2014 22:45:24 -0000 --_000_544B0DD62A64C1448B2DA253C011414607CCD4149ATUS1XCHEVSPIN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Symantec (and I suspect other CAs) would like more information about what r= oots will be configured into log servers. Root Certificates: The current spec includes a call to Retrieve Accepted Root Certificates. Sh= ould we infer from that that the list might change over time? We expect new= roots would be added, but would roots ever get removed? For example, brows= er vendors are in the process of removing 1024-bit roots from their trust s= tores, and in the next few years we expect that SHA-1 roots might be remove= d too. Would log server operators also phase out such roots? Once there are more than three log servers, we expect to decide up front wh= ich log servers we will contact for SCTs. We do not expect to dynamically q= uery each log server to confirm that it still trusts our root, just before = attempting to log a certificate. Is that a valid assumption? It would be preferable for the log server operator to publish a list of roo= ts and commit to supporting those roots until the CA informs the operator t= hat the root is no longer in active use, and all certificates chained to th= at root have expired. Cross-Certificates: We have been providing cross-certificates to customers to deploy so that th= eir certificate could chain up to a 1024-bit root (for use in older browser= s without our 2048-bit roots). If the cross-certificate is ignored, the end= -entity cert chains up to one of our 2048-bit roots. We expect to continue = using cross-certificates until we determine that their use is no longer req= uired. We'd like to be sure that the use of cross-certificates will not cau= se any problems for log servers. For example, take the case where we log a = certificate we're about to issue (or have issued) and we include the cross-= certificate in the chain sent to the log server. Then the customer (for wha= tever reason) decides to also send their certificate to the log server, but= without the cross-certificate. Will the log server see this as the same ce= rtificate, and return to the customer the same SCTs? Or will the certificat= e get logged a second time? If the latter, will that cause any problems? -Rick --_000_544B0DD62A64C1448B2DA253C011414607CCD4149ATUS1XCHEVSPIN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =
Symantec (and I suspect = other CAs) would like more information about what roots will be configured = into log servers.
 
Root Certificates:
The current spec include= s a call to Retrieve Accepted Root Certificates. Should we infer from that = that the list might change over time? We expect new roots would be added, b= ut would roots ever get removed? For example, browser vendors are in the process of removing 1024-bit roots from= their trust stores, and in the next few years we expect that SHA-1 roots m= ight be removed too. Would log server operators also phase out such roots?<= /font>
 
Once there are more than= three log servers, we expect to decide up front which log servers we will = contact for SCTs. We do not expect to dynamically query each log server to = confirm that it still trusts our root, just before attempting to log a certificate. Is that a valid assumption?
 
It would be preferable f= or the log server operator to publish a list of roots and commit to support= ing those roots until the CA informs the operator that the root is no longe= r in active use, and all certificates chained to that root have expired.
 
Cross-Certificates:
We have been providing c= ross-certificates to customers to deploy so that their certificate could ch= ain up to a 1024-bit root (for use in older browsers without our 2048-bit r= oots). If the cross-certificate is ignored, the end-entity cert chains up to one of our 2048-bit roots. We expect to co= ntinue using cross-certificates until we determine that their use is no lon= ger required. We’d like to be sure that the use of cross-certificates= will not cause any problems for log servers. For example, take the case where we log a certificate we’re about to = issue (or have issued) and we include the cross-certificate in the chain se= nt to the log server. Then the customer (for whatever reason) decides to al= so send their certificate to the log server, but without the cross-certificate. Will the log server see this as the same= certificate, and return to the customer the same SCTs? Or will the certifi= cate get logged a second time? If the latter, will that cause any problems?=
 
-Rick
 
 --_000_544B0DD62A64C1448B2DA253C011414607CCD4149ATUS1XCHEVSPIN_-- From nobody Wed Jul 2 03:33:23 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1386C1B28F4 for ; Wed, 2 Jul 2014 03:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, RP_MATCHES_RCVD=-0.651, 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 vfVXX-_0b39u for ; Wed, 2 Jul 2014 03:33:19 -0700 (PDT) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDA91B28F0 for ; Wed, 2 Jul 2014 03:33:19 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id eb12so11967222oac.13 for ; Wed, 02 Jul 2014 03:33:18 -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=ZX1dezI195iawH1XTAcI4fHP8eGrg2UeaOImX4DHpo4=; b=DNKaJInlDdXuLQB7bLgsMGbI9LGWknqs4V3igva5eDPuxz0ne7TEVxJmOgovFnZXN2 Ppmt5VtieC5yESLK4WqOhVplfQ4sL9uW31r2M2nlN30RCCfEqJLuNgLwQ9pQaNAm24Px /7dwwStHWqI4x8HeCvyJiigTm/PgeOgeWya17PsuFVhxn3GxM6GtTDzMiM94jAwgYWrK sYHGmZCJwsFfodmTcWGDO9ZVgSluirLwqbfBmwi71aCzsiBdqlX51JF2HuVB4+PvncIj 9QW5HSTv9qfWXyhEd/oILbRU/B170ZE01aCjmstnusrrvGBvs00d/Fz0kLTcAqmcWGVe /S6Q== 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=ZX1dezI195iawH1XTAcI4fHP8eGrg2UeaOImX4DHpo4=; b=aWkue1mPuOUNUFcv8PjGruMVSz6tlxqrHQRzaB6mlzaYab0E4C8s27lYPaW3SC2LqP QswwVYaxMovKagrkPKvCNIRwX8X7kHh260Gf2n4p+uSL4GvSyDh8s9tg9HJI+wCkRNhq Ijo2266zaT4jrM4v+oVjqQMYKbNsgg/Ldlyl5P1SKPc5orjc8oRGY1Z9VFcawO8Q4OAe cAODyAjuVYAV3mNINyyssiCcXdHBBQW/2JrugNx9Rmy+XIlP5wtwGo0J3R7g2iBCq6Oc sfRAW6Gn73AHv5BLGWkTewqAiMRimTriy6Hdy2CfxJolDVPGQFrRkAm++f2QvkZXxEb/ XxdA== X-Gm-Message-State: ALoCoQnby+t24NInAgLHAqECCoGONTYL0McYcyt+dCIwvWHivd9/w0+t+dAItPifOdk+umvGJWva MIME-Version: 1.0 X-Received: by 10.60.46.229 with SMTP id y5mr57506126oem.7.1404297198850; Wed, 02 Jul 2014 03:33:18 -0700 (PDT) Received: by 10.182.33.200 with HTTP; Wed, 2 Jul 2014 03:33:18 -0700 (PDT) In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CCD4149A@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C011414607CCD4149A@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Wed, 2 Jul 2014 11:33:18 +0100 Message-ID: From: Eran Messeri To: Rick Andrews Content-Type: multipart/alternative; boundary=089e0153745ab26aa804fd336b2c Archived-At: http://mailarchive.ietf.org/arch/msg/trans/3VQnCT7cNeSi6Y02aYJSmREi1vU Cc: "trans@ietf.org" Subject: Re: [Trans] Cross-certificates and log servers 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, 02 Jul 2014 10:33:22 -0000 --089e0153745ab26aa804fd336b2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 1, 2014 at 11:45 PM, Rick Andrews wrote: > Symantec (and I suspect other CAs) would like more information about > what roots will be configured into log servers. > > Root Certificates: > The current spec includes a call to Retrieve Accepted Root Certificates. > Should we infer from that that the list might change over time? We expect > new roots would be added, but would roots ever get removed? For example, > browser vendors are in the process of removing 1024-bit roots from their > trust stores, and in the next few years we expect that SHA-1 roots might = be > removed too. Would log server operators also phase out such roots? > The purpose behind requiring that submitted certificates chain to a set of accepted root certificates is to avoid the log being flooded with uninteresting certificates (e.g. self-signed certificates). To that purpose I do not think it matters if obsolete roots are removed because the log should not get submissions chaining to these roots. > > Once there are more than three log servers, we expect to decide up front > which log servers we will contact for SCTs. We do not expect to dynamical= ly > query each log server to confirm that it still trusts our root, just befo= re > attempting to log a certificate. Is that a valid assumption? > Yes - How a log operator changes the set of roots its log accepts is not specified in the RFC, but I expect log operators would communicate such changes beforehand. > > It would be preferable for the log server operator to publish a list of > roots and commit to supporting those roots until the CA informs the > operator that the root is no longer in active use, and all certificates > chained to that root have expired. > > > Cross-Certificates: > We have been providing cross-certificates to customers to deploy so that > their certificate could chain up to a 1024-bit root (for use in older > browsers without our 2048-bit roots). If the cross-certificate is ignored= , > the end-entity cert chains up to one of our 2048-bit roots. We expect to > continue using cross-certificates until we determine that their use is no > longer required. We=E2=80=99d like to be sure that the use of cross-certi= ficates > will not cause any problems for log servers. For example, take the case > where we log a certificate we=E2=80=99re about to issue (or have issued) = and we > include the cross-certificate in the chain sent to the log server. Then t= he > customer (for whatever reason) decides to also send their certificate to > the log server, but without the cross-certificate. Will the log server se= e > this as the same certificate, and return to the customer the same SCTs? O= r > will the certificate get logged a second time? If the latter, will that > cause any problems? > The SCT is over the certificate itself, not the entire chain, so that should not be a problem. As mentioned above, the log checks the chain just to prevent it being spammed. It shouldn't matter to the client if it gets the same SCT or not - as long as the log provides proofs for all SCTs it produces. The issue here is that to get a proof from the log the client has to provide the hash of the leaf in the tree, which is calculated over the certificate + timestamp from the SCT. If the log returns different SCTs from the same certificate it likely means it logged the certificate multiple times. Either way the client should get a valid inclusion proof. As a side note, it is beneficial if log operators keep obsolete roots in the set - that way it's easy to explain why a certificate was added to a log in the first place (since the chain that was in place when the certificate was added is never changed). > > -Rick > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > --089e0153745ab26aa804fd336b2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 1, 2014 at 11:45 PM, Rick Andrews <= ;Rick_Andrew= s@symantec.com> wrote:
Symantec (and I suspect other CAs) = would like more information about what roots will be configured into log se= rvers.
=C2=A0
Root Certificates:
The current spec includes a call to= Retrieve Accepted Root Certificates. Should we infer from that that the li= st might change over time? We expect new roots would be added, but would ro= ots ever get removed? For example, browser vendors are in the process of removing 1024-bit roots from= their trust stores, and in the next few years we expect that SHA-1 roots m= ight be removed too. Would log server operators also phase out such roots?<= /font>
The purpose behind requiring that submitted = certificates chain to a set of =C2=A0accepted root certificates is to avoid= the log being flooded with uninteresting certificates (e.g. self-signed ce= rtificates). To that purpose I do not think it matters if =C2=A0obsolete ro= ots are removed because the log should not get submissions chaining to thes= e roots.
=C2=A0
Once there are more than three log = servers, we expect to decide up front which log servers we will contact for= SCTs. We do not expect to dynamically query each log server to confirm tha= t it still trusts our root, just before attempting to log a certificate. Is that a valid assumption?
Yes - How a log operator changes t= he set of roots its log accepts is not specified in the RFC, but I expect l= og operators would communicate such changes beforehand.
=C2=A0
It would be preferable for the log = server operator to publish a list of roots and commit to supporting those r= oots until the CA informs the operator that the root is no longer in active= use, and all certificates chained to that root have expired.
=C2=A0
=C2=A0
Cross-Certificates:
We have been providing cross-certif= icates to customers to deploy so that their certificate could chain up to a= 1024-bit root (for use in older browsers without our 2048-bit roots). If t= he cross-certificate is ignored, the end-entity cert chains up to one of our 2048-bit roots. We expect to co= ntinue using cross-certificates until we determine that their use is no lon= ger required. We=E2=80=99d like to be sure that the use of cross-certificat= es will not cause any problems for log servers. For example, take the case where we log a certificate we=E2=80=99re about t= o issue (or have issued) and we include the cross-certificate in the chain = sent to the log server. Then the customer (for whatever reason) decides to = also send their certificate to the log server, but without the cross-certificate. Will the log server see this as the same= certificate, and return to the customer the same SCTs? Or will the certifi= cate get logged a second time? If the latter, will that cause any problems?=
The SCT is over the certificate itself, not = the entire chain, so that should not be a problem. As mentioned above, the = log checks the chain just to prevent it being spammed.=C2=A0
It s= houldn't matter to the client if it gets the same SCT or not - as long = as the log provides proofs for all SCTs it produces. The issue here is that= to get a proof from the log the client has to provide the hash of the leaf= in the tree, which is calculated over the certificate + timestamp from the= SCT. If the log returns different SCTs from the same certificate it likely= means it logged the certificate multiple times. Either way the client shou= ld get a valid inclusion proof.

As a side note, it is beneficial if log operators keep = obsolete roots in the set - that way it's easy to explain why a certifi= cate was added to a log in the first place (since the chain that was in pla= ce when the certificate was added is never changed).=C2=A0
=C2=A0
-Rick
=C2=A0

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


--089e0153745ab26aa804fd336b2c-- From nobody Wed Jul 2 04:08:41 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDB51B28FF for ; Wed, 2 Jul 2014 04:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, RP_MATCHES_RCVD=-0.651, 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 2jeQCq6ZLBmC for ; Wed, 2 Jul 2014 04:08:35 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08A91B28FC for ; Wed, 2 Jul 2014 04:08:34 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id va2so11903109obc.5 for ; Wed, 02 Jul 2014 04:08:34 -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=QWqGIEfBrpQBUfq4KAlLm7gA+8zbc5NnEmbXqrgGt5Q=; b=li7iekfH1+vC+ty5uvA5huadQ3RbDisctl0b1mZV2X1jZtauW3/wYSBTvHXwUSXjSm jbcjPKAKzy6NJr4UyP8SE1O4bddkqzwErVtAzk/f4n5lz/9Cvy/6k0+MWNXisatOHlem KjSsRIe/DYOOKbDFtWAtxBkapywzTaaSf8XK/xJjUWoBLafkZsfuBqDzFx969uSNJqqT 3/wTukyR/ncWgV+IrHgTV2+h46/Xf7Zvod7N65Y9F2YwtlDG/U8VxpTlpaAyI9aQRuQQ JPjvfVympnySo6gg3cVsb2fd5lEVpAprKz8P24PyReNj7J20Bw5rV3841wVKN8ms975b ak6w== 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=QWqGIEfBrpQBUfq4KAlLm7gA+8zbc5NnEmbXqrgGt5Q=; b=Aaesiwik2bE/iY7oRvOUNQsy33chVHM6NyeGHt1CzNDilt94kWcHGkBQmgA16+MlyM lPlP37AyuVzAqkqEMJjF3IUqfgU1Rdgro2g7vk4Ahyg3j0eXZUTytjLUWQ40fW6O3R1L olSyYhCJerL5pNv97EMondyAghPPtymQXeBP27vGoZAYUjhvsfLRmPonHcHAqSgvXgl+ pFLBDKMyeVWRKyAv70YXZMxjCRlWH0sQD3pm3fZQ8PTfsFE8AJQXKxjgYP0P8CWHkktP 2y+Mz2h/tm9odJK/eWsBdpMo+xwd2dORHFif/lt3DG3FBtIjnv1Y5fs9V7P3ZJKXGuuh O+Fw== X-Gm-Message-State: ALoCoQnO4zClqjTRSV1dRshDZsKhri/ZCVocq6F4YakA3hQHqbwTfc805++yVEXSyyzJ2VBl2jq6 MIME-Version: 1.0 X-Received: by 10.60.33.65 with SMTP id p1mr1543140oei.20.1404299314231; Wed, 02 Jul 2014 04:08:34 -0700 (PDT) Received: by 10.182.33.200 with HTTP; Wed, 2 Jul 2014 04:08:34 -0700 (PDT) In-Reply-To: References: <533986E8.6040201@bbn.com> <533A7923.9040302@mozilla.org> Date: Wed, 2 Jul 2014 12:08:34 +0100 Message-ID: From: Eran Messeri To: Ben Laurie Content-Type: multipart/alternative; boundary=089e01184610c893a904fd33e98c Archived-At: http://mailarchive.ietf.org/arch/msg/trans/7zNZxbXJYQB0XLqkIO19KOSUzfM Cc: "trans@ietf.org" , Gervase Markham , Stephen Kent Subject: Re: [Trans] RFC6962 BIS Log file encodings. 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, 02 Jul 2014 11:08:39 -0000 --089e01184610c893a904fd33e98c Content-Type: text/plain; charset=UTF-8 On Tue, Apr 1, 2014 at 10:33 AM, Ben Laurie wrote: > On 1 April 2014 09:30, Gervase Markham wrote: > > On 31/03/14 17:16, Stephen Kent wrote: > >> know how to process ASN.1), and since the consumers of the data are > >> browsers who already > >> process certs, it seems reasonable to stick with ASN.1. > > > > AIUI, when a browser receives a cert, it will need to reconstruct the > > pre-cert in order to check that the SCT (which is a signature over the > > pre-cert) is valid. If that is the case, is it not true that browsers > > will need to develop some way of _encoding_ ASN.1 which they did not > > need to have before? > > > > (I may well be wrong about this; please correct me if so.) > > No, you are right. > This is for a very specific case, and encoding ASN.1 For this specific purpose is much more manageable than a general-purpose ASN.1 encoder. For those concerned, the code (and tests) for Chrome can be found here: https://code.google.com/p/chromium/codesearch#chromium/src/net/cert/ct_serialization.cc&sq=package:chromium > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --089e01184610c893a904fd33e98c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Apr 1, 2014 at 10:33 AM, Ben Laurie <<= a href=3D"mailto:benl@google.com" target=3D"_blank">benl@google.com>= wrote:
On 1 April 2014 09:30, Gervase Markham <= ;gerv@mozilla.org> wrote:
> On 31/03/14 17:16, Stephen Kent wrote:
>> know how to process ASN.1), and since the consumers of the data ar= e
>> browsers who already
>> process certs, it seems reasonable to stick with ASN.1.
>
> AIUI, when a browser receives a cert, it will need to reconstruct the<= br> > pre-cert in order to check that the SCT (which is a signature over the=
> pre-cert) is valid. If that is the case, is it not true that browsers<= br> > will need to develop some way of _encoding_ ASN.1 which they did not > need to have before?
>
> (I may well be wrong about this; please correct me if so.)

No, you are right.
This is for a very specific c= ase, and encoding ASN.1 For this specific purpose is much more manageable t= han a general-purpose ASN.1 encoder. For those concerned, the code (and tes= ts) for Chrome can be found here:

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

--089e01184610c893a904fd33e98c-- From nobody Wed Jul 2 04:34:21 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DAE1B28F3 for ; Wed, 2 Jul 2014 04:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 fPNuXjLfa9ZR for ; Wed, 2 Jul 2014 04:34:09 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A581A0045 for ; Wed, 2 Jul 2014 04:34:09 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id x13so9474152qcv.5 for ; Wed, 02 Jul 2014 04:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=S+zRSIbXWnb8KoulobBmYkCJAgeUZVhMVaSbuEA1Ens=; b=eHNkeUgE36qFmWDA2Ky07bwZ4ouFFKb3sBHyGyQxmXVbsnRfay73emry8vynBcdG2/ bF6Hi2Av3X7KnaD0NIMpkvvFzVyW47sjFysqkqPd7m9xv79XsYE8ObFQVoRMSbO4IBOK jMVrC3pUqdlEDkfrz+7/Kt+liZTNmHVjbZXISLMrN1xIUYO9R8t+YCz5A+Ol7A53DJOs AG7TFzamChNvWepknoBppuU4gZWaz14rQBgboe+hyMAGSvAHVm/v5YIOQ+MMb+t2ZtgK oT5JFfy9mLLxfv7UJfgIGZmwXA7jL6pz7WWiGMJ6OTP4n1Qrs2GHlSE4m/ygPmVZ1xUe KFGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=S+zRSIbXWnb8KoulobBmYkCJAgeUZVhMVaSbuEA1Ens=; b=LIUoEv0cn3ZOunoDfqtPLCuOFR+HncQbfZFmflGj3OuQvF3y5CMYexhBNXkB1owPUC yiIkl2QemrqoBsPUfkfk2sX9a2dqOPBJcYxu3czM/3qzUvF1GF0qoC9+0SGXgLyHIJ03 YVOQDL0xmMkk6XdZ4StV/q+W/SyskrmuEGU72tddrNd9U34b0Iv5nnhKIiCH+YsNylVp wnlf1Xr/GXI/YNLL2fNOEcnDbhZ+GE4/U9rR/E0bxkXAIlgCtbG8ecpL/sIhz0M3OIYD tOa+huaDUzw9gNWCxfu0dD4cpzSkVWDNFzRoPU2BJZXBYvT4oJDK7GsO4e85d9SaxiAi jbAg== X-Gm-Message-State: ALoCoQlV5z2DvCmaum7MXzXRkz691C8YNcw6ffXF+4q1Gl21BM5lSaFAmfA2AMoNayr/cfn0fe2c MIME-Version: 1.0 X-Received: by 10.224.151.135 with SMTP id c7mr77858611qaw.95.1404300848710; Wed, 02 Jul 2014 04:34:08 -0700 (PDT) Received: by 10.229.100.72 with HTTP; Wed, 2 Jul 2014 04:34:08 -0700 (PDT) In-Reply-To: References: <544B0DD62A64C1448B2DA253C011414607CCD4149A@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Wed, 2 Jul 2014 12:34:08 +0100 Message-ID: From: Ben Laurie To: Eran Messeri , ct-policy@chromium.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RgduWJrVW694rjQ0WY00sRzygUQ Cc: "trans@ietf.org" , Rick Andrews Subject: Re: [Trans] Cross-certificates and log servers 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, 02 Jul 2014 11:34:15 -0000 I've added the ct-policy mailing list, which might be a better venue for this question, at least for Google's logs. To be clear, I don't think we can dictate what roots logs accept, though certainly the advice is "all roots accepted by common browsers" - which is a little vague, but hard to nail down further. This is certainly Google's current plan. On 2 July 2014 11:33, Eran Messeri wrote: > > > > On Tue, Jul 1, 2014 at 11:45 PM, Rick Andrews > wrote: >> >> Symantec (and I suspect other CAs) would like more information about wha= t >> roots will be configured into log servers. >> >> Root Certificates: >> The current spec includes a call to Retrieve Accepted Root Certificates. >> Should we infer from that that the list might change over time? We expec= t >> new roots would be added, but would roots ever get removed? For example, >> browser vendors are in the process of removing 1024-bit roots from their >> trust stores, and in the next few years we expect that SHA-1 roots might= be >> removed too. Would log server operators also phase out such roots? > > The purpose behind requiring that submitted certificates chain to a set o= f > accepted root certificates is to avoid the log being flooded with > uninteresting certificates (e.g. self-signed certificates). To that purpo= se > I do not think it matters if obsolete roots are removed because the log > should not get submissions chaining to these roots. Equally, it doesn't matter if they're still allowed - unless they suddenly become spammy. >> Once there are more than three log servers, we expect to decide up front >> which log servers we will contact for SCTs. We do not expect to dynamica= lly >> query each log server to confirm that it still trusts our root, just bef= ore >> attempting to log a certificate. Is that a valid assumption? > > Yes - How a log operator changes the set of roots its log accepts is not > specified in the RFC, but I expect log operators would communicate such > changes beforehand. Exactly so. >> It would be preferable for the log server operator to publish a list of >> roots and commit to supporting those roots until the CA informs the oper= ator >> that the root is no longer in active use, and all certificates chained t= o >> that root have expired. > > >> >> >> Cross-Certificates: >> We have been providing cross-certificates to customers to deploy so that >> their certificate could chain up to a 1024-bit root (for use in older >> browsers without our 2048-bit roots). If the cross-certificate is ignore= d, >> the end-entity cert chains up to one of our 2048-bit roots. We expect to >> continue using cross-certificates until we determine that their use is n= o >> longer required. We=E2=80=99d like to be sure that the use of cross-cert= ificates >> will not cause any problems for log servers. For example, take the case >> where we log a certificate we=E2=80=99re about to issue (or have issued)= and we >> include the cross-certificate in the chain sent to the log server. Then = the >> customer (for whatever reason) decides to also send their certificate to= the >> log server, but without the cross-certificate. Will the log server see t= his >> as the same certificate, and return to the customer the same SCTs? Or wi= ll >> the certificate get logged a second time? If the latter, will that cause= any >> problems? > > The SCT is over the certificate itself, not the entire chain, so that sho= uld > not be a problem. As mentioned above, the log checks the chain just to > prevent it being spammed. Not just for that reason: also so that there is a clear path for revocation, should the certificate be bad in some way. > It shouldn't matter to the client if it gets the same SCT or not - as lon= g > as the log provides proofs for all SCTs it produces. The issue here is th= at > to get a proof from the log the client has to provide the hash of the lea= f > in the tree, which is calculated over the certificate + timestamp from th= e > SCT. If the log returns different SCTs from the same certificate it likel= y > means it logged the certificate multiple times. Either way the client sho= uld > get a valid inclusion proof. In general, our log is unlikely to produce more than one SCT for the same certificate, but it can happen (that's a result of engineering tradeoffs for reliability vs. availability). > As a side note, it is beneficial if log operators keep obsolete roots in = the > set - that way it's easy to explain why a certificate was added to a log = in > the first place (since the chain that was in place when the certificate w= as > added is never changed). >> >> >> -Rick >> >> >> _______________________________________________ >> 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 Wed Jul 2 07:02:19 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E86E1A013B for ; Wed, 2 Jul 2014 07:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 JauIoEzUm2Xp for ; Wed, 2 Jul 2014 07:02:14 -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 B4EDC1A00E8 for ; Wed, 2 Jul 2014 07:02:12 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57996 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2L6x-0009qz-Ee for trans@ietf.org; Wed, 02 Jul 2014 10:02:11 -0400 Message-ID: <53B410E3.5070704@bbn.com> Date: Wed, 02 Jul 2014 10:02:11 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------060102060200040508020903" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Vpdiey7R58PG8Iw5R2FrDt-4rFQ Subject: [Trans] Comments on Section 4 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, 02 Jul 2014 14:02:17 -0000 This is a multi-part message in MIME format. --------------060102060200040508020903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit *Section 4* This section defines the messages sent between clients and logs, thus defining the interface to logs. There is an admonition to ignore fields that may appear in "... JSON objects and URL parameters..." that are not specified in this section. Ought the "should" be a "SHOULD" or a "MUST"? The texts says "The prefix can include a path as well as a server name and a port." Should the "can" become a "MAY"? Since human-readable error messages are to be returned, is the intent that people will need to deal with these errors? Shouldn't there be an enumerated list of errors for each operation, to enable client software to figure out what the log server didn't like about a request, without requiring human intervention? Creating a list of errors for each type of transaction would make the checks performed by a log server more obvious, a concern I note below. The introduction for this section should note the unusual convention adopted here, i.e., putting a version number into the URL for the POST, as a way of indicating what version of a data structure is being submitted/retrieved. This does mean that a log client has to track this information when maintaining a returned data structure, since it is not embedded in the structure per se. It would be useful to describe the rationale for this design choice, vs. the more conventional approach of embedding the version number inthe data structure itself. One could do both, to provide redundant means of determining when a server returns the one version of a data structure via a URL that indicated a request for a different one (or vice versa for a client that is confused). The subsections of 4 do not specify checks to be performed by the log server or the client with respect to message parameters. This seems to be an oversight. For example, in 4.1, I would expect the log to verify that the certificate chain terminates in one of the TAs it supports, and that the certificates do constitute a certificate chain. The text in 4.1 says what the input is expected to be, but does not indicate that the log server actually verifies this. Why is the log ID base64 encoded? In *Section 4.1*, it seems a bit odd to specify a base64 extension for which no further syntax is defined. Is it defined elsewhere in this document? Is it a good idea for a client to accept an SCT that it cannot parse? If the version of the SCT returned to a client is not one a client understands, the client has no way of knowing whether a TLS client can understand it. This postpones the time when the returned SCT might be treated as broken. This doesn't seem like a good idea. It also raises the question of how SCT version changes are expected to be coordinated among logs, log clients, TLS clients, Monitors, etc. This architectural issue should be addressed somewhere in this document. In *Section 4.3*, the encoding for the timestamp is not specified here. Why is the instance of a tree specified by the tree size? If a new STH is issued before any new entries are added, the tree size will be the same. Would it not be clearer to use a serial number or timestamp tree instances? In *Section 4.4*, there is a note that the two trees must (MUST?) be from v1 STHs. This raises the question of how the system deals with a request to acquire a consistency proof between two STHs that span a log version transition. Please address that issue. There should be a description of what a log server does to satisfy this request, and how it replies if one or both of the specified tree sizes do not correspond to the specified tree heads according to its records. (This raises the question of whether there might be a preferable way to refer to STHs, e.g., via a timestamp or serial number, as noted above.) In *Section 4.5*, there is another reference to a v1 STH. This raises the same sort of questions I noted in my comments on Section 4.4 above. The terms "leaf index" and "0-base index" are used, but they do not seem to have been defined previously. In *Section 4.6*, the term "0-based" index is used, as in Section 4.5. The v1 vs. later versions issue arises here, as in Sections 4.4 and 4.5.There does not seem to be enough detail in the description of the processing to be performed by the client. Perhaps an appendix is needed to provide the details. If a client requests more entries than a log operator is willing to return, should there be an explicit error indication, rather than just returning the server's max size? Should the limit on entries be part of the server information that is retrievable, like the list of supported TAs (see Section 4.7). *Section 4.8*Since the tree_size is required to refer to an existing STH, this is an example of where a specific error return could be defined, to signal that the supplied input parameter is in error. --------------060102060200040508020903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Section 4

 

This section defines the messages sent between clients and logs, thus defining the interface to logs.

 

There is an admonition to ignore fields that may appear in “… JSON objects and URL parameters…” that are not specified in this section. Ought the “should” be a “SHOULD” or a “MUST”?

 

The texts says “The <log server> prefix can include a path as well as a server name and a port.” Should the “can” become a “MAY”?

 

Since human-readable error messages are to be returned, is the intent that people will need to deal with these errors? Shouldn’t there be an enumerated list of errors for each operation, to enable client  software to figure out what the log server didn’t like about a request, without requiring human intervention? Creating a list of errors for each type of transaction would make the checks performed by a log server more obvious, a concern I note below.

 

The introduction for this section should note the unusual convention adopted here, i.e., putting a version number into the URL for the POST, as a way of indicating what version of a data structure is being submitted/retrieved. This does mean that a log client has to track this information when maintaining a returned data structure, since it is not embedded in the structure per se. It would be useful to describe the rationale for this design choice, vs. the more conventional approach of embedding the version number in  the data structure itself. One could do both, to provide redundant means of determining when a server returns the one version of a data structure via a URL that indicated a request for a different one (or vice versa for a client that is confused).

 

The subsections of 4 do not specify checks to be performed by the log server or the client with respect to message parameters. This seems to be an oversight. For example, in 4.1, I would expect the log to verify that the certificate chain terminates in one of the TAs it supports, and that the certificates do constitute a certificate chain. The text in 4.1 says what the input is expected to be, but does not indicate that the log server actually verifies this.

 

Why is the log ID base64 encoded?

 

In Section 4.1, it seems a bit odd to specify a base64 extension for which no further syntax is defined. Is it defined elsewhere in this document?

 

Is it a good idea for a client to accept an SCT that it cannot parse? If the version of the SCT returned to a client is not one a client understands, the client has no way of knowing whether a TLS client can understand it. This postpones the time when the returned SCT might be treated as broken. This doesn’t seem like a good idea. It also raises the question of how SCT version changes are expected to be coordinated among logs, log clients, TLS clients, Monitors, etc. This architectural issue should be addressed somewhere in this document.

 

In Section 4.3, the encoding for the timestamp is not specified here.

 

Why is the instance of a tree specified by the tree size? If a new STH is issued before any new entries are added, the tree size will be the same. Would it not be clearer to use a serial number or timestamp tree instances?

 

In Section 4.4, there is a note that the two trees must (MUST?) be from v1 STHs. This raises the question of how the system deals with a request to acquire a consistency proof between two STHs that span a log version transition. Please address that issue.

 

There should be a description of what a log server does to satisfy this request, and how it replies if one or both of the specified tree sizes do not correspond to the specified tree heads according to its records. (This raises the question of whether there might be a preferable way to refer to STHs, e.g., via a timestamp or serial number, as noted above.)

 

In Section 4.5, there is another reference to a v1 STH. This raises the same sort of questions I noted in my comments on Section 4.4 above. The terms “leaf index” and “0-base index” are used, but they do not seem to have been defined previously.

 

In Section 4.6, the term “0-based” index is used, as in Section 4.5. The v1 vs. later versions issue arises here, as in Sections 4.4 and 4.5.  There does not seem to be enough detail in the description of the processing to be performed by the client. Perhaps an appendix is needed to provide the details. If a client requests more entries than a log operator is willing to return, should there be an explicit error indication, rather than just returning the server’s max size? Should the limit on entries be part of the server information that is retrievable, like the list of supported TAs (see Section 4.7).

 

Section 4.8 Since the tree_size is required to refer to an existing STH, this is an example of where a specific error return could be defined, to signal that the supplied input parameter is in error.

 

 

--------------060102060200040508020903-- From nobody Wed Jul 2 14:19:26 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D124F1A00A6 for ; Tue, 1 Jul 2014 10:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.501 X-Spam-Level: X-Spam-Status: No, score=-22.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.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 MmOq7D6EMDi3 for ; Tue, 1 Jul 2014 10:40:17 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391BC1A03D2 for ; Tue, 1 Jul 2014 10:40:17 -0700 (PDT) DomainKey-Signature: s=paypalcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-Transfer-Encoding:MIME-Version: X-CFilter-Loop; b=Mo8nYFvvfh2vFiqkeqt1DNcQxXEgXudVA/n5OM4QPeweK1B3gQ7r1hGQ RHOmj9NmxHCEzffJsuPDezRnoZvpPhf92ipidPuEecJQ00q8EzGOohGv9 d/XdCdHdIEnouQTLKCGOA9GDOQ6M8nis595gn1SMn+avrAe99s5BLYQqV E=; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal.com; i=@paypal.com; q=dns/txt; s=paypalcorp; t=1404236417; x=1435772417; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oWBD4L8HBHkhNEcxK9QqZMAyM3OESpnogRyCBxwZuxs=; b=anjCRj5zgc1xMy5Q0IpvbX/S+HRtzFelBOAJSQ7Y389INHlBm/JhdWSc yePRk+zQ4UOdPSbtJ4JUAl23y6FbVityj7AKAGbXwifxHmRfecZvK1p7S UH7CIuUk/VKCvyffFqT9NcgHmA15ZULwAyu4cmeEBYmYZ6aMeD3n7shZB Q=; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="5.01,583,1400050800"; d="scan'208";a="55960387" Received: from den-vteml-004.corp.ebay.com (HELO DEN-EXMHT-003.corp.ebay.com) ([10.101.112.120]) by den-mipot-001.corp.ebay.com with ESMTP; 01 Jul 2014 10:40:16 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-003.corp.ebay.com ([fe80::55d3:9d86:3fc8:dbf4%14]) with mapi id 14.03.0174.001; Tue, 1 Jul 2014 11:40:16 -0600 From: "Hill, Brad" To: Stephen Kent , "trans@ietf.org" Thread-Topic: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT Thread-Index: Ac+ALQQtMitYwrQqR0u9E0AtBE3d5wVMcKGAAAmQQoAADIC7cA== Date: Tue, 1 Jul 2014 17:40:15 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E5E9F3C84@DEN-EXDDA-S12.corp.ebay.com> References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com> <53B2F131.6030606@bbn.com> In-Reply-To: <53B2F131.6030606@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.19.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/trans/qvUtQpqd-qEiaMuqppvvotZJc3Y X-Mailman-Approved-At: Wed, 02 Jul 2014 14:19:21 -0700 Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT 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, 01 Jul 2014 17:40:19 -0000 All that is really needed is a well-defined and easily reversible transform= ation of the serial number that can be applied to verify the proof. As issuing non-randomized serial numbers is no longer an acceptable practic= e for CAs, it could be as simple as: certSerialNum =3D preCertSerialNum++; -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Tuesday, July 01, 2014 10:35 AM To: trans@ietf.org Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBS= certificates for CT Ben, > ... > As you point out, the log can relax validation rules, which deals with=20 > this problem (and we do, indeed, do that in our implementation). My comments noted that relaxing rules in an unspecified fashion creates pot= ential problems for those submitting pre-certs. The specific changes needed= to enable acceptance oif pre-certs need to be spelled out. > ... >> CAs that randomly generate serial numbers during issuance can't=20 >> pre-generate serial numbers to be used in the TBScertificate, then=20 >> subsequently in the final certificate. Is the serial number *that*=20 >> important that it MUST be included in the SCT? The issuer for the=20 >> TBScertificate does not match the value of the certificate that=20 >> signed it, so what's the point of the serial number? The CN, SAN,=20 >> signing algorithms and keys are the most critical components. Can we li= mit the SCT to these values? > Serial numbers are used for revocation, so we need to know what they are. I understand the desire to have the serial number be submitted as part of t= he pre-cert, but the problem raised by Doug is a valid one that cannot be i= gnored. >> Recommendation 3: Don't require that the TBScertificate and the final=20 >> certificate contain the same serial number. > See above. see my comment above as well :-). > >> Summary: The CT Log validation rules need to be clearly defined so=20 >> that the CAs can post valid entries to the CT logs. >> >> * Currently I don't believe that the RFC is implementable by=20 >> compliant CAs that want to use Precertificate Signing Certificate. > This may be so, but I don't think you've found a way to fix this, if it i= s so. The burden on fixing it is not on Doug; it is on the authors of the doc! > >> * CAs that randomly generate serial numbers during issuance can't=20 >> pre-generate serial numbers to be used in the TBScertificate, then=20 >> subsequently in the final certificate, so serial numbers need to be=20 >> removed from the content hashed by the SCT. > See above. Ben, it's not reasonable to tell CAs that their extant serial number manage= ment mechanism has to change to accommodate the CT design. It is the respon= sibility of the CT designers to figure out how to accommodate valid CA oper= ation models. The RFC that forms the basis of the WG effort was experimental; there is no= presumption that a final, standards track doc will be the same in every de= tail. The pre-cert serial number problem may be one aspect of the design that nee= ds to change. Steve _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Thu Jul 3 09:01:23 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3400B1B2908 for ; Thu, 3 Jul 2014 09:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_FROM=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 97fbIpubHT-R for ; Thu, 3 Jul 2014 09:01:18 -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 1A5A41B2938 for ; Thu, 3 Jul 2014 09:01:16 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49216) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2jRv-000AkN-N0 for trans@ietf.org; Thu, 03 Jul 2014 12:01:27 -0400 Message-ID: <53B57E4A.9070906@bbn.com> Date: Thu, 03 Jul 2014 12:01:14 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------030400060402040502050403" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/dreHf3x4s2HtduMxvGLCiy7RK9I Subject: [Trans] Comments on Section 5 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, 03 Jul 2014 16:01:20 -0000 This is a multi-part message in MIME format. --------------030400060402040502050403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit *Section 5 * This section discusses the different types of clients in the CT ecosystem. Saying that this section describes "typical" clients is rather open-ended, illustrative vs. normative. I suggest this section say that it enumerates the current set of clients that CT was designed to support, and note that other types of clients may be defined in the future. The admonition that "All clients should gossip with each other, exchanging STHs at least;" is not suitable for a standard. First, since TLS Clients are an example of clients, this suggestion implies that every browser should "gossip" with every other browser. Do you really mean that? Also, since no protocol for "gossiping" is defined, this is not useful guidance. I suggest all references to "gossiping" be removed until the "separate document" mentioned here is written. *Section 5.1* The description of "Submitters" should list CAs and Web PKI certificate Subjects as the primary examples. *Section 5.2 * This section says that "TLS clients are not directly clients of the log ..." This seems to contradict the statement in 5.4 that says an Auditor might be part of a TLS client. Do you really want to exclude TLS clients? If so, then there needs to be an explanation of how TLS clients, who are the ultimate beneficiaries of CT, become aware of bad certificates and reject them in the future. Or, does CT assume that bad PR will always deter a CA fro m issuing a bad certificate? This section states "In addition to normal validation of the certificate and its chain, they should validate the SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key." Ought the "should" be "SHOULD"? More importantly, I don't recall seeing an algorithmic description of how a client matches a received end-entity certificate against an SCT(L). Given the variations allowed for SCT data (based on an end-entity certificate, end-entity pre-certificate, or name-constrained CA certificate) this really needs to be explained, in detail. You don't need to provide the algorithm details here; putting the details in a normative appendix might be fine. The text also says "Note that this document does not describe how clients obtain the logs' public keys." I think the document does need to posit how the public key for a log is obtained, in a secure fashion, and how key changes for logs are managed. *Section 5.3* The introduction for this subsection says that a monitor "watches for certificates of interest" but provides no details of how this is effected. Is each certificate of interest defined by a DNS name and associated CA, for example? Since this function is not described as a MAY, it merits as detailed a description as the correctness checking function for which the algorithm is provided. *Section 5.4 * This section defines Auditors as taking "...partial information about a log as input and verify[ing] that this information is consistent with other partial information they have." This description seems too vague to be in a standard. A higher level description of what an Auditor does is needed, plus a description of what inputs it operates on, and what algorithms it uses (at a minimum) to do its job. --------------030400060402040502050403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Section 5

 

This section discusses the different types of clients in the CT ecosystem. Saying that this section describes “typical” clients is rather open-ended, illustrative vs. normative. I suggest this section say that it enumerates the current set of clients that CT was designed to support, and note that other types of clients may be defined in the future.

 

The admonition that “All clients should gossip with each other, exchanging STHs at least;” is not suitable for a standard. First, since TLS Clients are an example of clients, this suggestion implies that every browser should “gossip” with every other browser. Do you really mean that? Also, since no protocol for “gossiping” is defined, this is not useful guidance. I suggest all references to “gossiping” be removed until the “separate document” mentioned here is written.

 

 

Section 5.1

 

The description of “Submitters” should list CAs and Web PKI certificate Subjects as the primary examples.

 

 

Section 5.2

 

This section says that “TLS clients are not directly clients of the log …” This seems to contradict the statement in 5.4 that says an Auditor might be part of a TLS client. Do you really want to exclude TLS clients? If so, then there needs to be an explanation of how TLS clients, who are the ultimate beneficiaries of CT, become aware of bad certificates and reject them in the future. Or, does CT assume that bad PR will always deter a CA fro m issuing a bad certificate?

 

This section states “In addition to normal validation of the certificate and its chain, they should validate the SCT by computing the signature input from the SCT data as well as the certificate and verifying the signature, using the corresponding log's public key." Ought the “should” be “SHOULD”? More importantly, I don’t recall seeing an algorithmic description of how a client matches a received end-entity certificate against an SCT(L). Given the variations allowed for SCT data (based on an end-entity certificate, end-entity pre-certificate, or name-constrained CA certificate) this really needs to be explained, in detail. You don’t need to provide the algorithm details here; putting the details in a normative appendix might be fine.

 

The text also says “Note that this document does not describe how clients obtain the logs' public keys." I think the document does need to posit how the public key for a log is obtained, in a secure fashion, and how key changes for logs are managed.

 

 

Section 5.3

 

The introduction for this subsection says that a monitor “watches for certificates of interest” but provides no details of how this is effected. Is each certificate of interest defined by a DNS name and associated CA, for example? Since this function is not described as a MAY, it merits as detailed a description as the correctness checking function for which the algorithm is provided.

 

 

Section 5.4

 

This section defines Auditors as taking “…partial information about a log as input and verify[ing] that this information is consistent with other partial information they have.” This description seems too vague to be in a standard. A higher level description of what an Auditor does is needed, plus a description of what inputs it operates on, and what algorithms it uses (at a minimum) to do its job. --------------030400060402040502050403-- From nobody Thu Jul 3 11:39:51 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA551B28F9 for ; Thu, 3 Jul 2014 11:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 pa5ykP0fACWn for ; Thu, 3 Jul 2014 11:39:43 -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 C18C91A03B1 for ; Thu, 3 Jul 2014 11:39:42 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49300) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X2lvG-000BrY-Jy for trans@ietf.org; Thu, 03 Jul 2014 14:39:54 -0400 Message-ID: <53B5A36D.3090400@bbn.com> Date: Thu, 03 Jul 2014 14:39:41 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: multipart/alternative; boundary="------------030603010209040601070904" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/3Owr3_78TPLVMReM1oiz7DKjyQs Subject: [Trans] comments on Sections 7 + 9 (the last set of comments before Toronto) 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, 03 Jul 2014 18:39:46 -0000 This is a multi-part message in MIME format. --------------030603010209040601070904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit *Section 7* The Security Considerations include some statements that worry me. It says "If a server presents a valid signed timestamp for a certificate, then the client knows that the certificate has been published in a log." This is not quite true, since the certificate may be published later, or never at all. Please try to be more precise here. It also says "...the client knows that the subject of the certificate has had some time to notice the misissue and take some action, such as asking a CA to revoke a misissued certificate."Since the client doesn't know, with certainty, that the Subject is monitoring for mis-issuance, the client can't know how long it may be before the mis-issuance may be remedied. The statement here needs to note that a client cannot assume how long it may be before mis-issuance problems are detected and remedied. The last sentence of the first paragraph of this section does a good job of noting these limitations, but its message is diluted by the preceding statements. The final paragraph is good, although "transparency" may be too much of a euphemism! The lack of a discussion of various scenarios with respect to how mis-issuance may occur (see my comments on the Introduction) makes it harder for a reader to understand the ways that CT is intended to address the problem of certificate mis-issuance. Itmight be appropriate to compare CT to key pinning (draft-ietf-websec-key-pinning-17.txt) , for example, since both mechanisms attempt to deal with some of the same attacks. *Section 7.1*provides a good explanation of how MMD fits into the CT scheme. But it begins with an absolute statement about TLS clients rejecting certificates w/o an SCT. Absent a discussion of how to address partial deployment, the first sentence does not seem reasonable. *Section 7.3*seems to offer a warning that some examples of redacted names could be dangerous, but it provides only a couple of examples. Without a more precise definition of what constitutes a dangerously "overly redacted" precertificate, the warning here is not adequate. The statement "TLS clients MAY reject a certificate whose corresponding precertificate would be overly redacted." seems impossible to implement, based on the level of specification presented here. (If a certificate is dangerously over-redacted, and we define what that means, maybe a SHOULD is more appropriate.) This subsection needs work, and may be indicative of a serious problem with respect to the security afforded by redacted precertificates. *Section 7.4*describes how two forms of log misbehavior can be detected. The first type of misbehavior is a violation of the MMD. This description is a bit worrisome as it specifies relying on a "trusted auditor" (a new term) if a client does not want to reveal what certificate is of interest. The alternative approach suggested (for a client that does not want to reveal what certificates are of interest) is to request proofs for a batch of certificates. A more algorithmic description of the suggested behavior should be provided, either here or in Section 5.4 (which probably needs to be re-written anyway), along with a definition for a "trusted auditor" (or just delete the term "trusted"). The second type of misbehavior, characterized as violating the append-only property, is detected by "global gossiping." This is not a reasonable explanation of a countermeasure, given the lack of any detailed description of how such gossiping is to take place. *Section 9*raises an important topic, i.e., key rollover. But saying that this topic needs to be addressed in the future is worrisome. The WG needs to decide if it's OK to postpone this critical aspect of the design to a future document. --------------030603010209040601070904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Section 7

 

The Security Considerations include some statements that worry me.  It says “If a server presents a valid signed timestamp for a certificate, then the client knows that the certificate has been published in a log.” This is not quite true, since the certificate may be published later, or never at all. Please try to be more precise here.

 

It also says “…the client knows that the subject of the certificate has had some time to notice the misissue and take some action, such as asking a CA to revoke a misissued certificate.”  Since the client doesn’t know, with certainty, that the Subject is monitoring for mis-issuance, the client can’t know how long it may be before the mis-issuance may be remedied. The statement here needs to note that a client cannot assume how long it may be before mis-issuance problems are detected and remedied. The last sentence of the first paragraph of this section does a good job of noting these limitations, but its message is diluted by the preceding statements.

 

The final paragraph is good, although “transparency” may be too much of a euphemism! The lack of a discussion of various scenarios with respect to how mis-issuance may occur (see my comments on the Introduction) makes it harder for a reader to understand the ways that CT is intended to address the problem of certificate mis-issuance. It  might be appropriate to compare CT to key pinning (draft-ietf-websec-key-pinning-17.txt) , for example, since both mechanisms attempt to deal with some of the same attacks.

 

Section 7.1 provides a good explanation of how MMD fits into the CT scheme. But it begins with an absolute statement about TLS clients rejecting certificates w/o an SCT. Absent a discussion of how to address partial deployment, the first sentence does not seem reasonable.

 

Section 7.3 seems to offer a warning that some examples of redacted names could be dangerous, but it provides only a couple of examples. Without a more precise definition of what constitutes a dangerously “overly redacted” precertificate, the warning here is not adequate. The statement “TLS clients MAY reject a certificate whose corresponding precertificate would be overly redacted.” seems impossible to implement, based on the level of specification presented here. (If a certificate is dangerously over-redacted, and we define what that means, maybe a SHOULD is more appropriate.) This subsection needs work, and may be indicative of a serious problem with respect to the security afforded by redacted precertificates.

 

Section 7.4 describes how two forms of log misbehavior can be detected. The first type of misbehavior is a violation of the MMD. This description is a bit worrisome as it specifies relying on a “trusted auditor” (a new term) if a client does not want to reveal what certificate is of interest. The alternative approach suggested (for a client that does not want to reveal what certificates are of interest) is to request proofs for a batch of certificates. A more algorithmic description of the suggested behavior should be provided, either here or in Section 5.4 (which probably needs to be re-written anyway), along with a definition for a “trusted auditor” (or just delete the term “trusted”). The second type of misbehavior, characterized as violating the append-only property, is detected by “global gossiping.” This is not a reasonable explanation of a countermeasure, given the lack of any detailed description of how such gossiping is to take place.

 

 

Section 9 raises an important topic, i.e., key rollover. But saying that this topic needs to be addressed in the future is worrisome. The WG needs to decide if it’s OK to postpone this critical aspect of the design to a future document.

--------------030603010209040601070904-- From nobody Thu Jul 3 12:47:55 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BEC1B2863 for ; Thu, 3 Jul 2014 12:47:54 -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 sPYbSVvbqGsi for ; Thu, 3 Jul 2014 12:47:53 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D6C1A03F9 for ; Thu, 3 Jul 2014 12:47:53 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so714514pdj.8 for ; Thu, 03 Jul 2014 12:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ge0koSIBTSnxiWpfRWMO1Pw1PkPMTysqJlTrXZU81bY=; b=cGqLCR4nqLqCVLxHE9ISgh/VVOy0oysa/BsmkrfW/s7FAYXRQUbnpGt5BRyr3WWTt1 4g9Po+AK0OtkHyVk2t03evZXbia294YazZgNmJMuNOnw0v/3MoYY+bGAomFDHYZAy8Nl 9Q167zZp4fwIGS9kgbEiOH5sL4PRCe9snzbYQXLAK9g+DfiEqK1GtfzMeUHOJTfyeAWs tH+21LPKkkihHFgh5rgPEWxkscNIhy6QsDh279QpDfebJuZbmGlqsMPgRaUbzL6lHOyU z/LFpxgZRUnlESGqIjtLy0bLM3hlJ5NoCLqK9mRphc4bsj84dJdxYs2JRD9KqntGA/DO BKhg== X-Received: by 10.66.174.199 with SMTP id bu7mr6797555pac.54.1404416872879; Thu, 03 Jul 2014 12:47:52 -0700 (PDT) Received: from spandex.local (63-140-93-117.dynamic.dsl.acsalaska.net. [63.140.93.117]) by mx.google.com with ESMTPSA id r1sm5881697pdm.16.2014.07.03.12.47.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 12:47:52 -0700 (PDT) Message-ID: <53B5B366.7010407@gmail.com> Date: Thu, 03 Jul 2014 11:47:50 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/quwQsyTmgFQWJ6ovTa0udTuU3to Subject: [Trans] Walking through the issue tracker: Ticket #4 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, 03 Jul 2014 19:47:54 -0000 Hey, all: We have 10 open issues in the trans issue tracker (http://trac.tools.ietf.org/wg/trans/trac/report/1) and I'd like to walk through them and see where things stand, what can be closed, etc. I'm going to take the liberty of assuming that the list is not comprehensive, as nothing's been added in the last two months and nothing from Steve's recent comments have been added. And that's okay - if the issue tracker isn't useful we don't need to use it. So, on to actual content: Ticket #4 asks whether signatures should be treated consistently across certificates and precertificates - i.e. should the TBS be signed in both cases, rather than the entire certificate as is currently specified for certificates. Melinda From nobody Thu Jul 3 12:57:32 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171981B287B for ; Thu, 3 Jul 2014 12:57:31 -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 BgJQx0KHnLD4 for ; Thu, 3 Jul 2014 12:57:29 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C5A1B284B for ; Thu, 3 Jul 2014 12:57:29 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id v10so736033pde.12 for ; Thu, 03 Jul 2014 12:57:29 -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 :content-type:content-transfer-encoding; bh=weS8hg8lkOyq+GvYKj9tHZsOru5dorxGF7AFQiiKKWk=; b=idEla4hnmIRhjnV594ni/OgnGZ6k8i62VvE5Nt76ovd+xePNmToDla6CMX0DnxTTSD dJyaQAy0rL3gDfmr0w0BcblPhsSqZ6nz3GI9X8UcyjPDLvdhi4PJEMmqPKerPSowjg9r 6wFgZRve808vtV9gLBXy0nt4y6laLSh0RnV6b7rmYLOrUwGq0yrvsT3A5BHoi8YWo6R1 4b3CEIRWLtx22FG+K1wxNYfDH0dAS8uD2l+e5oqvHReOI+7o+Wwe2lwB1n4fyx6f7PCz /pkHRLwlCbGoM9X0DuvTPwNPUw2i9ujyjQAMSLi5nPTRAELBO1SZM4CGLh9yyKqOWsRk /40Q== X-Received: by 10.70.125.226 with SMTP id mt2mr6027267pdb.93.1404417449538; Thu, 03 Jul 2014 12:57:29 -0700 (PDT) Received: from spandex.local (63-140-93-117.dynamic.dsl.acsalaska.net. [63.140.93.117]) by mx.google.com with ESMTPSA id r3sm5901394pdd.8.2014.07.03.12.57.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 12:57:28 -0700 (PDT) Message-ID: <53B5B5A7.106@gmail.com> Date: Thu, 03 Jul 2014 11:57:27 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/BTpgT5k0YpFxHvXMkLkXV4ic1l8 Subject: [Trans] Walking through the issue tracker: Ticket #8 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, 03 Jul 2014 19:57:31 -0000 This ticket asks about a mechanism for looking up Merkle proofs for a batch of certificates around the SCT timestamp. It looks as if there's an agreement to provide a DNS-based mechanism. It may be worth pointing out that it's occasionally difficult to get agreement to move data into the DNS and that we'll need to be prepared to answer questions about that in order to get the document through the process. So, if you're not familiar with RFC 6950 ("Architectural Considerations on Application Features in the DNS") it may be worth giving it a read. Should this ticket be closed? Melinda From nobody Thu Jul 3 16:19:04 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210901B2ABC for ; Thu, 3 Jul 2014 16:19: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 nHc1px2iga-k for ; Thu, 3 Jul 2014 16:19:00 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59E71B2ABA for ; Thu, 3 Jul 2014 16:19:00 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id fb1so959790pad.28 for ; Thu, 03 Jul 2014 16:19:00 -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 :content-type:content-transfer-encoding; bh=J+6gi5bfL8UtkAoT0Yg6TpR7FwVMyXyjjhT4zMyn0vE=; b=hHcLJAxXdi2MRV/EjJWW58scvVJtqggMNX02o4/rSpMMcZDHW+rPdZEM9aYxGSbTwL Ptun058HfkAPO17XPp1+ERKh1ZHvH21O3goHDFEPQNmSLRZ5M19sJ9I5le1uIO6w/Zqc 1x63BADpzJCny2P8xOuNT48plR59iuy9ZBisK8zxz/cfehPu1oq/otMxsfYupBhd35bt 2LXPnY4F6Yv9X9q8KfmbkitvW0VqhUbBp8AIVwpnx489V+CihAIRrcddKxyu4xF118N1 sjob9xHZbmvSt4+GTn2ByADFkej/8YMQWdyKK4rRVKuv3py6ofBCMgfA93LwcutiazsO qN2Q== X-Received: by 10.68.241.68 with SMTP id wg4mr159977pbc.66.1404429540424; Thu, 03 Jul 2014 16:19:00 -0700 (PDT) Received: from spandex.local (63-140-93-117.dynamic.dsl.acsalaska.net. [63.140.93.117]) by mx.google.com with ESMTPSA id jt7sm42159663pbc.46.2014.07.03.16.18.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 16:18:59 -0700 (PDT) Message-ID: <53B5E4E1.3010700@gmail.com> Date: Thu, 03 Jul 2014 15:18:57 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mtKifZBrF3-y2mc-HBH1zCIZHlU Subject: [Trans] Toronto planning 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, 03 Jul 2014 23:19:02 -0000 We've got a 2.5-hour slot on Friday, and based on discussions with Paul and Ben, here's what we think is going to be on the agenda: 1) 6962bis status, updates, issues. This will include discussion of issues raised on the mailing list, issue tracker tickets against the document, and so on 2) Gossip protocols, or rather a gossip protocol proposal. I do not believe there is a write-up of this anywhere yet, so this should be seen as the start of that discussion 3) Other applications. We've had some discussion both here and offline of dnssec logging, and there's been some interest in logging signatures of executables/binaries 4) any other work that needs to be done. At the last meeting we had a brief discussion of whether or not a client behavior document should be separated out of the bis document; without a volunteer to do it the question is moot. What are we omitting or have we forgotten? We'll get a firmer agenda out towards the end of next week, based on this list and any additional feedback. Melinda From nobody Fri Jul 4 02:19:57 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C161A032E for ; Fri, 4 Jul 2014 02:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, RP_MATCHES_RCVD=-0.651, 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 uiCPl2ULMEkj for ; Fri, 4 Jul 2014 02:19:54 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80271A0316 for ; Fri, 4 Jul 2014 02:19:53 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wp18so1591586obc.28 for ; Fri, 04 Jul 2014 02:19:53 -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=gzGDq2l+gFCFxeZNEWDxgPKOWbJdzD5G9zNKqrPNRAI=; b=OWZtAJdt6RHSqWVn64IMsUx3OlkloPOtl+5vGTCNN2ukIsLYSvT1N8B0APX9PHQPO5 7cNrhapGXEMbkEeiTB3BnLwOW6b23GwrsmYE6PhB7lTmvcawaO50IUXRSl7wR6Cevuvk 3o7KmcjjcFAwXWIx0S+Tdia9rKYMIPEDKhghZI5LomiIPgPzMqtwtHd3643TQDDRGS8H b3I83S2/vqC9OPofBwzvxZF6zmmmluDv01Nsqb7izZW8vivlalkbFkPk2fqL1qJXMXbK dmEq7P1AhNpAQ6kFEC+LyKTR8FV4f6U1gEN81DPlNbP7YOya2c3+u2e6S9gq5U7hTr9G kcWA== 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=gzGDq2l+gFCFxeZNEWDxgPKOWbJdzD5G9zNKqrPNRAI=; b=R5qYNxq+uv0z2VVBhLA2PNBMeI2H+43K3VgadBErKldPuqjZj/+jeK7a+D6r9E4L97 33FehieE0u6p09FBes6NBpSmp91kDfTN8WzLFQyCA/QC227wkebO71KTREKiknR+M0iz FvnJTZOc6VG3GeFZKa0+Mhn6oq0FNvGtYfXThHBLZNv01USIrwrRd1UVZ17cyZq7xerO ARir8nAj5cEVtarvP8CDHSm7rcxylXxlkhf8Q8nuh4nWzGHUqg10XNHXBPSsy10ttLPS 66Qq8p3koJeVDEc93tTNNW+Skanlhk9sRR/t2qRm5Kfg6FPyRmCkv9vLAjnEDY5xrSyB RMGA== X-Gm-Message-State: ALoCoQkxQ4ORp8Q0sUqDHUrmGnemV97Jb8dKC7361AdND+AVw3VZg7CYWa2v4K+WMms+MSeXrI/s MIME-Version: 1.0 X-Received: by 10.60.46.229 with SMTP id y5mr11234413oem.7.1404465593340; Fri, 04 Jul 2014 02:19:53 -0700 (PDT) Received: by 10.182.33.200 with HTTP; Fri, 4 Jul 2014 02:19:53 -0700 (PDT) In-Reply-To: <53B5E4E1.3010700@gmail.com> References: <53B5E4E1.3010700@gmail.com> Date: Fri, 4 Jul 2014 10:19:53 +0100 Message-ID: From: Eran Messeri To: Melinda Shore Content-Type: multipart/alternative; boundary=089e0153745aca734004fd5aa03d Archived-At: http://mailarchive.ietf.org/arch/msg/trans/rEFeTauNhLkoWeahTDqQx2nvyGY Cc: "trans@ietf.org" Subject: Re: [Trans] Toronto planning 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, 04 Jul 2014 09:19:55 -0000 --089e0153745aca734004fd5aa03d Content-Type: text/plain; charset=UTF-8 In addition, I propose a brief explanation on the following topics: * The way to avoid logging private subdomains (now-closed Trac ticket #1 ). That's one of the major changes since the last meeting (IIRC) so we should make sure it answers the needs of CAs while not introducing new security concerns (on top of what was already discussed). * Proof fetching via DNS queries: Ben recently implemented this mechanism for privacy-preserving inclusion proof lookups. In addition to description of the mechanism, it's worth discussing whether this mechanism should be mandatory for every log. On Fri, Jul 4, 2014 at 12:18 AM, Melinda Shore wrote: > We've got a 2.5-hour slot on Friday, and based on discussions with Paul > and Ben, here's what we think is going to be on the agenda: > > 1) 6962bis status, updates, issues. This will include discussion > of issues raised on the mailing list, issue tracker tickets against > the document, and so on > > 2) Gossip protocols, or rather a gossip protocol proposal. I do not > believe there is a write-up of this anywhere yet, so this should be > seen as the start of that discussion > > 3) Other applications. We've had some discussion both here and offline > of dnssec logging, and there's been some interest in logging > signatures of executables/binaries > > 4) any other work that needs to be done. At the last meeting we had > a brief discussion of whether or not a client behavior document > should be separated out of the bis document; without a volunteer to > do it the question is moot. > > What are we omitting or have we forgotten? We'll get a firmer agenda > out towards the end of next week, based on this list and any additional > feedback. > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --089e0153745aca734004fd5aa03d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri,= Jul 4, 2014 at 12:18 AM, Melinda Shore <melinda.shore@gmail.com= > wrote:
We've got a 2.5-hour slot on Friday, and= based on discussions with Paul
and Ben, here's what we think is going to be on the agenda:

1) 6962bis status, updates, issues. =C2=A0This will include discussion
=C2=A0 =C2=A0of issues raised on the mailing list, issue tracker tickets ag= ainst
=C2=A0 =C2=A0the document, and so on

2) Gossip protocols, or rather a gossip protocol proposal. =C2=A0I do not =C2=A0 =C2=A0believe there is a write-up of this anywhere yet, so this shou= ld be
=C2=A0 =C2=A0seen as the start of that discussion

3) Other applications. =C2=A0We've had some discussion both here and of= fline
=C2=A0 =C2=A0of dnssec logging, and there's been some interest in loggi= ng
=C2=A0 =C2=A0signatures of executables/binaries

4) any other work that needs to be done. =C2=A0At the last meeting we had =C2=A0 =C2=A0a brief discussion of whether or not a client behavior documen= t
=C2=A0 =C2=A0should be separated out of the bis document; without a volunte= er to
=C2=A0 =C2=A0do it the question is moot.

What are we omitting or have we forgotten? =C2=A0We'll get a firmer age= nda
out towards the end of next week, based on this list and any additional
feedback.

Melinda

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

--089e0153745aca734004fd5aa03d-- From nobody Fri Jul 4 02:26:26 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919E61A0AB8 for ; Fri, 4 Jul 2014 02:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 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, RP_MATCHES_RCVD=-0.651, 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 NK8Iw1Zi0Qb5 for ; Fri, 4 Jul 2014 02:26:23 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221DB1A03D7 for ; Fri, 4 Jul 2014 02:26:23 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id i7so1518800oag.8 for ; Fri, 04 Jul 2014 02:26:22 -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=oiFNJzwTLLkyFfobOC31RLKK/DI0Z8FjGnsKg3WEex0=; b=NL1nRbziVIFEvey9NmURL11rgQ1utNaIRpPtNaxVn7nnlDTmXTNTBj3VdIPb6rjGeN AjQQqNhrR0PROw99Q3nPCl29FOltzSest18JL3SZQbhY+ew7hjDzz0nlZXWdFdd8MdmN Yyr7T7Jdjc+yI4VrMRF5s7ETdqycWu2UyCWIwQGARFnFwxmby+CzWiuhXsLl2M/VRHdn 5FqCnGW8tbIgcKSD4hCCNE98o6IAnr/NW5ddHgt91sa/piuee7wneayRIk3Kf9LcduhS 2jD++OwiMA5a2OW6WWuiEu4xtLkN7XJVSt1yMxGfyafpsQlHKcit835Gphyw0FgNhKpF 0k/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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oiFNJzwTLLkyFfobOC31RLKK/DI0Z8FjGnsKg3WEex0=; b=fp4BPLPd0d3ute+RaWlrEfuKHEKeylpbqwPuPh1/3bhioruudSONhpKNvZq2AFiXKO 9AlV0b2O0Y2aMPqFSqv/oJVbFiJ4ugO5fPqSKFMb1nksCS5FRZyuSQDdlto89J7Q99Jj JAISWakdt1quYC2cXkOQxmjAoPKWuhWokMro/x+ZoQgNfb7Qa+oDsjpFDPy5wgsdEJHI X45aIhbY0Su4WrwoOK3HpIMoFwU0AcTbmfViZi1fYVgTrnYelR9RS4VTq96wschMOvZl cpVcEy9TNHj2Zw4VsIHQuK5+Fd6F1bn9TZxlIZBMv/x8f3MOd39nvkZe5PJsYZSzRFw+ Yh3w== X-Gm-Message-State: ALoCoQkuYWf1hfp1LO/HTCReHjBdizaJbCW4maEbsZn9EhhPgOW3k0SkKmqtF8DBywpAnZ9qaltk MIME-Version: 1.0 X-Received: by 10.60.33.65 with SMTP id p1mr11373418oei.20.1404465982523; Fri, 04 Jul 2014 02:26:22 -0700 (PDT) Received: by 10.182.33.200 with HTTP; Fri, 4 Jul 2014 02:26:22 -0700 (PDT) In-Reply-To: <53B5B5A7.106@gmail.com> References: <53B5B5A7.106@gmail.com> Date: Fri, 4 Jul 2014 10:26:22 +0100 Message-ID: From: Eran Messeri To: Melinda Shore Content-Type: multipart/alternative; boundary=089e01184610fceb3904fd5ab700 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/DA3O3KD6uVgDgsn9aE7MnDRq0Q4 Cc: "trans@ietf.org" Subject: Re: [Trans] Walking through the issue tracker: Ticket #8 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, 04 Jul 2014 09:26:24 -0000 --089e01184610fceb3904fd5ab700 Content-Type: text/plain; charset=UTF-8 IIUC the decision was to allow both - as you pointed out it may be difficult to move data into the DNS, so logs would offer an API to get a range of proofs as a fallback mechanism. So it seems like ticket 8 should remain open - I've assigned it to myself to add this method to the API. On Thu, Jul 3, 2014 at 8:57 PM, Melinda Shore wrote: > This ticket asks about a mechanism for looking up Merkle proofs for a > batch of certificates around the SCT timestamp. > > It looks as if there's an agreement to provide a DNS-based mechanism. > It may be worth pointing out that it's occasionally difficult to get > agreement to move data into the DNS and that we'll need to be prepared > to answer questions about that in order to get the document through the > process. So, if you're not familiar with RFC 6950 ("Architectural > Considerations on Application Features in the DNS") it may be worth > giving it a read. > > Should this ticket be closed? > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --089e01184610fceb3904fd5ab700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IIUC the decision was to allow both - as you pointed out i= t may be difficult to move data into the DNS, so logs would offer an API to= get a range of proofs as a fallback mechanism.
So it seems like ticket= 8 should remain open - I've assigned it to myself to add this method t= o the API.


On Thu,= Jul 3, 2014 at 8:57 PM, Melinda Shore <melinda.shore@gmail.com&= gt; wrote:
This ticket asks about a mechanism for looki= ng up Merkle proofs for a
batch of certificates around the SCT timestamp.

It looks as if there's an agreement to provide a DNS-based mechanism. It may be worth pointing out that it's occasionally difficult to get agreement to move data into the DNS and that we'll need to be prepared<= br> to answer questions about that in order to get the document through the
process. =C2=A0So, if you're not familiar with RFC 6950 ("Architec= tural
Considerations on Application Features in the DNS") it may be worth giving it a read.

Should this ticket be closed?

Melinda

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

--089e01184610fceb3904fd5ab700-- From nobody Fri Jul 4 04:23:00 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2675A1B2D39 for ; Fri, 4 Jul 2014 04:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 uTyjDWdtLkEm for ; Fri, 4 Jul 2014 04:22:49 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568641B2837 for ; Fri, 4 Jul 2014 04:22:49 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q107so1308481qgd.5 for ; Fri, 04 Jul 2014 04:22: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=284im1k5Fe5b6XmnAPvnvBkjXCbmv/azvNDatSZGeiQ=; b=TkaVU2HlGXiFDTYZqSJ4h5pMyTDKPg/4sDGwBd2IGOEds8HSdCpSjQoayn5hLjYoxn 5kNB0nr6CC+VZBeLolocxO4AFjS5ahhNS8iq2zdpLacIKDnrwSGJ8uojMLGT+3rW+7Bu jVeDyHgduSJAefMf/UU5ky/jZhZSMLoMpFiPfjLuRTGk4MsJFbn47Mvdtx/08ZilsBa5 F8hepRcRqxCzqt7gxzCPV+/YsARIR2eZTtnjl2/ndd8c5QbmKGWpqpcRp7Xzk9UIkmJX Q+DZ4LfkKgagm3toagn7CnH7qN1MANV2e4h9VTvSmJraJTBVrXji9VMc8V+1qq6xtE4k QmGA== 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=284im1k5Fe5b6XmnAPvnvBkjXCbmv/azvNDatSZGeiQ=; b=laH3fO/vvtpCQGa+3i1nh8dma7Ffi6M06tMoNB8gXotSxXHHuChzRriinzldarr/bY Hb9Qg4D7VE6KDvYfLy+3UVUde8gdmlFNZevkPYAKcGAxXk6E1Jme6wgQEdHxmpzQR+4f oNFhmfJjODaLU+sdbyCzIfI2JxO7krxAk0WUQLFDZ4NFtJHpvH79hCX/KCX56P+eRNBY kZ25k0jGGD2Ol5Zj4w354f95jBplbrgzejF0cRfutn2gbFW0E1pq/mXoZZ09FvhwaGj1 ddEGRViqbXQnYgwjY7Mqs7P3U+ZD2xQrEAIy+q0/Ao0EiDNxMCMl1P4wHEgBetXNNKnD hrlw== X-Gm-Message-State: ALoCoQmb4SodgwhIbQGjmZB4kFG0JH7B3tgf28DYUqhq8rQFmce/2l0SvNNRr3frkqGDf586bYCP MIME-Version: 1.0 X-Received: by 10.140.43.118 with SMTP id d109mr16597777qga.10.1404472968292; Fri, 04 Jul 2014 04:22:48 -0700 (PDT) Received: by 10.229.100.72 with HTTP; Fri, 4 Jul 2014 04:22:48 -0700 (PDT) In-Reply-To: References: <53B5B5A7.106@gmail.com> Date: Fri, 4 Jul 2014 12:22:48 +0100 Message-ID: From: Ben Laurie To: Eran Messeri Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Y1d4r3Tfs07daSO2XQ-pmbi5gC4 Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] Walking through the issue tracker: Ticket #8 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, 04 Jul 2014 11:22:53 -0000 On 4 July 2014 10:26, Eran Messeri wrote: > IIUC the decision was to allow both - as you pointed out it may be difficult > to move data into the DNS, so logs would offer an API to get a range of > proofs as a fallback mechanism. > So it seems like ticket 8 should remain open - I've assigned it to myself to > add this method to the API. Much as the DNS folk hate it, CT's needs for DNS work fine with TXT records (we have an implementation in the open source code, in fact). That said, I believe the application of DNS to this particular problem is within the guidelines in RFC 6950. > > > On Thu, Jul 3, 2014 at 8:57 PM, Melinda Shore > wrote: >> >> This ticket asks about a mechanism for looking up Merkle proofs for a >> batch of certificates around the SCT timestamp. >> >> It looks as if there's an agreement to provide a DNS-based mechanism. >> It may be worth pointing out that it's occasionally difficult to get >> agreement to move data into the DNS and that we'll need to be prepared >> to answer questions about that in order to get the document through the >> process. So, if you're not familiar with RFC 6950 ("Architectural >> Considerations on Application Features in the DNS") it may be worth >> giving it a read. >> >> Should this ticket be closed? >> >> Melinda >> >> _______________________________________________ >> 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 Jul 4 05:13:21 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA8B1B2D7E for ; Fri, 4 Jul 2014 05:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 4wwRP3haC25T for ; Fri, 4 Jul 2014 05:13:18 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47AEA1B2874 for ; Fri, 4 Jul 2014 05:13:18 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id w8so1249241qac.25 for ; Fri, 04 Jul 2014 05:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ai7TjyrS5p+I5l6DYSqw1J8ET2gsCZlgpXw/TXTxeWQ=; b=khq9KK5NjfKRFGh5/4CraIG3cCLG1LgXqE6NWEGMyp1g7NStDuwwi0jCiNVfITGiF9 AMfbH8j/AGgZIjn2X5nYLoZ1drVLaQ9pNOtR2gO9JuXnUaJ1gwAXo0hFTA985n0A0Agl qPZVkabG0g4gd/Oty5CYtz+UdsS5ZoaY3RvSthstfbqX1ANk2nz/DkUCV4mYxT1qL7n5 MY9dNGppPgZAVC5CtayDUU4whAlgKZCg2NBMk5jAi+3kYXkZw4KxcGfH4nH1MycJ4GGW mKkFppxOxE5uM2TNxM5inSwpKAFyxjj713IvWUxQ2ovK1nrFVtEgsrYppfR4FGIb4UUB F86w== 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=Ai7TjyrS5p+I5l6DYSqw1J8ET2gsCZlgpXw/TXTxeWQ=; b=ljbOYaFSmVa7TDClcsKzK3YqfhwaxHcgiY1YjnNXvnsgAd1PDm8KVvc1wzufMeSqT+ CIgXZJDmEr2lxsJ57eWMy9bda8CFspd3TxahK6wdWv1nrix3fMMKeeTXgQA0OtgHzn7C RlQsLFD7afqC4spHS4pM5V/2kaPJ6JsZxbIceT7YeZIPGRaFiUihPu21Ji46ch8xB4Gg s6YBICx3lwUf2/BYyX9DtDBn/ejv9RvuR6J9TiuLYVWJYUoKlTw02ciFfkkNRNI1lNzp EyKZivhsFXXozU3goN5CeFgu3s3rRyeg9AjsAm2TIlIT1CBvLXeaKqZDJ2puadOvfi4E f5YA== X-Gm-Message-State: ALoCoQnqEbhDxyZFMG0aQBLLoRLhhvuBju2o9tUolTYnwHwcRZH7LMmWZRnoKuR2zfm/ee2iTrWK MIME-Version: 1.0 X-Received: by 10.140.32.166 with SMTP id h35mr16660019qgh.114.1404475997338; Fri, 04 Jul 2014 05:13:17 -0700 (PDT) Received: by 10.229.100.72 with HTTP; Fri, 4 Jul 2014 05:13:17 -0700 (PDT) In-Reply-To: <53B5B366.7010407@gmail.com> References: <53B5B366.7010407@gmail.com> Date: Fri, 4 Jul 2014 13:13:17 +0100 Message-ID: From: Ben Laurie To: Melinda Shore Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/MKIUmS2jyqelVWApwBeCPm3mQzA Cc: "trans@ietf.org" Subject: Re: [Trans] Walking through the issue tracker: Ticket #4 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, 04 Jul 2014 12:13:20 -0000 On 3 July 2014 20:47, Melinda Shore wrote: > Hey, all: > > We have 10 open issues in the trans issue tracker > (http://trac.tools.ietf.org/wg/trans/trac/report/1) > and I'd like to walk through them and see where things > stand, what can be closed, etc. I'm going to take the > liberty of assuming that the list is not comprehensive, as > nothing's been added in the last two months and nothing > from Steve's recent comments have been added. And that's > okay - if the issue tracker isn't useful we don't need to > use it. > > So, on to actual content: Ticket #4 asks whether signatures > should be treated consistently across certificates and > precertificates - i.e. should the TBS be signed in both > cases, rather than the entire certificate as is currently > specified for certificates. Given that there's a certain amount of angst about precertificates and PKI rules, it could be that we really want to sign some other structure altogether, at least for precertificates. From nobody Fri Jul 4 05:24:39 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC60D1B28B5 for ; Fri, 4 Jul 2014 05:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 5mIivIuP3TtU for ; Fri, 4 Jul 2014 05:24:35 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8C01B28A5 for ; Fri, 4 Jul 2014 05:24:35 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id q108so1388450qgd.7 for ; Fri, 04 Jul 2014 05:24:34 -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=pr9TpDeIIkHh8MJ2kHctu247jrMXBcX+dv0/mPOI5V0=; b=nWb5OfMjKOXwB/zOmujn+rNRi4w+UuLs8A9qNI9tAQMuVOVTqxIUm8iRemHOC40JxZ lEo06ltIDAn3agnbp6z2FwEEwdCZNRkaTmvJZo8lMZW1DnvjXKGWU0c9NPyLx0KuWbB4 /+BmQ5bLAz6Y88qkpQ1F0xhrJ9jLycS1+zZPQ9Y8g5F018LNjMwZyfV0VORmKMouCqlZ RukTlro3pXZFazwMllFnAALcFEv5DxU7xtceiyV14/MkgNvTgrL/K0aiHTZvYlgHPu1L /UmJWoxVo7k3kGT3ZFhT7fB/EibVN9Hs2ArAU+0sAyiMKYWXqMMH+LBI0oPFiUPqT74P 6qhQ== 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=pr9TpDeIIkHh8MJ2kHctu247jrMXBcX+dv0/mPOI5V0=; b=jH/U1Vv7AM5vfEtbaA/xM3Zb5Jen7/7SpTBJ+Vo3pQAqoKIqNxN0ff/o9dYKOISWhf uehUm7OTmzxUscIIGSy27mS6Ey30KG6wFf7kECO40rdjcYYiD/kgpg+ILTyY0szN9o6O aXalfQagW8jIEO0R9HBdubphP/vL3il6lN6tnAsaq7EPiouK7BLTxFoH90JFCvxJl0nH FhQbjkq6AE9sPOg1gMchHUWWm7/iGqlyO3HhUpneWGbfgksvcCbC469Oq0uHB8sEt9mS ASSqlGVbwLy03vksDFeONt2qLzjkyywDaPtKIQwiGt2LvF8VXqRwyfFnV0BVTEKw2ENO UieA== X-Gm-Message-State: ALoCoQm21soNsFIiaDmWNynQqeOSN27uvmErOZPUv9U1cFyQy6wdAi8XRrb6BekfaIylWriTA5ZM MIME-Version: 1.0 X-Received: by 10.224.61.1 with SMTP id r1mr16922623qah.95.1404476674330; Fri, 04 Jul 2014 05:24:34 -0700 (PDT) Received: by 10.229.100.72 with HTTP; Fri, 4 Jul 2014 05:24:34 -0700 (PDT) In-Reply-To: <53B2F131.6030606@bbn.com> References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com> <53B2F131.6030606@bbn.com> Date: Fri, 4 Jul 2014 13:24:34 +0100 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/FGbGurSKksAzIA0GhjlalpRGpqI Cc: "trans@ietf.org" Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT 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, 04 Jul 2014 12:24:38 -0000 On 1 July 2014 18:34, Stephen Kent wrote: > Ben, >> >> ... >> >> As you point out, the log can relax validation rules, which deals with >> this problem (and we do, indeed, do that in our implementation). > > My comments noted that relaxing rules in an unspecified fashion creates > potential > problems for those submitting pre-certs. The specific changes needed to > enable > acceptance oif pre-certs need to be spelled out. Hmm. What we do is check the signatures validate all the way up the chain. That's it. I'm not sure we need anything tighter than that, so I guess we could specify that? >>> CAs that randomly generate serial numbers during issuance can't >>> pre-generate >>> serial numbers to be used in the TBScertificate, then subsequently in the >>> final certificate. Is the serial number *that* important that it MUST be >>> included in the SCT? The issuer for the TBScertificate does not match >>> the >>> value of the certificate that signed it, so what's the point of the >>> serial >>> number? The CN, SAN, signing algorithms and keys are the most critical >>> components. Can we limit the SCT to these values? >> >> Serial numbers are used for revocation, so we need to know what they are. > > I understand the desire to have the serial number be submitted as part > of the pre-cert, but the problem raised by Doug is a valid one that > cannot be ignored. My response is that, yes, the serial number is *that* important that is MUST be included in the SCT. >>> Recommendation 3: Don't require that the TBScertificate and the final >>> certificate contain the same serial number. >> >> See above. > > see my comment above as well :-). > >> >>> Summary: The CT Log validation rules need to be clearly defined so that >>> the >>> CAs can post valid entries to the CT logs. >>> >>> * Currently I don't believe that the RFC is implementable by compliant >>> CAs >>> that want to use Precertificate Signing Certificate. >> >> This may be so, but I don't think you've found a way to fix this, if it is >> so. > > The burden on fixing it is not on Doug; it is on the authors of the doc! Our position is that compliant CAs _can_ use Precertificate Signing Certificates - though possibly not with the exact toolchain they use to issue certificates. If someone wants to propose a mechanism that is compatible with whatever restrictions their s/w imposes, we'd be happy to consider it. >>> * CAs that randomly generate serial numbers during issuance can't >>> pre-generate serial numbers to be used in the TBScertificate, then >>> subsequently in the final certificate, so serial numbers need to be >>> removed >>> from the content hashed by the SCT. >> >> See above. > > Ben, it's not reasonable to tell CAs that their extant serial number > management > mechanism has to change to accommodate the CT design. It is the > responsibility > of the CT designers to figure out how to accommodate valid CA operation > models. I don't agree. If things have to change in order to achieve the agreed goals, then they have to change. It is not our obligation to preserve the world in its current perfection. > The RFC that forms the basis of the WG effort was experimental; there is no > presumption that a final, standards track doc will be the same in every > detail. > The pre-cert serial number problem may be one aspect of the design that > needs > to change. The serial number is required to fulfil the purpose of CT. If you want to not have serial numbers in the log, then we must also change the revocation mechanisms. > > Steve > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans From nobody Fri Jul 4 09:12:48 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65EB1B2AE7 for ; Fri, 4 Jul 2014 09:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 CbHS7MJk-Dzd for ; Fri, 4 Jul 2014 09:12:45 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CF71A004B for ; Fri, 4 Jul 2014 09:12:45 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l6so1624678qcy.4 for ; Fri, 04 Jul 2014 09:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ElFjfiIBcIf3RmZIXomEGIyytgQi+UWudvpmgvz33sI=; b=ghecDZ+AJ42f1DBncFoJoNU8CQXgZhIaGyC1ZHR9dyP9gvOmUYbpbPdtlxcWp3b99Y UNC+RN1INXgpaCNJF1x8ucqHcF0wbq5QzjWNzDxp7c0IgFCPSiXFN21INdxkCPxsemBk 6CMSTQ5gHQ985W+6pycaNLABnWcInBpOfZKHnOgML+spp/jUMb4D83A2ure6zXfr3yqG Gtt2+GWogmPDFElSaHhKTHuQ9wIBJP1B0q/uZzcoC99Qr7NqN5cH0S+jinbgNMj2fTdI 2tcuUzqRCeCBJG81VJwSllrJ1p+aGD/9xqpnGHc7hIEIiuq0FFyl2tDmOcpRFa4ksgWN 0+VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ElFjfiIBcIf3RmZIXomEGIyytgQi+UWudvpmgvz33sI=; b=QH4wgEYPohi7BcT5Q5uLkgnKZ64p0DP4dryH/Q5E2aeHbK+ss4eNmDkHDvhvQSwBZG cdRaLvrNYdoSAsQ3h4TRBhangT9O1fxZuwu8GXhS+/KVPx4F5+Yowq/wYTnD2YDg/v13 aUTgZU3NtctswmKBYIwbHcWWQOjqyIQrQusAkMRpCq/ROsTBUOTi7C2IMU1JL7k8/nM/ a/ZR2hmlzaS5gOf9+yS/rQAWrkIum8HLa/lJvWz+uDebE+PhWhAeAx2Ig/DMFk0+s+e5 PaS5ssmI4hl6hf9R+MyTJ8FdqQKTsq5TiWsjrp9fEALY/mHJW8QqixkLbvIcCVMdAEuK JOUA== X-Gm-Message-State: ALoCoQlwpd9kTC7sDGhFgSufF7+9QYgDC8NZV/05STRoWn9BBe4Xv6fp1x/rURInUpY+zQHwwmRM MIME-Version: 1.0 X-Received: by 10.140.108.200 with SMTP id j66mr16460740qgf.57.1404490364784; Fri, 04 Jul 2014 09:12:44 -0700 (PDT) Received: by 10.229.100.72 with HTTP; Fri, 4 Jul 2014 09:12:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Jul 2014 17:12:44 +0100 Message-ID: From: Ben Laurie To: Russ Housley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/trans/LFa5uV7RzFAUC9KdTcGsAIrwwko Cc: "trans@ietf.org" Subject: Re: [Trans] Comments on draft-ietf-trans-rfc6962-bis-03 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, 04 Jul 2014 16:12:48 -0000 On 20 June 2014 21:23, Russ Housley wrote: > I just got around to reading draft-ietf-trans-rfc6962-bis-03. I have 12 = comments. > > (1) I believe that the point of this document is to advance the protocol= from experimental to the standards track. However, the Abstract still say= s that it is an experimental protocol. Please fix this. This will be addressed in the next update. > (2) I find the Informal Introduction difficult to follow. It has not ch= anged since RFC 6962, and I hope that we can be more clear in this document= . I had to read this section more than once to figure out that who the act= ors are in this protocol and what they are expected to do. > > Here are the points as I understand them... > > - Some CAs (Certification Authorities) are issuing certificates that are= surprising to the subject of those certificates. > > - Certificate transparency facilitates the detection of such certificate= s using publicly auditable, append-only, untrusted logs of all issued certi= ficates. > > - Anyone can provide certificates to the logs, and it is expected that p= ublic CAs will contribute all their newly issued certificates. > > - Logs will only accept (unexpired?) certificates that chain back to a t= rust anchor in their configuration. Different logs can have a different se= t of trust anchors. > > - Accepted certificate submissions will get a signed timestamped respons= e as evidence of the addition to the log. > > - Merkle Trees are used to provide the append-only property of each log.= Merkle Trees also help ensure honest operation of the log. > > - The logs provide a service to three entities in the overall PKI: > > -- The relying party (but only TLS clients are described) get increa= sed confidence in the peer's certificate if it is in a log. > > -- Submitter can used the signed timestamped message to demand a pro= of of inclusion in the log. > > -- Certificate subjects can check the logs for unexpected certificat= es, and if detected take some action that is beyond the scope of this docum= ent. > > While I understand the reason for declaring the action beyond the scope o= f the document, I think that some help can be provided to the reader. Disc= overy of an unexpected certificate might lead to (1) work with the CA to ge= t the unexpected certificate revoked, or (2) work with maintainers of trust= anchor lists to get the CA removed if this is a continual problem. I've added some text to this effect. Not entirely sure what you're asking me to do about the rest - that section has already been rewritten multiple times in efforts to make it clearer. I do quite like your bulleted list, but I wonder if it would actually be useful for someone who didn't already have a fairly good idea of what was going on? > This exercise helped me to understand the big picture for this protocol. = I hope that the author can use it to make this easier for the next reader. > > I was looking at Figure 1 in RFC 5280 and wondering how the entities migh= t be shown in a similar figure. I'm not sure, but maybe the authors have a= figure in their heads. We have a figure on our website :-) http://www.certificate-transparency.org/how-ct-works Possibly we should reference that for a more ... graphical ... introduction= ? > (3) Section 2.1 once again call this protocol experimental. Please fix t= his. Done. > (4) In Section 2.1, this protocol only supports SHA-256. (This is repeat= ed in Section 3.5) For this protocol to move to the standards track, I wou= ld like to see an algorithm identifier. I have great confidence in SHA-256= , but I am sure that a different hash function will be needed in the distan= t future. Please make this transition easy by including the identifier now= . We have examples where the transition away from SHA-1 was much harder be= cause protocol work was needed to add such an identifier. Please add it no= w. I think the impact is to the structure defined in Section 3.3. Further= , the digitally-signed structure from TLS already makes use of a hash algor= ithm identifier, so it should be no big deal to use the same identifier her= e. I am not sure we want to allow any hash TLS might accept, so I'm inclined to establish our own registry. > (5) In Section 2.1.4, this protocol supports two signature algorithms. I= do not think this raises any algorithm identifier concerns because the dig= itally-signed structure from TLS is used. By reusing this structure, you a= re accepting the IANA Registry rules for algorithm identifier assignment. = This leads to a question: will this protocol ever need a hash algorithm ide= ntifier or a signature algorithm identifier that is not already registered?= I ask because the rules are strict (because the number of identifiers is = not very big)... > > - TLS SignatureAlgorithm Registry: > -- Values in the range 0-63 (decimal) inclusive are assigned via Sta= ndards Action. > -- Values in the range 64-223 (decimal) inclusive are assigned via S= pecification Required. > -- Values from 224-255 (decimal) inclusive are reserved for Private = Use. > > - TLS HashAlgorithm Registry: > -- Values in the range 0-63 (decimal) inclusive are assigned via Sta= ndards Action. > -- Values in the range 64-223 (decimal) inclusive are assigned via S= pecification Required. > -- Values from 224-255 (decimal) inclusive are reserved for Private = Use. I don't know, so I have added a ticket (http://trac.tools.ietf.org/wg/trans/trac/ticket/20) > (6) Since anyone can submit a certificate to the log, one can imagine the= same certificate being submitted from more than one source. It the certif= icate added multiple times, or do subsequent submissions get a pointer to t= he node in the tree associated with the first submission? Section 3 should= answer this question. It does: "If the log has previously seen the certificate, it MAY return the same SCT as it returned before" (which, of course, implies that it could also return a new SCT). > (7) I find the mix of the Precertificate into Section 3.1 a bit confusing= . It says, "The Precertificate is an X.509v3 certificate for simplicity, b= ut, since it isn't used for anything but logging, could equally be some oth= er data structure." This standards-track document should say what structur= e is used, and not go into the potential for other structures. In fact, th= e described "special critical poison extension" only works with X.509v3 cer= tificates. Given that there seems to be some call for Precertificates to not be X.509v3, I'm inclined to not mess with this for now. The poison extension is only needed if they are X.509v3 certificates. > (8) Section 3.1 says, "Logs MAY limit the length of chain they will accep= t." I think they SHOULD do so to protect the log from denial of service at= tacks. OK. > (9) In Section 3.1 the "certificate_chain" and "precertificate_chain" inc= lude the trust anchor. The submitter must know which trust anchors are sup= ported by the log, so there does not seem to be value in transmitting it. = It is identified by the issuer field in the next certificate in the chain a= nyway. Further, RFC 5280 does not require trust anchors to have self-signe= d root certificates. Eh? No they don't: "The root certificate itself MAY be omitted from the chain submitted to the log server." > (10) I do not understand the use of whitespace in Section 4. if I was su= pposed to get meaning from this, it did not work. I am not sure what you mean by "use of whitespace". > (11) Section 5.4 talks about an auditor role. I got no hint of such a ro= le in the Introduction. Please update the introduction so that this role i= s included. The introduction already says: "Similarly, those who have seen signed timestamps from a particular log can later demand a proof of inclusion from that log. " > (12) In Section 6, if you want IANA to point to this document for the def= inition of the signed_certificate_timestamp extension instead of RFC 6962, = you should say so here. Done. Thanks for your comments. From nobody Fri Jul 4 09:38:05 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D6A1A04D2 for ; Fri, 4 Jul 2014 09:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 lUhXVf3MSoVW for ; Fri, 4 Jul 2014 09:37:58 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC9E1A0262 for ; Fri, 4 Jul 2014 09:37:58 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id w7so1630901qcr.21 for ; Fri, 04 Jul 2014 09:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NGjQ2cKEmYzXi57n91rhl134Rrn3vv+N3wOGSdhAwts=; b=UIje/OI6BeRtFbsdn2UnLnalOMGo6RMVxe+4TPENEZJUPaUl20c4rRxFgm/J5Eqrj3 7fsAS3MBBTrDaK8/glfGR8K75UWcCvCHMVoxr6aadCQ1IaSzlBN0bG9ycNIc71p6ROkq 0e0unUP4h9BxfrRoSyREgUu9IJyinZYG1pLGCekM9+SV8TKT6wUsKoyR/jf2xuDg5cfc bTYjJ0dSpHi5nYnhtoFrfnBX9/G4jYOf5PhaAZ7SaiZfBePTY17QGNRebqxLqIydds9f lrfh6bLRTV26G4Weya+lR0SxrNbUNNyDXAH8x9kbsXFeWN8qx3s3o10xYmDsYWtjNR5d 03Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NGjQ2cKEmYzXi57n91rhl134Rrn3vv+N3wOGSdhAwts=; b=R3hDhsx0NZ2Z+uuX8MIKof3IltFv47/s/qFnjATdKAEQH86bp1OUTrJm2iYQhBYiKz +y5ONRIoGuMoYEV6yn75+jlvJPqmWAjgVsyZnsh3DICM8azxTU7xpGl0yrqXjqgNnLsI ypTxr8i3VILNDHY+Rb0bPtskz7DL7OJBmlQfbmEPPOhogDFmxJh0YqUtSU8n5m+xGHJu WjC+vHTP4iq7tDG761CI0iYlqNXW7di5ORpir/+XeSBEm/CyWU74RH3v8j4++MTbn5i/ yVJrEp86UDw88SAhiKgKIk88DqPqOvAb8N8ay08oxx7O6jeTunFkeuq+DjPgCoGS2z5I HK2w== X-Gm-Message-State: ALoCoQlVLlytDLIRwdQWtvVRRdhYi5ngZOr4+3B4x+os7oprEU/1d4nuV4TwUTG/5Y+CeludKuxJ MIME-Version: 1.0 X-Received: by 10.224.80.201 with SMTP id u9mr20510653qak.82.1404491877684; Fri, 04 Jul 2014 09:37:57 -0700 (PDT) Received: by 10.229.100.72 with HTTP; Fri, 4 Jul 2014 09:37:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Jul 2014 17:37:57 +0100 Message-ID: From: Ben Laurie To: Russ Housley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ua5Gg2EhmDzFsSg_oV6VC77gNt0 Cc: "trans@ietf.org" Subject: Re: [Trans] Comments on draft-ietf-trans-rfc6962-bis-03 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, 04 Jul 2014 16:38:01 -0000 BTW, if you want to comment on my proposed updates, you can see them here: https://github.com/google/certificate-transparency-rfcs/pull/1. On 4 July 2014 17:12, Ben Laurie wrote: > On 20 June 2014 21:23, Russ Housley wrote: >> I just got around to reading draft-ietf-trans-rfc6962-bis-03. I have 12= comments. >> >> (1) I believe that the point of this document is to advance the protoco= l from experimental to the standards track. However, the Abstract still sa= ys that it is an experimental protocol. Please fix this. > > This will be addressed in the next update. > >> (2) I find the Informal Introduction difficult to follow. It has not c= hanged since RFC 6962, and I hope that we can be more clear in this documen= t. I had to read this section more than once to figure out that who the ac= tors are in this protocol and what they are expected to do. >> >> Here are the points as I understand them... >> >> - Some CAs (Certification Authorities) are issuing certificates that ar= e surprising to the subject of those certificates. >> >> - Certificate transparency facilitates the detection of such certificat= es using publicly auditable, append-only, untrusted logs of all issued cert= ificates. >> >> - Anyone can provide certificates to the logs, and it is expected that = public CAs will contribute all their newly issued certificates. >> >> - Logs will only accept (unexpired?) certificates that chain back to a = trust anchor in their configuration. Different logs can have a different s= et of trust anchors. >> >> - Accepted certificate submissions will get a signed timestamped respon= se as evidence of the addition to the log. >> >> - Merkle Trees are used to provide the append-only property of each log= . Merkle Trees also help ensure honest operation of the log. >> >> - The logs provide a service to three entities in the overall PKI: >> >> -- The relying party (but only TLS clients are described) get incre= ased confidence in the peer's certificate if it is in a log. >> >> -- Submitter can used the signed timestamped message to demand a pr= oof of inclusion in the log. >> >> -- Certificate subjects can check the logs for unexpected certifica= tes, and if detected take some action that is beyond the scope of this docu= ment. >> >> While I understand the reason for declaring the action beyond the scope = of the document, I think that some help can be provided to the reader. Dis= covery of an unexpected certificate might lead to (1) work with the CA to g= et the unexpected certificate revoked, or (2) work with maintainers of trus= t anchor lists to get the CA removed if this is a continual problem. > > I've added some text to this effect. Not entirely sure what you're > asking me to do about the rest - that section has already been > rewritten multiple times in efforts to make it clearer. I do quite > like your bulleted list, but I wonder if it would actually be useful > for someone who didn't already have a fairly good idea of what was > going on? > >> This exercise helped me to understand the big picture for this protocol.= I hope that the author can use it to make this easier for the next reader= . >> >> I was looking at Figure 1 in RFC 5280 and wondering how the entities mig= ht be shown in a similar figure. I'm not sure, but maybe the authors have = a figure in their heads. > > We have a figure on our website :-) > > http://www.certificate-transparency.org/how-ct-works > > Possibly we should reference that for a more ... graphical ... introducti= on? > >> (3) Section 2.1 once again call this protocol experimental. Please fix = this. > > Done. > >> (4) In Section 2.1, this protocol only supports SHA-256. (This is repea= ted in Section 3.5) For this protocol to move to the standards track, I wo= uld like to see an algorithm identifier. I have great confidence in SHA-25= 6, but I am sure that a different hash function will be needed in the dista= nt future. Please make this transition easy by including the identifier no= w. We have examples where the transition away from SHA-1 was much harder b= ecause protocol work was needed to add such an identifier. Please add it n= ow. I think the impact is to the structure defined in Section 3.3. Furthe= r, the digitally-signed structure from TLS already makes use of a hash algo= rithm identifier, so it should be no big deal to use the same identifier he= re. > > I am not sure we want to allow any hash TLS might accept, so I'm > inclined to establish our own registry. > >> (5) In Section 2.1.4, this protocol supports two signature algorithms. = I do not think this raises any algorithm identifier concerns because the di= gitally-signed structure from TLS is used. By reusing this structure, you = are accepting the IANA Registry rules for algorithm identifier assignment. = This leads to a question: will this protocol ever need a hash algorithm id= entifier or a signature algorithm identifier that is not already registered= ? I ask because the rules are strict (because the number of identifiers is= not very big)... >> >> - TLS SignatureAlgorithm Registry: >> -- Values in the range 0-63 (decimal) inclusive are assigned via St= andards Action. >> -- Values in the range 64-223 (decimal) inclusive are assigned via = Specification Required. >> -- Values from 224-255 (decimal) inclusive are reserved for Private= Use. >> >> - TLS HashAlgorithm Registry: >> -- Values in the range 0-63 (decimal) inclusive are assigned via St= andards Action. >> -- Values in the range 64-223 (decimal) inclusive are assigned via = Specification Required. >> -- Values from 224-255 (decimal) inclusive are reserved for Private= Use. > > I don't know, so I have added a ticket > (http://trac.tools.ietf.org/wg/trans/trac/ticket/20) > >> (6) Since anyone can submit a certificate to the log, one can imagine th= e same certificate being submitted from more than one source. It the certi= ficate added multiple times, or do subsequent submissions get a pointer to = the node in the tree associated with the first submission? Section 3 shoul= d answer this question. > > It does: "If the log has previously seen the certificate, it MAY > return the same SCT as it returned before" (which, of course, implies > that it could also return a new SCT). > >> (7) I find the mix of the Precertificate into Section 3.1 a bit confusin= g. It says, "The Precertificate is an X.509v3 certificate for simplicity, = but, since it isn't used for anything but logging, could equally be some ot= her data structure." This standards-track document should say what structu= re is used, and not go into the potential for other structures. In fact, t= he described "special critical poison extension" only works with X.509v3 ce= rtificates. > > Given that there seems to be some call for Precertificates to not be > X.509v3, I'm inclined to not mess with this for now. The poison > extension is only needed if they are X.509v3 certificates. > >> (8) Section 3.1 says, "Logs MAY limit the length of chain they will acce= pt." I think they SHOULD do so to protect the log from denial of service a= ttacks. > > OK. > >> (9) In Section 3.1 the "certificate_chain" and "precertificate_chain" in= clude the trust anchor. The submitter must know which trust anchors are su= pported by the log, so there does not seem to be value in transmitting it. = It is identified by the issuer field in the next certificate in the chain = anyway. Further, RFC 5280 does not require trust anchors to have self-sign= ed root certificates. > > Eh? No they don't: "The root certificate itself MAY be omitted from > the chain submitted to the log server." > >> (10) I do not understand the use of whitespace in Section 4. if I was s= upposed to get meaning from this, it did not work. > > I am not sure what you mean by "use of whitespace". > >> (11) Section 5.4 talks about an auditor role. I got no hint of such a r= ole in the Introduction. Please update the introduction so that this role = is included. > > The introduction already says: > > "Similarly, those who have seen signed timestamps from a particular > log can later demand a proof of inclusion from that log. " > >> (12) In Section 6, if you want IANA to point to this document for the de= finition of the signed_certificate_timestamp extension instead of RFC 6962,= you should say so here. > > Done. > > Thanks for your comments. From nobody Fri Jul 4 11:52:45 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198471B2E5F for ; Fri, 4 Jul 2014 11:52:42 -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 tDFlXpid6RDj for ; Fri, 4 Jul 2014 11:52:39 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629CC1B2E58 for ; Fri, 4 Jul 2014 11:52:35 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id r10so2303654pdi.9 for ; Fri, 04 Jul 2014 11:52:34 -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=dA/OOJVDEpKjCGTf1xZtnHrwej06WuHrFeB9XMmuMpc=; b=z0o8Yl2rhhY/DkHO634whtwVx3Rs2YhdENEEWYsmi9h5uNHqPEex1DddBCu/QTFzPS aoPwdOhZixrboBVIyo+rogvG2L67ueDY7niV/tugfCqqNyMtZRYExf/VL7Gkwy50MuVK 1JnaB4TQmzEw51lgo260UfpHL+0OQBFV51iUgMpc9bpXb7e4mLzORpjSCizYeM5tDpmu tQ0dw+3c1lGBCYZ/cj4za2F4fMv/8bL1OlXsnshTzaj4yENsyUP4aktwLGx5RAOI+Nyx Ixc44GGCBgwyifQUZOzH9fawwcyTF7QGHfpS8B30QJYoe3yExwdMkh9lVgL9zgfNG3Zt OCQQ== X-Received: by 10.68.250.3 with SMTP id yy3mr4652089pbc.56.1404499954917; Fri, 04 Jul 2014 11:52:34 -0700 (PDT) Received: from spandex.local ([216.67.57.220]) by mx.google.com with ESMTPSA id cj17sm9843781pdb.75.2014.07.04.11.52.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 11:52:33 -0700 (PDT) Message-ID: <53B6F7EE.5020008@gmail.com> Date: Fri, 04 Jul 2014 10:52:30 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eran Messeri References: <53B5E4E1.3010700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/I4gSo-bzx3ZA7JiKZlrv-4iDtoM Cc: "trans@ietf.org" Subject: Re: [Trans] Toronto planning 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, 04 Jul 2014 18:52:42 -0000 On 7/4/14 1:19 AM, Eran Messeri wrote: > In addition, I propose a brief explanation on the following topics: > * The way to avoid logging private subdomains (now-closed Trac ticket #1 > ). That's one of the > major changes since the last meeting (IIRC) so we should make sure it > answers the needs of CAs while not introducing new security concerns (on > top of what was already discussed). It might be a good idea to start discussion on the mailing list prior to the meeting - if nothing else, there's a broader constituency on the mailing list and you're more likely to receive CA feedback. If it gets contentious (which doesn't appear likely) we'd need to close it on the mailing list, anyway. Do you feel that it would be helpful to have a separate slot for these, or would you be okay with addressing them as part of running down the tickets during the meeting? Melinda From nobody Sat Jul 5 05:51:02 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFAD1A052E for ; Sat, 5 Jul 2014 05:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Y9aEsWjXiIR6 for ; Sat, 5 Jul 2014 05:50:59 -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 CA88B1A0505 for ; Sat, 5 Jul 2014 05:50:58 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50663 helo=fritz.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1X3PQe-0000Zv-KP; Sat, 05 Jul 2014 08:50:56 -0400 Message-ID: <53B7F4B0.7060306@bbn.com> Date: Sat, 05 Jul 2014 08:50:56 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Laurie References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com> <53B2F131.6030606@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010006030404080900040505" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/34N-8m2YJpMJEiyKPP-i3lucKw4 Cc: "trans@ietf.org" Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 12:51:01 -0000 This is a multi-part message in MIME format. --------------010006030404080900040505 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Ben, > On 1 July 2014 18:34, Stephen Kent wrote: >> Ben, >>> ... >>> >>> As you point out, the log can relax validation rules, which deals with >>> this problem (and we do, indeed, do that in our implementation). >> My comments noted that relaxing rules in an unspecified fashion creates >> potential >> problems for those submitting pre-certs. The specific changes needed to >> enable >> acceptance oif pre-certs need to be spelled out. > Hmm. What we do is check the signatures validate all the way up the > chain. That's it. I'm not sure we need anything tighter than that, so > I guess we could specify that? Ok, that's what _you_ do, but 5280 describes a long list of cert path validation rules and your doc just says that these can be relaxed. It does not prohibit a log from performing the full set dictated by PKIX and X.509 path validation procedures, nor does it provide guidance of which subset SHOULD/MUST be performed. Absent such guidance different log operators can legitimately perform different checks, resulting in chaos. > >>>> CAs that randomly generate serial numbers during issuance can't >>>> pre-generate >>>> serial numbers to be used in the TBScertificate, then subsequently in the >>>> final certificate. Is the serial number *that* important that it MUST be >>>> included in the SCT? The issuer for the TBScertificate does not match >>>> the >>>> value of the certificate that signed it, so what's the point of the >>>> serial >>>> number? The CN, SAN, signing algorithms and keys are the most critical >>>> components. Can we limit the SCT to these values? >>> Serial numbers are used for revocation, so we need to know what they are. >> I understand the desire to have the serial number be submitted as part >> of the pre-cert, but the problem raised by Doug is a valid one that >> cannot be ignored. > My response is that, yes, the serial number is *that* important that > is MUST be included in the SCT. If we had a agreed-upon requirements doc that explained why the serial number is critical, and if it discussed the impact on CAs that may use serial number management techniques that preclude pre-determining the serial number assigned to a cert, then we would be in good shape. But we don't. So, I think we may have a serious problem with this aspect of the precert model. > ... >> The burden on fixing it is not on Doug; it is on the authors of the doc! > Our position is that compliant CAs _can_ use Precertificate Signing > Certificates - though possibly not with the exact toolchain they use > to issue certificates. If someone wants to propose a mechanism that is > compatible with whatever restrictions their s/w imposes, we'd be happy > to consider it. "Compliant" with what set of specs? I noted an aspect of a design for a CA-focused HSM that, for several years, was used by VeriSign to issue every cert. It is a powerful feature for high assurance cert issuance. It is also incompatible with the precert design. The precert design seems to preclude use of some approaches to serial number management that may reduce CA secruity. Thus it appears to be a tradeoff, one that this WG has not discussed. Please describe what you mean by a "complaint" CA. >> Ben, it's not reasonable to tell CAs that their extant serial number >> management >> mechanism has to change to accommodate the CT design. It is the >> responsibility >> of the CT designers to figure out how to accommodate valid CA operation >> models. > I don't agree. If things have to change in order to achieve the agreed > goals, then they have to change. It is not our obligation to preserve > the world in its current perfection. Agreed goals? As I noted, this WG does not have a agreed-upon set of requirements. We have an experimental RFC (that does not appear to have been carefully reviewed prior to publication, not unreasonable for an experimental RFC, but ...) as a starting point. The RFC identifies 3 different ways to convey SCTs. One of these appears to be problematic. So, maybe it's time to discuss why there are three ways to deliver SCTs, and why the precert method is critical. > The serial number is required to fulfil the purpose of CT. If you want > to not have serial numbers in the log, then we must also change the > revocation mechanisms. I don't recall the doc mentioning revocation as a remediation mechanism. On this list someone suggested that CT is a reputation mechanism, and one might infer that the primary remediation mechanism is shaming CAs into submission. If we had an architecture doc, not just a description of a set of mechanisms, we would not have to guess what aspects of CT are critical and agreed upon by the WG (not just the document authors). Steve --------------010006030404080900040505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Ben,
On 1 July 2014 18:34, Stephen Kent <kent@bbn.com> wrote:

Ben,

...

As you point out, the log can relax validation rules, which deals with
this problem (and we do, indeed, do that in our implementation).

My comments noted that relaxing rules in an unspecified fashion creates
potential
problems for those submitting pre-certs. The specific changes needed to
enable
acceptance oif pre-certs need to be spelled out.

Hmm. What we do is check the signatures validate all the way up the
chain. That's it. I'm not sure we need anything tighter than that, so
I guess we could specify that?
Ok, that's what you do, but 5280 describes a long list of cert path validation rules
and your doc just says that these can be relaxed. It does not prohibit a log from
performing  the full set dictated by PKIX and X.509 path validation procedures, nor
does it provide guidance of which subset SHOULD/MUST be performed. Absent such guidance
different log operators can legitimately perform different checks, resulting in chaos.


CAs that randomly generate serial numbers during issuance can't
pre-generate
serial numbers to be used in the TBScertificate, then subsequently in the
final certificate. Is the serial number *that* important that it MUST be
included in the SCT?  The issuer for the TBScertificate does not match
the
value of the certificate that signed it, so what's the point of the
serial
number?  The CN, SAN, signing algorithms and keys are the most critical
components.  Can we limit the SCT to these values?

Serial numbers are used for revocation, so we need to know what they are.

I understand the desire to have the serial number be submitted as part
of the pre-cert, but the problem raised by Doug is a valid one that
cannot be ignored.

My response is that, yes, the serial number is *that* important that
is MUST be included in the SCT.
If we had a agreed-upon  requirements doc that explained why the serial number is
critical, and if it discussed the impact on CAs that may use serial number management
techniques that preclude pre-determining the serial number assigned to a cert, then
we would be in good shape. But we don't. So, I think we may have a serious problem
with this aspect of the precert model.
...
The burden on fixing it is not on Doug; it is on the authors of the doc!

Our position is that compliant CAs _can_ use Precertificate Signing
Certificates - though possibly not with the exact toolchain they use
to issue certificates. If someone wants to propose a mechanism that is
compatible with whatever restrictions their s/w imposes, we'd be happy
to consider it.
"Compliant" with what set of specs? I noted an aspect of a design for a CA-focused
HSM that, for several years, was used by VeriSign to issue every cert. It is a powerful
feature for high assurance cert issuance. It is also incompatible with the precert design.
The precert design seems to preclude use of some approaches to serial number management
that may reduce CA secruity. Thus it appears to be a tradeoff, one that this WG has not
discussed. Please describe what you mean by a "complaint" CA. 

      

        
Ben, it's not reasonable to tell CAs that their extant serial number
management
mechanism has to change to accommodate the CT design. It is the
responsibility
of the CT designers to figure out how to accommodate valid CA operation
models.


      

      
I don't agree. If things have to change in order to achieve the agreed
goals, then they have to change. It is not our obligation to preserve
the world in its current perfection.

    

    Agreed goals? As I noted, this WG does not have a agreed-upon set of
    requirements.

    We have an experimental RFC (that does not appear to have been
    carefully reviewed

    prior to publication, not unreasonable for an experimental RFC, but
    ...) as a starting

    point. The RFC identifies 3 different ways to convey SCTs. One of
    these appears to

    be problematic. So, maybe it's time to discuss why there are three
    ways to deliver

    SCTs, and why the precert method is critical. 

    

      
The serial number is required to fulfil the purpose of CT. If you want
to not have serial numbers in the log, then we must also change the
revocation mechanisms.


    

    I don't recall the doc mentioning revocation as a remediation
    mechanism. On this

    list someone suggested that CT is a reputation mechanism, and one
    might infer that

    the primary remediation mechanism is shaming CAs into submission. If
    we had an architecture 

    doc, not just a description of a set of mechanisms, we would not
    have to guess what

    aspects of CT are critical and agreed upon by the WG (not just the
    document authors).

    

    Steve

  


--------------010006030404080900040505--


From nobody Sat Jul  5 11:35:07 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19581A0263 for ; Sat,  5 Jul 2014 11:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 U5rEAqeenzCX for ; Sat,  5 Jul 2014 11:35:04 -0700 (PDT)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8551A016F for ; Sat,  5 Jul 2014 11:35:04 -0700 (PDT)
Received: by mail-qa0-f48.google.com with SMTP id x12so2283488qac.35 for ; Sat, 05 Jul 2014 11:35:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=Tq7g2Iectey1sEFXFrvsZVu0CLpEfS6G9qDFnFc4lVs=; b=PeoEDyHrJIYIHRFnIh3NmqaaofiMloqQsKg0ZQnxC/u7bDC3V4ioPa4nW1MUetgB1L 6wEftO/uaPrvSqWKALcVnjErQE+DfHlm+9fUk1OBW0Jo1xMAmLGKuq1JCeDjyr3fEQe4 EUcByzfNrxf2NOBv9Z9rA0iHowytMwjtTOPvXrI9xfJWmHwo1ll0FyIWxhQ+h1SBfAj5 1IA0V7wQEaDHcabU8PonZsgc+bXQVJPi0y/31ERHeLWgd+ZiURxs8VNtkj9uYiutkgdW 3JJOEw2OMa/KoR6c9pdk1Vm5ekOZlxBwF/0isbZD3gx5TTNeBgLLsgYqulPQm5MNKtRE 0sVg==
X-Gm-Message-State: ALoCoQmRDArPK5EMd2579eTOcbi9D6XlaKBvdVMjakE7FYgNP8uuD8SQnaM+MByhm+dmtPs+CSmD
X-Received: by 10.224.25.10 with SMTP id x10mr30899087qab.104.1404585303225; Sat, 05 Jul 2014 11:35:03 -0700 (PDT)
Received: from [192.168.2.2] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id v10sm63205793qaj.25.2014.07.05.11.35.01 for  (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 05 Jul 2014 11:35:02 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.4.2.140509
Date: Sat, 05 Jul 2014 14:34:57 -0400
From: Carl Wallace 
To: "trans@ietf.org" 
Message-ID: 
Thread-Topic: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT
References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com>  <53B2F131.6030606@bbn.com>  <53B7F4B0.7060306@bbn.com>
In-Reply-To: <53B7F4B0.7060306@bbn.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RF68efg0ymh8wdIqYB4fm9C1JH4
Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 05 Jul 2014 18:35:06 -0000

From:  Stephen Kent 
Date:  Saturday, July 5, 2014 at 8:50 AM
To:  Ben Laurie 
Cc:  "trans@ietf.org" 
Subject:  Re: [Trans] Using a Precertificate Signing Certificate to sign
TBScertificates for CT

>  
>      On 1 July 2014 18:34, Stephen Kent 
> wrote:
>          ...
>
>As you point out, the log can relax validation rules, which deals with
>this problem (and we do, indeed, do that in our implementation).
>
>        
>
>        My comments noted that relaxing rules in an unspecified fashion
>creates
>potential
>problems for those submitting pre-certs. The specific changes needed to
>enable
>acceptance oif pre-certs need to be spelled out.
>
>      
>
>      Hmm. What we do is check the signatures validate all the way up the
>chain. That's it. I'm not sure we need anything tighter than that, so
>I guess we could specify that?
>    
>
>    Ok, that's what you do, but 5280 describes a long list of
>    cert path validation rules
>    and your doc just says that these can be relaxed. It does not
>    prohibit a log from
>    performing  the full set dictated by PKIX and X.509 path validation
>    procedures, nor
>    does it provide guidance of which subset SHOULD/MUST be performed.
>    Absent such guidance
>    different log operators can legitimately perform different checks,
>    resulting in chaos.
>

Seems easy enough to specify and justify the relaxed rules (signature
checking only) for this application but is it worth supporting the
highlighting of errors, like name constraint violations, to draw the
attention of log monitors?  An indication could probably be represented as
a CTExtension.



From nobody Mon Jul  7 07:14:06 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669731A01A8 for ; Mon,  7 Jul 2014 07:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 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, RP_MATCHES_RCVD=-0.651, 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 d8Z7k1e6kgDx for ; Mon,  7 Jul 2014 07:14:01 -0700 (PDT)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418941A0163 for ; Mon,  7 Jul 2014 07:14:01 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id x13so3698398qcv.5 for ; Mon, 07 Jul 2014 07:14:00 -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=sdQsna1Lmv/kRRrl3TFd/8zH5xCHF5XbA6MEu6pqzR4=; b=fIDpl8LoplNbQxKtTrrb84dVo7ShNpBDzDvnFKcOPwzWkYWYV4KtjQbKUbByjMpl2V 0SQG7MOW1umWgsmTVGUjtsqEWA00shPmY/KHcLydZqF3WiVTXsTb7AkeUBQoEyzXjTVg pyJCapOfpgoGpxQVh+L1SWKsT7Gdq9quvaDnd/iV1hzXZAyqaoYN3y0hDpJN7OH8k/JE a2q+EUFCb685t9MUEspaJcFUsMR31NNR/58cB/Vu2YW1Ex16Us/g0kiVz24T25JQ7fsz LeXGIuou1p7kqWIPcgeRCfs9m8PyDS6h7FUzvLi5WsZuUK9Rrg/JVoJ7miWjvdovJQFv +Nyg==
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=sdQsna1Lmv/kRRrl3TFd/8zH5xCHF5XbA6MEu6pqzR4=; b=btn74EfRjF+BZd7YeGst6nULlxVoXLtBtyywowceAAJI4Qo7Bpq60cLuLdi37vyATI DUZD5Vy4GOqKL4YLuvSdXJJA0wOn5RjFTN/3kRKFQj/KBA4y9fkzV3ZQVxwMh4eG9Cy+ aiZjSRu3Xfv5ii80xmx/lG7YoesD73nFz3Vs83WO6kQvDus1BGtXosGvcJ0zrkg0Khc5 6NyH1NzOIiHsKXxZFr0rcro7xdGcCoj39XvbM8Gp/kKuEAwfdhI+/MbIHF6Yuf5woRO/ HYgfi2EL7UY3IGyt1I9L0mVSefTmNk1PIsEdksYKVKHzqxDTrVj1vWuOiY+3ZOqaJopm ax4g==
X-Gm-Message-State: ALoCoQlNSCWpmlRgcpKEg86aeDDfStIHYyRvCiQACDJcRX/+DkwQxoj20t/Ugg7iaOvCJFvtmeqD
MIME-Version: 1.0
X-Received: by 10.140.43.118 with SMTP id d109mr45361792qga.10.1404742440386;  Mon, 07 Jul 2014 07:14:00 -0700 (PDT)
Received: by 10.229.100.72 with HTTP; Mon, 7 Jul 2014 07:14:00 -0700 (PDT)
In-Reply-To: <53B7F4B0.7060306@bbn.com>
References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com>  <53B2F131.6030606@bbn.com>  <53B7F4B0.7060306@bbn.com>
Date: Mon, 7 Jul 2014 15:14:00 +0100
Message-ID: 
From: Ben Laurie 
To: Stephen Kent 
Content-Type: multipart/alternative; boundary=001a113a92f22922da04fd9b165c
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/zQzIE8QwHhwvl-jssAytwfv4v_0
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT
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, 07 Jul 2014 14:14:04 -0000

--001a113a92f22922da04fd9b165c
Content-Type: text/plain; charset=UTF-8

On 5 July 2014 13:50, Stephen Kent  wrote:

>  Ben,
>
>  On 1 July 2014 18:34, Stephen Kent   wrote:
>
>  Ben,
>
>  ...
>
> As you point out, the log can relax validation rules, which deals with
> this problem (and we do, indeed, do that in our implementation).
>
>  My comments noted that relaxing rules in an unspecified fashion creates
> potential
> problems for those submitting pre-certs. The specific changes needed to
> enable
> acceptance oif pre-certs need to be spelled out.
>
>  Hmm. What we do is check the signatures validate all the way up the
> chain. That's it. I'm not sure we need anything tighter than that, so
> I guess we could specify that?
>
>  Ok, that's what *you* do, but 5280 describes a long list of cert path
> validation rules
> and your doc just says that these can be relaxed. It does not prohibit a
> log from
> performing  the full set dictated by PKIX and X.509 path validation
> procedures, nor
> does it provide guidance of which subset SHOULD/MUST be performed. Absent
> such guidance
> different log operators can legitimately perform different checks,
> resulting in chaos.
>

I don't believe it will result in chaos, but anyway, the purpose of
checking signatures on log submissions is to combat spam. I don't think we
should tightly define exactly what checks are performed to that end,
because that's a great way to leave yourself unable to defend against some
kind of unforeseen spam. We can certainly clarify that. I've added a ticket.


>
>    CAs that randomly generate serial numbers during issuance can't
> pre-generate
> serial numbers to be used in the TBScertificate, then subsequently in the
> final certificate. Is the serial number *that* important that it MUST be
> included in the SCT?  The issuer for the TBScertificate does not match
> the
> value of the certificate that signed it, so what's the point of the
> serial
> number?  The CN, SAN, signing algorithms and keys are the most critical
> components.  Can we limit the SCT to these values?
>
>  Serial numbers are used for revocation, so we need to know what they are.
>
>  I understand the desire to have the serial number be submitted as part
> of the pre-cert, but the problem raised by Doug is a valid one that
> cannot be ignored.
>
>  My response is that, yes, the serial number is *that* important that
> is MUST be included in the SCT.
>
>  If we had a agreed-upon  requirements doc that explained why the serial
> number is
> critical, and if it discussed the impact on CAs that may use serial number
> management
> techniques that preclude pre-determining the serial number assigned to a
> cert, then
> we would be in good shape. But we don't. So, I think we may have a serious
> problem
> with this aspect of the precert model.
>

The purpose of CT is to detect mis-issuance so that it can be rectified. As
already explained, some revocation mechanisms require the serial number of
the revoked cert. I don\t think we need a separate requirements doc for it
to be obvious that without the serial number, we have a problem.


>  ...
>
>  The burden on fixing it is not on Doug; it is on the authors of the doc!
>
>  Our position is that compliant CAs _can_ use Precertificate Signing
> Certificates - though possibly not with the exact toolchain they use
> to issue certificates. If someone wants to propose a mechanism that is
> compatible with whatever restrictions their s/w imposes, we'd be happy
> to consider it.
>
>  "Compliant" with what set of specs? I noted an aspect of a design for a
> CA-focused
> HSM that, for several years, was used by VeriSign to issue every cert. It
> is a powerful
> feature for high assurance cert issuance. It is also incompatible with the
> precert design.
> The precert design seems to preclude use of some approaches to serial
> number management
> that may reduce CA secruity. Thus it appears to be a tradeoff, one that
> this WG has not
> discussed. Please describe what you mean by a "complaint" CA.
>

I do not believe that the use of an HSM in any way constrains a CA's
ability to deal with serial numbers as needed. The issue of compliance is a
red herring.


>   Ben, it's not reasonable to tell CAs that their extant serial number
> management
> mechanism has to change to accommodate the CT design. It is the
> responsibility
> of the CT designers to figure out how to accommodate valid CA operation
> models.
>
>  I don't agree. If things have to change in order to achieve the agreed
> goals, then they have to change. It is not our obligation to preserve
> the world in its current perfection.
>
>  Agreed goals? As I noted, this WG does not have a agreed-upon set of
> requirements.
> We have an experimental RFC (that does not appear to have been carefully
> reviewed
> prior to publication, not unreasonable for an experimental RFC, but ...)
> as a starting
> point. The RFC identifies 3 different ways to convey SCTs. One of these
> appears to
> be problematic. So, maybe it's time to discuss why there are three ways to
> deliver
> SCTs, and why the precert method is critical.
>

Precerts are critical because otherwise server s/w has to be updated to
deliver SCTs to clients. We know that isn't going to happen universally any
time soon. I agree the I-D should mention this.


>  The serial number is required to fulfil the purpose of CT. If you want
> to not have serial numbers in the log, then we must also change the
> revocation mechanisms.
>
>  I don't recall the doc mentioning revocation as a remediation mechanism.
>

The latest version does, though its pretty obvious - what do you think
remediation mechanisms are for mis-issuance in PKIX? Surely these are
already specified by existing RFCs?

I notice, BTW, we've slipped past the cutoff date without updating, which
is unfortunate.


> On this
> list someone suggested that CT is a reputation mechanism, and one might
> infer that
> the primary remediation mechanism is shaming CAs into submission. If we
> had an architecture
> doc, not just a description of a set of mechanisms, we would not have to
> guess what
> aspects of CT are critical and agreed upon by the WG (not just the
> document authors).
>

>

> Steve
>

--001a113a92f22922da04fd9b165c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On 5 July 2014 13:50, Stephen Kent <kent@bbn.com> wrote:<=
br>


 =20
   =20
 =20
  

    Ben,


    

      
On 1 July 2014 18:34, Stephen Kent <kent@bbn.com> wrote:


      

        
Ben,


        

          
...

As you point out, the log can relax validation rules, which deals with
this problem (and we do, indeed, do that in our implementation).


        

        
My comments noted that relaxing rules in an unspecified fashio=
n creates
potential
problems for those submitting pre-certs. The specific changes needed to
enable
acceptance oif pre-certs need to be spelled out.


      

      
Hmm. What we do is check the signatures validate all the way up =
the
chain. That's it. I'm not sure we need anything tighter than that, =
so
I guess we could specify that?

    

    Ok, that's what you do, but 5280 describes a long list of
    cert path validation rules

    and your doc just says that these can be relaxed. It does not
    prohibit a log from

    performing=C2=A0 the full set dictated by PKIX and X.509 path validatio=
n
    procedures, nor

    does it provide guidance of which subset SHOULD/MUST be performed.
    Absent such guidance

    different log operators can legitimately perform different checks,
    resulting in chaos.

I don't b=
elieve it will result in chaos, but anyway, the purpose of checking signatu=
res on log submissions is to combat spam. I don't think we should tight=
ly define exactly what checks are performed to that end, because that's=
 a great way to leave yourself unable to defend against some kind of unfore=
seen spam. We can certainly clarify that. I've added a ticket.


=C2=A0


    

      

      

        

          

            
CAs that randomly generate serial numbers during issuance =
can't
pre-generate
serial numbers to be used in the TBScertificate, then subsequently in the
final certificate. Is the serial number *that* important that it MUST be
included in the SCT?  The issuer for the TBScertificate does not match
the
value of the certificate that signed it, so what's the point of the
serial
number?  The CN, SAN, signing algorithms and keys are the most critical
components.  Can we limit the SCT to these values?


          

          
Serial numbers are used for revocation, so we need to know w=
hat they are.


        

        
I understand the desire to have the serial number be submitted=
 as part
of the pre-cert, but the problem raised by Doug is a valid one that
cannot be ignored.


      

      
My response is that, yes, the serial number is *that* important =
that
is MUST be included in the SCT.

    

    If we had a agreed-upon=C2=A0 requirements doc that explained why the
    serial number is 

    critical, and if it discussed the impact on CAs that may use serial
    number management

    techniques that preclude pre-determining the serial number assigned
    to a cert, then

    we would be in good shape. But we don't. So, I think we may have a
    serious problem

    with this aspect of the precert model.

<=
/div>
The purpose of CT is to detect mis-issuance so that it can be rec=
tified. As already explained, some revocation mechanisms require the serial=
 number of the revoked cert. I don\t think we need a separate requirements =
doc for it to be obvious that without the serial number, we have a problem.=



=C2=A0

    

      
...

      

        
The burden on fixing it is not on Doug; it is on the authors o=
f the doc!


      

      
Our position is that compliant CAs _can_ use Precertificate Sign=
ing
Certificates - though possibly not with the exact toolchain they use
to issue certificates. If someone wants to propose a mechanism that is
compatible with whatever restrictions their s/w imposes, we'd be happy
to consider it.

    

    "Compliant" with what set of specs? I noted an aspect of a de=
sign
    for a CA-focused

    HSM that, for several years, was used by VeriSign to issue every
    cert. It is a powerful

    feature for high assurance cert issuance. It is also incompatible
    with the precert design.

    The precert design seems to preclude use of some approaches to
    serial number management

    that may reduce CA secruity. Thus it appears to be a tradeoff, one
    that this WG has not

    discussed. Please describe what you mean by a "complaint" CA.=
 

I do not believe that the use o=
f an HSM in any way constrains a CA's ability to deal with serial numbe=
rs as needed. The issue of compliance is a red herring.


=C2=A0

    

      

      

        
Ben, it's not reasonable to tell CAs that their extant ser=
ial number
management
mechanism has to change to accommodate the CT design. It is the
responsibility
of the CT designers to figure out how to accommodate valid CA operation
models.


      

      
I don't agree. If things have to change in order to achieve =
the agreed
goals, then they have to change. It is not our obligation to preserve
the world in its current perfection.

    

    Agreed goals? As I noted, this WG does not have a agreed-upon set of
    requirements.

    We have an experimental RFC (that does not appear to have been
    carefully reviewed

    prior to publication, not unreasonable for an experimental RFC, but
    ...) as a starting

    point. The RFC identifies 3 different ways to convey SCTs. One of
    these appears to

    be problematic. So, maybe it's time to discuss why there are three
    ways to deliver

    SCTs, and why the precert method is critical. 

Precerts are critical because otherwise server s/w has to=
 be updated to deliver SCTs to clients. We know that isn't going to hap=
pen universally any time soon. I agree the I-D should mention this.


=C2=A0

    

      
The serial number is required to fulfil the purpose of CT. If yo=
u want
to not have serial numbers in the log, then we must also change the
revocation mechanisms.


    

    I don't recall the doc mentioning revocation as a remediation
    mechanism.

The latest version doe=
s, though its pretty obvious - what do you think remediation mechanisms are=
 for mis-issuance in PKIX? Surely these are already specified by existing R=
FCs?



I notice, BTW, we've slipped past the cutoff date w=
ithout updating, which is unfortunate.
=C2=A0


 On this

    list someone suggested that CT is a reputation mechanism, and one
    might infer that

    the primary remediation mechanism is shaming CAs into submission. If
    we had an architecture 

    doc, not just a description of a set of mechanisms, we would not
    have to guess what

    aspects of CT are critical and agreed upon by the WG (not just the
    document authors).
=C2=A0



    

    Steve

  






--001a113a92f22922da04fd9b165c--


From nobody Mon Jul  7 07:15:03 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD401A0123 for ; Mon,  7 Jul 2014 07:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.029
X-Spam-Level: 
X-Spam-Status: No, score=-2.029 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, RP_MATCHES_RCVD=-0.651, 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 USlq31ahtOwz for ; Mon,  7 Jul 2014 07:15:00 -0700 (PDT)
Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7CA1A011C for ; Mon,  7 Jul 2014 07:15:00 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id r5so3725915qcx.22 for ; Mon, 07 Jul 2014 07:14:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3nKkFWaFICMk6nOoaa/R3bkSJGPXxy1Cp/tMVsQJUw0=; b=WGyilWYlbr24ZVyhEoq4rHtT9KL9YOA2kQ0OWS6ZIcvsaKiRb7Gv+nYn8oSHoQhwRk StXnhn86JA+A81aUNTfXiYmbvsg+7LAIf5UsuOixcLW/icKtIMti8O6ujp8LDRLQ7G7Z UOJ05WssHWipqDkIYDEeTbe6xpfs7scqb0+yig/Gr/0XAU/WTWJVCDvRRI33P3jQNxQR hYgWCpUSUPAoTu0UOniJEdRFu87THhyoJva1T45WvjB7jGTPNA858c16SKn2ldRWQhUB 2z0CS16Bn8k0dotCGAvNTgpHl9zm7inl64X0ugr9bXraNVPTagy0a0Gxxk9VLqwOrM6p D8Ow==
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=3nKkFWaFICMk6nOoaa/R3bkSJGPXxy1Cp/tMVsQJUw0=; b=jEZQ5j/bWGxv4QABlt5qEM9A+kLufYfS2ESQarGmSiMlQXVVVOPu0v0Xnw7ujJWHjV Li97+hrS7pKf0jWhgVPvo6ugkYzn8rqbXrFORUW09Xo9s4jM2YUxYq9cw5nfs1vBb3YR 3sVWkPA4PoKeaaROqXGhL43ntiHUJdrGAts7loh3zg/fDnLIGGsrRjOMYplYvIZzdpAh 3PfUQ8Pagj+VtZJDVDEp1IsfSTsx81wzLz1DMKgydgoiu/PmyT/AKL/zNinf2AKtzmRx OA/OUxog3+s/avpBriAxKoLScL8MRYT8F42x+ILL9n9S+2ukRH44JHoEuJYlkk2q5dlZ +DRQ==
X-Gm-Message-State: ALoCoQkq0vi3eQrSIvdp1NOwTHxCdP7jKAdeGPu2CRugjtlw0778E3YuGnPHtm34D0IqrEsttgg4
MIME-Version: 1.0
X-Received: by 10.224.42.196 with SMTP id t4mr47300493qae.48.1404742499586; Mon, 07 Jul 2014 07:14:59 -0700 (PDT)
Received: by 10.229.100.72 with HTTP; Mon, 7 Jul 2014 07:14:59 -0700 (PDT)
In-Reply-To: 
References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com>  <53B2F131.6030606@bbn.com>  <53B7F4B0.7060306@bbn.com> 
Date: Mon, 7 Jul 2014 15:14:59 +0100
Message-ID: 
From: Ben Laurie 
To: Carl Wallace 
Content-Type: multipart/alternative; boundary=089e0158b67cb0772d04fd9b19b9
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/nZTPrzGqjgqE4sU4Cm8KJJqYXzY
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT
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, 07 Jul 2014 14:15:02 -0000

--089e0158b67cb0772d04fd9b19b9
Content-Type: text/plain; charset=UTF-8

On 5 July 2014 19:34, Carl Wallace  wrote:

> From:  Stephen Kent 
> Date:  Saturday, July 5, 2014 at 8:50 AM
> To:  Ben Laurie 
> Cc:  "trans@ietf.org" 
> Subject:  Re: [Trans] Using a Precertificate Signing Certificate to sign
> TBScertificates for CT
>
> >
> >      On 1 July 2014 18:34, Stephen Kent 
> > wrote:
> >          ...
> >
> >As you point out, the log can relax validation rules, which deals with
> >this problem (and we do, indeed, do that in our implementation).
> >
> >
> >
> >        My comments noted that relaxing rules in an unspecified fashion
> >creates
> >potential
> >problems for those submitting pre-certs. The specific changes needed to
> >enable
> >acceptance oif pre-certs need to be spelled out.
> >
> >
> >
> >      Hmm. What we do is check the signatures validate all the way up the
> >chain. That's it. I'm not sure we need anything tighter than that, so
> >I guess we could specify that?
> >
> >
> >    Ok, that's what you do, but 5280 describes a long list of
> >    cert path validation rules
> >    and your doc just says that these can be relaxed. It does not
> >    prohibit a log from
> >    performing  the full set dictated by PKIX and X.509 path validation
> >    procedures, nor
> >    does it provide guidance of which subset SHOULD/MUST be performed.
> >    Absent such guidance
> >    different log operators can legitimately perform different checks,
> >    resulting in chaos.
> >
>
> Seems easy enough to specify and justify the relaxed rules (signature
> checking only) for this application but is it worth supporting the
> highlighting of errors, like name constraint violations, to draw the
> attention of log monitors?  An indication could probably be represented as
> a CTExtension.
>

Seems to me that it would be better to share the rules for checking such
things (ideally as open source software) than to have people rely on third
parties to correctly flag...


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

--089e0158b67cb0772d04fd9b19b9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On 5 July 2014 19:34, Carl Wallace <carl@redhoundsoftware.=
com> wrote:


From: =C2=A0Stephen Kent <kent@bbn.com>

Date: =C2=A0Saturday, July 5, 2014 at 8:50 AM

To: =C2=A0Ben Laurie <benl@google.com=
>

Cc: =C2=A0"trans@ietf.org" =
<trans@ietf.org>

Subject: =C2=A0Re: [Trans] Using a Precertificate Signing Certificate to si=
gn

TBScertificates for CT



>


> =C2=A0 =C2=A0 =C2=A0On 1 July 2014 18:34, Stephen Kent=
 <kent@bbn.com>


><mailto:kent@b=
bn.com> wrote:

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

>

>As you point out, the log can relax validation rules, which deals with<=
br>
>this problem (and we do, indeed, do that in our implementation).

>

>

>

> =C2=A0 =C2=A0 =C2=A0 =C2=A0My comments noted that relaxing rules in an=
 unspecified fashion

>creates

>potential

>problems for those submitting pre-certs. The specific changes needed to=


>enable

>acceptance oif pre-certs need to be spelled out.

>

>

>

> =C2=A0 =C2=A0 =C2=A0Hmm. What we do is check the signatures validate a=
ll the way up the

>chain. That's it. I'm not sure we need anything tighter than th=
at, so

>I guess we could specify that?

>

>

> =C2=A0 =C2=A0Ok, that's what you do, but 5280 describes a long lis=
t of

> =C2=A0 =C2=A0cert path validation rules

> =C2=A0 =C2=A0and your doc just says that these can be relaxed. It does=
 not

> =C2=A0 =C2=A0prohibit a log from

> =C2=A0 =C2=A0performing =C2=A0the full set dictated by PKIX and X.509 =
path validation

> =C2=A0 =C2=A0procedures, nor

> =C2=A0 =C2=A0does it provide guidance of which subset SHOULD/MUST be p=
erformed.

> =C2=A0 =C2=A0Absent such guidance

> =C2=A0 =C2=A0different log operators can legitimately perform differen=
t checks,

> =C2=A0 =C2=A0resulting in chaos.

>




Seems easy enough to specify and justify the relaxed rules (signature=


checking only) for this application but is it worth supporting the

highlighting of errors, like name constraint violations, to draw the

attention of log monitors? =C2=A0An indication could probably be represente=
d as

a CTExtension.

Seems to me that it woul=
d be better to share the rules for checking such things (ideally as open so=
urce software) than to have people rely on third parties to correctly flag.=
..


=C2=A0






_______________________________________________

Trans mailing list

Trans@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/trans





--089e0158b67cb0772d04fd9b19b9--


From douglas.beattie@globalsign.com  Mon Jul  7 08:57:15 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC9E1A02FE for ; Mon,  7 Jul 2014 08:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 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] 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 nrUG_yFHItWz for ; Mon,  7 Jul 2014 08:57:13 -0700 (PDT)
Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8091A0166 for ; Mon,  7 Jul 2014 08:57:13 -0700 (PDT)
Received: by mail-ve0-f181.google.com with SMTP id db11so4182387veb.26 for ; Mon, 07 Jul 2014 08:57:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalsign.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k4KZJzQx/uNGHFjv2nQSdCn3bLLuUrJuv8S4KJ7hAqE=; b=CadE4rheS89mT69ufI481UHT8YlpTE+uGFm79pHvUrLCsG2JHBEqUufhAxlQ5lljt3 QGYwbKbfJFkOSmDwW7X3SS33KZGDMHAv+JtdZdLtpdJNfEJvAfDUOxZIACD46Lx8HVhF umXmDWKw98EbOaSGPqIpPVBIFaoALV5Ppx4x4=
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=k4KZJzQx/uNGHFjv2nQSdCn3bLLuUrJuv8S4KJ7hAqE=; b=KpYRoh3Q4SuAhUlgjQtXD/UmS3saWkt1adIi8tCDFAd8DlgMb0DKQbCaXO+j2lT53P Si3UnkwtA0sLwKNcVCe3RRBVA6PcXps7+iQqjroCM0obDMk9YtmubQ8Binc6ENO9OMw4 vNdb7rEkXQ7uVgUT9fc1BV19uOZs17GU7hTK/bGLfyqXpNjnmuPBHj6sjQjVJ3Q08tzt T33IUXcxywkpmSRxRed3Xz9TiN3VOW14DY+iC2YPPSyEwIABkGEWIHvBhBT+4bxNOkgS b6g/458NyLoRu7wN7+UUNFAd8b14+/mm8mXAE8JLA3ErIMCvHicVBjasjPYOwf/bOSmw UGsQ==
X-Gm-Message-State: ALoCoQlPATGnV/9WZrEOnrX27N/G9FYRwJoe/UOhdCjgJSN30CiPGU0uNU75gAvwqV2s7I0YALGT
MIME-Version: 1.0
X-Received: by 10.220.73.137 with SMTP id q9mr1113751vcj.64.1404748632844; Mon, 07 Jul 2014 08:57:12 -0700 (PDT)
Received: by 10.220.113.9 with HTTP; Mon, 7 Jul 2014 08:57:12 -0700 (PDT)
In-Reply-To: 
References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com>  <53B2F131.6030606@bbn.com>  <53B7F4B0.7060306@bbn.com>  
Date: Mon, 7 Jul 2014 11:57:12 -0400
Message-ID: 
From: Doug Beattie 
To: Ben Laurie 
Content-Type: multipart/alternative; boundary=001a11c2ab4e42836504fd9c8788
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/QsOr9-5_0Nvw_SAQKC0tmNTzows
Cc: "trans@ietf.org" , Carl Wallace 
Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT
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, 07 Jul 2014 16:01:37 -0000

--001a11c2ab4e42836504fd9c8788
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 7, 2014 at 10:14 AM, Ben Laurie  wrote:

>
>
>
> On 5 July 2014 19:34, Carl Wallace  wrote:
>
>> From:  Stephen Kent 
>> Date:  Saturday, July 5, 2014 at 8:50 AM
>> To:  Ben Laurie 
>> Cc:  "trans@ietf.org" 
>> Subject:  Re: [Trans] Using a Precertificate Signing Certificate to sign
>> TBScertificates for CT
>>
>> >
>> >      On 1 July 2014 18:34, Stephen Kent 
>> > wrote:
>> >          ...
>> >
>> >As you point out, the log can relax validation rules, which deals with
>> >this problem (and we do, indeed, do that in our implementation).
>> >
>> >
>> >
>> >        My comments noted that relaxing rules in an unspecified fashion
>> >creates
>> >potential
>> >problems for those submitting pre-certs. The specific changes needed to
>> >enable
>> >acceptance oif pre-certs need to be spelled out.
>> >
>> >
>> >
>> >      Hmm. What we do is check the signatures validate all the way up t=
he
>> >chain. That's it. I'm not sure we need anything tighter than that, so
>> >I guess we could specify that?
>> >
>> >
>> >    Ok, that's what you do, but 5280 describes a long list of
>> >    cert path validation rules
>> >    and your doc just says that these can be relaxed. It does not
>> >    prohibit a log from
>> >    performing  the full set dictated by PKIX and X.509 path validation
>> >    procedures, nor
>> >    does it provide guidance of which subset SHOULD/MUST be performed.
>> >    Absent such guidance
>> >    different log operators can legitimately perform different checks,
>> >    resulting in chaos.
>> >
>>
>> Seems easy enough to specify and justify the relaxed rules (signature
>> checking only) for this application but is it worth supporting the
>> highlighting of errors, like name constraint violations, to draw the
>> attention of log monitors?  An indication could probably be represented =
as
>> a CTExtension.
>>
>
> Seems to me that it would be better to share the rules for checking such
> things (ideally as open source software) than to have people rely on thir=
d
> parties to correctly flag...
>

I=E2=80=99m not connecting the logic from the last couple of emails.  We kn=
ow that
path validation *cannot* follow PKIX and path validation procedures
 because when a Pre-certificate signing certificate is used the Issuer DN,
AIA and Auth Key ID will *all* not correctly point to the pre-certificate.


We need to change =E2=80=9Cmay=E2=80=9D to =E2=80=9Cmust=E2=80=9D in this p=
arenthetical note in 3.1:

   =E2=80=9C(note that the log may relax standard validation rules to allow=
 this,
so long as the issued certificate will be valid),=E2=80=9D

and we need to specify exactly which rules can be relaxed.


The use of pre-signing certificates is a good thing from a security
perspective.  It lets you off-load the external communications from you CA
and you can locate this in a different security zone in your infrastructure
with different security requirements.  Specifying how log operators handle
these chains is essential or the ability to obtain SCTs will vary from one
log operator to another.


>
>>
>>
>> _______________________________________________
>> 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
>
>

--001a11c2ab4e42836504fd9c8788
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Mon, Jul 7, 2014 at 10:14 AM, Ben Laurie <<=
a href=3D"mailto:benl@google.com" target=3D"_blank">benl@google.com>=
 wrote:







On 5 July 2014 19:34, Carl Wallace <carl@re=
dhoundsoftware.com> wrote:


From: =C2=A0Stephen Kent <kent@bbn.com>


Date: =C2=A0Saturday, July 5, 2014 at 8:50 AM

To: =C2=A0Ben Laurie <benl@google.com>

Cc: =C2=A0"trans@i=
etf.org" <t=
rans@ietf.org>

Subject: =C2=A0Re: [Trans] Using a Precertificate Signing Certificate to si=
gn

TBScertificates for CT



>


> =C2=A0 =C2=A0 =C2=A0On 1 July 2014 18:34, Stephen Kent <kent@bbn.com>


><mailto:kent@bbn.com> wrote:

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

>

>As you point out, the log can relax validation rules, which deals with<=
br>
>this problem (and we do, indeed, do that in our implementation).

>

>

>

> =C2=A0 =C2=A0 =C2=A0 =C2=A0My comments noted that relaxing rules in an=
 unspecified fashion

>creates

>potential

>problems for those submitting pre-certs. The specific changes needed to=


>enable

>acceptance oif pre-certs need to be spelled out.

>

>

>

> =C2=A0 =C2=A0 =C2=A0Hmm. What we do is check the signatures validate a=
ll the way up the

>chain. That's it. I'm not sure we need anything tighter than th=
at, so

>I guess we could specify that?

>

>

> =C2=A0 =C2=A0Ok, that's what you do, but 5280 describes a long lis=
t of

> =C2=A0 =C2=A0cert path validation rules

> =C2=A0 =C2=A0and your doc just says that these can be relaxed. It does=
 not

> =C2=A0 =C2=A0prohibit a log from

> =C2=A0 =C2=A0performing =C2=A0the full set dictated by PKIX and X.509 =
path validation

> =C2=A0 =C2=A0procedures, nor

> =C2=A0 =C2=A0does it provide guidance of which subset SHOULD/MUST be p=
erformed.

> =C2=A0 =C2=A0Absent such guidance

> =C2=A0 =C2=A0different log operators can legitimately perform differen=
t checks,

> =C2=A0 =C2=A0resulting in chaos.

>




Seems easy enough to specify and justify the relaxed rules (signature=


checking only) for this application but is it worth supporting the

highlighting of errors, like name constraint violations, to draw the

attention of log monitors? =C2=A0An indication could probably be represente=
d as

a CTExtension.

Seems to me =
that it would be better to share the rules for checking such things (ideall=
y as open source software) than to have people rely on third parties to cor=
rectly flag...



I=E2=
=80=99m not connecting the logic from the last couple of
emails.=C2=A0 We know that path validation *cannot* follow PKIX and path va=
lidation procedures =C2=A0because when a Pre-certificate signing certificat=
e
is used the Issuer DN, AIA and Auth Key ID will *all* not correctly point t=
o the
pre-certificate.=C2=A0=C2=A0

We need to change =E2=80=9Cmay=E2=80=9D
to =E2=80=9Cmust=E2=80=9D in this parenthetical note in 3.1:=C2=A0=C2=A0
=C2=A0 =C2=A0=E2=80=9C(note that the log may relax =
standard validation rules to allow this,
so long as the issued certificate will be valid),=E2=80=9D=C2=A0
and we need to specify exactly
which rules can be relaxed.




The use of pre-signing certificates is a go=
od thing from a security
perspective.=C2=A0 It lets you off-load the
external communications from you CA and you can locate this in a different
security zone in your infrastructure with different security requirements.=
=C2=A0 Specifying how log operators handle these
chains is essential or the ability to obtain SCTs will vary from one log
operator to another.=C2=A0





=C2=A0






_______________________________________________

Trans mailing list

Trans@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/trans





_______________________________________________

Trans mailing list

Trans@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/trans





--001a11c2ab4e42836504fd9c8788--


From nobody Mon Jul  7 09:20:06 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597AB1A0371 for ; Mon,  7 Jul 2014 09:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level: 
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 7n_-jdYdIBV6 for ; Mon,  7 Jul 2014 09:19:49 -0700 (PDT)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DAE1A037A for ; Mon,  7 Jul 2014 09:19:49 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id x13so3915595qcv.5 for ; Mon, 07 Jul 2014 09: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=v32/xwz3owkJbFbKNRoRWTg+Nsrny7Tu+QdrwYU1JMg=; b=bMYl0bj4do3lAZxXaKyosq6HHGxmsNimhpI+e1zq8KncUX51vILV+1Bs//tOTVyk2l IBKzhGyNsMypYvcZyQURnXzsYWwlaZTaH0warFkFq1OZ2cTHIp3pECTv6PXfGxLFEvqJ KdmBrLsK44CDW9vAFpQVLbIWCgU8EcWx+Rd34g56zqrQwLbWmzx92SSxKdNfbv1oc8oE i5jLb8m8Wqj+Mf386hvcAnZQEsXbMqf8e0fw29mDClL3yd9mHApssS75vAUo5+cI5WzU Nkq7GucLVUYicv1S+AtAl1BR4IHp0nrJdPZK4A2m3KJFsKJnPE9Zg6sczm7zFqwvURIt AFtQ==
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=v32/xwz3owkJbFbKNRoRWTg+Nsrny7Tu+QdrwYU1JMg=; b=Up+pFYlJ1VpFwfZEArG1nw+Rf5L8N9v3roHe5KVJGffT521tHGX+2ZlrsFl/mg7Got I99H7PebITWBNgQyx2CqtscVW5AcaJqMpPXL7SFY5qLDWEYdkS/blpR7yZmhCqsTYEv+ DwXddstXmSq5zFdZLbUxvfWciD5Uvi/ryCFsUk2/Be4Z+iQj4kSlP8dMsEZyQw84wy8G gHL2QCbStUKVBp1Jn3G+BQgm8StNyRvFKzVzrlwIYUtUe++SFg9Wf+6FVl/TZRpl6h6w 5QgDMUTpNb+teUp+lvLrBMqTwbQaEHOBpdVywMo2eOdSHoK/57AV/+zCsWSlDbount4X lA5Q==
X-Gm-Message-State: ALoCoQkRVyyYAnDqjsm7UV9FfeBjJmm3gP9HHcEK7Y4Fd5aIJ78v/aigsHqjbohaWbm3JthRcmu1
MIME-Version: 1.0
X-Received: by 10.224.61.1 with SMTP id r1mr49167147qah.95.1404749988568; Mon, 07 Jul 2014 09:19:48 -0700 (PDT)
Received: by 10.229.100.72 with HTTP; Mon, 7 Jul 2014 09:19:48 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 7 Jul 2014 17:19:48 +0100
Message-ID: 
From: Ben Laurie 
To: Nico Williams 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Qxv2jx8TToK9zSp7EfGRi0zlVOU
Cc: Melinda Shore , "trans@ietf.org" , Dmitry Belyavsky 
Subject: Re: [Trans] Log checking should be asynchronous (Re: Volunteer opportunity! (was Re: DNSSEC also needs CT))
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, 07 Jul 2014 16:19:58 -0000

On 2 June 2014 17:57, Nico Williams  wrote:
> On Tue, May 13, 2014 at 3:41 AM, Dmitry Belyavsky  wrote:
>> Here are my ideas about "strict" behaviour of the TLS client:
>>
>> [...]
>
> IMO log checking should be mostly asynchronous.  This means that CT
> couldn't detect MITMing CAs in real-time, but that's OK because CT is
> about CA reputation, and all we care about is that when we detect
> lying CAs we can report them.
>
> This means that clients mostly should only reject TLS connections when
> there's no evidence of server certs being logged in an acceptable log.
>
> It also means we need some mechanism for reporting lying CAs.  Thus
> far reporting via blogs, news outlets, and trust anchor set managers,
> has been good enough, and I'm not sure that we need anything more than
> any async notification to users (and upstreams) by browsers (and other
> clients).
>
> There are privacy protection considerations in reporting lying CAs:
> report the name about which they lied, just the log entry(ies) that
> are missing, or just an assertion that they lied?
>
> Again, as I see it CT is purely a reputation-based system.  Reputation
> is established (and blemished/destroyed) asynchronously.

Just to be clear here - logs do not provide reputation. They provide a
mechanism by which others can establish reputation. I hope we agree on
this important point!

>
> This is important: we cannot be adding too much latency to TLS.  By
> doing log checking asynchronously we won't be.

Right.


From nobody Mon Jul  7 09:28:02 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE021A0389 for ; Mon,  7 Jul 2014 09:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level: 
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 QyfIFvLgQGg1 for ; Mon,  7 Jul 2014 09:27:57 -0700 (PDT)
Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105F41A0386 for ; Mon,  7 Jul 2014 09:27:56 -0700 (PDT)
Received: by mail-qc0-f180.google.com with SMTP id r5so4058602qcx.11 for ; Mon, 07 Jul 2014 09:27:56 -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=kE+SKN9ohCVsUB6HTW6Tl2CI+Ar7D2eojAtV4c1uo4E=; b=K/q4Qs4UoEOtZy4UO+ptV7jMEDma9jM/1Jss/Z/xyQ/gFJuhoNBrj/ifOgOfNNbVyS BPBrI13lyi1l775MTa9FCxMmcQg1DQohOSDgMGlmqebbK460S34+W7yLkHU8Gq6EpEbP U+I2l49sr2AB9lY6HJyGSDomSiBcPnUvDSkMasKn4mTKISua1bYtrhssj6lOhFl7mYbq xq0S8qDi/vrLhPuiQE8u4q7otZ3U6D94soVwIGLJGeQm4uk5wI9wdFoMSe2OQSo2seZK pHuODYoBK1u7cdxHsDIkPElUqbfhV0bRZK5Kj5CE+u/xi7sip0/YklkU4Z5VmiMdsL4x 5amg==
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=kE+SKN9ohCVsUB6HTW6Tl2CI+Ar7D2eojAtV4c1uo4E=; b=RpxGvRO3OzRrMgl3mOpD4LTsNjYBg71B//PVCrAtXMzIS4iSzKdxnBF1+WtlsHG9Vm F3p9u7mldLAx9WV0bsDJNLix5upuYJgXr387+tF4SBTXi3rbiOSeJalAJS96jqTo/P0+ pmWtABLK8Bbyds2eIyM/j0w1ezv/gUmo1aOBPXs8nySI/v3C4Q13g9Y4oWer2DU1tEWP FTx9o5hsUazaRhu63JDC8spxKBbhcD7blzsNW5BiDAP8dUqT041W1W3bE8cbMpznpdHo UsZXY7gD7H+c6d3OiHqvC9KZhhtkAH11nse5wsDk+T/g2d3OacI7VVlDYnng04rDw4DG UGDQ==
X-Gm-Message-State: ALoCoQnDG9ZM7zddjCDw4sbdu4/44e1ZCanPjiGKpekW9ZXdX1W2vCsTW8/dYZVC97UsMIxI+cc2
MIME-Version: 1.0
X-Received: by 10.140.105.163 with SMTP id c32mr47128225qgf.85.1404750476275;  Mon, 07 Jul 2014 09:27:56 -0700 (PDT)
Received: by 10.229.100.72 with HTTP; Mon, 7 Jul 2014 09:27:56 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 7 Jul 2014 17:27:56 +0100
Message-ID: 
From: Ben Laurie 
To: Erwann Abalea 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/A2oY8L-CT3FUXLfWV_of5wh461M
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Relaxed X.509 validation rules
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, 07 Jul 2014 16:27:58 -0000

On 2 June 2014 17:08, Erwann Abalea  wrote:
> Bonjour,
>
> For security reasons, our online CAs have a critical BC extension with
> pathLenConstraint set to 0.
> For security+compliance reasons (RFC5280/X.509), our CA system doesn't allow
> for duplicate serial numbers under a CA, so we're going to issue a
> "Precertificate Signing Certificate" under our different issuing CAs for
> precertificate generation.
>
> Of course, a compliant X.509 third party MUST fail to validate the
> precertificate (because of the pathLenConstraint=0 issuing something that
> acts as a CA without being declared as is).

It must also fail to validate because of the critical poison extension.

> How will this case be handled by log servers? RFC6962 in section 3.1 states
> that "the log may relax standard validation rules to allow this, so long as
> the issued certificate will be valid", without any detail on relaxed rules.
>
> Will it be mandatory to re-issue pathLenConstraint=1 CA certificates and
> relax our security rules?

No. We have a ticket open to make it clearer what "relaxed validation"
looks like, but certainly we recognise that we should not enforce path
length constraints. As I mentioned earlier, validation is mostly an
anti-spam measure, so I don't think its smart to lock down too exactly
what rules should and should not be applied, but it is nice to hear
about specific exceptions that clearly have to be made.


From nobody Tue Jul  8 08:55:06 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4C21B2B3F for ; Tue,  8 Jul 2014 08:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level: 
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 hmFA46SWGLDl for ; Tue,  8 Jul 2014 08:54:56 -0700 (PDT)
Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81BC41B2B5B for ; Tue,  8 Jul 2014 08:54:35 -0700 (PDT)
Received: by mail-qc0-f170.google.com with SMTP id l6so5521388qcy.29 for ; Tue, 08 Jul 2014 08:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gaCg0u+0L2YFUsSDatuidsygaqLa8MaDW+ebnUrENO0=; b=JR+fcw4CC2Z6hb//Jq3ImBi1cwBSnkqdDIW4lzKYqXrGhonDH857p34tgmsJBWafI4 C1hw8JHv1u3Y0HG8ICngqI5w/E7hTY9n9j3HFQGNM+bSAh1Ho4UiYk/mWf83ipIwoT2R MxHUIiUASjoLFhvqqa87bpEHlfI5+6N4YgbeXYpDYmmjbpZ8x1aQZ//B6xOJqpkb8JAQ xpAyJUG/Hkfzd/zNv5uv7vO3qozadojpdV3rM48VgiiGCeOR009uJ1GsOS1eDJ7EhVl1 haedJUJpYFOeZnjlK5JjanyqiPPH4CTL4m3MhQR3EaDKv/BvL7HJUDJnopH96g4lNO2n UCKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gaCg0u+0L2YFUsSDatuidsygaqLa8MaDW+ebnUrENO0=; b=QaEc+qeT/qCNbl+Kw0iCNXiMIr6975JhP01ED4DrATgC8VrGTzZgIzf/Mbhh9AmjHw Ath39dro7sIfwQ6dHQAMj+hmf52SCfAosRTVR8cQonySPPVVfA+4qHgoNNCRVElKshpa 1AUfDfs+a0b+/d3cHijnuXklqOAv7/YRf64Vu/t5lvO6NTZDVv+YPGT7F6Naye/99SOD ft470U95OcWMbEXQu/Va1/4WHnwEG1BBQ6B4Jky2/EOgGyrYVBTq/CMNK/ocfNuSWZXa MmSdtcvV7KvV9zrc4YOG/oSi93WFuMASj7ylXIs8UP32Xr3X5Gs98FiYJdlGM+RkXtzs MMug==
X-Gm-Message-State: ALoCoQltfVOOT5qBnDpdwhdlIA/RqqJfNhWjLcxSsx61YVPcoue9Tcb7svmdLkIpBYzmhCufiFYL
MIME-Version: 1.0
X-Received: by 10.140.43.118 with SMTP id d109mr56636179qga.10.1404834874712;  Tue, 08 Jul 2014 08:54:34 -0700 (PDT)
Received: by 10.229.100.72 with HTTP; Tue, 8 Jul 2014 08:54:34 -0700 (PDT)
In-Reply-To: 
References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com>  <53B2F131.6030606@bbn.com>  <53B7F4B0.7060306@bbn.com>   
Date: Tue, 8 Jul 2014 16:54:34 +0100
Message-ID: 
From: Ben Laurie 
To: Doug Beattie 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/rLg7kPOJhWzGB64DikevDYJVHGI
Cc: "trans@ietf.org" , Carl Wallace 
Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT
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, 08 Jul 2014 15:55:01 -0000

On 7 July 2014 16:57, Doug Beattie  wrote:
>
>
>
> On Mon, Jul 7, 2014 at 10:14 AM, Ben Laurie  wrote:
>>
>>
>>
>>
>> On 5 July 2014 19:34, Carl Wallace  wrote:
>>>
>>> From:  Stephen Kent 
>>> Date:  Saturday, July 5, 2014 at 8:50 AM
>>> To:  Ben Laurie 
>>> Cc:  "trans@ietf.org" 
>>> Subject:  Re: [Trans] Using a Precertificate Signing Certificate to sig=
n
>>> TBScertificates for CT
>>>
>>> >
>>> >      On 1 July 2014 18:34, Stephen Kent 
>>> > wrote:
>>> >          ...
>>> >
>>> >As you point out, the log can relax validation rules, which deals with
>>> >this problem (and we do, indeed, do that in our implementation).
>>> >
>>> >
>>> >
>>> >        My comments noted that relaxing rules in an unspecified fashio=
n
>>> >creates
>>> >potential
>>> >problems for those submitting pre-certs. The specific changes needed t=
o
>>> >enable
>>> >acceptance oif pre-certs need to be spelled out.
>>> >
>>> >
>>> >
>>> >      Hmm. What we do is check the signatures validate all the way up
>>> > the
>>> >chain. That's it. I'm not sure we need anything tighter than that, so
>>> >I guess we could specify that?
>>> >
>>> >
>>> >    Ok, that's what you do, but 5280 describes a long list of
>>> >    cert path validation rules
>>> >    and your doc just says that these can be relaxed. It does not
>>> >    prohibit a log from
>>> >    performing  the full set dictated by PKIX and X.509 path validatio=
n
>>> >    procedures, nor
>>> >    does it provide guidance of which subset SHOULD/MUST be performed.
>>> >    Absent such guidance
>>> >    different log operators can legitimately perform different checks,
>>> >    resulting in chaos.
>>> >
>>>
>>> Seems easy enough to specify and justify the relaxed rules (signature
>>> checking only) for this application but is it worth supporting the
>>> highlighting of errors, like name constraint violations, to draw the
>>> attention of log monitors?  An indication could probably be represented
>>> as
>>> a CTExtension.
>>
>>
>> Seems to me that it would be better to share the rules for checking such
>> things (ideally as open source software) than to have people rely on thi=
rd
>> parties to correctly flag...
>
>
> I=E2=80=99m not connecting the logic from the last couple of emails.  We =
know that
> path validation *cannot* follow PKIX and path validation procedures  beca=
use
> when a Pre-certificate signing certificate is used the Issuer DN, AIA and
> Auth Key ID will *all* not correctly point to the pre-certificate.
>
>
> We need to change =E2=80=9Cmay=E2=80=9D to =E2=80=9Cmust=E2=80=9D in this=
 parenthetical note in 3.1:
>
>    =E2=80=9C(note that the log may relax standard validation rules to all=
ow this, so
> long as the issued certificate will be valid),=E2=80=9D
>
> and we need to specify exactly which rules can be relaxed.

As I've said, any rules can be relaxed - inclusion in the log says
nothing about the validity of certificates. Clearly there are some
rules that MUST be relaxed, and I guess we can attempt to enumerate
them.

> The use of pre-signing certificates is a good thing from a security
> perspective.  It lets you off-load the external communications from you C=
A
> and you can locate this in a different security zone in your infrastructu=
re
> with different security requirements.  Specifying how log operators handl=
e
> these chains is essential or the ability to obtain SCTs will vary from on=
e
> log operator to another.

I don't think we can make that impossible - for example, what is the
definitive set of CAs that all logs should accept?

>
>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Tue Jul  8 09:07:11 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957E91B2B73 for ; Tue,  8 Jul 2014 09:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4twNVsfm8Vm1 for ; Tue,  8 Jul 2014 09:07:07 -0700 (PDT)
Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9501B2B6F for ; Tue,  8 Jul 2014 09:07:07 -0700 (PDT)
Received: by mail-qg0-f46.google.com with SMTP id q107so5007803qgd.19 for ; Tue, 08 Jul 2014 09:07:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type; bh=jsIvIuTVF+H/95+SobP5Z1/W9s3nyaw4CyPjtuIhwGI=; b=YXXJu+J3GEjkNYX0wlWjLOTYHoEF+TzJbmHDG1ih68EVjQwDktxTY6vzocnkXOoS38 9cnF+flNJ/NQ96dbqVBCdn0wOmiHVdy9wwgVHCHbhvADm/nfl0YEcwwqzeOJZL8ynbly WDWe9yJ+DWSLEcOzWnkmsATHcWeY7YOe8/vfxcMfnFXlDlipJ6tHYApiOKfFpBURTq7e 9hsT0N/kgKq9ElYgRJVBybdP/iRkbJFIY0mla4a7ww8KUiwUtJvhL4r/uUB7NExUkjp4 k3lukJpoPgMNW6gHuyKGm7fNyR+TIWldWquxyX4TOHRgH1umTknKgE7qu6w/NdGNhF3a kjFg==
X-Gm-Message-State: ALoCoQlXXhzu+iG1WbmMmyJXtD7rWuxrSWiH5/NK1nIijooKadjCp4MRf7p63mShOwOs1K9oeI4W
X-Received: by 10.140.98.195 with SMTP id o61mr46899295qge.41.1404835626307; Tue, 08 Jul 2014 09:07:06 -0700 (PDT)
Received: from [192.168.2.4] (pool-173-79-132-199.washdc.fios.verizon.net. [173.79.132.199]) by mx.google.com with ESMTPSA id l5sm2704946qaz.33.2014.07.08.09.07.04 for  (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 08 Jul 2014 09:07:05 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.4.2.140509
Date: Tue, 08 Jul 2014 12:07:02 -0400
From: Carl Wallace 
To: Ben Laurie 
Message-ID: 
Thread-Topic: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT
References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com>  <53B2F131.6030606@bbn.com>  <53B7F4B0.7060306@bbn.com>  
In-Reply-To: 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3487666025_6736349"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/GY_3OflFzZHmkiDsDo7VnG9nKro
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT
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, 08 Jul 2014 16:07:09 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3487666025_6736349
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit



From:  Ben Laurie 
Date:  Monday, July 7, 2014 at 10:14 AM
To:  Carl Wallace 
Cc:  "trans@ietf.org" 
Subject:  Re: [Trans] Using a Precertificate Signing Certificate to sign
TBScertificates for CT

>     Ok, that's what you do, but 5280 describes a long list of
>>> >    cert path validation rules
>>> >    and your doc just says that these can be relaxed. It does not
>>> >    prohibit a log from
>>> >    performing  the full set dictated by PKIX and X.509 path validation
>>> >    procedures, nor
>>> >    does it provide guidance of which subset SHOULD/MUST be performed.
>>> >    Absent such guidance
>>> >    different log operators can legitimately perform different checks,
>>> >    resulting in chaos.
>>> >
>> 
>> Seems easy enough to specify and justify the relaxed rules (signature
>> checking only) for this application but is it worth supporting the
>> highlighting of errors, like name constraint violations, to draw the
>> attention of log monitors?  An indication could probably be represented as
>> a CTExtension.
> 
> Seems to me that it would be better to share the rules for checking such
> things (ideally as open source software) than to have people rely on third
> parties to correctly flag...

I was not suggesting that the log be relied upon to do the check.  The point
was the log is in a position to observe when things have gone wrong across a
broad range of certs and highlighting these instances as a courtesy may be
worth doing.    Monitoring for names is probably sufficient to capture name
constraints violations of interest to a given monitor but drawing attention
to violations may cast some doubt on a CA's operations in general.



--B_3487666025_6736349
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable




From:  Ben Laurie <benl@google.com>
Date:  Monday, July 7, 2014 at 10:14 AM
To:=
  Carl Wallace <carl@re=
dhoundsoftware.com>
Cc:  "trans@ietf.org" <trans@ietf.org>
Subject: =
 Re: [Trans] Using a Precertificate Signing Certificate to sign TBSce=
rtificates for CT

<snip>    Ok, that's what you do=
, but 5280 describes a long list of

>    cert path validation rules

>    and your doc just says that these can be relaxed. It does=
 not

>    prohibit a log from

>    performing  the full set dictated by PKIX and X.509 =
path validation

>    procedures, nor

>    does it provide guidance of which subset SHOULD/MUST be p=
erformed.

>    Absent such guidance

>    different log operators can legitimately perform differen=
t checks,

>    resulting in chaos.

>

Seems easy enough to specify and justify the relaxed rule=
s (signature

checking only) for this application but is it worth supporting the

highlighting of errors, like name constraint violations, to draw the

attention of log monitors?  An indication could probably be represente=
d as

a CTExtension.

Seems to me that it woul=
d be better to share the rules for checking such things (ideally as open sou=
rce software) than to have people rely on third parties to correctly flag...=


I was not su=
ggesting that the log be relied upon to do the check.  The point was th=
e log is in a position to observe when things have gone wrong across a broad=
 range of certs and highlighting these instances as a courtesy may be worth =
doing.    Monitoring for names is probably sufficient to capture n=
ame constraints violations of interest to a given monitor but drawing attent=
ion to violations may cast some doubt on a CA's operations in general.  =
;


--B_3487666025_6736349--



From nobody Tue Jul  8 19:16:33 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90EF1A0299 for ; Tue,  8 Jul 2014 19:16:31 -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 Cu2jHKdLtx84 for ; Tue,  8 Jul 2014 19:16:30 -0700 (PDT)
Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2281A02A0 for ; Tue,  8 Jul 2014 19:16:30 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id ft15so8064066pdb.7 for ; Tue, 08 Jul 2014 19:16:30 -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=LMGy6T0dh7Jfxl2m7SET7jfIsSEEpYvgdUO56IMTyoE=; b=R2r/jsqbGTLT9bpEYuyqjsOiwfhorFjoOUlPBXilre3Nf30h5Q/cM4SCKAtQyFFgHx tKbFMMLtrPHt/XEqDlti+rJpPmEOIlWnrZ0y6BaoUN0kDXj49zPamBEdIRdFJeX7WHAW A+2ckhM4JjQiH8LAZyVt2JioaapQttcZd1vC2GI8juAc2At96e3+XqdFwz+0bHiW3cWj s7w3SEwT5BjLI+8w3IChS7DUg/zuLY84DQ93RBWq43gSx4y/whKritkDO1zE325I/iQf tvo35rq+XGopHtBe+hmYui51gRhHcE3bfl3fTrQvicmYPhcemRW7Lc9bi6PR1m6R5ezZ ZyNA==
X-Received: by 10.68.241.68 with SMTP id wg4mr31540369pbc.66.1404872189524; Tue, 08 Jul 2014 19:16:29 -0700 (PDT)
Received: from spandex.local (66-230-109-132-rb1.nwc.dsl.dynamic.acsalaska.net. [66.230.109.132]) by mx.google.com with ESMTPSA id zc10sm209698997pac.46.2014.07.08.19.16.28 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 19:16:28 -0700 (PDT)
Message-ID: <53BCA5FA.2080509@gmail.com>
Date: Tue, 08 Jul 2014 18:16:26 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Ben Laurie 
References: <53B5B366.7010407@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/H4o9apDyEWiogovsQCzf8l5IZ4g
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Walking through the issue tracker: Ticket #4
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, 09 Jul 2014 02:16:32 -0000

On 7/4/14 4:13 AM, Ben Laurie wrote:
> Given that there's a certain amount of angst about precertificates and
> PKI rules, it could be that we really want to sign some other
> structure altogether, at least for precertificates.

Is there a proposal for that that's ready for discussion?

Melinda



From nobody Tue Jul  8 19:22:03 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43431A0270 for ; Tue,  8 Jul 2014 19:21: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 vWNSzm9MG3Dz for ; Tue,  8 Jul 2014 19:21:57 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C96D1A0298 for ; Tue,  8 Jul 2014 19:21:53 -0700 (PDT)
Received: by mail-pa0-f53.google.com with SMTP id ey11so8311196pad.40 for ; Tue, 08 Jul 2014 19:21:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=MgFBqPLaqfs6rbIF7RryObNr6p6Sq4YVPFEvt27A4q8=; b=Tp7ILAEKwFg5mCkOq85zwrEGuvoNWj2xHpYPcao0s2GSfkiHsqIAAKVpJ45lSZEYTe L4q7Ft0YuuHfaFRCSH5DMLUboHRK6YT4uyIl8T+zHQg9h8jvakPTKrRc7RISqw5hM2Iw K8xu+RseF62cNT5foef2E+ZMW9UxyxmN2aYbi4mUHmBJ0b1R8Am2DPAXlDpZoKYL3PH3 8Lt/m+azRt0rdJPJlpTyhXGjcbwFmyVyxlaHtNd+ZNDS7hkMQjpu/5URB2fToAN7+6iq QUpaTKWwofU5OtmR97rfMnH3boGvh6o76nu3TAES7fMY5khIGy0E7i5SLlO2xUazk2RB dqzg==
X-Received: by 10.66.251.233 with SMTP id zn9mr39140632pac.67.1404872513244; Tue, 08 Jul 2014 19:21:53 -0700 (PDT)
Received: from spandex.local (66-230-109-132-rb1.nwc.dsl.dynamic.acsalaska.net. [66.230.109.132]) by mx.google.com with ESMTPSA id ak1sm57141933pbc.58.2014.07.08.19.21.51 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 19:21:52 -0700 (PDT)
Message-ID: <53BCA73E.80102@gmail.com>
Date: Tue, 08 Jul 2014 18:21:50 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "trans@ietf.org" ,  Rob Stradling 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/rwBQOtC73LK1V55Zaw99mE2qOCc
Cc: Paul Wouters 
Subject: [Trans] Walking through the issue tracker: Ticket #10
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, 09 Jul 2014 02:21:59 -0000

I see that Rob's taken ownership of this one (on precertificate
SCTs and OCSP) - it looks like there was agreement about how
to handle it, but is there text?

Thanks,

Melinda


From nobody Wed Jul  9 09:49:55 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F611A001C for ; Wed,  9 Jul 2014 09:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level: 
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 ytcy61hBO-qg for ; Wed,  9 Jul 2014 09:49:50 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC441A009E for ; Wed,  9 Jul 2014 09:49:50 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id ik5so7350615vcb.21 for ; Wed, 09 Jul 2014 09:49:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5rPp89DhZJQ34bjhRJ2MQ7yJkHmR0xrzBAjEXrO0va4=; b=V+S/gqPSJNDu8JdljQXrviXi85IOOPN7zvdx7TqDKGyzCZ6bGwHfkFiINRqfA8Jx71 01ccAr8w2MD2wdnNDw7qCVN0t1ebCduyuapwqOlfVMOqKJqcMAup9neJ8CnWzuEUcTIe i4wxe2T1x+H4XLjogD8iJzvVi9ebZtNhiEF62BtQWJqWpWEHudOb9fcawAfBPxK54JOu 1OCjqLbS4wgjZx19Obr3CBI87Gds+4zYLQ1p3dWhcprI8TyPU5vywM7iZbzz/eOqned0 DgimXFtdW91v0B5VZyOYEMHH/kKZNL3GPPVfX3Qde0TBD63MrJIp+fVad2pHT5vHNpYs tSvQ==
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=5rPp89DhZJQ34bjhRJ2MQ7yJkHmR0xrzBAjEXrO0va4=; b=frMhQnLighvznpK+Blo+nuXoqtM7kwMH3pQBy/K7cFdE+uiuWTwMiMmijlpRpGa7l9 s1oq03lrnzsXctBy4HwalqUZWtNTlhhInmIQUlYgOil3m86NPDO70Wf1u7NNB48tIn2w hLoeKiOvGJKJPvm9fR+I8D/HogxkIhyiBlcRcHDScIlGIc5L2KjIiXoou5AHYWXfCmHp VaY0zGZ6wjG4ryzBSNaQ4KMIvLpuioA4svkTGj0HmSoHqD43mtqMDjhBhgQwnlNPrSDT T5obdgVF+BcLiqcGZgNpc/+nO+QOiWnb2+A0ifar+kaN7LYrUEDPKI6D7opeM0BklrN6 1wyQ==
X-Gm-Message-State: ALoCoQnbJdSAais2ZzE32zcBU1Qe4FNRBt3y5TIGj4hDUUZVc+PN6Iw1PLdSVlASvs6JyWNp9dl+
MIME-Version: 1.0
X-Received: by 10.58.147.40 with SMTP id th8mr953087veb.67.1404924589456; Wed, 09 Jul 2014 09:49:49 -0700 (PDT)
Received: by 10.229.162.15 with HTTP; Wed, 9 Jul 2014 09:49:49 -0700 (PDT)
In-Reply-To: <53BCA5FA.2080509@gmail.com>
References: <53B5B366.7010407@gmail.com>  <53BCA5FA.2080509@gmail.com>
Date: Wed, 9 Jul 2014 17:49:49 +0100
Message-ID: 
From: Ben Laurie 
To: Melinda Shore 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Xd8HjyYIgbx91A14oDZuuN2ZCHY
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Walking through the issue tracker: Ticket #4
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, 09 Jul 2014 16:49:52 -0000

On 9 July 2014 03:16, Melinda Shore  wrote:
> On 7/4/14 4:13 AM, Ben Laurie wrote:
>> Given that there's a certain amount of angst about precertificates and
>> PKI rules, it could be that we really want to sign some other
>> structure altogether, at least for precertificates.
>
> Is there a proposal for that that's ready for discussion?

Sorry, I mis-spoke. We pretty clearly need to sign the TBSCertificate
(or at least, all the data that is in it). What we might want to do,
at least for Precertificates, is to sign it in a way that is not
X.509v3, to completely remove all question that it could be used as an
X.509v3 certificate, or be subject to their validation rules.

As for exactly how it is signed, I don't have strong feelings about
that. Is there some appropriate RFC that specifies how to sign some
arbitrary binary blob using RSA or EC keys?

In any case, I am conflating two issues. Trac issue 4 is about what
the _log_ signs. Just signing the TBSCertificate certainly makes some
kind of sense, from a consistency POV. Sorry for the confusion.


From nobody Wed Jul  9 10:33:57 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D241A0296 for ; Wed,  9 Jul 2014 10:33: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 zQskBcRmgtUd for ; Wed,  9 Jul 2014 10:33:55 -0700 (PDT)
Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6ED1A0304 for ; Wed,  9 Jul 2014 10:33:55 -0700 (PDT)
Received: by mail-pd0-f174.google.com with SMTP id y10so9383559pdj.33 for ; Wed, 09 Jul 2014 10:33: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:cc:subject :content-type:content-transfer-encoding; bh=TPc8Df3OfntMHlNfJnG8Hky41PSnJeVvXjFsxm7QJho=; b=hpww91Kx8TckkvY+RPnrYaJJcsW+aLC/eUyq9OxnTV9tjvi1+9awUCG8miGVEQgPDS PObAcZfn6AWTxHXbWXiV5VI7CULK7KHX+QLPhzE4ZvflgJCbLwr0yawmZ3aGdZFEn/em GaHbCoMNZjtTUB0D2XJ4azS3r67BX6QlyGSfIVC/o0UYshEo6VON4ZVKOpEvKmfe/s0F dZp7zwMkoygSY/HG5ZDbqqigBdoop1YEC6LRGt9rY+QEImdrrgzdHW4roa5/A09YPeDi pGivUNngkbqICr8JguGdpKff8wX5BEAHJ8Z+d9KZ13LdkFofLKF5rQS4gdZv6wb04adX RrCw==
X-Received: by 10.68.203.132 with SMTP id kq4mr42573059pbc.12.1404927234698; Wed, 09 Jul 2014 10:33:54 -0700 (PDT)
Received: from spandex.local (216-67-7-38-rb2.fai.dsl.dynamic.acsalaska.net. [216.67.7.38]) by mx.google.com with ESMTPSA id y2sm217888203pas.45.2014.07.09.10.33.53 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Jul 2014 10:33:54 -0700 (PDT)
Message-ID: <53BD7CFB.8090406@gmail.com>
Date: Wed, 09 Jul 2014 09:33:47 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "trans@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/XUa08Zok9B4f4Z7galkSUJ2-Cg4
Cc: Paul Wouters 
Subject: [Trans] Meeting agenda uploaded
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, 09 Jul 2014 17:33:56 -0000

I've uploaded a first cut at a meeting agenda for IETF 90.
Please let Paul and I know of any changes or additional requests.
Also, if you've got a slot on the agenda please get slides to
us by Wednesday before the session; it's a big help for remote
participants and non-native English speakers to have those
available reasonably well in advance.

Melinda


From nobody Thu Jul 10 07:30:56 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3879B1B290A for ; Thu, 10 Jul 2014 07:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, 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 sfei2ut16lrX for ; Thu, 10 Jul 2014 07:30:43 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (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 AC98C1A0347 for ; Thu, 10 Jul 2014 07:30:42 -0700 (PDT)
Received: (qmail 25072 invoked by uid 1000); 10 Jul 2014 14:30:39 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 10 Jul 2014 15:30:39 +0100
Message-ID: <53BEA38E.90602@comodo.com>
Date: Thu, 10 Jul 2014 15:30:38 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Melinda Shore , "trans@ietf.org" 
References: <53BCA73E.80102@gmail.com>
In-Reply-To: <53BCA73E.80102@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/eiwHxjXTQYBFkJDB547EQavnnu4
Cc: Paul Wouters 
Subject: Re: [Trans] Walking through the issue tracker: Ticket #10
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, 10 Jul 2014 14:30:49 -0000

On 09/07/14 03:21, Melinda Shore wrote:
> I see that Rob's taken ownership of this one (on precertificate
> SCTs and OCSP) - it looks like there was agreement about how
> to handle it, but is there text?

Sorry, I haven't done any work on this issue yet.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Thu Jul 10 09:53:44 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E161A0AB4; Thu, 10 Jul 2014 09:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=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 WcHeOUMZ_8Ks; Thu, 10 Jul 2014 09:53:42 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 263E71A03B5; Thu, 10 Jul 2014 09:53:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140710165342.10082.54274.idtracker@ietfa.amsl.com>
Date: Thu, 10 Jul 2014 09:53:42 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/zWhJx0EViN7Q-oAp1f4Nkj2TPJc
Cc: trans@ietf.org
Subject: [Trans] I-D ACTION:draft-ietf-trans-rfc6962-bis-04.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: Thu, 10 Jul 2014 16:53:43 -0000

--NextPart

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         : Certificate Transparency
    Author(s)     : B. Laurie, et al
    Filename      : draft-ietf-trans-rfc6962-bis
    Pages         : 31 
    Date          : 2014-07-10 
    
   This document describes a protocol for publicly logging the existence
   of Transport Layer Security (TLS) certificates as they are issued or
   observed, in a manner that allows anyone to audit certificate
   authority (CA) activity and notice the issuance of suspect
   certificates as well as to audit the certificate logs themselves.
   The intent is that eventually clients would refuse to honor
   certificates that do not appear in a log, effectively forcing CAs to
   add all issued certificates to the logs.

   Logs are network services that implement the protocol operations for
   submissions and queries that are defined in this document.

A URL for this Internet-Draft is:
https://www.ietf.org/internet-drafts/draft-ietf-trans-rfc6962-bis-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-trans-rfc6962-bis";
 site="ftp.ietf.org"; access-type="anon-ftp";
 directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2014-07-10095342.I-D@ietf.org>


--NextPart--


From nobody Thu Jul 10 16:01:30 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495811A0080 for ; Thu, 10 Jul 2014 16:01:18 -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 dfj96Pbp9vXc for ; Thu, 10 Jul 2014 16:01:13 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF6F1A0087 for ; Thu, 10 Jul 2014 16:01:13 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id eu11so316950pac.33 for ; Thu, 10 Jul 2014 16:01:13 -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; bh=RImUZMxYVnRT/neY2m6dY272VaPTUOnZQiWZ0N04ysU=; b=ccaDdLKaDHVknhjWYtEZFiQ7WVX367u0TITRMSW6bt2EyZk3XmsMhoVoDSVltN6Tcs zdQjP6qtNmUlF8IauQ65hJvBYxauLWWqhuVargFbvJxw4lZf+wfW7vN2F3IWXasJSqSE hR10Xr5IC3rVX6DCZqaVR7sc92n/oHFW1jwg8PEfUcvQWRHH1xB8Z8qyUwIqkXLjrH1H uSkEeKO73zVzpWl69yx+R7qQ+19KMpZU06owBkzdoKfxEn1b1G/iSJaY4Y083M8G1sPn zYYp58pLo+ZltDDBp346pNEXdfW1XyRI/P5JkjnN0FEIpyVsIxtr6aS7z5n6XFvfPJQy XHrA==
X-Received: by 10.70.54.162 with SMTP id k2mr5761915pdp.138.1405033273269; Thu, 10 Jul 2014 16:01:13 -0700 (PDT)
Received: from spandex.local (216-67-41-201-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.41.201]) by mx.google.com with ESMTPSA id r4sm483130pdh.28.2014.07.10.16.01.11 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jul 2014 16:01:12 -0700 (PDT)
Message-ID: <53BF1B36.4010208@gmail.com>
Date: Thu, 10 Jul 2014 15:01:10 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "trans@ietf.org" 
References: <20140710165342.10082.54274.idtracker@ietfa.amsl.com>
In-Reply-To: <20140710165342.10082.54274.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140710165342.10082.54274.idtracker@ietfa.amsl.com>
Content-Type: multipart/mixed; boundary="------------010706050709080002010006"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/FZUyFfteutVQayM1L996v764OJ8
Subject: [Trans] Fwd:  I-D ACTION:draft-ietf-trans-rfc6962-bis-04.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, 10 Jul 2014 23:01:19 -0000

This is a multi-part message in MIME format.
--------------010706050709080002010006
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Many thanks to Ben and his co-authors for getting the new
draft out.  Working group participants should give this a
careful read and if you spot any issues or have suggestions
(OR TEXT), please raise those on the mailing list.  This is
the document that will be under discussion in Toronto.

Thanks,

Melinda


-------- Original Message --------
Subject: [Trans] I-D ACTION:draft-ietf-trans-rfc6962-bis-04.txt
Date: Thu, 10 Jul 2014 09:53:42 -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         : Certificate Transparency
    Author(s)     : B. Laurie, et al
    Filename      : draft-ietf-trans-rfc6962-bis
    Pages         : 31
    Date          : 2014-07-10

   This document describes a protocol for publicly logging the existence
   of Transport Layer Security (TLS) certificates as they are issued or
   observed, in a manner that allows anyone to audit certificate
   authority (CA) activity and notice the issuance of suspect
   certificates as well as to audit the certificate logs themselves.
   The intent is that eventually clients would refuse to honor
   certificates that do not appear in a log, effectively forcing CAs to
   add all issued certificates to the logs.

   Logs are network services that implement the protocol operations for
   submissions and queries that are defined in this document.

A URL for this Internet-Draft is:
https://www.ietf.org/internet-drafts/draft-ietf-trans-rfc6962-bis-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.




--------------010706050709080002010006
Content-Type: Message/External-body;
 name="draft-ietf-trans-rfc6962-bis"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="draft-ietf-trans-rfc6962-bis"

Content-Type: text/plain
Content-ID: <2014-07-10095342.I-D@ietf.org>



--------------010706050709080002010006
Content-Type: text/plain; charset=UTF-8;
 name="Attached Message Part"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Attached Message Part"

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


--------------010706050709080002010006--


From mpalmer@hezmatt.org  Mon Jul 14 22:24:13 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8BB1A02ED for ; Mon, 14 Jul 2014 22:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.387
X-Spam-Level: **
X-Spam-Status: No, score=2.387 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SPF_SOFTFAIL=0.665] 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 gri7Xrxj9g-Y for ; Mon, 14 Jul 2014 22:24:12 -0700 (PDT)
Received: from mail.hezmatt.org (mpalmer-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:9e6::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF1E1A02E8 for ; Mon, 14 Jul 2014 22:24:12 -0700 (PDT)
Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id A4A6C282E0B for ; Tue, 15 Jul 2014 15:24:11 +1000 (EST)
Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id D6AE39FB95; Tue, 15 Jul 2014 15:24:10 +1000 (EST)
Date: Tue, 15 Jul 2014 15:24:10 +1000
From: Matt Palmer 
To: trans@ietf.org
Message-ID: <20140715052410.GB17452@hezmatt.org>
References: <544B0DD62A64C1448B2DA253C011414607CCD4149A@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CCD4149A@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hmS3c-eM58TERUEqFwmRpv2K9ZM
Subject: Re: [Trans] Cross-certificates and log servers
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, 15 Jul 2014 06:35:51 -0000

As someone who is looking to run a log server, I'll answer with my personal
opinions.

On Tue, Jul 01, 2014 at 03:45:12PM -0700, Rick Andrews wrote:
> The current spec includes a call to Retrieve Accepted Root Certificates.
> Should we infer from that that the list might change over time?  We expect
> new roots would be added, but would roots ever get removed?  For example,
> browser vendors are in the process of removing 1024-bit roots from their
> trust stores, and in the next few years we expect that SHA-1 roots might
> be removed too.  Would log server operators also phase out such roots?

Since roots are only there to prevent mass-spammage, the only circumstance
in which I would foresee a root certificate being removed from the log's
trusted set would be if it went so totally rogue it was issuing a huge
volume of certificates and submitting it to the log.

Quite frankly, if you get control of a root or intermediate CA certificate's
signing key, and the most valuable thing you can think to do with it is spam
a CT log, you need to get out more.

> Once there are more than three log servers, we expect to decide up front
> which log servers we will contact for SCTs.  We do not expect to
> dynamically query each log server to confirm that it still trusts our
> root, just before attempting to log a certificate.  Is that a valid
> assumption?

Completely valid.

> It would be preferable for the log server operator to publish a list of
> roots and commit to supporting those roots until the CA informs the
> operator that the root is no longer in active use, and all certificates
> chained to that root have expired.

Darn tootin'.

> We have been providing cross-certificates to customers to deploy so that
> their certificate could chain up to a 1024-bit root (for use in older
> browsers without our 2048-bit roots).  If the cross-certificate is
> ignored, the end-entity cert chains up to one of our 2048-bit roots.  We
> expect to continue using cross-certificates until we determine that their
> use is no longer required.  We'd like to be sure that the use of
> cross-certificates will not cause any problems for log servers.  For
> example, take the case where we log a certificate we're about to issue (or
> have issued) and we include the cross-certificate in the chain sent to the
> log server.  Then the customer (for whatever reason) decides to also send
> their certificate to the log server, but without the cross-certificate. 
> Will the log server see this as the same certificate, and return to the
> customer the same SCTs?  Or will the certificate get logged a second time? 
> If the latter, will that cause any problems?

The Signed Certificate Timestamps identify the end-entity certificate being
signed, and a timestamp of when it was accepted for inclusion into the log. 
My implementation, at the very least, re-issues the same SCT if it sees the
same certificate again, regardless of the method by which is it chained to
one of the trusted root certs.

On a related point, I'm intending (until circumstances prove it to be a
foolhardy notion) to be *very* liberal in what roots I accept -- I'll
probably pre-populate with the trust stores of the browsers, etc, but I'll
have a form or something you can paste your root CA cert into and I'll add
it, unless you're obviously trying it on.

- Matt

-- 
When I was a kid I used to pray every night for a new bicycle. Then I
realised that the Lord doesn't work that way so I stole one and asked Him to
forgive me.
		-- Emo Philips


From mpalmer@hezmatt.org  Mon Jul 14 22:15:48 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03C81A02D7 for ; Mon, 14 Jul 2014 22:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, 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 5KBy4Bf-O1Is for ; Mon, 14 Jul 2014 22:15:46 -0700 (PDT)
Received: from mail.hezmatt.org (sasquatch.hezmatt.org [70.85.129.92]) by ietfa.amsl.com (Postfix) with ESMTP id 696151A02E7 for ; Mon, 14 Jul 2014 22:15:46 -0700 (PDT)
Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id 5A63D282E0B for ; Tue, 15 Jul 2014 15:15:45 +1000 (EST)
Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id 4D2619FB95; Tue, 15 Jul 2014 15:15:44 +1000 (EST)
Date: Tue, 15 Jul 2014 15:15:44 +1000
From: Matt Palmer 
To: trans@ietf.org
Message-ID: <20140715051544.GA17452@hezmatt.org>
References: <53B5B366.7010407@gmail.com>  <53BCA5FA.2080509@gmail.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/b-qQxhAyiDSob9FUx9kQEuC2wjQ
Subject: Re: [Trans] Walking through the issue tracker: Ticket #4
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, 15 Jul 2014 06:36:01 -0000

On Wed, Jul 09, 2014 at 05:49:49PM +0100, Ben Laurie wrote:
> On 9 July 2014 03:16, Melinda Shore  wrote:
> > On 7/4/14 4:13 AM, Ben Laurie wrote:
> >> Given that there's a certain amount of angst about precertificates and
> >> PKI rules, it could be that we really want to sign some other
> >> structure altogether, at least for precertificates.
> >
> > Is there a proposal for that that's ready for discussion?
> 
> Sorry, I mis-spoke. We pretty clearly need to sign the TBSCertificate
> (or at least, all the data that is in it). What we might want to do,
> at least for Precertificates, is to sign it in a way that is not
> X.509v3, to completely remove all question that it could be used as an
> X.509v3 certificate, or be subject to their validation rules.
> 
> As for exactly how it is signed, I don't have strong feelings about
> that. Is there some appropriate RFC that specifies how to sign some
> arbitrary binary blob using RSA or EC keys?

struct {
    digitally-signed TBSCertificate;
    opaque TBSCertificate<1..2^24-1>;
} Precertificate;

?

- Matt


From nobody Tue Jul 15 03:21:54 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECC01B2820 for ; Tue, 15 Jul 2014 03:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Level: 
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.651, 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 t_zDaTDQ_9zA for ; Tue, 15 Jul 2014 03:21:51 -0700 (PDT)
Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6251A0379 for ; Tue, 15 Jul 2014 03:21:51 -0700 (PDT)
Received: by mail-qg0-f46.google.com with SMTP id z60so3044371qgd.5 for ; Tue, 15 Jul 2014 03:21:50 -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=LJdPY4dEjsN6RRK9ONoNdemI8JiVliMPYL3v+PtvkeY=; b=o39RfCHR80M39rFgDjH2PS3juuHlvXt6MXohLwcnp8PDwLiStBbWZHxfDfPSt6UJaE zOn2sK/vkL9rbA+YWJ0l5jRPorN2VzvJjarqrZymfx3FYBzI8xl5fYizvigKLzgGRCLd FOGjczmOnUEW034zFe1YOsEpdXMuPwuLSERsGvqbvh1PIqpTrPrus4UuG9BFNXbaKgu+ 5Yu2wqzMdzclCaSC4Cuje7HZ2mK0rX/KXesj77XDGv1+jyGpb/+APoBcu8JQY7E6Do6s 9IL67ueQCxHSIv88ChDJy5Ut6g4vuB7KI//aZNstBMOgJLH4a1Rjxthj7er8HMdOIXTP dFQQ==
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=LJdPY4dEjsN6RRK9ONoNdemI8JiVliMPYL3v+PtvkeY=; b=WGint2t+m5eDAecw9TZ3w5pNX8WgJ8ZnZD8MntHX2iW78dJaJMjOmJdkcSMYMARcfv GNdPaJ/q+YmCGziIAsDSho3vaF55eeZk7U7BiFQpiBgCb9VIxEBQj12tYKtptpv3t6Gr bd2RdLIgfIeNlA7HVzaW60Rich1aEb9ZUAvkRAVbDSkMtbsfr33KGCyVek1Ap+Eb6ZKs pE6ZzSSeLchiLcGlfe1HAOJZiIzHgnuTMPy1yoXViLCTj14J6UvBR47YUSehXXoq5TtX kjt4l6AHms6aSwUYGRwYc0BjBPFAiMwW17CkksQPPmbPdah9uRZzVQLv5taBXowv8h5Q mX5w==
X-Gm-Message-State: ALoCoQmpYwQCyLUdx+HUXTaYUFYH1u7sPFZBruZiiIjIa1+fhxlLsUzhccJDQVGpLNw+H+b3fMhb
MIME-Version: 1.0
X-Received: by 10.140.105.163 with SMTP id c32mr32151388qgf.85.1405419710822;  Tue, 15 Jul 2014 03:21:50 -0700 (PDT)
Received: by 10.229.162.15 with HTTP; Tue, 15 Jul 2014 03:21:50 -0700 (PDT)
In-Reply-To: <20140715051544.GA17452@hezmatt.org>
References: <53B5B366.7010407@gmail.com>  <53BCA5FA.2080509@gmail.com>  <20140715051544.GA17452@hezmatt.org>
Date: Tue, 15 Jul 2014 11:21:50 +0100
Message-ID: 
From: Ben Laurie 
To: Matt Palmer 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Q8AyDtSFNqDd8ssAFc4PrD_OCnM
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Walking through the issue tracker: Ticket #4
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, 15 Jul 2014 10:21:53 -0000

On 15 July 2014 06:15, Matt Palmer  wrote:
> On Wed, Jul 09, 2014 at 05:49:49PM +0100, Ben Laurie wrote:
>> On 9 July 2014 03:16, Melinda Shore  wrote:
>> > On 7/4/14 4:13 AM, Ben Laurie wrote:
>> >> Given that there's a certain amount of angst about precertificates and
>> >> PKI rules, it could be that we really want to sign some other
>> >> structure altogether, at least for precertificates.
>> >
>> > Is there a proposal for that that's ready for discussion?
>>
>> Sorry, I mis-spoke. We pretty clearly need to sign the TBSCertificate
>> (or at least, all the data that is in it). What we might want to do,
>> at least for Precertificates, is to sign it in a way that is not
>> X.509v3, to completely remove all question that it could be used as an
>> X.509v3 certificate, or be subject to their validation rules.
>>
>> As for exactly how it is signed, I don't have strong feelings about
>> that. Is there some appropriate RFC that specifies how to sign some
>> arbitrary binary blob using RSA or EC keys?
>
> struct {
>     digitally-signed TBSCertificate;
>     opaque TBSCertificate<1..2^24-1>;
> } Precertificate;

Hmm. That's a tempting thought!


From nobody Tue Jul 15 04:09:40 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41051B2860 for ; Tue, 15 Jul 2014 04:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, 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 tNCJ4v5xiqAY for ; Tue, 15 Jul 2014 04:09:37 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (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 25BA61B2836 for ; Tue, 15 Jul 2014 04:09:36 -0700 (PDT)
Received: (qmail 30190 invoked by uid 1000); 15 Jul 2014 11:09:33 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 15 Jul 2014 12:09:33 +0100
Message-ID: <53C50BED.8000708@comodo.com>
Date: Tue, 15 Jul 2014 12:09:33 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Laurie , Matt Palmer 
References: <53B5B366.7010407@gmail.com>  <53BCA5FA.2080509@gmail.com>  <20140715051544.GA17452@hezmatt.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ADQB-W2B8YR-U7OBw3Rn8fPIctw
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Walking through the issue tracker: Ticket #4
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, 15 Jul 2014 11:09:39 -0000

On 15/07/14 11:21, Ben Laurie wrote:
> On 15 July 2014 06:15, Matt Palmer  wrote:

>>> As for exactly how it is signed, I don't have strong feelings about
>>> that. Is there some appropriate RFC that specifies how to sign some
>>> arbitrary binary blob using RSA or EC keys?
>>
>> struct {
>>      digitally-signed TBSCertificate;
>>      opaque TBSCertificate<1..2^24-1>;
>> } Precertificate;
>
> Hmm. That's a tempting thought!

"SIGNED", defined by X.509, is one of the ASN.1 ways to sign arbitrary 
blobs.  It's used for signing certificates, CRLs, CSRs, OCSP responses, etc.

RFC2459 expressed it as...
   "SIGNED { ToBeSigned } ::= SEQUENCE {
       toBeSigned  ToBeSigned,
       algorithm   AlgorithmIdentifier,
       signature   BIT STRING
    }

    Certificate            ::=   SIGNED { SEQUENCE {
       version                 [0]   Version DEFAULT v1,
       serialNumber                  CertificateSerialNumber,
       ..."

(However, for some reason RFC3280/5280 dropped "SIGNED" and changed the 
certificate definition to...
   "Certificate  ::=  SEQUENCE  {
         tbsCertificate       TBSCertificate,
         signatureAlgorithm   AlgorithmIdentifier,
         signature            BIT STRING  }")

We could define TBSPrecertificate as an ASN.1 structure that is very 
similar to, but incompatible with, TBSCertificate.  And then we could 
define...
    Precertificate   ::=   SIGNED { TBSPrecertificate }


An alternative ASN.1 way to sign arbitrary binary blobs is CMS 
(originally called PKCS#7).  See RFC5652.
A Precertificate could be a CMS object that uses the Signed-data content 
type to carry a TBSCertificate.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Tue Jul 15 12:37:12 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2D51B2930 for ; Tue, 15 Jul 2014 12:37:09 -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 6Ui_3Tk3pKbD for ; Tue, 15 Jul 2014 12:37:07 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3501A0AB0 for ; Tue, 15 Jul 2014 12:37:07 -0700 (PDT)
Received: by mail-pa0-f45.google.com with SMTP id eu11so348718pac.32 for ; Tue, 15 Jul 2014 12:37:07 -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; bh=5AyInR09/7aDqXxRK3XHeULZuDVC9V7dm7jF+gejATE=; b=dRFvNnVEgtEQyGe0kLjtI045C4OTdpUVlFSf7bRXqP3NCgXcwJVmruXyF8CiKmqk3c 7UuwDXUTHOCRAe4d1n54nwgQ1sDMQlFF2NpjSGE/tNnbw6Yw/W3Icj1LKzeNilpRyyWJ y6Xyq7FRrJ2LrN+C7fvZ9+zYeTCOIqm4Uarxw0gVwiz4N8Vx6DqvxK2pR2izObYy6hzU E6fjaoXsvmyjzeadKrlgDNIIPucQ1zuAbCJ4UeXA3LALo+NfVuGTVYVh9ReKWej6plp8 nbUOSveIQGOvMQNm2AqN1WhBiWoFZ+tY93G6+g4Gk+JnRg97N7ZKKejxE7DZeAFmXfjE pfGQ==
X-Received: by 10.70.140.13 with SMTP id rc13mr9870141pdb.127.1405453027278; Tue, 15 Jul 2014 12:37:07 -0700 (PDT)
Received: from [192.168.254.10] (ip70-189-237-85.lv.lv.cox.net. [70.189.237.85]) by mx.google.com with ESMTPSA id ko7sm19693802pdb.26.2014.07.15.12.37.04 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 12:37:05 -0700 (PDT)
Message-ID: <53C582DE.1010500@gmail.com>
Date: Tue, 15 Jul 2014 12:37:02 -0700
From: Kyle Hamilton 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Laurie , trans@ietf.org
References: <53B5B366.7010407@gmail.com>  <53BCA5FA.2080509@gmail.com>  <20140715051544.GA17452@hezmatt.org> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000501010807090602000900"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mpJ954p065X8OFKnGiuYCValUgU
Subject: Re: [Trans] Walking through the issue tracker: Ticket #4
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, 15 Jul 2014 19:37:10 -0000

This is a cryptographically signed message in MIME format.

--------------ms000501010807090602000900
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On 7/15/2014 3:21 AM, Ben Laurie wrote:
> On 15 July 2014 06:15, Matt Palmer  wrote:
>> On Wed, Jul 09, 2014 at 05:49:49PM +0100, Ben Laurie wrote:
>>> On 9 July 2014 03:16, Melinda Shore  wrote:
>>>> On 7/4/14 4:13 AM, Ben Laurie wrote:
>>>>> Given that there's a certain amount of angst about precertificates =
and
>>>>> PKI rules, it could be that we really want to sign some other
>>>>> structure altogether, at least for precertificates.
>>>> Is there a proposal for that that's ready for discussion?
>>> Sorry, I mis-spoke. We pretty clearly need to sign the TBSCertificate=

>>> (or at least, all the data that is in it). What we might want to do,
>>> at least for Precertificates, is to sign it in a way that is not
>>> X.509v3, to completely remove all question that it could be used as a=
n
>>> X.509v3 certificate, or be subject to their validation rules.
>>>
>>> As for exactly how it is signed, I don't have strong feelings about
>>> that. Is there some appropriate RFC that specifies how to sign some
>>> arbitrary binary blob using RSA or EC keys?
>> struct {
>>     digitally-signed TBSCertificate;
>>     opaque TBSCertificate<1..2^24-1>;
>> } Precertificate;
> Hmm. That's a tempting thought!

Why not use a modified Certificate structure with a non-optional,
explictly-tagged (tag 1 or something) datum in the place of the Version
field?  Especially if it wasn't an INTEGER, it would cause any
conformant Certificate parser to reject it.  (Anything that checks to
see that the first item either isn't tagged or has tag 0 will refuse to
parse it.)

-Kyle H



--------------ms000501010807090602000900
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKSDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIFJjCCBA6gAwIBAgIRALbv5xh8RSMuXP9qrA/5ONAwDQYJKoZIhvcN
AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD
T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQw
NjAzMDAwMDAwWhcNMTUwNjAzMjM1OTU5WjAjMSEwHwYJKoZIhvcNAQkBFhJhZXJvd29sZkBn
bWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIrYxg/oIPfnNfvNCm
OoctdpmYxFYygtJ7eHGCGyUvGnqaiNacsYgsvtfyyC3Hwq82Va9Sr2/y8+iPB/oAWPvlfJUO
viFkCFsPBRsuRo8Iul6GElOiZSq9Q4PtVseJt9JK4cee8GPeD3kWIp0ynktDPW17XhOK8J4U
Hrvn04Yaa6eK7nLDnsboaxRBHOZ1B/3qAWGznF5L/oQf0NV6rdz+v31CyOoZhvtldC9ooK3t
q7Xve075VrnrkqM2HQe8Whg5J1Oo1TfNeqFWayZU9o0jK07oGv7wYsKHVc5FpIFZ8j9odB3J
gM7hmtCYuwOMzqp0jxeQA38k2yqAxWHx1W/nAgMBAAGjggHiMIIB3jAfBgNVHSMEGDAWgBR6
E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUENa7REnXA37GDe/Ytjs6PmRVaE4wDgYD
VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQB
sjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr
MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBO
MEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNh
dGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKG
Rmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k
U2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNv
bTAdBgNVHREEFjAUgRJhZXJvd29sZkBnbWFpbC5jb20wDQYJKoZIhvcNAQEFBQADggEBADaN
kVFmWQxIp1qk5r4R1WaTVb77fED2CFEihXNvIfJEWIdFKRtlfSAyCGQzarMxf5HMRjYi62Tl
H4OMGUgc3Eult0EtdO/hFBz9lYNTQmi+uY6GZM7ZjXxkmHexycQoWR8fQg+w3UMkVKxEiVji
OZOuer7R79KVw18rDZcQipSO/n/Zz4i5CAk1cC/kWnBcs3VOm+rr27gQrO0/QQfCjcRu0WE0
ymEHunnNm9F/vZbvBL4V+xxUvxrsR4JeQoePKCFprHnaVmuHHluZq5UPZNTRq7C5Q+T9YvYW
e525UiAj1LD9eV58LWTurmayjoxYqaktJf4x9Og0h9Gz2mopU5sxggQcMIIEGAIBATCBqTCB
kzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH
U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALbv5xh8RSMuXP9q
rA/5ONAwCQYFKw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTQwNzE1MTkzNzAyWjAjBgkqhkiG9w0BCQQxFgQUD/+LZs2TQG7ZwnJMclAQ
Wz85cNEwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS
R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g
Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
U2VjdXJlIEVtYWlsIENBAhEAtu/nGHxFIy5c/2qsD/k40DCBvAYLKoZIhvcNAQkQAgsxgayg
gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV
BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P
RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQC27+cYfEUj
Llz/aqwP+TjQMA0GCSqGSIb3DQEBAQUABIIBADIJFFvpa6z5e63hy7vFZZwyy7j5HlwJqbhM
aSlydWPKIq+4QEMSwdw7KetRCk8hlr3tv60MJMIZV9We5xN4gU4tgLDChX24jYUr2Pl/nheF
VBLx2prnSIwPW67n1vpJtbLy//9UIUhZQ8Ao94diXveNxQ5+HHU+5ai7sGE0Mv8+6usuVc0c
J+w1CCZI1yW96HwgepCJSQx3eRarVANnxbKVrFG47aEVDeg5jY5XZ7WK+Hp61PiXwwJwh6Zi
w/S0LKL78DBSKB0HFsvkiCvhmVu8NLctgUyJ0zroDqqnuOe6Ink8r3E6xwJKCLTvge+1uog+
nPSwWz1Ynt5kHDXeH4wAAAAAAAA=
--------------ms000501010807090602000900--


From nobody Fri Jul 18 11:11:39 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9F11B2A21 for ; Fri, 18 Jul 2014 11:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 vkSJPlKIzFHH for ; Fri, 18 Jul 2014 11:11:31 -0700 (PDT)
Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415861B2A24 for ; Fri, 18 Jul 2014 11:11:27 -0700 (PDT)
X-AuditID: d80ac3f2-f79de6d000003fee-10-53c9634e428a
Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 5D.C9.16366.E4369C35; Fri, 18 Jul 2014 19:11:26 +0100 (BST)
Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1X8Ccw-0003np-Ei for trans@ietf.org; Fri, 18 Jul 2014 18:11:26 +0000
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Fri, 18 Jul 2014 11:11:26 -0700
From: Rick Andrews 
To: "trans@ietf.org" 
Date: Fri, 18 Jul 2014 11:11:24 -0700
Thread-Topic: List of Roots Accepted by Log Servers
Thread-Index: Ac+irl+ii5Y1QiW8SKiN+XC17uqP9g==
Message-ID: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_544B0DD62A64C1448B2DA253C011414607CD475FD2TUS1XCHEVSPIN_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42I5sOKajq5f8slgg5235S3WPr7I4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJbHP5gKfihUrHz4gr2B8YZ0FyMnh4SAiUT/jUvsELaYxIV7 69m6GLk4hAQ+MEpsP9HLCOH8Z5Rov/4HylnFKLH47TUmkBY2AT2JLY+vgLWLCKhKfL7fAhZn AbI3fLrLCGILA9VMn3qHGaLGWOLk5k1MELaeRP+CX6wgNq9AlMT+74vA5jACnfH91BqwGmYB cYlbT+YzQZwnILFkz3lmCFtU4uXjf6wQ9aISd9rXM0LU50vMmn6aGWKmoMTJmU9YJjAKz0Iy ahaSsllIyiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRpmS0mLD4tyS/NKSgtQKAyO9 4srcRGDkJOsl5+duYgRGzw2uw592MM7c63iIUYCDUYmHVyfkZLAQa2IZUOUhRgkOZiUR3g2h QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK80dongoUE0hNLUrNTUwtSi2CyTBycUg2MAnv47ZN2 W519eTTRJSXw1td4TQP2FBWv97cKWr3qC5/H+NT1ZNVL3fJ/u4DxQo2f7prrYbfe+Z4++rYj MWur3OpzHIuvPk6VfMJ0XMjnq5Ta2RmLks5lT3oZKJFhtKU11qg5IPVHjXZJRZdzhY532N+o njil23bKC6S+3D/awPjgULy4noUSS3FGoqEWc1FxIgCKiT6YmgIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/s5dVQdIhboaJuM6V_BuH5u8mEjY
Subject: [Trans] List of Roots Accepted by Log Servers
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, 18 Jul 2014 18:11:37 -0000

--_000_544B0DD62A64C1448B2DA253C011414607CD475FD2TUS1XCHEVSPIN_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I finally got around to reading the list of roots accepted by the pilot and=
 aviator log servers (using the get-roots command). I see a number of our r=
oots that seem inappropriate to me, meaning that we have never issued SSL c=
erts (EV or non-EV) from those roots, and never intend to. It seems to me t=
hat Google cast a wide net to add all relevant roots to kickstart the log s=
ervers (perhaps bootstrapped from Mozilla's root list?), but at some point =
(before CT is "live") I would like to see the list trimmed.

My thinking is that if I somehow issue an SSL cert from a root that I did n=
ot intend to use for SSL, I would prefer to catch that as quickly as possib=
le; ideally, when the log server refuses to give me an SCT. Is Google willi=
ng to remove roots from pilot and aviator?

I think we need a somewhat formal way for CAs to provide log server operato=
rs their list of roots, and update that over time. For example, we have a f=
ew new roots that we expect to be using in the next few months, and I need =
to make sure they're added to log servers before I start using them. If log=
 server operators provide an service level agreement (SLA) for such changes=
, that would be great.

Comments?

-Rick



--_000_544B0DD62A64C1448B2DA253C011414607CD475FD2TUS1XCHEVSPIN_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









=


I finally got around to =
reading the list of roots accepted by the pilot and aviator log servers (us=
ing the get-roots command). I see a number of our roots that seem inappropr=
iate to me, meaning that we have never
issued SSL certs (EV or non-EV) from those roots, and never intend to. It s=
eems to me that Google cast a wide net to add all relevant roots to kicksta=
rt the log servers (perhaps bootstrapped from Mozilla’s root list?), =
but at some point (before CT is “live”)
I would like to see the list trimmed.


 


My thinking is that if I=
 somehow issue an SSL cert from a root that I did not intend to use for SSL=
, I would prefer to catch that as quickly as possible; ideally, when the lo=
g server refuses to give me an SCT.
Is Google willing to remove roots from pilot and aviator?


 


I think we need a somewh=
at formal way for CAs to provide log server operators their list of roots, =
and update that over time. For example, we have a few new roots that we exp=
ect to be using in the next few months,
and I need to make sure they’re added to log servers before I start u=
sing them. If log server operators provide an service level agreement (SLA)=
 for such changes, that would be great.


 


Comments?


 


-Rick


 


 





--_000_544B0DD62A64C1448B2DA253C011414607CD475FD2TUS1XCHEVSPIN_--


From nobody Fri Jul 18 13:17:04 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7421A00E1 for ; Fri, 18 Jul 2014 13:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.313
X-Spam-Level: 
X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SPF_SOFTFAIL=0.665] 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 PlH1aMziJbi0 for ; Fri, 18 Jul 2014 13:17:00 -0700 (PDT)
Received: from mail.hezmatt.org (mpalmer-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:9e6::2]) by ietfa.amsl.com (Postfix) with ESMTP id 09CDF1A00C3 for ; Fri, 18 Jul 2014 13:17:00 -0700 (PDT)
Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id 00A84282E0B for ; Sat, 19 Jul 2014 06:16:58 +1000 (EST)
Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id F3BEE9FF7A; Sat, 19 Jul 2014 06:16:57 +1000 (EST)
Date: Sat, 19 Jul 2014 06:16:57 +1000
From: Matt Palmer 
To: trans@ietf.org
Message-ID: <20140718201657.GU17452@hezmatt.org>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/7t96riFnj-sn0Il3XoB7P8MaVDE
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 18 Jul 2014 20:17:02 -0000

I can't speak for Google, but I'll speak as an intending log operator.

On Fri, Jul 18, 2014 at 11:11:24AM -0700, Rick Andrews wrote:
> My thinking is that if I somehow issue an SSL cert from a root that I did
> not intend to use for SSL, I would prefer to catch that as quickly as
> possible; ideally, when the log server refuses to give me an SCT.  Is
> Google willing to remove roots from pilot and aviator?

I'd be willing to remove root certs from the logs I run if requested, based
on a suitably authenticated communication from the CA operator.

I wonder, though, why a root CA certificate would end up in a log in the
first place if it wasn't intended to produce publically-trusted
certificates.  Like you, I've been led to believe that Google scraped one or
more browser trust stores for the list of certs on pilot/aviator.  Why would
a root CA operator have added their root cert to a browser trust store if
they weren't intending to issue trusted certificates?  If the root was added
for a non-web-server trust bit, I see that as being within the purview of
CT, because I'd like to be able to audit for the issuance of code signing
and e-mail certificates as well.

> I think we need a somewhat formal way for CAs to provide log server
> operators their list of roots, and update that over time.  For example, we
> have a few new roots that we expect to be using in the next few months,
> and I need to make sure they're added to log servers before I start using
> them.  If log server operators provide an service level agreement (SLA)
> for such changes, that would be great.

I'm planning on publishing operator contact details in or near the log
itself -- send an e-mail to the address in there and you'll get a response
within the MMD.  Seem reasonable?

- Matt

-- 
You know you have a distributed system when the crash of a computer you’ve
never heard of stops you from getting any work done.
		-- Leslie Lamport "Security Engineering: A Guide to Building
		   Dependable Distributed Systems"


From nobody Fri Jul 18 13:31:41 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3461A00E1 for ; Fri, 18 Jul 2014 13:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level: 
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq5nIaDo3xsy for ; Fri, 18 Jul 2014 13:31:35 -0700 (PDT)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2691A00C3 for ; Fri, 18 Jul 2014 13:31:35 -0700 (PDT)
From: Jeremy Rowley 
To: 'Matt Palmer' , "'trans@ietf.org'" 
Thread-Topic: [Trans] List of Roots Accepted by Log Servers
Thread-Index: Ac+irl+ii5Y1QiW8SKiN+XC17uqP9gASSQ6AAAxXT5A=
Date: Fri, 18 Jul 2014 20:31:33 +0000
Message-ID: <7691eb56329c4b6ca2cf30801eb7ce32@EX1.corp.digicert.com>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20140718201657.GU17452@hezmatt.org>
In-Reply-To: <20140718201657.GU17452@hezmatt.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [67.137.52.8]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/cBr2JxtpDkzFKtDk4tQLvNK_XeM
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 18 Jul 2014 20:31:37 -0000

QWx0aG91Z2ggSSBjYW4gc2VlIHRoZSBhcHBlYWwgZm9yIGEgcHJvY2VzcyB3aXRoIEdvb2dsZSBv
cGVyYXRlZCBsb2dzLCBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIG11Y2ggdmFsdWUgaW4gY3JlYXRp
bmcgYSBzeXN0ZW0gdG8gYWRkL3JlbW92ZSByb290cyBmcm9tIGEgbG9nIGF0IGEgQ0EncyByZXF1
ZXN0LiAgSWYgQ0FzIGRvbid0IHdhbnQgdG8gaW5jbHVkZSB0aGVpciBjZXJ0IG9uIGEgc3BlY2lm
aWMgbG9nLCB0aGUgQ0Egc2hvdWxkbid0IGV2ZXIgaGl0IHRoZSBsb2cgd2l0aCBhIHByZS1jZXJ0
LiAgIEZvciBvdXIgbG9nLCB3ZSBhcmUgc2ltcGx5IGdvaW5nIHRvIGVuYWJsZSByb290cyBhcyB3
ZSBzZWUgYXBwcm9wcmlhdGUsIG1vc3QgbGlrZWQgYmFzZWQgb24gdGhlIGNlcnRzIHRydXN0ZWQg
aW4gYm90aCBNb3ppbGxhIGFuZCBNUyAoYnV0IHdlIGFyZSBzdGlsbCBkZWJhdGluZyB0aGlzIGlz
c3VlKS4NCg0KSmVyZW15DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUcmFu
cyBbbWFpbHRvOnRyYW5zLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXR0IFBhbG1l
cg0KU2VudDogRnJpZGF5LCBKdWx5IDE4LCAyMDE0IDI6MTcgUE0NClRvOiB0cmFuc0BpZXRmLm9y
Zw0KU3ViamVjdDogUmU6IFtUcmFuc10gTGlzdCBvZiBSb290cyBBY2NlcHRlZCBieSBMb2cgU2Vy
dmVycw0KDQpJIGNhbid0IHNwZWFrIGZvciBHb29nbGUsIGJ1dCBJJ2xsIHNwZWFrIGFzIGFuIGlu
dGVuZGluZyBsb2cgb3BlcmF0b3IuDQoNCk9uIEZyaSwgSnVsIDE4LCAyMDE0IGF0IDExOjExOjI0
QU0gLTA3MDAsIFJpY2sgQW5kcmV3cyB3cm90ZToNCj4gTXkgdGhpbmtpbmcgaXMgdGhhdCBpZiBJ
IHNvbWVob3cgaXNzdWUgYW4gU1NMIGNlcnQgZnJvbSBhIHJvb3QgdGhhdCBJIA0KPiBkaWQgbm90
IGludGVuZCB0byB1c2UgZm9yIFNTTCwgSSB3b3VsZCBwcmVmZXIgdG8gY2F0Y2ggdGhhdCBhcyBx
dWlja2x5IA0KPiBhcyBwb3NzaWJsZTsgaWRlYWxseSwgd2hlbiB0aGUgbG9nIHNlcnZlciByZWZ1
c2VzIHRvIGdpdmUgbWUgYW4gU0NULiAgDQo+IElzIEdvb2dsZSB3aWxsaW5nIHRvIHJlbW92ZSBy
b290cyBmcm9tIHBpbG90IGFuZCBhdmlhdG9yPw0KDQpJJ2QgYmUgd2lsbGluZyB0byByZW1vdmUg
cm9vdCBjZXJ0cyBmcm9tIHRoZSBsb2dzIEkgcnVuIGlmIHJlcXVlc3RlZCwgYmFzZWQgb24gYSBz
dWl0YWJseSBhdXRoZW50aWNhdGVkIGNvbW11bmljYXRpb24gZnJvbSB0aGUgQ0Egb3BlcmF0b3Iu
DQoNCkkgd29uZGVyLCB0aG91Z2gsIHdoeSBhIHJvb3QgQ0EgY2VydGlmaWNhdGUgd291bGQgZW5k
IHVwIGluIGEgbG9nIGluIHRoZSBmaXJzdCBwbGFjZSBpZiBpdCB3YXNuJ3QgaW50ZW5kZWQgdG8g
cHJvZHVjZSBwdWJsaWNhbGx5LXRydXN0ZWQgY2VydGlmaWNhdGVzLiAgTGlrZSB5b3UsIEkndmUg
YmVlbiBsZWQgdG8gYmVsaWV2ZSB0aGF0IEdvb2dsZSBzY3JhcGVkIG9uZSBvciBtb3JlIGJyb3dz
ZXIgdHJ1c3Qgc3RvcmVzIGZvciB0aGUgbGlzdCBvZiBjZXJ0cyBvbiBwaWxvdC9hdmlhdG9yLiAg
V2h5IHdvdWxkIGEgcm9vdCBDQSBvcGVyYXRvciBoYXZlIGFkZGVkIHRoZWlyIHJvb3QgY2VydCB0
byBhIGJyb3dzZXIgdHJ1c3Qgc3RvcmUgaWYgdGhleSB3ZXJlbid0IGludGVuZGluZyB0byBpc3N1
ZSB0cnVzdGVkIGNlcnRpZmljYXRlcz8gIElmIHRoZSByb290IHdhcyBhZGRlZCBmb3IgYSBub24t
d2ViLXNlcnZlciB0cnVzdCBiaXQsIEkgc2VlIHRoYXQgYXMgYmVpbmcgd2l0aGluIHRoZSBwdXJ2
aWV3IG9mIENULCBiZWNhdXNlIEknZCBsaWtlIHRvIGJlIGFibGUgdG8gYXVkaXQgZm9yIHRoZSBp
c3N1YW5jZSBvZiBjb2RlIHNpZ25pbmcgYW5kIGUtbWFpbCBjZXJ0aWZpY2F0ZXMgYXMgd2VsbC4N
Cg0KPiBJIHRoaW5rIHdlIG5lZWQgYSBzb21ld2hhdCBmb3JtYWwgd2F5IGZvciBDQXMgdG8gcHJv
dmlkZSBsb2cgc2VydmVyIA0KPiBvcGVyYXRvcnMgdGhlaXIgbGlzdCBvZiByb290cywgYW5kIHVw
ZGF0ZSB0aGF0IG92ZXIgdGltZS4gIEZvciANCj4gZXhhbXBsZSwgd2UgaGF2ZSBhIGZldyBuZXcg
cm9vdHMgdGhhdCB3ZSBleHBlY3QgdG8gYmUgdXNpbmcgaW4gdGhlIA0KPiBuZXh0IGZldyBtb250
aHMsIGFuZCBJIG5lZWQgdG8gbWFrZSBzdXJlIHRoZXkncmUgYWRkZWQgdG8gbG9nIHNlcnZlcnMg
DQo+IGJlZm9yZSBJIHN0YXJ0IHVzaW5nIHRoZW0uICBJZiBsb2cgc2VydmVyIG9wZXJhdG9ycyBw
cm92aWRlIGFuIHNlcnZpY2UgDQo+IGxldmVsIGFncmVlbWVudCAoU0xBKSBmb3Igc3VjaCBjaGFu
Z2VzLCB0aGF0IHdvdWxkIGJlIGdyZWF0Lg0KDQpJJ20gcGxhbm5pbmcgb24gcHVibGlzaGluZyBv
cGVyYXRvciBjb250YWN0IGRldGFpbHMgaW4gb3IgbmVhciB0aGUgbG9nIGl0c2VsZiAtLSBzZW5k
IGFuIGUtbWFpbCB0byB0aGUgYWRkcmVzcyBpbiB0aGVyZSBhbmQgeW91J2xsIGdldCBhIHJlc3Bv
bnNlIHdpdGhpbiB0aGUgTU1ELiAgU2VlbSByZWFzb25hYmxlPw0KDQotIE1hdHQNCg0KLS0NCllv
dSBrbm93IHlvdSBoYXZlIGEgZGlzdHJpYnV0ZWQgc3lzdGVtIHdoZW4gdGhlIGNyYXNoIG9mIGEg
Y29tcHV0ZXIgeW914oCZdmUgbmV2ZXIgaGVhcmQgb2Ygc3RvcHMgeW91IGZyb20gZ2V0dGluZyBh
bnkgd29yayBkb25lLg0KCQktLSBMZXNsaWUgTGFtcG9ydCAiU2VjdXJpdHkgRW5naW5lZXJpbmc6
IEEgR3VpZGUgdG8gQnVpbGRpbmcNCgkJICAgRGVwZW5kYWJsZSBEaXN0cmlidXRlZCBTeXN0ZW1z
Ig0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVHJh
bnMgbWFpbGluZyBsaXN0DQpUcmFuc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby90cmFucw0K


From nobody Fri Jul 18 13:52:24 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030AC1A0146 for ; Fri, 18 Jul 2014 13:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 LCszHd1h5RZr for ; Fri, 18 Jul 2014 13:52:20 -0700 (PDT)
Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2CE1A00C3 for ; Fri, 18 Jul 2014 13:52:19 -0700 (PDT)
X-AuditID: a66201d1-f79bd6d0000018ae-82-53c989003b82
Received: from tus1smtintpin02.ges.symantec.com (tus1smtintpin02.ges.symantec.com [192.168.215.102]) by ecl1mtaoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id A4.B9.06318.00989C35; Fri, 18 Jul 2014 20:52:17 +0000 (GMT)
Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1smtintpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1X8F8a-00045W-Az; Fri, 18 Jul 2014 20:52:16 +0000
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Fri, 18 Jul 2014 13:52:16 -0700
From: Rick Andrews 
To: Jeremy Rowley , 'Matt Palmer' , "'trans@ietf.org'" 
Date: Fri, 18 Jul 2014 13:52:15 -0700
Thread-Topic: [Trans] List of Roots Accepted by Log Servers
Thread-Index: Ac+irl+ii5Y1QiW8SKiN+XC17uqP9gASSQ6AAAxXT5AAGAdmcA==
Message-ID: <544B0DD62A64C1448B2DA253C011414607CD4761AA@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20140718201657.GU17452@hezmatt.org> <7691eb56329c4b6ca2cf30801eb7ce32@EX1.corp.digicert.com>
In-Reply-To: <7691eb56329c4b6ca2cf30801eb7ce32@EX1.corp.digicert.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsVyYMX1NF3GzpPBBssamC1Ono206Gm9ymSx 9vFFFgdmj/1zXzJ7THt/jM1jyZKfTAHMUVw2Kak5mWWpRfp2CVwZPy9/ZitYo19xctUF5gbG CXpdjJwcEgImEhNPHWaDsMUkLtxbD2RzcQgJfGSUePyrkxkkISTwilFi+ww9iMQqRomWEzuY QBJsAnoSWx5fYQexRQSqJJ7dXcjSxcjBwSKgKnHufiJIWFjASuLG9h9sECXWEgd//GIHKRER cJL4PFUHJMwrECXxtW0PK8T4PYwSS3/NYwSp4RRwldh9yRGkhhHotu+n1oBtZRYQl7j1ZD4T xM0CEkv2nGeGsEUlXj7+xwpRLypxp3092BhmAU2J9bv0IVoVJaZ0P2SHWCsocXLmE5YJjGKz kEydhdAxC0nHLCQdCxhZVjHKpCbnGOaWJOaXlhSkVhgY6hVX5iYCoypZLzk/dxMjMLKWJTFe 3MF44bDuIUYBDkYlHl6/6pPBQqyJZUCVhxglOJiVRHidyoFCvCmJlVWpRfnxRaU5qcWHGKU5 WJTEebu1TwQLCaQnlqRmp6YWpBbBZJk4OKUaGAskVFxuWog4Gh7c/2ueWWH6tRSOPgO9J/qc 6ievH++5vnj1KnaGR83O6gv72ue8ym08LLTh26V/ij6qF1TXSM1fs+EgxxROx74tojHfhbYd Ddz1UUt39o7uqlXz9SQcVxf0PZez+XC5ZjOTteuuH6em6bJ8jlSfpOWyh+c+76MS4/xLYYW3 vyqxFGckGmoxFxUnAgBej0WXqAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Z6IRg13O1HWmGQYpLKHtGivzyFk
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 18 Jul 2014 20:52:22 -0000

TWF0dCwgSmVyZW15LA0KDQpNYXR0IGFza2VkICJXaHkgd291bGQgYSByb290IENBIG9wZXJhdG9y
IGhhdmUgYWRkZWQgdGhlaXIgcm9vdCBjZXJ0IHRvIGEgYnJvd3NlciB0cnVzdCBzdG9yZSBpZiB0
aGV5IHdlcmVuJ3QgaW50ZW5kaW5nIHRvIGlzc3VlIHRydXN0ZWQgY2VydGlmaWNhdGVzPyIgQmVj
YXVzZSB3ZSBhbHNvIGlzc3VlIGNsaWVudCBhdXRoIGNlcnRpZmljYXRlcywgUy9NSU1FIGNlcnRp
ZmljYXRlcywgY29kZSBzaWduaW5nIGNlcnRpZmljYXRlcywgdGltZXN0YW1waW5nIGNlcnRpZmlj
YXRlcywgZXRjLiBJZiBHb29nbGUgaGFkIGZpbHRlcmVkIG91dCBqdXN0IHRob3NlIHJvb3RzIHdp
dGhvdXQgdGhlICJUaGlzIGNlcnRpZmljYXRlIGNhbiBpZGVudGlmeSB3ZWJzaXRlcyIgYml0IHNl
dCwgdGhhdCB3b3VsZCBoYXZlIGVsaW1pbmF0ZWQgYSBsb3Qgb2YgdGhlIGlycmVsZXZhbnQgcm9v
dHMuDQoNCk1hdHQgYWxzbyBhc2tlZCAiSSdtIHBsYW5uaW5nIG9uIHB1Ymxpc2hpbmcgb3BlcmF0
b3IgY29udGFjdCBkZXRhaWxzIGluIG9yIG5lYXIgdGhlIGxvZyBpdHNlbGYgLS0gc2VuZCBhbiBl
LW1haWwgdG8gdGhlIGFkZHJlc3MgaW4gdGhlcmUgYW5kIHlvdSdsbCBnZXQgYSByZXNwb25zZSB3
aXRoaW4gdGhlIE1NRC4gIFNlZW0gcmVhc29uYWJsZT8iIFllcywgZGVmaW5pdGVseS4NCg0KSmVy
ZW15LCBpZiB3ZSBkb24ndCB3YW50IHRvIGFkZCBvdXIgY2VydHMgdG8gYSBzcGVjaWZpYyBsb2cs
IHlvdSdyZSByaWdodCB0aGF0IHdlIGNhbiBhdm9pZCB1c2luZyB0aGF0IGxvZy4gQnV0IENUIGFs
bG93cyBhbnlvbmUgKHRoZSBDQSwgdGhlIG93bmVyIG9mIHRoZSBjZXJ0LCBhbiBpbnRlcmVzdGVk
IHBhcnR5KSB0byBsb2cgYW55IGNlcnQgaW4gYW55IGxvZyBzZXJ2ZXIuIEJ5IGtlZXBpbmcgYWxs
IHRoZXNlIHJvb3RzIGluIGEgbG9nIHNlcnZlciwgd2UncmUgYWxsb3dpbmcgYW55IHR5cGUgb2Yg
Y2VydCB0byBiZSBhZGRlZCB0byB0aGUgbG9nLiBXZSBtYXkgZ2V0IHRoZXJlIHNvbWVkYXksIGJ1
dCB0aGF0J3Mgbm90IHRoZSBpbnRlbnQgZm9yIHRoaXMgZmlyc3QgdXNlIG9mIENULiBXZSdyZSBm
b2N1c2VkIG9uIEVWIFNTTCBjZXJ0cy4gTGV0J3Mgbm90IGZvcmNlIG1vbml0b3JzIGFuZCBhdWRp
dG9ycyB0byB3YWRlIHRocm91Z2ggaXJyZWxldmFudCBjZXJ0cy4NCg0KLVJpY2sNCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRyYW5zIFttYWlsdG86dHJhbnMtYm91bmNlc0Bp
ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEplcmVteSBSb3dsZXkNClNlbnQ6IEZyaWRheSwgSnVseSAx
OCwgMjAxNCAxOjMyIFBNDQpUbzogJ01hdHQgUGFsbWVyJzsgJ3RyYW5zQGlldGYub3JnJw0KU3Vi
amVjdDogUmU6IFtUcmFuc10gTGlzdCBvZiBSb290cyBBY2NlcHRlZCBieSBMb2cgU2VydmVycw0K
DQpBbHRob3VnaCBJIGNhbiBzZWUgdGhlIGFwcGVhbCBmb3IgYSBwcm9jZXNzIHdpdGggR29vZ2xl
IG9wZXJhdGVkIGxvZ3MsIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgbXVjaCB2YWx1ZSBpbiBjcmVh
dGluZyBhIHN5c3RlbSB0byBhZGQvcmVtb3ZlIHJvb3RzIGZyb20gYSBsb2cgYXQgYSBDQSdzIHJl
cXVlc3QuICBJZiBDQXMgZG9uJ3Qgd2FudCB0byBpbmNsdWRlIHRoZWlyIGNlcnQgb24gYSBzcGVj
aWZpYyBsb2csIHRoZSBDQSBzaG91bGRuJ3QgZXZlciBoaXQgdGhlIGxvZyB3aXRoIGEgcHJlLWNl
cnQuICAgRm9yIG91ciBsb2csIHdlIGFyZSBzaW1wbHkgZ29pbmcgdG8gZW5hYmxlIHJvb3RzIGFz
IHdlIHNlZSBhcHByb3ByaWF0ZSwgbW9zdCBsaWtlZCBiYXNlZCBvbiB0aGUgY2VydHMgdHJ1c3Rl
ZCBpbiBib3RoIE1vemlsbGEgYW5kIE1TIChidXQgd2UgYXJlIHN0aWxsIGRlYmF0aW5nIHRoaXMg
aXNzdWUpLg0KDQpKZXJlbXkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRy
YW5zIFttYWlsdG86dHJhbnMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hdHQgUGFs
bWVyDQpTZW50OiBGcmlkYXksIEp1bHkgMTgsIDIwMTQgMjoxNyBQTQ0KVG86IHRyYW5zQGlldGYu
b3JnDQpTdWJqZWN0OiBSZTogW1RyYW5zXSBMaXN0IG9mIFJvb3RzIEFjY2VwdGVkIGJ5IExvZyBT
ZXJ2ZXJzDQoNCkkgY2FuJ3Qgc3BlYWsgZm9yIEdvb2dsZSwgYnV0IEknbGwgc3BlYWsgYXMgYW4g
aW50ZW5kaW5nIGxvZyBvcGVyYXRvci4NCg0KT24gRnJpLCBKdWwgMTgsIDIwMTQgYXQgMTE6MTE6
MjRBTSAtMDcwMCwgUmljayBBbmRyZXdzIHdyb3RlOg0KPiBNeSB0aGlua2luZyBpcyB0aGF0IGlm
IEkgc29tZWhvdyBpc3N1ZSBhbiBTU0wgY2VydCBmcm9tIGEgcm9vdCB0aGF0IEkgDQo+IGRpZCBu
b3QgaW50ZW5kIHRvIHVzZSBmb3IgU1NMLCBJIHdvdWxkIHByZWZlciB0byBjYXRjaCB0aGF0IGFz
IHF1aWNrbHkgDQo+IGFzIHBvc3NpYmxlOyBpZGVhbGx5LCB3aGVuIHRoZSBsb2cgc2VydmVyIHJl
ZnVzZXMgdG8gZ2l2ZSBtZSBhbiBTQ1QuDQo+IElzIEdvb2dsZSB3aWxsaW5nIHRvIHJlbW92ZSBy
b290cyBmcm9tIHBpbG90IGFuZCBhdmlhdG9yPw0KDQpJJ2QgYmUgd2lsbGluZyB0byByZW1vdmUg
cm9vdCBjZXJ0cyBmcm9tIHRoZSBsb2dzIEkgcnVuIGlmIHJlcXVlc3RlZCwgYmFzZWQgb24gYSBz
dWl0YWJseSBhdXRoZW50aWNhdGVkIGNvbW11bmljYXRpb24gZnJvbSB0aGUgQ0Egb3BlcmF0b3Iu
DQoNCkkgd29uZGVyLCB0aG91Z2gsIHdoeSBhIHJvb3QgQ0EgY2VydGlmaWNhdGUgd291bGQgZW5k
IHVwIGluIGEgbG9nIGluIHRoZSBmaXJzdCBwbGFjZSBpZiBpdCB3YXNuJ3QgaW50ZW5kZWQgdG8g
cHJvZHVjZSBwdWJsaWNhbGx5LXRydXN0ZWQgY2VydGlmaWNhdGVzLiAgTGlrZSB5b3UsIEkndmUg
YmVlbiBsZWQgdG8gYmVsaWV2ZSB0aGF0IEdvb2dsZSBzY3JhcGVkIG9uZSBvciBtb3JlIGJyb3dz
ZXIgdHJ1c3Qgc3RvcmVzIGZvciB0aGUgbGlzdCBvZiBjZXJ0cyBvbiBwaWxvdC9hdmlhdG9yLiAg
V2h5IHdvdWxkIGEgcm9vdCBDQSBvcGVyYXRvciBoYXZlIGFkZGVkIHRoZWlyIHJvb3QgY2VydCB0
byBhIGJyb3dzZXIgdHJ1c3Qgc3RvcmUgaWYgdGhleSB3ZXJlbid0IGludGVuZGluZyB0byBpc3N1
ZSB0cnVzdGVkIGNlcnRpZmljYXRlcz8gIElmIHRoZSByb290IHdhcyBhZGRlZCBmb3IgYSBub24t
d2ViLXNlcnZlciB0cnVzdCBiaXQsIEkgc2VlIHRoYXQgYXMgYmVpbmcgd2l0aGluIHRoZSBwdXJ2
aWV3IG9mIENULCBiZWNhdXNlIEknZCBsaWtlIHRvIGJlIGFibGUgdG8gYXVkaXQgZm9yIHRoZSBp
c3N1YW5jZSBvZiBjb2RlIHNpZ25pbmcgYW5kIGUtbWFpbCBjZXJ0aWZpY2F0ZXMgYXMgd2VsbC4N
Cg0KPiBJIHRoaW5rIHdlIG5lZWQgYSBzb21ld2hhdCBmb3JtYWwgd2F5IGZvciBDQXMgdG8gcHJv
dmlkZSBsb2cgc2VydmVyIA0KPiBvcGVyYXRvcnMgdGhlaXIgbGlzdCBvZiByb290cywgYW5kIHVw
ZGF0ZSB0aGF0IG92ZXIgdGltZS4gIEZvciANCj4gZXhhbXBsZSwgd2UgaGF2ZSBhIGZldyBuZXcg
cm9vdHMgdGhhdCB3ZSBleHBlY3QgdG8gYmUgdXNpbmcgaW4gdGhlIA0KPiBuZXh0IGZldyBtb250
aHMsIGFuZCBJIG5lZWQgdG8gbWFrZSBzdXJlIHRoZXkncmUgYWRkZWQgdG8gbG9nIHNlcnZlcnMg
DQo+IGJlZm9yZSBJIHN0YXJ0IHVzaW5nIHRoZW0uICBJZiBsb2cgc2VydmVyIG9wZXJhdG9ycyBw
cm92aWRlIGFuIHNlcnZpY2UgDQo+IGxldmVsIGFncmVlbWVudCAoU0xBKSBmb3Igc3VjaCBjaGFu
Z2VzLCB0aGF0IHdvdWxkIGJlIGdyZWF0Lg0KDQpJJ20gcGxhbm5pbmcgb24gcHVibGlzaGluZyBv
cGVyYXRvciBjb250YWN0IGRldGFpbHMgaW4gb3IgbmVhciB0aGUgbG9nIGl0c2VsZiAtLSBzZW5k
IGFuIGUtbWFpbCB0byB0aGUgYWRkcmVzcyBpbiB0aGVyZSBhbmQgeW91J2xsIGdldCBhIHJlc3Bv
bnNlIHdpdGhpbiB0aGUgTU1ELiAgU2VlbSByZWFzb25hYmxlPw0KDQotIE1hdHQNCg0KLS0NCllv
dSBrbm93IHlvdSBoYXZlIGEgZGlzdHJpYnV0ZWQgc3lzdGVtIHdoZW4gdGhlIGNyYXNoIG9mIGEg
Y29tcHV0ZXIgeW914oCZdmUgbmV2ZXIgaGVhcmQgb2Ygc3RvcHMgeW91IGZyb20gZ2V0dGluZyBh
bnkgd29yayBkb25lLg0KCQktLSBMZXNsaWUgTGFtcG9ydCAiU2VjdXJpdHkgRW5naW5lZXJpbmc6
IEEgR3VpZGUgdG8gQnVpbGRpbmcNCgkJICAgRGVwZW5kYWJsZSBEaXN0cmlidXRlZCBTeXN0ZW1z
Ig0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVHJh
bnMgbWFpbGluZyBsaXN0DQpUcmFuc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby90cmFucw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NClRyYW5zIG1haWxpbmcgbGlzdA0KVHJhbnNAaWV0Zi5vcmcNCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbnMNCg==


From nobody Fri Jul 18 13:58:27 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F331AD6B0 for ; Fri, 18 Jul 2014 13:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.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 nSv243qqxf1a for ; Fri, 18 Jul 2014 13:58:24 -0700 (PDT)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D511B279B for ; Fri, 18 Jul 2014 13:58:23 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id at1so4998366iec.16 for ; Fri, 18 Jul 2014 13:58:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LpPsgFBi4cuhN0kOV2T/oLApXpCRhOB4kUxrnuztXiY=; b=SQbXKkAKgC3xo+4kiG2XCSZckX7+jeLJka9yYj+UlUw9PjFMkWlelZrsJSC5T72XD/ zcK1MBLEASY1cLxhc184in/6YiZiGoW6LPJ1nwWa7LM7XjoM6YSlbqPk/kHdZ4ACdga0 p5O4X+09iD6wRUfWzvdW6PMaZbn55rq179HvmuXET455E1V0sBSkMeY8Gg69p9DFDU+0 Jtvgu8wf/l8dvLjgxzc8/wQR+zBofNLs388Ropc6LWvqgGepel18AAhCcHQ+dQexX5Yz RRvmCzY+he8bhQ6BgZ9EdIO0Fh77RZnKSxgHGveVtCkFechuAO6q+2zO8zgigln9oSoS vssA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LpPsgFBi4cuhN0kOV2T/oLApXpCRhOB4kUxrnuztXiY=; b=cG3f++iVDnhphbvHS2fuETGPwzfy5vNQ2k6+r8gZrr61PInF/+aTYlUBpRjwi1YaxC cB7qsNdm9JfctEuH4yBLQtftkDSiUS97pjfxEdasCnJuoa2rRuJrPZKZGJe0vozdt0+X eaVtUGzrunyUjZx+eFGlMb5eu0VCKRkuBv/+X2/qwIfG3saj1uq7+ns1tAgO9gZNeVfU SpqNO1HTub/zh79bYBvBATl9hJuybZ1k1BS2QoVleeOqHoXa6qOofr+y9zDh88Xa4plF gEHqvRcAq88fE4FjAt4hTmXoDPtNfH529BIqjRkR9M2MxfMjCUx+wOR/Q+xgXB+h6fD8 t0Uw==
X-Gm-Message-State: ALoCoQkWz//VJYO+Crmqwd/xggDF9Cg2VINm4n/XM5ArKPnwL8fEVb0k3hdR9YiZWCcPl3cxlmQV
MIME-Version: 1.0
X-Received: by 10.42.32.136 with SMTP id e8mr11056600icd.44.1405717103166; Fri, 18 Jul 2014 13:58:23 -0700 (PDT)
Received: by 10.64.97.65 with HTTP; Fri, 18 Jul 2014 13:58:23 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Fri, 18 Jul 2014 21:58:23 +0100
Message-ID: 
From: Ben Laurie 
To: Rick Andrews 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/vnavNvX4qpA2uvdsR9Vd7PfXsmg
Cc: "trans@ietf.org" 
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 18 Jul 2014 20:58:25 -0000

On 18 July 2014 19:11, Rick Andrews  wrote:
> I finally got around to reading the list of roots accepted by the pilot a=
nd
> aviator log servers (using the get-roots command). I see a number of our
> roots that seem inappropriate to me, meaning that we have never issued SS=
L
> certs (EV or non-EV) from those roots, and never intend to. It seems to m=
e
> that Google cast a wide net to add all relevant roots to kickstart the lo=
g
> servers (perhaps bootstrapped from Mozilla=E2=80=99s root list?), but at =
some point
> (before CT is =E2=80=9Clive=E2=80=9D) I would like to see the list trimme=
d.

The list is the union of the roots accepted by popular browsers on
popular platforms.

> My thinking is that if I somehow issue an SSL cert from a root that I did
> not intend to use for SSL, I would prefer to catch that as quickly as
> possible; ideally, when the log server refuses to give me an SCT. Is Goog=
le
> willing to remove roots from pilot and aviator?

Yes, it if makes sense.

> I think we need a somewhat formal way for CAs to provide log server
> operators their list of roots, and update that over time. For example, we
> have a few new roots that we expect to be using in the next few months, a=
nd
> I need to make sure they=E2=80=99re added to log servers before I start u=
sing them.
> If log server operators provide an service level agreement (SLA) for such
> changes, that would be great.
>
> Comments?
>
> -Rick
>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>


From nobody Fri Jul 18 14:10:04 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241431B2A65 for ; Fri, 18 Jul 2014 14:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 86yG6r2ZNZY7 for ; Fri, 18 Jul 2014 14:09:59 -0700 (PDT)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80161B2A44 for ; Fri, 18 Jul 2014 14:09:59 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id B08751C20D6; Fri, 18 Jul 2014 23:09:57 +0200 (CEST)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 73C1E1FE05AF; Fri, 18 Jul 2014 23:09:57 +0200 (CEST)
Date: Fri, 18 Jul 2014 23:09:57 +0200
From: Kurt Roeckx 
To: Rick Andrews 
Message-ID: <20140718210957.GA3326@roeckx.be>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/uhvPPoReiltFQ8W_gvUQif3TO6s
Cc: "trans@ietf.org" 
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 18 Jul 2014 21:10:02 -0000

On Fri, Jul 18, 2014 at 11:11:24AM -0700, Rick Andrews wrote:
> I finally got around to reading the list of roots accepted by the pilot and aviator log servers (using the get-roots command). I see a number of our roots that seem inappropriate to me, meaning that we have never issued SSL certs (EV or non-EV) from those roots, and never intend to. It seems to me that Google cast a wide net to add all relevant roots to kickstart the log servers (perhaps bootstrapped from Mozilla's root list?), but at some point (before CT is "live") I would like to see the list trimmed.
> 
> My thinking is that if I somehow issue an SSL cert from a root that I did not intend to use for SSL, I would prefer to catch that as quickly as possible; ideally, when the log server refuses to give me an SCT. Is Google willing to remove roots from pilot and aviator?

It's my understanding that CT shouldn't only work for HTTPS, but
for all different kind of certificates.  Maybe you want a log that
only contains HTTPS, and have logs for different kind of
certificates?


Kurt


From nobody Fri Jul 18 14:16:06 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D934A1B2A73 for ; Fri, 18 Jul 2014 14:16:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level: 
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V418Lz3W5uV2 for ; Fri, 18 Jul 2014 14:16:02 -0700 (PDT)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id EFC771B2A6D for ; Fri, 18 Jul 2014 14:16:00 -0700 (PDT)
From: Jeremy Rowley 
To: 'Kurt Roeckx' , 'Rick Andrews' 
Thread-Topic: [Trans] List of Roots Accepted by Log Servers
Thread-Index: Ac+irl+ii5Y1QiW8SKiN+XC17uqP9gAUIuqAAAyFmGA=
Date: Fri, 18 Jul 2014 21:15:47 +0000
Message-ID: <61b510abc9f94c2292ea0685c068bad5@EX1.corp.digicert.com>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20140718210957.GA3326@roeckx.be>
In-Reply-To: <20140718210957.GA3326@roeckx.be>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [67.137.52.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/M45qdpwdvdGFYIGXuDpi0mg4KuQ
Cc: "'trans@ietf.org'" 
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 18 Jul 2014 21:16:04 -0000

Although CT could function for all types of certificates, Google doesn't ne=
cessarily utilize client or code signing certs.  Until other software vendo=
rs implement CT as a requirement, you'll likely only see CT used for SSL.  =
Plus, utilizing the logs only for SSL reduces log size.  Logging every clie=
nt certificate issued will quickly fill up the log with less important info=
rmation.=20

Jeremy

-----Original Message-----
From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Kurt Roeckx
Sent: Friday, July 18, 2014 3:10 PM
To: Rick Andrews
Cc: trans@ietf.org
Subject: Re: [Trans] List of Roots Accepted by Log Servers

On Fri, Jul 18, 2014 at 11:11:24AM -0700, Rick Andrews wrote:
> I finally got around to reading the list of roots accepted by the pilot a=
nd aviator log servers (using the get-roots command). I see a number of our=
 roots that seem inappropriate to me, meaning that we have never issued SSL=
 certs (EV or non-EV) from those roots, and never intend to. It seems to me=
 that Google cast a wide net to add all relevant roots to kickstart the log=
 servers (perhaps bootstrapped from Mozilla's root list?), but at some poin=
t (before CT is "live") I would like to see the list trimmed.
>=20
> My thinking is that if I somehow issue an SSL cert from a root that I did=
 not intend to use for SSL, I would prefer to catch that as quickly as poss=
ible; ideally, when the log server refuses to give me an SCT. Is Google wil=
ling to remove roots from pilot and aviator?

It's my understanding that CT shouldn't only work for HTTPS, but for all di=
fferent kind of certificates.  Maybe you want a log that only contains HTTP=
S, and have logs for different kind of certificates?


Kurt

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


From nobody Fri Jul 18 17:12:09 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A461A02D6 for ; Fri, 18 Jul 2014 17:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 4bPC3DLKRcmv for ; Fri, 18 Jul 2014 17:12:07 -0700 (PDT)
Received: from prodomx03.usaa.com (prodomx03.usaa.com [167.24.101.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0A01A0203 for ; Fri, 18 Jul 2014 17:12:07 -0700 (PDT)
Received: from pps.filterd (prodomx03.usaa.com [127.0.0.1]) by prodomx03.usaa.com (8.14.5/8.14.5) with SMTP id s6J0ATsN011388 for ; Fri, 18 Jul 2014 19:12:06 -0500
Received: from pps.reinject (localhost [127.0.0.1]) by prodomx03.usaa.com with ESMTP id 1n4f6j3rh8-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Jul 2014 19:12:06 -0500
Received: from prodomx03.usaa.com (prodomx03.usaa.com [127.0.0.1]) by pps.reinject (8.14.5/8.14.5) with SMTP id s6J0C6Jb012496 for ; Fri, 18 Jul 2014 19:12:06 -0500
Received: from prodexch03w.eagle.usaa.com (prodexch03w.usaa.com [10.70.41.152]) by prodomx03.usaa.com with ESMTP id 1n4f6j3rh6-1; Fri, 18 Jul 2014 19:12:06 -0500
Received: from PRODEXCH11W.eagle.usaa.com (10.70.40.36) by PRODEXCH03W.eagle.usaa.com (10.70.41.152) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Jul 2014 19:12:05 -0500
Received: from PRODEXMB01W.eagle.usaa.com ([169.254.1.97]) by PRODEXCH11W.eagle.usaa.com ([10.70.40.36]) with mapi id 14.03.0158.001; Fri, 18 Jul 2014 19:12:05 -0500
From: "Mehner, Carl" 
To: Rick Andrews , "trans@ietf.org" 
Thread-Topic: List of Roots Accepted by Log Servers
Thread-Index: Ac+irl+ii5Y1QiW8SKiN+XC17uqP9gANUUDo
Date: Sat, 19 Jul 2014 00:12:04 +0000
Message-ID: <19075EB00EA7FE49AFF87E5818D673D4111AE279@PRODEXMB01W.eagle.usaa.com>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.170.30.9]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Direction: Internet
X-Proofpoint-Direction: FromExch
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14,  0.0.0000 definitions=2014-07-18_06:2014-07-18,2014-07-18,1970-01-01 signatures=0
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/9d23p33vuIG2sVsAUsrPFQ8_CxY
Subject: Re: [Trans] List of Roots Accepted by Log Servers
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Jul 2014 00:12:09 -0000

Hi Rick,

I think that it might be best to have a glut of roots for now. This way, yo=
u (as a CA) can monitor the logs to see if anyone has issued a cert that co=
uld be valid for SSL off of any =93inappropriate=94 root and I (as a host o=
perator) can monitor to see if someone has issued anything off that (or any=
) root for our domain. At least until all the major browsers/platforms requ=
ire CT for all SSL connections. Otherwise, someone could issue a cert for o=
ur domain that could be used for SSL transport of data between a server and=
 a non-CT validating client (which I expect to remain in plentiful supply f=
or several years).

On the other hand, even though it's predominantly for TLS, that is not the =
only thing that CT is useful for. I would not mind a window into who is iss=
uing s/mime certs, code signing certs, and any number of other cert types f=
or our domain in order to put a stop to issuance against our standards and =
policy. So perhaps casting the widest net of roots that, as Ben says, does =
not =93suddenly become spammy=94 would be best. Although, as Jeremy pointed=
 out, this could increase log size by quite a bit.

-carl

________________________________
From: Trans [trans-bounces@ietf.org] on behalf of Rick Andrews [Rick_Andrew=
s@symantec.com]
Sent: Friday, July 18, 2014 1:11 PM
To: trans@ietf.org
Subject: EXTERNAL: [Trans] List of Roots Accepted by Log Servers

I finally got around to reading the list of roots accepted by the pilot and=
 aviator log servers (using the get-roots command). I see a number of our r=
oots that seem inappropriate to me, meaning that we have never issued SSL c=
erts (EV or non-EV) from those roots, and never intend to. It seems to me t=
hat Google cast a wide net to add all relevant roots to kickstart the log s=
ervers (perhaps bootstrapped from Mozilla=92s root list?), but at some poin=
t (before CT is =93live=94) I would like to see the list trimmed.

My thinking is that if I somehow issue an SSL cert from a root that I did n=
ot intend to use for SSL, I would prefer to catch that as quickly as possib=
le; ideally, when the log server refuses to give me an SCT. Is Google willi=
ng to remove roots from pilot and aviator?

I think we need a somewhat formal way for CAs to provide log server operato=
rs their list of roots, and update that over time. For example, we have a f=
ew new roots that we expect to be using in the next few months, and I need =
to make sure they=92re added to log servers before I start using them. If l=
og server operators provide an service level agreement (SLA) for such chang=
es, that would be great.

Comments?

-Rick



From nobody Fri Jul 18 18:02:52 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A731A02F4 for ; Fri, 18 Jul 2014 18:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 XeTllgUrlSjk for ; Fri, 18 Jul 2014 18:02:48 -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 AF92E1A02F2 for ; Fri, 18 Jul 2014 18:02:48 -0700 (PDT)
X-AuditID: a66201d2-f78ff6d0000015f3-28-53c9c3b659f9
Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by ecl1mtaoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id B0.01.05619.7B3C9C35; Sat, 19 Jul 2014 01:02:47 +0000 (GMT)
Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1X8J30-00012x-R4; Sat, 19 Jul 2014 01:02:46 +0000
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Fri, 18 Jul 2014 18:02:47 -0700
From: Rick Andrews 
To: "Mehner, Carl" , "trans@ietf.org" 
Date: Fri, 18 Jul 2014 18:02:44 -0700
Thread-Topic: List of Roots Accepted by Log Servers
Thread-Index: Ac+irl+ii5Y1QiW8SKiN+XC17uqP9gANUUDoAAEsdJA=
Message-ID: <544B0DD62A64C1448B2DA253C011414607CD476516@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <19075EB00EA7FE49AFF87E5818D673D4111AE279@PRODEXMB01W.eagle.usaa.com>
In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D4111AE279@PRODEXMB01W.eagle.usaa.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsVyYMU1Hd3th08GG2zbJWMxd/sPVou1jy+y ODB5LFnyk8lj8bMXbAFMUVw2Kak5mWWpRfp2CVwZL7b8ZC14LVsx5/lSpgbGS+JdjJwcEgIm Emcu7mCHsMUkLtxbz9bFyMUhJPCBUeJJ4yEo5xWjRNvZ7ywQzipGiYPTFjGDtLAJ6ElseXwF rF1EwEfi9omPbCA2i4CqxLWGg0wgtrCAkcSD6dtYIWqMJU5u3sQEYVtJ7H71FqyXVyBKYnf/ AUaIBYsYJT41fwNbwCkQJHG79QBYMyPQfd9PrQFrZhYQl7j1ZD4TxN0CEkv2nGeGsEUlXj7+ B1UvKnGnfT0jRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlW McqkJucY5pYk5peWFKRWGBjpFVfmJgLjKVkvOT93EyMwppYlMV7awXj/sO4hRgEORiUeXsHN J4OFWBPLgCoPMUpwMCuJ8LqsAQrxpiRWVqUW5ccXleakFh9ilOZgURLn7dY+ESwkkJ5Ykpqd mlqQWgSTZeLglGpgrDjyrfS+UWn3ov+zMxaUsE+yi7TYJPGYebeEnNT9NwcLttZ3pvut8pnW +iw+9Yn+0y3dPzYWHny/5tT9JznP523Ze+Xgj4jZUlLqzsef34mu7LO5mzmB/8fGszUT3u29 xCwjdPW2kk/A5xNrjvTvYahK+Z93KSrl4fzp2w+bs4ffvvr5yvcX5mZKLMUZiYZazEXFiQDj HNDZpQIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/N_08Ojeib5O3yE6lpFnNnIcS19M
Subject: Re: [Trans] List of Roots Accepted by Log Servers
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Jul 2014 01:02:50 -0000

Carl,

Unless I've lost control over my private keys, I don't need to monitor CT l=
ogs to see if anyone else has issued an SSL cert from one of my inappropria=
te roots. I can just look in my database.

Within the CA/Browser Forum, there's been a lot of discussion about how to =
define an SSL cert, but unfortunately every browser (and every non-browser =
app that acts as a TLS client) seems to have a different definition, and it=
 doesn't seem likely that we'll ever reach consensus. My point is that for =
the moment, CT is a browser initiative, and one browser is building support=
 for it. You're not alone in thinking that CT is useful beyond TLS; there's=
 been a lot of discussion about where else it might be used. However, I thi=
nk it's prudent to work out the kinks with a limited set of certs first, wh=
ich is why I think Google decided to limit it to Chrome-based EV SSL for no=
w.

-Rick

-----Original Message-----
From: Mehner, Carl [mailto:Carl.Mehner@usaa.com]=20
Sent: Friday, July 18, 2014 5:12 PM
To: Rick Andrews; trans@ietf.org
Subject: RE: List of Roots Accepted by Log Servers

Hi Rick,

I think that it might be best to have a glut of roots for now. This way, yo=
u (as a CA) can monitor the logs to see if anyone has issued a cert that co=
uld be valid for SSL off of any "inappropriate" root and I (as a host opera=
tor) can monitor to see if someone has issued anything off that (or any) ro=
ot for our domain. At least until all the major browsers/platforms require =
CT for all SSL connections. Otherwise, someone could issue a cert for our d=
omain that could be used for SSL transport of data between a server and a n=
on-CT validating client (which I expect to remain in plentiful supply for s=
everal years).

On the other hand, even though it's predominantly for TLS, that is not the =
only thing that CT is useful for. I would not mind a window into who is iss=
uing s/mime certs, code signing certs, and any number of other cert types f=
or our domain in order to put a stop to issuance against our standards and =
policy. So perhaps casting the widest net of roots that, as Ben says, does =
not "suddenly become spammy" would be best. Although, as Jeremy pointed out=
, this could increase log size by quite a bit.

-carl

________________________________
From: Trans [trans-bounces@ietf.org] on behalf of Rick Andrews [Rick_Andrew=
s@symantec.com]
Sent: Friday, July 18, 2014 1:11 PM
To: trans@ietf.org
Subject: EXTERNAL: [Trans] List of Roots Accepted by Log Servers

I finally got around to reading the list of roots accepted by the pilot and=
 aviator log servers (using the get-roots command). I see a number of our r=
oots that seem inappropriate to me, meaning that we have never issued SSL c=
erts (EV or non-EV) from those roots, and never intend to. It seems to me t=
hat Google cast a wide net to add all relevant roots to kickstart the log s=
ervers (perhaps bootstrapped from Mozilla's root list?), but at some point =
(before CT is "live") I would like to see the list trimmed.

My thinking is that if I somehow issue an SSL cert from a root that I did n=
ot intend to use for SSL, I would prefer to catch that as quickly as possib=
le; ideally, when the log server refuses to give me an SCT. Is Google willi=
ng to remove roots from pilot and aviator?

I think we need a somewhat formal way for CAs to provide log server operato=
rs their list of roots, and update that over time. For example, we have a f=
ew new roots that we expect to be using in the next few months, and I need =
to make sure they're added to log servers before I start using them. If log=
 server operators provide an service level agreement (SLA) for such changes=
, that would be great.

Comments?

-Rick



From nobody Sat Jul 19 04:13:32 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A637E1A0A9D for ; Sat, 19 Jul 2014 04:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.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 F2s7l_l-JNUx for ; Sat, 19 Jul 2014 04:13:28 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D5A1A030E for ; Sat, 19 Jul 2014 04:13:28 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id tp5so5438115ieb.37 for ; Sat, 19 Jul 2014 04:13:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BWwYssZDDfYgG930oRlz542xTqC/OLtUKBaWZOOokD4=; b=jGo7gI2Qh9fVIAEqDmtYXCsuaW1OFRq/iRI7prapAUjHrHG0euTDhLFwmOoBAho1nn A08ATbRF7I2CNqt5SC90/83CEBsaKn3kPWh8M08lUsxpOTnWOkTjDk8NY+9p7dTQsqkd w8NxOKzi2KiG/nckaCEf8QZQsTwSbyLAINqAUShTq+MOgZOo/uAZZnLtmkmQ1UMf9/hu gAHrK5cD05vTzRs19jvl3FvdGvsswtolVlktt8RlGkIMejQAzeaaHgrlL5HPJJiOnVqU wG8VjLjTTFu3sC/Afjf/3pXpHr4MibO+A4bmR/Oh0Os472KCh1lzHcbBs1Rjx8BM38cF 0QtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BWwYssZDDfYgG930oRlz542xTqC/OLtUKBaWZOOokD4=; b=W8sTVS1Nd6T+u8odpQsfwAuDm5Ewfpu7Vf3v9NiK4innJmZqq+CbVRlRxzjx6yuOIA dEgA7KZlbAuTKnKamWjk7JEuHaa4HORNNpJxZpnUBeTS3a2vZXowBm0OjqBpHmsbeI1n 5FUc30rf0fhezGvMFHc11YNzMfZcHd96Eeyn4okF9FvvmHiIfUbQjod8kFWFFSdh2NLg cFAH2TUzQrBV+Ob0XdAJCPbdzrPHDZoKGqbl+dgdeq7mzai6hOGmcmcvpkxXtDfd9So1 35XcJawldg04e3i9rk5qBqarpr3aAGPp9y4DXzwUr39iMJ0IeIN1shK5qeg727hkZIDR rYbQ==
X-Gm-Message-State: ALoCoQn+EwMpWgwm+L7V8jsbZ0fKRdO3H2fxrl48csDWoo9FhOi4WpR447bvohA0TzUQplkutnHr
MIME-Version: 1.0
X-Received: by 10.50.141.170 with SMTP id rp10mr19017292igb.6.1405768407495; Sat, 19 Jul 2014 04:13:27 -0700 (PDT)
Received: by 10.64.97.65 with HTTP; Sat, 19 Jul 2014 04:13:27 -0700 (PDT)
In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D4111AE279@PRODEXMB01W.eagle.usaa.com>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <19075EB00EA7FE49AFF87E5818D673D4111AE279@PRODEXMB01W.eagle.usaa.com>
Date: Sat, 19 Jul 2014 12:13:27 +0100
Message-ID: 
From: Ben Laurie 
To: "Mehner, Carl" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5IZiNNc4etQgbjfyk4Wzj9Jd_kI
Cc: "trans@ietf.org" , Rick Andrews 
Subject: Re: [Trans] List of Roots Accepted by Log Servers
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Jul 2014 11:13:29 -0000

On 19 July 2014 01:12, Mehner, Carl  wrote:
> Hi Rick,
>
> I think that it might be best to have a glut of roots for now. This way, =
you (as a CA) can monitor the logs to see if anyone has issued a cert that =
could be valid for SSL off of any =E2=80=9Cinappropriate=E2=80=9D root and =
I (as a host operator) can monitor to see if someone has issued anything of=
f that (or any) root for our domain. At least until all the major browsers/=
platforms require CT for all SSL connections. Otherwise, someone could issu=
e a cert for our domain that could be used for SSL transport of data betwee=
n a server and a non-CT validating client (which I expect to remain in plen=
tiful supply for several years).

Indeed, one of the nice things about CT (I think) is that it confers
some level of herd immunity, even for non-validating clients.

> On the other hand, even though it's predominantly for TLS, that is not th=
e only thing that CT is useful for. I would not mind a window into who is i=
ssuing s/mime certs, code signing certs, and any number of other cert types=
 for our domain in order to put a stop to issuance against our standards an=
d policy. So perhaps casting the widest net of roots that, as Ben says, doe=
s not =E2=80=9Csuddenly become spammy=E2=80=9D would be best. Although, as =
Jeremy pointed out, this could increase log size by quite a bit.

Log size isn't inherently a problem, unless it becomes truly massive.
Each doubling adds a single hash to inclusion proofs. STH consistency
proof size is related to the growth in the log, and so doubling in
size would tend to also add a single hash to those (on average). The
main problem is for monitors, but even so, the size of logs we're
currently looking at are easily managed by monitors.

>
> -carl
>
> ________________________________
> From: Trans [trans-bounces@ietf.org] on behalf of Rick Andrews [Rick_Andr=
ews@symantec.com]
> Sent: Friday, July 18, 2014 1:11 PM
> To: trans@ietf.org
> Subject: EXTERNAL: [Trans] List of Roots Accepted by Log Servers
>
> I finally got around to reading the list of roots accepted by the pilot a=
nd aviator log servers (using the get-roots command). I see a number of our=
 roots that seem inappropriate to me, meaning that we have never issued SSL=
 certs (EV or non-EV) from those roots, and never intend to. It seems to me=
 that Google cast a wide net to add all relevant roots to kickstart the log=
 servers (perhaps bootstrapped from Mozilla=E2=80=99s root list?), but at s=
ome point (before CT is =E2=80=9Clive=E2=80=9D) I would like to see the lis=
t trimmed.
>
> My thinking is that if I somehow issue an SSL cert from a root that I did=
 not intend to use for SSL, I would prefer to catch that as quickly as poss=
ible; ideally, when the log server refuses to give me an SCT. Is Google wil=
ling to remove roots from pilot and aviator?
>
> I think we need a somewhat formal way for CAs to provide log server opera=
tors their list of roots, and update that over time. For example, we have a=
 few new roots that we expect to be using in the next few months, and I nee=
d to make sure they=E2=80=99re added to log servers before I start using th=
em. If log server operators provide an service level agreement (SLA) for su=
ch changes, that would be great.
>
> Comments?
>
> -Rick
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans


From ryan_hurst@hotmail.com  Fri Jul 18 15:14:10 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256871A0205 for ; Fri, 18 Jul 2014 15:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 y0KHxB71-2Nr for ; Fri, 18 Jul 2014 15:14:08 -0700 (PDT)
Received: from COL004-OMC1S11.hotmail.com (col004-omc1s11.hotmail.com [65.55.34.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C1C1A0146 for ; Fri, 18 Jul 2014 15:14:08 -0700 (PDT)
Received: from COL401-EAS484 ([65.55.34.7]) by COL004-OMC1S11.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Fri, 18 Jul 2014 15:14:08 -0700
X-TMN: [wjTrVUY4OlFe/1LPO2gUs0f89qir04hrhysLmse3++k=]
X-Originating-Email: [ryan_hurst@hotmail.com]
Message-ID: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Ryan Hurst 
MIME-Version: 1.0 (1.0)
Date: Fri, 18 Jul 2014 15:14:07 -0700
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20140718210957.GA3326@roeckx.be> <61b510abc9f94c2292ea0685c068bad5@EX1.corp.digicert.com>
In-Reply-To: <61b510abc9f94c2292ea0685c068bad5@EX1.corp.digicert.com>
To: Jeremy Rowley 
Sender: 
X-OriginalArrivalTime: 18 Jul 2014 22:14:08.0232 (UTC) FILETIME=[98341E80:01CFA2D5]
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/DhS56f-o5_gRCMr5gUTLhAMXiaM
X-Mailman-Approved-At: Sat, 19 Jul 2014 13:00:54 -0700
Cc: "trans@ietf.org" , Kurt Roeckx , Rick Andrews 
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 18 Jul 2014 22:15:14 -0000

The transparency offered by CT has value outside of SS;, therefore I am inte=
rested in seeing the log services contain as much information about the WebP=
KI  ecosystem as possible.=20

Of course nothing should require a log service operator to contain informati=
on they are not interested.

With that said this is outside the scope of the specification of CT protocol=
.


Ryan Hurst
@rmhrisk / rmh@unmitigatedrisk.com
=20
Sent from my iPhone

> On Jul 18, 2014, at 2:15 PM, Jeremy Rowley  wr=
ote:
>=20
> Although CT could function for all types of certificates, Google doesn't n=
ecessarily utilize client or code signing certs.  Until other software vendo=
rs implement CT as a requirement, you'll likely only see CT used for SSL.  P=
lus, utilizing the logs only for SSL reduces log size.  Logging every client=
 certificate issued will quickly fill up the log with less important informa=
tion.=20
>=20
> Jeremy
>=20
> -----Original Message-----
> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Kurt Roeckx
> Sent: Friday, July 18, 2014 3:10 PM
> To: Rick Andrews
> Cc: trans@ietf.org
> Subject: Re: [Trans] List of Roots Accepted by Log Servers
>=20
>> On Fri, Jul 18, 2014 at 11:11:24AM -0700, Rick Andrews wrote:
>> I finally got around to reading the list of roots accepted by the pilot a=
nd aviator log servers (using the get-roots command). I see a number of our r=
oots that seem inappropriate to me, meaning that we have never issued SSL ce=
rts (EV or non-EV) from those roots, and never intend to. It seems to me tha=
t Google cast a wide net to add all relevant roots to kickstart the log serv=
ers (perhaps bootstrapped from Mozilla's root list?), but at some point (bef=
ore CT is "live") I would like to see the list trimmed.
>>=20
>> My thinking is that if I somehow issue an SSL cert from a root that I did=
 not intend to use for SSL, I would prefer to catch that as quickly as possi=
ble; ideally, when the log server refuses to give me an SCT. Is Google willi=
ng to remove roots from pilot and aviator?
>=20
> It's my understanding that CT shouldn't only work for HTTPS, but for all d=
ifferent kind of certificates.  Maybe you want a log that only contains HTTP=
S, and have logs for different kind of certificates?
>=20
>=20
> Kurt
>=20
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>=20
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans


From nobody Mon Jul 21 02:32:56 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8035A1B2C9D for ; Mon, 21 Jul 2014 02:32:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] 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 45TOZoPH1RXz for ; Mon, 21 Jul 2014 02:32:51 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) (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 569DD1B28A9 for ; Mon, 21 Jul 2014 02:32:51 -0700 (PDT)
Received: from [192.168.0.101] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B8D70F2024; Mon, 21 Jul 2014 02:32:49 -0700 (PDT)
Message-ID: <53CCDE40.9060301@mozilla.org>
Date: Mon, 21 Jul 2014 10:32:48 +0100
From: Gervase Markham 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Rick Andrews ,  "Mehner, Carl" , "trans@ietf.org" 
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <19075EB00EA7FE49AFF87E5818D673D4111AE279@PRODEXMB01W.eagle.usaa.com> <544B0DD62A64C1448B2DA253C011414607CD476516@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CD476516@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
X-Enigmail-Version: 1.7a1pre
OpenPGP: id=9DF43DBB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/YzQrwpR2nqlDYDehulK6MjZ0j0A
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 21 Jul 2014 09:32:53 -0000

On 19/07/14 02:02, Rick Andrews wrote:
> Unless I've lost control over my private keys, I don't need to
> monitor CT logs to see if anyone else has issued an SSL cert from one
> of my inappropriate roots. I can just look in my database.

Not implying anything about your security, Rick, but one of the benefits
of CT is that people who don't realise that they've lost control of
their private keys can find out! :-)

Gerv


From nobody Mon Jul 21 06:34:31 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8BA1B2DD6 for ; Mon, 21 Jul 2014 06:34:19 -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 7mAKtJiCCSSU for ; Mon, 21 Jul 2014 06:34:13 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB08C1B2DF2 for ; Mon, 21 Jul 2014 06:30:16 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id tr6so6845939ieb.18 for ; Mon, 21 Jul 2014 06:30:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=mPuW5CoimqQ2yAUP6ImFWBMnOnN7Cnf/bFThbEOzj94=; b=kyn7DY8jA2w7RVqpQEktAeb2CydChIHiqJPuHBuHakOr4pHQXMSMmB4tZbiWaLOJio jAt6s77luvtVQUG2LyRpNBtIPzxhTNsDfWmyyWfOrXPUYflF+BKBo3FPjHPt5psAdyoI UbzFWndKu9VP8HDwmZ000l/umfOE8iCQPt4aP5hodDWjPfzGysD2Ss1iHS0CfQ+wZi/T J2G59lyYlkpjKUHxTNgDNWqvWVl/kDxML7kyUeOLAGnYZqbHgJDZzRFnso7fWpQvLLVD j96zPUYJqb6TaALk3u0nYyWS2ScF66oz/bx3RkyimUQjuuw1WA7dVu6Wbona9NhhkWae av/Q==
X-Received: by 10.50.88.37 with SMTP id bd5mr28175528igb.1.1405949416202; Mon, 21 Jul 2014 06:30:16 -0700 (PDT)
Received: from dhcp-9736.meeting.ietf.org (dhcp-9736.meeting.ietf.org. [31.133.151.54]) by mx.google.com with ESMTPSA id kw1sm38770703igb.2.2014.07.21.06.30.15 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 06:30:15 -0700 (PDT)
Message-ID: <53CD15E7.7070003@gmail.com>
Date: Mon, 21 Jul 2014 09:30:15 -0400
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: trans@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/IZVz-seGya8X3CyTYCveptJZ8Fw
Subject: [Trans] Meetecho available during trans session
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, 21 Jul 2014 13:34:19 -0000

For those unable to be physically present during the
trans session on Friday, we've requested Meetecho
coverage.  The link will be: http://www.meetecho.com/ietf90/trans
once the session is underway.

Melinda


From nobody Mon Jul 21 08:08:44 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589D01A00F1 for ; Mon, 21 Jul 2014 08:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 wEs4JGr2qnXu for ; Mon, 21 Jul 2014 08:08:41 -0700 (PDT)
Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC481A0142 for ; Mon, 21 Jul 2014 08:08:41 -0700 (PDT)
X-AuditID: d80ac3f3-f79ab6d000005c59-a3-53cd2cf830e7
Received: from ecl1mtahubpin01.ges.symantec.com (ecl1mtahubpin01.ges.symantec.com [10.48.69.201]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id 1F.39.23641.8FC2DC35; Mon, 21 Jul 2014 16:08:40 +0100 (BST)
Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1X9FCh-0004uQ-Vl; Mon, 21 Jul 2014 15:08:40 +0000
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Mon, 21 Jul 2014 08:08:15 -0700
From: Rick Andrews 
To: Gervase Markham , "Mehner, Carl" ,  "trans@ietf.org" 
Date: Mon, 21 Jul 2014 08:08:13 -0700
Thread-Topic: [Trans] List of Roots Accepted by Log Servers
Thread-Index: Ac+kxr+/W4pu4B58SRG9MiiQGikWCgALTyYw
Message-ID: <544B0DD62A64C1448B2DA253C011414607CD4766EA@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <19075EB00EA7FE49AFF87E5818D673D4111AE279@PRODEXMB01W.eagle.usaa.com> <544B0DD62A64C1448B2DA253C011414607CD476516@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53CCDE40.9060301@mozilla.org>
In-Reply-To: <53CCDE40.9060301@mozilla.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsXCZeB6UveHztlgg9ZbGhZzt/9gtdiz4xqT xdrHF1kcmD2WLPnJ5LH60hVWj8XPXrAFMEdx2aSk5mSWpRbp2yVwZUz5k1ywg6/i4OcFrA2M HXxdjJwcEgImEnsuHWOHsMUkLtxbz9bFyMUhJPCOUeJryzJ2COcVo0T3ug0sIFVCAqsYJR43 RYPYbAJ6ElseXwHrFhEokrjfNIUZxGYRUJW4/GUlE4gtLGAlcWP7DzaIGmuJgz9+QdUbSWxe fQRsJq9AlETTzWvMEMumMEkcvfqQtYuRg4NTQFvi9ZFCkBpGoOu+n1oDNpNZQFzi1pP5TBBX C0gs2XOeGcIWlXj5+B8rRL2oxJ329YwgY5gFNCXW79KHaFWUmNL9kB1iraDEyZlPWCYwis1C MnUWQscsJB2zkHQsYGRZxShTUlpsWJxbkl9aUpBaYWCsV1yZmwiMrGS95PzcTYzA6LrBdfjz DsbfexwPMQpwMCrx8Ippng0WYk0sA6o8xCjBwawkwsurDRTiTUmsrEotyo8vKs1JLT7EKM3B oiTOW6p9IlhIID2xJDU7NbUgtQgmy8TBKdXA2PnCaNnVlxdWTrpgcTHq5vspLuvsU1fp2Czf pNrmIr7n3xf/2JIXhm6te/9abFE7+5I7fOd6G0Ntz7PXDD9cVqvSP6/7ep3FhfDs6aGJcZO2 WyVU3M06XtO17ZSJls+ywHcBk65ubO1czcWqXr3xhsmO8zPuKf+e+sLL1rtdIcP1gn70hppl NkosxRmJhlrMRcWJAK6RV+qqAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mQm-ZbwNsQ1eNTO_kzRSksleKG0
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 21 Jul 2014 15:08:43 -0000

VHJ1ZS4gVGhlIHBvaW50IEknbSB0cnlpbmcgdG8gbWFrZSBpcyB0aGF0IHdlJ3JlIGEgbG9uZyB3
YXkgZnJvbSByZXF1aXJpbmcgU0NUcyBmb3IgYWxsIHR5cGVzIG9mIGNlcnRzLCBTU0wgYW5kIG5v
bi1TU0wuIFVudGlsIGFsbCBhcHBsaWNhdGlvbnMgcmVxdWlyZSBTQ1RzIGZvciBhbGwgdHlwZXMg
b2YgY2VydHMsIEkgc2VlIG5vIHJlYXNvbiB0byBhZGQgdGhlIGNvbXBsZXhpdHkgb2YgbG9nZ2lu
ZyBhbGwgY2VydHMuIEF0IHRoaXMgcG9pbnQgaW4gdGltZSwgR29vZ2xlIHdhbnRzIFNDVHMgZm9y
IEVWIFNTTCBjZXJ0cywgYW5kIHRoYXQncyB3aGF0IEknbSBzaG9vdGluZyBmb3IuIENocm9tZSBr
bm93cyB3aGljaCByb290cyBhcmUgZW5hYmxlZCBmb3IgRVYsIGFuZCBzbyB0aG9zZSBhcmUgdGhl
IG9ubHkgcm9vdHMgdGhhdCBsb2cgc2VydmVycyBNVVNUIGFjY2VwdC4NCg0KT3RoZXIgQ0FzIG1p
Z2h0IHdhbnQgdG8gbG9nIGFsbCB0aGVpciBjZXJ0cy4gUmVseWluZyBwYXJ0aWVzIG1pZ2h0IHdh
bnQgdG8gcHVzaCBldmVyeSBjZXJ0IHRoZXkgc2VlIGludG8gbG9nIHNlcnZlcnMuIEJ1dCBJIHNl
ZSB2YWx1ZSBpbiBsaW1pdGluZyB3aGljaCBvZiBteSByb290cyBhcmUgYWNjZXB0ZWQgYnkgbG9n
IHNlcnZlcnMsIGFuZCBJJ2QgbGlrZSB0aGUgYWJpbGl0eSB0byBjb250cm9sIHRoYXQuDQoNCi1S
aWNrDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBHZXJ2YXNlIE1hcmtoYW0g
W21haWx0bzpnZXJ2QG1vemlsbGEub3JnXSANClNlbnQ6IE1vbmRheSwgSnVseSAyMSwgMjAxNCAy
OjMzIEFNDQpUbzogUmljayBBbmRyZXdzOyBNZWhuZXIsIENhcmw7IHRyYW5zQGlldGYub3JnDQpT
dWJqZWN0OiBSZTogW1RyYW5zXSBMaXN0IG9mIFJvb3RzIEFjY2VwdGVkIGJ5IExvZyBTZXJ2ZXJz
DQoNCk9uIDE5LzA3LzE0IDAyOjAyLCBSaWNrIEFuZHJld3Mgd3JvdGU6DQo+IFVubGVzcyBJJ3Zl
IGxvc3QgY29udHJvbCBvdmVyIG15IHByaXZhdGUga2V5cywgSSBkb24ndCBuZWVkIHRvIG1vbml0
b3IgDQo+IENUIGxvZ3MgdG8gc2VlIGlmIGFueW9uZSBlbHNlIGhhcyBpc3N1ZWQgYW4gU1NMIGNl
cnQgZnJvbSBvbmUgb2YgbXkgDQo+IGluYXBwcm9wcmlhdGUgcm9vdHMuIEkgY2FuIGp1c3QgbG9v
ayBpbiBteSBkYXRhYmFzZS4NCg0KTm90IGltcGx5aW5nIGFueXRoaW5nIGFib3V0IHlvdXIgc2Vj
dXJpdHksIFJpY2ssIGJ1dCBvbmUgb2YgdGhlIGJlbmVmaXRzIG9mIENUIGlzIHRoYXQgcGVvcGxl
IHdobyBkb24ndCByZWFsaXNlIHRoYXQgdGhleSd2ZSBsb3N0IGNvbnRyb2wgb2YgdGhlaXIgcHJp
dmF0ZSBrZXlzIGNhbiBmaW5kIG91dCEgOi0pDQoNCkdlcnYNCg==


From nobody Mon Jul 21 08:09:52 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B9E1A024E for ; Mon, 21 Jul 2014 08:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.006
X-Spam-Level: 
X-Spam-Status: No, score=-1.006 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, PLING_QUERY=0.994, 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 2_JO_wEJz6eg for ; Mon, 21 Jul 2014 08:09:47 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020D71A0142 for ; Mon, 21 Jul 2014 08:09:45 -0700 (PDT)
Received: by mail-ig0-f170.google.com with SMTP id h3so3164594igd.5 for ; Mon, 21 Jul 2014 08:09: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 :content-type:content-transfer-encoding; bh=CRoLORIDj6oT7BeP25NTNjjOruekAPn90tM0CE1/tMU=; b=xyalPp85xUbQDuzpFZPjO9IKDgdEMmR0F/0NN4K1SsVdMyZp85qF/mzP8oBLMiCH0L /pXj1rLqBU2ss0l5t2hpJqRbshXEyxXR90kCtH8YX55yWOgKLJIGIzo3ag8yIxVOdJ+0 T94kY/ConjNEnQC5JRgqghR7XhRHgXYNtoNNvXWV17SUyGb6AjeqFR5gIUt59RCZiGvV kG2il23S57v9lngUiW+iVkcXJng+lvRB9btrR9aw8pEYQbbUlDpFYwl6ulX/e5TNPsHn /3miFND8jv1r5soc9LKGR/LNyNTXnMiy3n1nXaNaHpETvcd/t4DQLCKl2uQnBlE/u8uJ WjKw==
X-Received: by 10.42.50.82 with SMTP id z18mr13296810icf.47.1405955385242; Mon, 21 Jul 2014 08:09:45 -0700 (PDT)
Received: from dhcp-9736.meeting.ietf.org (dhcp-9736.meeting.ietf.org. [31.133.151.54]) by mx.google.com with ESMTPSA id y14sm7731287igg.0.2014.07.21.08.09.44 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 08:09:44 -0700 (PDT)
Message-ID: <53CD2D37.2090209@gmail.com>
Date: Mon, 21 Jul 2014 11:09:43 -0400
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: trans@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/L1bvAhbTt5dBr6h4MfJy9nOFV9U
Cc: paul@nohats.ca
Subject: [Trans] Slides!?
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, 21 Jul 2014 15:09:48 -0000

If you're going to be showing slides during the trans
working group session on Friday, please send them to
Paul and me by noon Thursday, EDT.

Thanks,

Melinda


From nobody Mon Jul 21 13:00:13 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768DD1A0413 for ; Mon, 21 Jul 2014 13:00:12 -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 TOSASWCQCDVs for ; Mon, 21 Jul 2014 13:00:08 -0700 (PDT)
Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E0E1A0418 for ; Mon, 21 Jul 2014 13:00:05 -0700 (PDT)
Received: by mail-pd0-f174.google.com with SMTP id fp1so9674187pdb.5 for ; Mon, 21 Jul 2014 13:00:05 -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; bh=jiHRJ3qGHt2Hm4gNAGgwQW57AolU+KKycReVXwOdai4=; b=MjtjVGNXGY7o/hGG5S7388HqX98i7GGtiF/5XFSKeiaxtjwVdym6x1uWSC5pSY/X6I PmyO7TUUngLb91FhSjLSjzJMYpz28MXmyJUVwoyCJY+o1NmNGFrSRZqBZnStk2Q7cghr nmcpnFtmj85SuQA6d2HG1HycT56wxpvQUbHXa9g4ZQkKOmfOweKxxmHMncNkgO7VRKKd 1eKchHl2BU4sTtKKEfB1COOmx2KsCknEtipArIPtMZWy2L8B+bnZ5ZAwX1ogL3JRnpvF Az5Gk9ceizmwHfdg/2DtWHxUw4TsuzVdNstglPsODolibF7CExuCeaRryE2+0tMiuH6G EKpA==
X-Received: by 10.67.14.193 with SMTP id fi1mr15603613pad.17.1405972804875; Mon, 21 Jul 2014 13:00:04 -0700 (PDT)
Received: from [192.168.254.10] (ip70-189-237-85.lv.lv.cox.net. [70.189.237.85]) by mx.google.com with ESMTPSA id tg9sm15035034pbc.29.2014.07.21.13.00.02 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 13:00:03 -0700 (PDT)
Message-ID: <53CD713F.2010306@gmail.com>
Date: Mon, 21 Jul 2014 12:59:59 -0700
From: Kyle Hamilton 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Rick Andrews , gerv@mozilla.org,  Carl.Mehner@usaa.com, trans@ietf.org
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <19075EB00EA7FE49AFF87E5818D673D4111AE279@PRODEXMB01W.eagle.usaa.com> <544B0DD62A64C1448B2DA253C011414607CD476516@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53CCDE40.9060301@mozilla.org> <544B0DD62A64C1448B2DA253C011414607CD4766EA@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CD4766EA@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080000010505030809000301"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Kx3t8dbYe-2BcKDKb1IgMbhFobo
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 21 Jul 2014 20:00:12 -0000

This is a cryptographically signed message in MIME format.

--------------ms080000010505030809000301
Content-Type: multipart/alternative;
 boundary="------------070602050105060600050709"

This is a multi-part message in MIME format.
--------------070602050105060600050709
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Until there's adequate support in SCT for all types of certs, there is
no drive to add SCT to other protocols and clients.  Therefore, there
will never be a requirement for it.  Ultimately, the unwillingness to
support it now shall only guarantee that it will never be required.

But unless and until Google wants to step up and actively promote it, I
guess Google gets a lack of it.  Therefore, according to your argument,
Google now has de facto administrative control over Internet security
infrastructure administration and buildout.

Value might be perceived because of the lack of cost to modify *all*=20
issuance systems to be on the same code base, as opposed to forking them
all.  However, as a reminder, forks increase maintenance cost and
decrease capacity, capability, and interoperability across multiple
systems -- particularly on previously-enabled systems that haven't yet
been fully brought into production.

-Kyle H

On 7/21/2014 8:08 AM, Rick Andrews wrote:
> True. The point I'm trying to make is that we're a long way from requir=
ing SCTs for all types of certs, SSL and non-SSL. Until all applications =
require SCTs for all types of certs, I see no reason to add the complexit=
y of logging all certs. At this point in time, Google wants SCTs for EV S=
SL certs, and that's what I'm shooting for. Chrome knows which roots are =
enabled for EV, and so those are the only roots that log servers MUST acc=
ept.
>
> Other CAs might want to log all their certs. Relying parties might want=
 to push every cert they see into log servers. But I see value in limitin=
g which of my roots are accepted by log servers, and I'd like the ability=
 to control that.
>
> -Rick
>
> -----Original Message-----
> From: Gervase Markham [mailto:gerv@mozilla.org]=20
> Sent: Monday, July 21, 2014 2:33 AM
> To: Rick Andrews; Mehner, Carl; trans@ietf.org
> Subject: Re: [Trans] List of Roots Accepted by Log Servers
>
> On 19/07/14 02:02, Rick Andrews wrote:
>> Unless I've lost control over my private keys, I don't need to monitor=
=20
>> CT logs to see if anyone else has issued an SSL cert from one of my=20
>> inappropriate roots. I can just look in my database.
> Not implying anything about your security, Rick, but one of the benefit=
s of CT is that people who don't realise that they've lost control of the=
ir private keys can find out! :-)
>
> Gerv
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans


--------------070602050105060600050709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Until there's adequate support in SCT for all types of=
 certs, there is
no drive to add SCT to other protocols and clients.  Therefore, there
will never be a requirement for it.  Ultimately, the unwillingness to
support it now shall only guarantee that it will never be required.

But unless and until Google wants to step up and actively promote it, I
guess Google gets a lack of it.  Therefore, according to your argument,
Google now has de facto administrative control over Internet security
infrastructure administration and buildout.

Value might be perceived because of the lack of cost to modify *all*=20
issuance systems to be on the same code base, as opposed to forking them
all.  However, as a reminder, forks increase maintenance cost and
decrease capacity, capability, and interoperability across multiple
systems -- particularly on previously-enabled systems that haven't yet
been fully brought into production.

-Kyle H

    
On 7/21/2014 8:08 AM, Rick Andrews
      wrote:

    

    

      
True. The point I'm trying to make is that we're a l=
ong way from requiring SCTs for all types of certs, SSL and non-SSL. Unti=
l all applications require SCTs for all types of certs, I see no reason t=
o add the complexity of logging all certs. At this point in time, Google =
wants SCTs for EV SSL certs, and that's what I'm shooting for. Chrome kno=
ws which roots are enabled for EV, and so those are the only roots that l=
og servers MUST accept.

Other CAs might want to log all their certs. Relying parties might want t=
o push every cert they see into log servers. But I see value in limiting =
which of my roots are accepted by log servers, and I'd like the ability t=
o control that.

-Rick

-----Original Message-----
From: Gervase Markham [mailto:gerv@mozilla.org]=20
Sent: Monday, July 21, 2014 2:33 AM
To: Rick Andrews; Mehner, Carl; trans@ietf.org
Subject: Re: [Trans] List of Roots Accepted by Log Servers

On 19/07/14 02:02, Rick Andrews wrote:


      

        
Unless I've lost control over my private keys, I d=
on't need to monitor=20
CT logs to see if anyone else has issued an SSL cert from one of my=20
inappropriate roots. I can just look in my database.


      

      
Not implying anything about your security, Rick, but one of the benefits =
of CT is that people who don't realise that they've lost control of their=
 private keys can find out! :-)

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


    

    

  


--------------070602050105060600050709--

--------------ms080000010505030809000301
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKSDCC
BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu
Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE
ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA
GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq
1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg
7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS
D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw
ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG
eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV
HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu
Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI
KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO
QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av
QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo
2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr
P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa
XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q
peeU0rD+83X5f27nMIIFJjCCBA6gAwIBAgIRALbv5xh8RSMuXP9qrA/5ONAwDQYJKoZIhvcN
AQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAO
BgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBD
T01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTQw
NjAzMDAwMDAwWhcNMTUwNjAzMjM1OTU5WjAjMSEwHwYJKoZIhvcNAQkBFhJhZXJvd29sZkBn
bWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIrYxg/oIPfnNfvNCm
OoctdpmYxFYygtJ7eHGCGyUvGnqaiNacsYgsvtfyyC3Hwq82Va9Sr2/y8+iPB/oAWPvlfJUO
viFkCFsPBRsuRo8Iul6GElOiZSq9Q4PtVseJt9JK4cee8GPeD3kWIp0ynktDPW17XhOK8J4U
Hrvn04Yaa6eK7nLDnsboaxRBHOZ1B/3qAWGznF5L/oQf0NV6rdz+v31CyOoZhvtldC9ooK3t
q7Xve075VrnrkqM2HQe8Whg5J1Oo1TfNeqFWayZU9o0jK07oGv7wYsKHVc5FpIFZ8j9odB3J
gM7hmtCYuwOMzqp0jxeQA38k2yqAxWHx1W/nAgMBAAGjggHiMIIB3jAfBgNVHSMEGDAWgBR6
E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUENa7REnXA37GDe/Ytjs6PmRVaE4wDgYD
VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQB
sjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATAr
MCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBO
MEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNh
dGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKG
Rmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k
U2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNv
bTAdBgNVHREEFjAUgRJhZXJvd29sZkBnbWFpbC5jb20wDQYJKoZIhvcNAQEFBQADggEBADaN
kVFmWQxIp1qk5r4R1WaTVb77fED2CFEihXNvIfJEWIdFKRtlfSAyCGQzarMxf5HMRjYi62Tl
H4OMGUgc3Eult0EtdO/hFBz9lYNTQmi+uY6GZM7ZjXxkmHexycQoWR8fQg+w3UMkVKxEiVji
OZOuer7R79KVw18rDZcQipSO/n/Zz4i5CAk1cC/kWnBcs3VOm+rr27gQrO0/QQfCjcRu0WE0
ymEHunnNm9F/vZbvBL4V+xxUvxrsR4JeQoePKCFprHnaVmuHHluZq5UPZNTRq7C5Q+T9YvYW
e525UiAj1LD9eV58LWTurmayjoxYqaktJf4x9Og0h9Gz2mopU5sxggQcMIIEGAIBATCBqTCB
kzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH
U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRALbv5xh8RSMuXP9q
rA/5ONAwCQYFKw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG
9w0BCQUxDxcNMTQwNzIxMTk1OTU5WjAjBgkqhkiG9w0BCQQxFgQUQ37magdsWZGJQfRSBgYD
C+vuSXgwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqG
SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG
9w0DAgIBKDCBugYJKwYBBAGCNxAEMYGsMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS
R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g
Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg
U2VjdXJlIEVtYWlsIENBAhEAtu/nGHxFIy5c/2qsD/k40DCBvAYLKoZIhvcNAQkQAgsxgayg
gakwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV
BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01P
RE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQC27+cYfEUj
Llz/aqwP+TjQMA0GCSqGSIb3DQEBAQUABIIBAMSIVCTpjNaBF+zUOnMwngRGneNiQ5JqawXA
Og66plkd0oGNh2yWuA5Ej0tczZXBQ1MWmVI4h8c/8pkyJ6qIlKtWhmefyMKXPWYMNG5jhBrS
FwV/m6HsJc4sZSHdmevGiDPIYloC/TVyezDdc3G+4R2B8hSYxyHbPgrOAl+ffMtZ3hVULuf2
1J+/s44YBedAug8lC8xMKDlL47TK0pLqGcGbUH5N/Cvp/+N4it0ZclodYOGb/GOyCkLjvSt0
b2c7cy01VmxWJFooYPsfAqEAK1QhiFcECBg8EUHt0eq3aWOrvLzYxWJuTzuaUEFRZjFDi61a
8NqEjIQOndqSbAXTGy0AAAAAAAA=
--------------ms080000010505030809000301--


From nobody Mon Jul 21 13:44:35 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80921A043D for ; Mon, 21 Jul 2014 13:44:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP2RjXVDyYce for ; Mon, 21 Jul 2014 13:44:31 -0700 (PDT)
Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id 43CF41A0406 for ; Mon, 21 Jul 2014 13:44:31 -0700 (PDT)
From: Jeremy Rowley 
To: 'Kyle Hamilton' , 'Rick Andrews' , "'gerv@mozilla.org'" , "'Carl.Mehner@usaa.com'" , "'trans@ietf.org'" 
Thread-Topic: [Trans] List of Roots Accepted by Log Servers
Thread-Index: Ac+irl+ii5Y1QiW8SKiN+XC17uqP9gANUUDoAAEsdJAAhCwDAAALttyAAAowmYAACy5doA==
Date: Mon, 21 Jul 2014 20:44:29 +0000
Message-ID: <4de49203d27142349d1b3e5345b45259@EX1.corp.digicert.com>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <19075EB00EA7FE49AFF87E5818D673D4111AE279@PRODEXMB01W.eagle.usaa.com> <544B0DD62A64C1448B2DA253C011414607CD476516@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53CCDE40.9060301@mozilla.org> <544B0DD62A64C1448B2DA253C011414607CD4766EA@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53CD713F.2010306@gmail.com>
In-Reply-To: <53CD713F.2010306@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [67.137.52.8]
Content-Type: multipart/alternative; boundary="_000_4de49203d27142349d1b3e5345b45259EX1corpdigicertcom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/OHQ_Uig_eMcPYCp9835NTNC5oEU
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 21 Jul 2014 20:44:34 -0000

--_000_4de49203d27142349d1b3e5345b45259EX1corpdigicertcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Because of the differences in root program requirements, operational requir=
ements, and verification needs, from my experience, most client and code si=
gning systems already fork from the SSL cert systems.  Client certs are esp=
ecially different in their issuance process. For most CAs, I imagine it's m=
ore work to add CT support for the three base certificate types than simply=
 enable it for SSL.

Jeremy

From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Kyle Hamilton
Sent: Monday, July 21, 2014 2:00 PM
To: Rick Andrews; gerv@mozilla.org; Carl.Mehner@usaa.com; trans@ietf.org
Subject: Re: [Trans] List of Roots Accepted by Log Servers


Until there's adequate support in SCT for all types of certs, there is

no drive to add SCT to other protocols and clients.  Therefore, there

will never be a requirement for it.  Ultimately, the unwillingness to

support it now shall only guarantee that it will never be required.



But unless and until Google wants to step up and actively promote it, I

guess Google gets a lack of it.  Therefore, according to your argument,

Google now has de facto administrative control over Internet security

infrastructure administration and buildout.



Value might be perceived because of the lack of cost to modify *all*

issuance systems to be on the same code base, as opposed to forking them

all.  However, as a reminder, forks increase maintenance cost and

decrease capacity, capability, and interoperability across multiple

systems -- particularly on previously-enabled systems that haven't yet

been fully brought into production.



-Kyle H
On 7/21/2014 8:08 AM, Rick Andrews wrote:

True. The point I'm trying to make is that we're a long way from requiring =
SCTs for all types of certs, SSL and non-SSL. Until all applications requir=
e SCTs for all types of certs, I see no reason to add the complexity of log=
ging all certs. At this point in time, Google wants SCTs for EV SSL certs, =
and that's what I'm shooting for. Chrome knows which roots are enabled for =
EV, and so those are the only roots that log servers MUST accept.



Other CAs might want to log all their certs. Relying parties might want to =
push every cert they see into log servers. But I see value in limiting whic=
h of my roots are accepted by log servers, and I'd like the ability to cont=
rol that.



-Rick



-----Original Message-----

From: Gervase Markham [mailto:gerv@mozilla.org]

Sent: Monday, July 21, 2014 2:33 AM

To: Rick Andrews; Mehner, Carl; trans@ietf.org

Subject: Re: [Trans] List of Roots Accepted by Log Servers



On 19/07/14 02:02, Rick Andrews wrote:

Unless I've lost control over my private keys, I don't need to monitor

CT logs to see if anyone else has issued an SSL cert from one of my

inappropriate roots. I can just look in my database.



Not implying anything about your security, Rick, but one of the benefits of=
 CT is that people who don't realise that they've lost control of their pri=
vate keys can find out! :-)



Gerv

_______________________________________________

Trans mailing list

Trans@ietf.org

https://www.ietf.org/mailman/listinfo/trans


--_000_4de49203d27142349d1b3e5345b45259EX1corpdigicertcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Because of the difference=
s in root program requirements, operational requirements, and verification =
needs, from my experience, most client and code signing
 systems already fork from the SSL cert systems.  Client certs are esp=
ecially different in their issuance process. For most CAs, I imagine itR=
17;s more work to add CT support for the three base certificate types than =
simply enable it for SSL.


 


Jeremy<=
/p>

 <=
/p>





From: Trans [mailto:trans-bounces@ietf.org]
On Behalf Of Kyle Hamilton

Sent: Monday, July 21, 2014 2:00 PM

To: Rick Andrews; gerv@mozilla.org; Carl.Mehner@usaa.com; trans@ietf=
.org

Subject: Re: [Trans] List of Roots Accepted by Log Servers






 


Until there's adequate support in SCT for all types of certs, there is=



no drive to add SCT to other protocols and clients.  Therefore, t=
here


will never be a requirement for it.  Ultimately, the unwillingnes=
s to


support it now shall only guarantee that it will never be required.


 


But unless and until Google wants to step up and actively promote it, =
I


guess Google gets a lack of it.  Therefore, according to your arg=
ument,


Google now has de facto administrative control over Internet security<=
o:p>


infrastructure administration and buildout.


 


Value might be perceived because of the lack of cost to modify *all* 


issuance systems to be on the same code base, as opposed to forking th=
em


all.  However, as a reminder, forks increase maintenance cost and=



decrease capacity, capability, and interoperability across multiple


systems -- particularly on previously-enabled systems that haven't yet=



been fully brought into production.


 


-Kyle H




On 7/21/2014 8:08 AM, Rick Andrews wrote:=







True. The point I'm trying to make is that we're a long way from requi=
ring SCTs for all types of certs, SSL and non-SSL. Until all applications r=
equire SCTs for all types of certs, I see no reason to add the complexity o=
f logging all certs. At this point in time, Google wants SCTs for EV SSL ce=
rts, and that's what I'm shooting for. Chrome knows which roots are enabled=
 for EV, and so those are the only roots that log servers MUST accept.=



 


Other CAs might want to log all their certs. Relying parties might wan=
t to push every cert they see into log servers. But I see value in limiting=
 which of my roots are accepted by log servers, and I'd like the ability to=
 control that.


 


-Rick


 


-----Original Message-----


From: Gervase Markham [mailto:gerv=
@mozilla.org] 


Sent: Monday, July 21, 2014 2:33 AM


To: Rick Andrews; Mehner, Carl; tran=
s@ietf.org


Subject: Re: [Trans] List of Roots Accepted by Log Servers<=
/pre>

 


On 19/07/14 02:02, Rick Andrews wrote:




Unless I've lost control over my private keys, I don't need to monitor=
 


CT logs to see if anyone else has issued an SSL cert from one of my 


inappropriate roots. I can just look in my database.




 


Not implying anything about your security, Rick, but one of the benefi=
ts of CT is that people who don't realise that they've lost control of thei=
r private keys can find out! :-)


 


Gerv


_______________________________________________


Trans mailing list


Trans@ietf.org


https://www.ie=
tf.org/mailman/listinfo/trans




 






--_000_4de49203d27142349d1b3e5345b45259EX1corpdigicertcom_--


From nobody Tue Jul 22 09:34:16 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5211B29ED for ; Tue, 22 Jul 2014 09:34:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 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, RP_MATCHES_RCVD=-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 YxiUqWajWUBW for ; Tue, 22 Jul 2014 09:34:14 -0700 (PDT)
Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552551A01C6 for ; Tue, 22 Jul 2014 09:34:14 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id la4so15232301vcb.5 for ; Tue, 22 Jul 2014 09:34:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lBabEHeCXiH9FXcEl8WR0Qf2TqQpbaj0YWw7w9gLTg8=; b=hw5vnL4CD62MSDdHHiwdQrGv7LSYxnioF+DMAt0fZParV/QR/Cxy3rHeRR2++R+m/K LXSqX2/ihN53TYcPsz/aGeyouwvIdpHFF26zwcgwIYUIeh6t1kaB8INYRhYGioApg03a X9sd74n4xWm7w0T15+QjL9sM5iLpPzg8GvNJ6D3TTiCe3IHNpOOjVQ3oRfqUkfxmUsHc wKcBoZYALaxfdW1zG31yJOcNh/R/TZ3kZSfnN6yWJ32/NtNSViGJx8ePG6TF5cmJSJX8 fT5w4LkFBwuf2sdT8oBNP7Uqmold/5QvcjvD8A0N7BBrf4VxdD9Zr125D8LV0KdgkQ/U haMg==
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=lBabEHeCXiH9FXcEl8WR0Qf2TqQpbaj0YWw7w9gLTg8=; b=fWd4CkGmjQ7fIikVqOtMAN1Cd02a8bPaMHiAgANGx8L4eBcUAe9U/UE7y4KKFlQeMN Xhy8xdAHnf7SrGD21UMY3W9yzHLbF2lBSys10B2CbZTAAt9xpJHjN76SrrcUH31t78+Y qG/93wL9+1j31cLvbf5CUhIX0oqoGC8CHpLf/OCWyQe6l7wdP18yES/E+lJnunwjvX94 B8NhQzLsiib1tOosol+qxsEiMDYVBdvgXkpyad4zprS14cEDNg7K8ZpfgZwe/lGes8Nk 0Gjx2g3w86EGE3nVjtnIQlk/myUWF09OKh6wr8WQmsTUDglOeq8npZnN+bO9G52qtbdo 4fMw==
X-Gm-Message-State: ALoCoQnK9ELNxTEYSGCE5I2G64VSJKk67gTnwbQzBR+OQHPQH3XBxKZj11uWDQSWmcg6ZZXWqv+f
MIME-Version: 1.0
X-Received: by 10.52.241.76 with SMTP id wg12mr35488441vdc.5.1406046853320; Tue, 22 Jul 2014 09:34:13 -0700 (PDT)
Received: by 10.52.161.201 with HTTP; Tue, 22 Jul 2014 09:34:13 -0700 (PDT)
In-Reply-To: <4de49203d27142349d1b3e5345b45259@EX1.corp.digicert.com>
References: <544B0DD62A64C1448B2DA253C011414607CD475FD2@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <19075EB00EA7FE49AFF87E5818D673D4111AE279@PRODEXMB01W.eagle.usaa.com> <544B0DD62A64C1448B2DA253C011414607CD476516@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53CCDE40.9060301@mozilla.org> <544B0DD62A64C1448B2DA253C011414607CD4766EA@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53CD713F.2010306@gmail.com> <4de49203d27142349d1b3e5345b45259@EX1.corp.digicert.com>
Date: Tue, 22 Jul 2014 17:34:13 +0100
Message-ID: 
From: Eran Messeri 
To: Jeremy Rowley 
Content-Type: multipart/alternative; boundary=001a1133e9203af35904fecacb9a
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/qB9Q8PvXdXtO2PbCWSQ6TYdrrmE
Cc: "Carl.Mehner@usaa.com" , "trans@ietf.org" , "gerv@mozilla.org" , Rick Andrews , Kyle Hamilton 
Subject: Re: [Trans] List of Roots Accepted by Log Servers
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, 22 Jul 2014 16:34:16 -0000

--001a1133e9203af35904fecacb9a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

To support what Jeremy and Rick said, I'll point out that it's entirely
possible to spin up multiple logs for different uses of X.509 certificates.
I understand that different X.509 certificates are used by different client
software, each kind of client software could use a different set of logs
(and these sets would be monitored differently depending on the
application).
Nothing prevents the logs to be based on the same software and
infrastructure.

Specifically:
* There's already a reference implementation for a CT log server as
open-source code (and we're working on a more robust version).
* Given Ben's interest in binary transparency and general transparency, I
believe he won't outright reject running extra logs for other cert types
(on Google's infrastructure).
* Code for general transparency service would allow running a transparency
log for arbitrary binary blobs. Ben may be able to share some details on
such an effort.




On Mon, Jul 21, 2014 at 9:44 PM, Jeremy Rowley 
wrote:

>  Because of the differences in root program requirements, operational
> requirements, and verification needs, from my experience, most client and
> code signing systems already fork from the SSL cert systems.  Client cert=
s
> are especially different in their issuance process. For most CAs, I imagi=
ne
> it=E2=80=99s more work to add CT support for the three base certificate t=
ypes than
> simply enable it for SSL.
>
>
>
> Jeremy
>
>
>
> *From:* Trans [mailto:trans-bounces@ietf.org] *On Behalf Of *Kyle Hamilto=
n
> *Sent:* Monday, July 21, 2014 2:00 PM
> *To:* Rick Andrews; gerv@mozilla.org; Carl.Mehner@usaa.com; trans@ietf.or=
g
>
> *Subject:* Re: [Trans] List of Roots Accepted by Log Servers
>
>
>
> Until there's adequate support in SCT for all types of certs, there is
>
> no drive to add SCT to other protocols and clients.  Therefore, there
>
> will never be a requirement for it.  Ultimately, the unwillingness to
>
> support it now shall only guarantee that it will never be required.
>
>
>
> But unless and until Google wants to step up and actively promote it, I
>
> guess Google gets a lack of it.  Therefore, according to your argument,
>
> Google now has de facto administrative control over Internet security
>
> infrastructure administration and buildout.
>
>
>
> Value might be perceived because of the lack of cost to modify ****all**
>
> issuance systems to be on the same code base, as opposed to forking them
>
> all.  However, as a reminder, forks increase maintenance cost and
>
> decrease capacity, capability, and interoperability across multiple
>
> systems -- particularly on previously-enabled systems that haven't yet
>
> been fully brought into production.
>
>
>
> -Kyle H
>
>  On 7/21/2014 8:08 AM, Rick Andrews wrote:
>
> True. The point I'm trying to make is that we're a long way from requirin=
g SCTs for all types of certs, SSL and non-SSL. Until all applications requ=
ire SCTs for all types of certs, I see no reason to add the complexity of l=
ogging all certs. At this point in time, Google wants SCTs for EV SSL certs=
, and that's what I'm shooting for. Chrome knows which roots are enabled fo=
r EV, and so those are the only roots that log servers MUST accept.
>
>
>
> Other CAs might want to log all their certs. Relying parties might want t=
o push every cert they see into log servers. But I see value in limiting wh=
ich of my roots are accepted by log servers, and I'd like the ability to co=
ntrol that.
>
>
>
> -Rick
>
>
>
> -----Original Message-----
>
> From: Gervase Markham [mailto:gerv@mozilla.org ]
>
> Sent: Monday, July 21, 2014 2:33 AM
>
> To: Rick Andrews; Mehner, Carl; trans@ietf.org
>
> Subject: Re: [Trans] List of Roots Accepted by Log Servers
>
>
>
> On 19/07/14 02:02, Rick Andrews wrote:
>
>  Unless I've lost control over my private keys, I don't need to monitor
>
> CT logs to see if anyone else has issued an SSL cert from one of my
>
> inappropriate roots. I can just look in my database.
>
>
>
> Not implying anything about your security, Rick, but one of the benefits =
of CT is that people who don't realise that they've lost control of their p=
rivate keys can find out! :-)
>
>
>
> Gerv
>
> _______________________________________________
>
> 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
>
>

--001a1133e9203af35904fecacb9a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


To support what Jeremy and Rick said, I'll point out t=
hat it's entirely possible to spin up multiple logs for different uses =
of X.509 certificates.
I understand that different X.509 certificates a=
re used by different client software, each kind of client software could us=
e a different set of logs (and these sets would be monitored differently de=
pending on the application).


Nothing prevents the logs to be based on the same software and infrast=
ructure.=C2=A0

Specifically:
* There'=
;s already a reference implementation for a CT log server as open-source co=
de (and we're working on a more robust version).


* Given Ben's interest in binary transparency and general transpar=
ency, I believe he won't outright reject running extra logs for other c=
ert types (on Google's infrastructure).=C2=A0
* Code for gene=
ral transparency service would allow running a transparency log for arbitra=
ry binary blobs. Ben may be able to share some details on such an effort.





On Mon, Jul 21, 2014 at 9:44 PM, Jeremy Rowley <Jeremy.Rowley@digicert.com> wrote:













Because of the difference=
s in root program requirements, operational requirements, and verification =
needs, from my experience, most client and code signing
 systems already fork from the SSL cert systems.=C2=A0 Client certs are esp=
ecially different in their issuance process. For most CAs, I imagine it=E2=
=80=99s more work to add CT support for the three base certificate types th=
an simply enable it for SSL.



=C2=A0


Jeremy


=C2=A0






From: Trans [mailto:trans-bounces@ietf.org]
On Behalf Of Kyle Hamilton

Sent: Monday, July 21, 2014 2:00 PM

To: Rick Andrews; gerv@mozilla.org; Carl.Mehner@usaa.com; trans@ietf.org




Subject: Re: [Trans] List of Roots Accepted by Log Servers=







=C2=A0


Until there's adequate support in SCT for all types of certs, ther=
e is


no drive to add SCT to other protocols and clients.=C2=A0 Therefore, t=
here


will never be a requirement for it.=C2=A0 Ultimately, the unwillingnes=
s to


support it now shall only guarantee that it will never be required.=



=C2=A0


But unless and until Google wants to step up and actively promote it, =
I


guess Google gets a lack of it.=C2=A0 Therefore, according to your arg=
ument,


Google now has de facto administrative control over Internet security<=
u>


infrastructure administration and buildout.


=C2=A0


Value might be perceived because of the lack of cost to modify <=
b>*all* 


issuance systems to be on the same code base, as opposed to forking th=
em


all.=C2=A0 However, as a reminder, forks increase maintenance cost and=



decrease capacity, capability, and interoperability across multiple=



systems -- particularly on previously-enabled systems that haven't=
 yet


been fully brought into production.


=C2=A0


-Kyle H




On 7/21/2014 8:08 AM, Rick Andrews wrote:<=
/u>






True. The point I'm trying to make is that we're a long way fr=
om requiring SCTs for all types of certs, SSL and non-SSL. Until all applic=
ations require SCTs for all types of certs, I see no reason to add the comp=
lexity of logging all certs. At this point in time, Google wants SCTs for E=
V SSL certs, and that's what I'm shooting for. Chrome knows which r=
oots are enabled for EV, and so those are the only roots that log servers M=
UST accept.



=C2=A0


Other CAs might want to log all their certs. Relying parties might wan=
t to push every cert they see into log servers. But I see value in limiting=
 which of my roots are accepted by log servers, and I'd like the abilit=
y to control that.



=C2=A0


-Rick


=C2=A0


-----Original Message-----


From: Gervase Markham [mailto:gerv@mozilla.org] 


Sent: Monday, July 21, 2014 2:33 AM


To: Rick Andrews; Mehner, Carl; trans@ietf.org


Subject: Re: [Trans] List of Roots Accepted by Log Servers


=C2=A0


On 19/07/14 02:02, Rick Andrews wrote:




Unless I've lost control over my private keys, I don't need to=
 monitor 


CT logs to see if anyone else has issued an SSL cert from one of my 


inappropriate roots. I can just look in my database.



=C2=A0


Not implying anything about your security, Rick, but one of the benefi=
ts of CT is that people who don't realise that they've lost control=
 of their private keys can find out! :-)


=C2=A0


Gerv


_______________________________________________


Trans mailing list


Trans@ietf.org=



https://www.ietf.org/mailman/listinfo/trans




=C2=A0







_______________________________________________

Trans mailing list

Trans@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/trans





--001a1133e9203af35904fecacb9a--


From nobody Wed Jul 23 06:20:04 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9621B28F7 for ; Wed, 23 Jul 2014 06:19: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 46XgeXVxxuno for ; Wed, 23 Jul 2014 06:19:56 -0700 (PDT)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2D3A1B28E9 for ; Wed, 23 Jul 2014 06:19:56 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id at1so952145iec.30 for ; Wed, 23 Jul 2014 06:19: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 :content-type:content-transfer-encoding; bh=aAjNs6TYrtQxOoUG5OXa2JMDhToNC4aOOiuLvngHC48=; b=nDG+ZA+BPVxs4B/VeOty9g8DsuuB1/PGI9VKFswULXyhZfxPFpzEDno7wbwSLvQsUe Sy3HdXtzSsAdV7tBy9uGYTB2KqY781l7TwRXsyBHncMZluq9TkPMAHx7LAkaYQb4k6K8 xvIFY8j4H8JJXYOrl9T3tbbERXKaqFu6wRqGz96nHNpZ2my1JajSooawuo1uPlRX3ksE j0ePRB29Zva7R/ns8x337NGpTeXCK//TLTBPKBwQRJiH8CEghhEE6UK8g1r52SQ13wyH 801jIGZBrTmYzTXTwBlwUt6v2mYxbHat79YqVOHIqcaw0dYT9zommapzdMln/lBpHZrx pIYA==
X-Received: by 10.50.152.98 with SMTP id ux2mr28205794igb.27.1406121595999; Wed, 23 Jul 2014 06:19:55 -0700 (PDT)
Received: from dhcp-9055.meeting.ietf.org (dhcp-9055.meeting.ietf.org. [31.133.144.85]) by mx.google.com with ESMTPSA id p17sm12658150igi.15.2014.07.23.06.19.55 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 06:19:55 -0700 (PDT)
Message-ID: <53CFB67A.9010904@gmail.com>
Date: Wed, 23 Jul 2014 09:19:54 -0400
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: trans@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/GuhoiSoz7pEP57o0weX18v2NUx8
Subject: [Trans] Contributing to the issue tracker
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, 23 Jul 2014 13:19:58 -0000

I've been reminded to remind everybody that the issue tracker
(http://tools.ietf.org/wg/trans/trac/report/1) is currently
open to additions from anybody who's got an IETF tools account.
Please review the open tickets, but also add tickets for issues
you've identified that need to be resolved before 6962-bis will
be ready for working group last call.  (It would be helpful
to start a discussion on the mailing list before opening a
ticket).

In the event that the tracker is abused we'll restrict access,
but for the time being we're keeping it open.  Note that Eran
Messeri is the de facto issue tracker editor and can help
with issue tracker questions, etc.

Thanks,

Melinda


From nobody Wed Jul 23 07:10:19 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6441B2817 for ; Wed, 23 Jul 2014 07:10:18 -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 v1_OuG4-8bOi for ; Wed, 23 Jul 2014 07:10:14 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3871B29C3 for ; Wed, 23 Jul 2014 07:10:12 -0700 (PDT)
Received: by mail-ig0-f169.google.com with SMTP id r2so5390651igi.2 for ; Wed, 23 Jul 2014 07:10:12 -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=kkgzkXnNWiw2lKluXGSZpnBM/E7pMv/Gxq6kk8IThbE=; b=YDEaQzbjVnRdS7MQAgwO4UEIc2Wp2VZQROjKkRris4zVrSA5hgq1dWHBmZisNAIsgB bjkdQMGCUD7N5lBc9nxv9lIMWR+GuzrAkQFMlo8Ry2AHCMTb/0xesqsMiyE7ocqtGkx4 jJDUEAHXCoKEseavGNHHAC0rqJ1YSImUWEYOHGmDzEmrx93ELVxTE2jz/jzGEEqZCebe HbjLEwxcnLWDXi85Y/erF8gjOkCNLIiUVjTCdRwTWKlFGyFjwUuYa647EMq4r8RfXgP/ kdJB8cEFTRnm5WuACijPuDRAMs8qKUxkcy4XpInqyIER3tzbCXb24dsRrhjy6nd2+FUC xBDA==
X-Received: by 10.42.23.16 with SMTP id q16mr3760904icb.0.1406124612226; Wed, 23 Jul 2014 07:10:12 -0700 (PDT)
Received: from dhcp-9055.meeting.ietf.org (dhcp-9055.meeting.ietf.org. [31.133.144.85]) by mx.google.com with ESMTPSA id d2sm28209646igl.6.2014.07.23.07.10.11 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 07:10:11 -0700 (PDT)
Message-ID: <53CFC240.1070609@gmail.com>
Date: Wed, 23 Jul 2014 10:10:08 -0400
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: trans@ietf.org
References: <20140722155655.21895.335.idtracker@ietfa.amsl.com>
In-Reply-To: <20140722155655.21895.335.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140722155655.21895.335.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mh0tXjLjmBkDOUx1H4HJofrUqcs
Subject: [Trans] Fwd: I-D Action: draft-zhang-ct-dnssec-trans-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, 23 Jul 2014 14:10:18 -0000

Please note that an initial draft has been uploaded proposing
logging dnssec.  Dacheng will be discussing this on Friday,
so please take a look at the draft prior to our session.

Melinda


-------- Original Message --------
Subject: I-D Action: draft-zhang-ct-dnssec-trans-00.txt
Date: Tue, 22 Jul 2014 08:56:55 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


         Title           : Certificate Transparency for Domain Name 
System Security Extensions
         Author          : Dacheng Zhang
	Filename        : draft-zhang-ct-dnssec-trans-00.txt
	Pages           : 6
	Date            : 2014-07-22

Abstract:
    In draft-ietf-trans-rfc6962-bis, a solution is proposed for publicly
    logging the existence of Transport Layer Security (TLS) certificates
    using Merkle Hash Trees.  This document tries to use this idea in
    DNSSEC and publicly logging the existence of keys used in securing
    DNS resource records.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-zhang-ct-dnssec-trans/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-zhang-ct-dnssec-trans-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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



From nobody Wed Jul 23 12:40:09 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4371A014F for ; Wed, 23 Jul 2014 12:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 dHFTG9w4M9R4 for ; Wed, 23 Jul 2014 12:40: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 183A51B2CA5 for ; Wed, 23 Jul 2014 12:39:59 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:57081 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XA2OY-000Dbv-Lw for trans@ietf.org; Wed, 23 Jul 2014 15:40:11 -0400
Message-ID: <53D00F89.7040007@bbn.com>
Date: Wed, 23 Jul 2014 15:39:53 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: trans@ietf.org
References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com>  <53B2F131.6030606@bbn.com>  <53B7F4B0.7060306@bbn.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070806000408030504070500"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/t_k9F4qHJRYOfpTFXsyxXTbK1Fo
Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT
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, 23 Jul 2014 19:40:07 -0000

This is a multi-part message in MIME format.
--------------070806000408030504070500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ben,


> ... Ok, that's what _you_ do, but 5280 describes a long list of cert 
> path validation rules
>
>     and your doc just says that these can be relaxed. It does not
>     prohibit a log from
>     performing  the full set dictated by PKIX and X.509 path
>     validation procedures, nor
>     does it provide guidance of which subset SHOULD/MUST be performed.
>     Absent such guidance
>     different log operators can legitimately perform different checks,
>     resulting in chaos.
>
>
> I don't believe it will result in chaos, but anyway, the purpose of 
> checking signatures on log submissions is to combat spam. I don't 
> think we should tightly define exactly what checks are performed to 
> that end, because that's a great way to leave yourself unable to 
> defend against some kind of unforeseen spam. We can certainly clarify 
> that. I've added a ticket.
Perhaps I have not been clear enough in specifying my concern. A CA (or 
cert Subject) submitting
a cert chain to a log needs to know, unambiguously, what checks will be 
performed. This specificity
is needed to ensure that submissions to multiple logs will all be 
accepted or rejected (assuming
that the root CA for the chain is advertised as acceptable by the log 
operator).
>
>     ...
>     If we had a agreed-upon  requirements doc that explained why the
>     serial number is
>     critical, and if it discussed the impact on CAs that may use
>     serial number management
>     techniques that preclude pre-determining the serial number
>     assigned to a cert, then
>     we would be in good shape. But we don't. So, I think we may have a
>     serious problem
>     with this aspect of the precert model.
>
>
> The purpose of CT is to detect mis-issuance so that it can be 
> rectified. As already explained, some revocation mechanisms require 
> the serial number of the revoked cert. I don\t think we need a 
> separate requirements doc for it to be obvious that without the serial 
> number, we have a problem.
I think we do need a document that specifies what remediation mechanisms 
are required. I
saw no reference to revocation in the doc. Some list members have 
speculated that CT is
a reputation mechanism, and a recent response from you supported that 
notion. A reputation
mechanism need not make use of revocation as per X.509 mechanisms. For 
example, one might
have an auditor distribute a list of "bad" certs to clients, where the 
public key was the
means of identifying the bad cert. I agree that one remediation 
mechanism calls for the
issuing CA to put a detected, bad cert onto a CRL. But, that presumes 
that the mis-issuance
was an error or the result of an attack. Since there is no attack model 
for CT, I don't
know if that is the only sort of mis-issuance event it is supposed to 
counter.
>
>>     ...
>     "Compliant" with what set of specs? I noted an aspect of a design
>     for a CA-focused
>     HSM that, for several years, was used by VeriSign to issue every
>     cert. It is a powerful
>     feature for high assurance cert issuance. It is also incompatible
>     with the precert design.
>     The precert design seems to preclude use of some approaches to
>     serial number management
>     that may reduce CA secruity. Thus it appears to be a tradeoff, one
>     that this WG has not
>     discussed. Please describe what you mean by a "complaint" CA.
>
>
> I do not believe that the use of an HSM in any way constrains a CA's 
> ability to deal with serial numbers as needed. The issue of compliance 
> is a red herring.
You introduced the term "complaint" into this issue, not me, so if it is 
a red herring, it's yours!
More to the point, I identified a legitimate way for HSMs to operate, to 
reduce the vulnerability
of a CA to the sort of attack that DigiNotar experienced. And, that 
model of operation has been
used by large CAs in the past. Your offhand dismissal of this issue is 
inappropriate. In essence
you are saying that Google has developed a rough model of how to make CT 
work and CAs need to
'make changes to their operational processes, and to software and maybe 
hardware, to accommodate
your model. This is an inappropriate mindset for working in the IETF.
>
>     ...
>
>
> Precerts are critical because otherwise server s/w has to be updated 
> to deliver SCTs to clients. We know that isn't going to happen 
> universally any time soon. I agree the I-D should mention this.
So, the designer have decided that it is appropriate to require CAs to 
change their software,
rather than asking server software developers to change theirs. I 
acknowledge that there are
more servers in operation than CAs, but that's not really the right 
metric. The issue is how
many sources of server software are used by the vast majority of 
servers. I'm guessing that
that number is small, especially compared to the number of CAs, many of 
which have had to
write all or most of their provisining software. This is a critical 
design decision that
ought to be articulated in the document, and agreed upon by the WG, not 
just the CT design team.

Steve

--------------070806000408030504070500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ben,

    

    


    

    

      
... Ok, that's what you do, but 5280
        describes a long list of cert path validation rules

        

          

            

              
 and your doc just
                says that these can be relaxed. It does not prohibit a
                log from

                performing  the full set dictated by PKIX and X.509 path
                validation procedures, nor

                does it provide guidance of which subset SHOULD/MUST be
                performed. Absent such guidance

                different log operators can legitimately perform
                different checks, resulting in chaos.

            

            


            

            
I don't believe it will result in chaos, but anyway,
              the purpose of checking signatures on log submissions is
              to combat spam. I don't think we should tightly define
              exactly what checks are performed to that end, because
              that's a great way to leave yourself unable to defend
              against some kind of unforeseen spam. We can certainly
              clarify that. I've added a ticket.

          

        

      

    

    Perhaps I have not been clear enough in specifying my concern. A CA
    (or cert Subject) submitting

    a cert chain to a log needs to know, unambiguously, what checks will
    be performed. This specificity

    is needed to ensure that submissions to multiple logs will all be
    accepted or rejected (assuming

    that the root CA for the chain is advertised as acceptable by the
    log operator).

    

      

        

          

            
 

            

              

                
...

                If we had a agreed-upon  requirements doc that explained
                why the serial number is 

                critical, and if it discussed the impact on CAs that may
                use serial number management

                techniques that preclude pre-determining the serial
                number assigned to a cert, then

                we would be in good shape. But we don't. So, I think we
                may have a serious problem

                with this aspect of the precert model.

              

            

            


            

            
The purpose of CT is to detect mis-issuance so that it
              can be rectified. As already explained, some revocation
              mechanisms require the serial number of the revoked cert.
              I don\t think we need a separate requirements doc for it
              to be obvious that without the serial number, we have a
              problem.

          

        

      

    

    I think we do need a document that specifies what remediation
    mechanisms are required. I

    saw no reference to revocation in the doc. Some list members have
    speculated that CT is

    a reputation mechanism, and a recent response from you supported
    that notion. A reputation

    mechanism need not make use of revocation as per X.509 mechanisms.
    For example, one might

    have an auditor distribute a list of "bad" certs to clients, where
    the public key was the

    means of identifying the bad cert. I agree that one remediation
    mechanism calls for the

    issuing CA to put a detected, bad cert onto a CRL. But, that
    presumes that the mis-issuance

    was an error or the result of an attack. Since there is no attack
    model for CT, I don't

    know if that is the only sort of mis-issuance event it is supposed
    to counter.

    

      

        

          

            
 

            

              

                
...

                "Compliant" with what set of specs? I noted an aspect of
                a design for a CA-focused

                HSM that, for several years, was used by VeriSign to
                issue every cert. It is a powerful

                feature for high assurance cert issuance. It is also
                incompatible with the precert design.

                The precert design seems to preclude use of some
                approaches to serial number management

                that may reduce CA secruity. Thus it appears to be a
                tradeoff, one that this WG has not

                discussed. Please describe what you mean by a
                "complaint" CA. 

              

            

            


            

            
I do not believe that the use of an HSM in any way
              constrains a CA's ability to deal with serial numbers as
              needed. The issue of compliance is a red herring.

          

        

      

    

    You introduced the term "complaint" into this issue, not me, so if
    it is a red herring, it's yours!

    More to the point, I identified a legitimate way for HSMs to
    operate, to reduce the vulnerability

    of a CA to the sort of attack that DigiNotar experienced. And, that
    model of operation has been

    used by large CAs in the past. Your offhand dismissal of this issue
    is inappropriate. In essence

    you are saying that Google has developed a rough model of how to
    make CT work and CAs need to

    'make changes to their operational processes, and to software and
    maybe hardware, to accommodate

    your model. This is an inappropriate mindset for working in the
    IETF.

    

      

        

          

            
 

            

              
...

              

            

            


            

            
Precerts are critical because otherwise server s/w has
              to be updated to deliver SCTs to clients. We know that
              isn't going to happen universally any time soon. I agree
              the I-D should mention this.

          

        

      

    

    So, the designer have decided that it is appropriate to require CAs
    to change their software,

    rather than asking server software developers to change theirs. I
    acknowledge that there are

    more servers in operation than CAs, but that's not really the right
    metric. The issue is how

    many sources of server software are used by the vast majority of
    servers. I'm guessing that

    that number is small, especially compared to the number of CAs, many
    of which have had to 

    write all or most of their provisining software. This is a critical
    design decision that

    ought to be articulated in the document, and agreed upon by the WG,
    not just the CT design team.

    

    Steve

  


--------------070806000408030504070500--


From nobody Wed Jul 23 13:28:12 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD52C1B2882 for ; Wed, 23 Jul 2014 13:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 bDqZ2mvgQKNC for ; Wed, 23 Jul 2014 13:28:08 -0700 (PDT)
Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF161A0B0E for ; Wed, 23 Jul 2014 13:28:08 -0700 (PDT)
X-AuditID: a66201d1-f790e6d000005dca-a3-53d01ad796e3
Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by ecl1mtaoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 97.EA.24010.7DA10D35; Wed, 23 Jul 2014 20:28: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 1XA38x-0004KX-6p; Wed, 23 Jul 2014 16:28:07 -0400
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Wed, 23 Jul 2014 13:27:45 -0700
From: Rick Andrews 
To: Melinda Shore , "trans@ietf.org" 
Date: Wed, 23 Jul 2014 13:27:43 -0700
Thread-Topic: [Trans] Contributing to the issue tracker
Thread-Index: Ac+meNw0pwAZzw3TRf6gXJ0A/pgNyQANvMiQ
Message-ID: <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <53CFB67A.9010904@gmail.com>
In-Reply-To: <53CFB67A.9010904@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42LhMnA9pXtd6kKwwceDYhZtbbNYLNY+vsji wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGVMOzGDueA1b8XKbfuZGxiXc3cxcnJICJhI TPl6kx3CFpO4cG89WxcjF4eQwDtGie61rcwQzitGie/9h9ghnFWMEo8+fGEEaWET0JPY8vgK WLuIgJ9E9+VHzCA2i4CqRPOn1UA1HBzCAmYSu977QpSYS3yZvYERwjaSmLapH6ycVyBKYtf+ 3SwgtpCAhkTzsZUsIK2cApoSU6/ngoQZgY77fmoNE4jNLCAucevJfCaIowUkluw5zwxhi0q8 fPyPFaJeVOJO+3pGiHodiQW7P7FB2NoSyxa+hlorKHFy5hOWCYxis5CMnYWkZRaSlllIWhYw sqxilElNzjHMLUnMLy0pSK0wMNQrrsxNBEZSsl5yfu4mRmA0LUtivLiD8cJh3UOMAhyMSjy8 QcIXgoVYE8uAKg8xSnAwK4nw/vl+PliINyWxsiq1KD++qDQntfgQozQHi5I4b7f2iWAhgfTE ktTs1NSC1CKYLBMHp1QDY+y5DueqV0qni00Xz6nxfL781OYU2QdaMW/23Jj75vrlxP/Xoq/s ndfuMVPdcum190dSZ8eXOx/tmFDlX/BV//6ySUUVYR9Llm2LsXwQEWyj5s/kE3HPIE/1cqWF QJqNjdTBl9z32JnFma+m8eiduzP9dMHxNUyqC/cukCt4kBxR+0dWU3eBpRJLcUaioRZzUXEi AP6HUHmiAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/EepQzfa71sc3PQW4a-h4sHhjn8g
Subject: Re: [Trans] Contributing to the issue tracker
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, 23 Jul 2014 20:28:10 -0000

Will the issues raised by Stephen Kent and Russ Housely will make it onto t=
he issue tracker, and/or be considered for Google's initial rollout next Ja=
nuary?

At least one of the comments suggested changing the protocol to allow for e=
asier algorithm agility in the future, and I don't see that on the tracker.=
 Stephen also asked for a description of how CT would be incrementally depl=
oyed, and he doubted that a flag day would be viewed as credible. But we're=
 marching towards a flag day now. He also suggested trying to simplify prec=
ertificates or come up with alternatives, and that's captured in Ticket #26=
, but that's unlikely to be done in time to help any CAs before January.

-Rick

-----Original Message-----
From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Melinda Shore
Sent: Wednesday, July 23, 2014 6:20 AM
To: trans@ietf.org
Subject: [Trans] Contributing to the issue tracker

I've been reminded to remind everybody that the issue tracker
(http://tools.ietf.org/wg/trans/trac/report/1) is currently open to additio=
ns from anybody who's got an IETF tools account.
Please review the open tickets, but also add tickets for issues you've iden=
tified that need to be resolved before 6962-bis will be ready for working g=
roup last call.  (It would be helpful to start a discussion on the mailing =
list before opening a ticket).

In the event that the tracker is abused we'll restrict access, but for the =
time being we're keeping it open.  Note that Eran Messeri is the de facto i=
ssue tracker editor and can help with issue tracker questions, etc.

Thanks,

Melinda

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


From nobody Wed Jul 23 13:30:19 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B106D1B299C for ; Wed, 23 Jul 2014 13:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 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, RP_MATCHES_RCVD=-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 3SRMpJtg5r8U for ; Wed, 23 Jul 2014 13:30:16 -0700 (PDT)
Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46D81B2910 for ; Wed, 23 Jul 2014 13:30:16 -0700 (PDT)
Received: by mail-vc0-f171.google.com with SMTP id hq11so3204025vcb.16 for ; Wed, 23 Jul 2014 13:30:15 -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=+1lSmTLS4XyOcUl/4upmqNdSTIXnlQZ5zbOS+KoZN9I=; b=o4O5FpaDM6+oQNHWEw32HXEc28sPuzQQ4IWHGmS+6GNyonD0TZRB8C6prFqMR6iHnx BCVGFTTKlk5omFnFucSzgGdD/sd3NuNzSAIoPow+0Prnw/ewUOpTbg3WV1jY56jAj0L2 7VZ6ptNNgDqGuZobJybcQ5ZHGEHZeOALMkivGTpydpNsk+T0B7uKM/VAuks/iPiwJdHc ToD8QU1sLQHIKwkvXMFRC4cPEHSWuVcALsT1zjpDkVcUzmVx1zRzVLpiI+3C3JljmuUh yTnuDc8YhgTfLOjrlOBg2X75SCqUGNZcM7zSGv44TqisPq86v2T120TGvQ+kXe3M0BLX h1bw==
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=+1lSmTLS4XyOcUl/4upmqNdSTIXnlQZ5zbOS+KoZN9I=; b=io6LgKJVccRnq1Pd0wz/2n2FDuSxkXzrgByzL3vDlZItBeI7THVBLElrN5QsIfCeAN wRycF3efJkBNAWF+CF4B0bqVhV5NE/eHWI6ZnaGhGN87Tl9voh9bosJ4TXPNUUtRPxwy pkEcR0gDnobgoZ6zpc/Sx1Ct1e5qhL65+9MOtCp2XaGGWJZ86EAccARdxuFKvPRpt7WE +k+4iZO/0nozvomIB4jmqSLUzDQU6UmQZ87lfgpQECaCPaogKBa56fdLAKP0fV09OwFY XMDg9mwxN+LnO0SgtGPyDeng7G6S6MSWV0iEzuu6/DbKrbDH3uh9Ts1vRjfM8usjirU0 aBPQ==
X-Gm-Message-State: ALoCoQmOOZAxAytBE3j4NzcjBfjNPQKJJmbQ40Rs9zeqdKMwHd0sM53T71Gz9ux8/+ntfC9SSGws
MIME-Version: 1.0
X-Received: by 10.221.69.8 with SMTP id ya8mr5837457vcb.39.1406147415740; Wed, 23 Jul 2014 13:30:15 -0700 (PDT)
Received: by 10.52.161.201 with HTTP; Wed, 23 Jul 2014 13:30:15 -0700 (PDT)
Date: Wed, 23 Jul 2014 21:30:15 +0100
Message-ID: 
From: Eran Messeri 
To: "trans@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11369fa037c37504fee235c0
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-HKvfZ9c0zwog53_311qXRmBdlk
Subject: [Trans] When are non-EE certificates expected to be logged?
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, 23 Jul 2014 20:30:17 -0000

--001a11369fa037c37504fee235c0
Content-Type: text/plain; charset=UTF-8

Following a discussion about correlating SCTs to certificates (ticket 23
):

My understanding is that any intermediate CA certificate may be logged
(either as a Precertificate or after issuance) *in addition* to the
end-entity certificate.

RFC6962 only requires TLS clients to validate SCTs for server certificates
(presumably end-entity certificates), so SCTs for any intermediate is not
very useful.

The only case I see where an intermediate CA certificate is logged
*instead* of a CA certificate is when a Name-Constrained intermediate CA
cert is logged.

In light of this, it seems that ticket 23 can be solved by specifying that
TLS clients check all non-embedded SCTs against the end-entity certificate
or the intermediate certificate with extension OID 1.3.6.1.4.1.11129.2.4.7.

Eran

--001a11369fa037c37504fee235c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Following a discussion about correlating SCTs to certifica=
tes (ticket =
23):

My understanding is that any intermediate CA ce=
rtificate may be logged (either as a Precertificate or after issuance) *in =
addition* to the end-entity certificate.



RFC6962 only requires TLS clients to validate SCTs for =
server certificates (presumably end-entity certificates), so SCTs for any i=
ntermediate is not very useful.

The only case I se=
e where an intermediate CA certificate is logged *instead* of a CA certific=
ate is when a Name-Constrained intermediate CA cert is logged.



In light of this, it seems that ticket 23 can be solved=
 by specifying that TLS clients check all non-embedded SCTs against the end=
-entity certificate or the intermediate certificate with extension=C2=A0OID 1.3.6.1.4.1.11129.2.4.7.



Eran=C2=A0


--001a11369fa037c37504fee235c0--


From nobody Wed Jul 23 13:52:59 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297B81A03F9 for ; Wed, 23 Jul 2014 13:52: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 ZKfyNTKYucsk for ; Wed, 23 Jul 2014 13:52:54 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893D31B296A for ; Wed, 23 Jul 2014 13:52:54 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id rd18so1494337iec.28 for ; Wed, 23 Jul 2014 13:52:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=RCRUO/h+bRB0mH+Fiibhq+u75LIFRyExEMRuwU6kyQY=; b=snbAg0OoqN9hh7pJFyMvc0BcaXsxia0pYgSYjpGDh0TLlMwZWH0EC1apsaAgM1s65r OWGw7Aym9QP9ISEEphHaq9zvPOJiNMYnYfwZEVWg+9iX2a80jdlGtxtyg9TBofPfKHg7 cV5ChAr70P0HiuE8We3tQHYrh/Eu958rvnW/MiA9HD7oL6FO9AzFa/nSmZpyle9AsNw1 EiZnTDXkDplnoWSZaRFNq6TMgylpPa43F50arL5fXIOvidtG4wnD7i3we570sb+jmUcN 2dosR9cnjLZxfUrYrcGZyUAEtnzyCqZ7PbT8laEj0KEQYlR4F8Wg9mLzdDIw6DXUq+n4 m5pA==
X-Received: by 10.42.110.208 with SMTP id r16mr6294053icp.17.1406148773811; Wed, 23 Jul 2014 13:52:53 -0700 (PDT)
Received: from dhcp-9055.meeting.ietf.org (dhcp-9055.meeting.ietf.org. [31.133.144.85]) by mx.google.com with ESMTPSA id il3sm16130038igb.1.2014.07.23.13.52.52 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 13:52:53 -0700 (PDT)
Message-ID: <53D020A4.8070904@gmail.com>
Date: Wed, 23 Jul 2014 16:52:52 -0400
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Rick Andrews ,  "trans@ietf.org" 
References: <53CFB67A.9010904@gmail.com> <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/98TdOeTHdRf6r6MFY9cRu4HN2nU
Subject: Re: [Trans] Contributing to the issue tracker
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, 23 Jul 2014 20:52:56 -0000

On 7/23/14, 4:27 PM, Rick Andrews wrote:
> Will the issues raised by Stephen Kent and Russ Housely will make it
> onto the issue tracker, and/or be considered for Google's initial
> rollout next January?

One of the things we'll be talking about on Friday and then
bringing back to the mailing list is working method, and
whether or not the issue tracker is going to be comprehensive.
Clearly there are some issues that have been raised and that
need to be addressed that haven't yet made it into the tracker
(frankly Steve's big blast of issues was almost certainly
challenging to break down).  Regardless of whether or not
there are tickets created for every issue raised, we'll be
making sure they're addressed on the mailing list and brought
to closure.

What makes it into Google's code is out of scope for the working
group.

Melinda


From nobody Wed Jul 23 13:57:10 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121611A0181 for ; Wed, 23 Jul 2014 13:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 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, RP_MATCHES_RCVD=-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 YIC2MbD8LQh8 for ; Wed, 23 Jul 2014 13:57:08 -0700 (PDT)
Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93BF11A0033 for ; Wed, 23 Jul 2014 13:57:08 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id hu12so3267497vcb.6 for ; Wed, 23 Jul 2014 13:57:07 -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=5Q3Zj8zAh+Hm65wI2TzKUTfZkZ67TJAFZGkfh+pqN00=; b=FdF0EinMs6n4XuDfwt0h6O4g5wvzpFzPu2u0qm6PLJlt+TB0Lwfva0JozyMeXV3LFF Mv7VU3wJX5JwziQajg1dJ8veRwdh3C9V4XCK9/jEdXsfmWEGbWUfDQgoSyWM3LnL+0LN QkT1uremL3pYZwz2jsmQc5K985zf2NpMDajTcmqTksMw39PFdFeO0jOa2AwQ1qaxihk/ lcenrvFGlyC02vaNbnrhu0T2JBYTJGRn+8Sw922pKeQpCEdzkiRtWPWenec0ogKIeybk UT3+FPcMgkf267uBA4T2my7sOTdOsA/OCq3twWePWSlcTvAnzBBltrXl58oNUrYf+QAM V5QA==
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=5Q3Zj8zAh+Hm65wI2TzKUTfZkZ67TJAFZGkfh+pqN00=; b=PLvWoi33iBlnLm7T7tBp6d0aYNY/hU8n+bxzA9Gnxn94W4KNhfSrzGQO1KrkGvW7/v T1jd3FW4l8cZRUja/I8xTq7mkcX8Wl4Ao+LdmaWp+Tf8qc1kjtAn9XSpDA4rZRLAVciC rVQnLeRMN9ixK9u6kNwrYXUWK0ONfYYEbyc4ErfMigjwCcw/LubDoJ5a8mpRfpltaDAI LEqpeRfx81Nvzt3I5YWAngHsnouIPKrnYrc7j+h02xi4BJ1N+EIjWIvQtJoab2rWQE71 /aKh7seFfR1JfSc0JqfM8LzQXOYF9AiktReaRfaEDgx14pmmnlaDN7+HaXoTj70oaF0p 7wkQ==
X-Gm-Message-State: ALoCoQnv9vKTNU46B6LmzFGR38oZe1MAYGKvjLiRPYS9hXF3msMrKIScd8wV596DxmLAN9bPWx4h
MIME-Version: 1.0
X-Received: by 10.220.7.71 with SMTP id c7mr5927433vcc.77.1406149027771; Wed, 23 Jul 2014 13:57:07 -0700 (PDT)
Received: by 10.52.161.201 with HTTP; Wed, 23 Jul 2014 13:57:07 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <53CFB67A.9010904@gmail.com> <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Wed, 23 Jul 2014 21:57:07 +0100
Message-ID: 
From: Eran Messeri 
To: Rick Andrews 
Content-Type: multipart/alternative; boundary=001a11c3b4124d518304fee295db
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hwGDnoAWV0VcDJx-30eObxllW8M
Cc: Melinda Shore , "trans@ietf.org" 
Subject: Re: [Trans] Contributing to the issue tracker
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, 23 Jul 2014 20:57:10 -0000

--001a11c3b4124d518304fee295db
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 23, 2014 at 9:27 PM, Rick Andrews 
wrote:

> Will the issues raised by Stephen Kent and Russ Housely will make it onto
> the issue tracker, and/or be considered for Google's initial rollout next
> January?
>
Yes - there were quite a few comments. Some of them were
 addressed
,
some of them will be. We're working on putting together an organized
response. Melinda kindly reminded everyone that the issue tracker is open -
making the comments as specific issues in the tracker is a guaranteed way
to get a faster response from me, anyway (I'm terrible at reading long,
verbose emails).

>
> At least one of the comments suggested changing the protocol to allow for
> easier algorithm agility in the future, and I don't see that on the
> tracker. Stephen also asked for a description of how CT would be
> incrementally deployed, and he doubted that a flag day would be viewed as
> credible.

I agree there should be more explanations about deployment - we should do
better on documenting the different aspects of CT. I think Chromium's CT/EV
plan
 and
log inclusion policy are some of these documents, though.

I simply think that deployment issues should not be in this RFC. My view is
that this RFC would be used by implementors of logs, monitors or clients,
so it should not discuss matters which could be considered operational.


> But we're marching towards a flag day now. He also suggested trying to
> simplify precertificates or come up with alternatives, and that's captured
> in Ticket #26, but that's unlikely to be done in time to help any CAs
> before January.
>
(1) I'd love to see a concrete proposal for simplifying Precertificates. My
understanding is that we're after a standardized data structure which
includes a signature and would be easy for CAs to use.
(2) I don't believe we'll be changing the Precertificates format before
January - Ben should provide more details on that.

>
> -Rick
>
> -----Original Message-----
> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Melinda Shore
> Sent: Wednesday, July 23, 2014 6:20 AM
> To: trans@ietf.org
> Subject: [Trans] Contributing to the issue tracker
>
> I've been reminded to remind everybody that the issue tracker
> (http://tools.ietf.org/wg/trans/trac/report/1) is currently open to
> additions from anybody who's got an IETF tools account.
> Please review the open tickets, but also add tickets for issues you've
> identified that need to be resolved before 6962-bis will be ready for
> working group last call.  (It would be helpful to start a discussion on the
> mailing list before opening a ticket).
>
> In the event that the tracker is abused we'll restrict access, but for the
> time being we're keeping it open.  Note that Eran Messeri is the de facto
> issue tracker editor and can help with issue tracker questions, etc.
>
> Thanks,
>
> Melinda
>
> _______________________________________________
> 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
>

--001a11c3b4124d518304fee295db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Jul 23, 2014 at 9:27 PM, Rick Andrews <=
;Rick_Andrew=
s@symantec.com> wrote:


Will the issues raised by Stephen Kent and R=
uss Housely will make it onto the issue tracker, and/or be considered for G=
oogle's initial rollout next January?


Yes - there were quite a few comments. Some of them were<=
/a>=C2=A0addressed, some of th=
em will be. We're working on putting together an organized response. Me=
linda kindly reminded everyone that the issue tracker is open - making the =
comments as specific issues in the tracker is a guaranteed way to get a fas=
ter response from me, anyway (I'm terrible at reading long, verbose ema=
ils).





At least one of the comments suggested changing the protocol to allow for e=
asier algorithm agility in the future, and I don't see that on the trac=
ker. Stephen also asked for a description of how CT would be incrementally =
deployed, and he doubted that a flag day would be viewed as credible.

I agree there should be more explanations about deployment - we should=
 do better on documenting the different aspects of CT. I think Chr=
omium's CT/EV plan=C2=A0and log inclusion policy=C2=A0are some of t=
hese documents, though.



I simply think that deployment issues should not be in =
this RFC. My view is that this RFC would be used by implementors of logs, m=
onitors or clients, so it should not discuss matters which could be conside=
red operational.


=C2=A0
But we're marching towa=
rds a flag day now. He also suggested trying to simplify precertificates or=
 come up with alternatives, and that's captured in Ticket #26, but that=
's unlikely to be done in time to help any CAs before January.


(1) I'd love to see a concrete proposal for simplifyi=
ng Precertificates. My understanding is that we're after a standardized=
 data structure which includes a signature and would be easy for CAs to use=
.


(2) I don't believe we'll be changing the Precertificates form=
at before January - Ben should provide more details on that.




-Rick




-----Original Message-----

From: Trans [mailto:trans-bounces=
@ietf.org] On Behalf Of Melinda Shore

Sent: Wednesday, July 23, 2014 6:20 AM

To: trans@ietf.org

Subject: [Trans] Contributing to the issue tracker



I've been reminded to remind everybody that the issue tracker

(http://tools.ietf.org/wg/trans/trac/report/1) is currently open to add=
itions from anybody who's got an IETF tools account.

Please review the open tickets, but also add tickets for issues you've =
identified that need to be resolved before 6962-bis will be ready for worki=
ng group last call. =C2=A0(It would be helpful to start a discussion on the=
 mailing list before opening a ticket).




In the event that the tracker is abused we'll restrict access, but for =
the time being we're keeping it open. =C2=A0Note that Eran Messeri is t=
he de facto issue tracker editor and can help with issue tracker questions,=
 etc.




Thanks,



Melinda



_______________________________________________

Trans mailing list

Trans@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/trans



_______________________________________________

Trans mailing list

Trans@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/trans





--001a11c3b4124d518304fee295db--


From nobody Wed Jul 23 15:11:27 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724811A03C5 for ; Wed, 23 Jul 2014 15:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 irhIlQKEGWPY for ; Wed, 23 Jul 2014 15:11:24 -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 0D9A61A03A9 for ; Wed, 23 Jul 2014 15:11:24 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:51463 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XA4l5-000EkG-SO for trans@ietf.org; Wed, 23 Jul 2014 18:11:36 -0400
Message-ID: <53D0330A.9030003@bbn.com>
Date: Wed, 23 Jul 2014 18:11:22 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: trans@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030909070100010601060502"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/HM3DBKvIeDGMQTlGZH629UR5xT0
Subject: Re: [Trans] When are non-EE certificates expected to be logged?
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, 23 Jul 2014 22:11:25 -0000

This is a multi-part message in MIME format.
--------------030909070100010601060502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Eran,
> Following a discussion about correlating SCTs to certificates (ticket 
> 23 ):
>
> My understanding is that any intermediate CA certificate may be logged 
> (either as a Precertificate or after issuance) *in addition* to the 
> end-entity certificate.
>
> RFC6962 only requires TLS clients to validate SCTs for server 
> certificates (presumably end-entity certificates), so SCTs for any 
> intermediate is not very useful.
6962 is experimental, so it's not binding. It's what this new doc says, 
when approved by the WG
and the IESG, that counts.
> The only case I see where an intermediate CA certificate is logged 
> *instead* of a CA certificate is when a Name-Constrained intermediate 
> CA cert is logged.
I think you mean to say "The only case I see where an intermediate CA 
certificate is logged *instead* of an EE certificate ..." right?
> In light of this, it seems that ticket 23 can be solved by specifying 
> that TLS clients check all non-embedded SCTs against the end-entity 
> certificate or the intermediate certificate with extension OID 
> 1.3.6.1.4.1.11129.2.4.7.
This statement isn't as clear as it needs to be, since it talks about 
what a client does for a
non-embedded SCT. Does a TLS client check an SCT that it encounters 
embedded in a CA cert?

Steve

--------------030909070100010601060502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Eran,

    

      
Following a discussion about correlating SCTs to
        certificates (ticket
          23):
        


        

        
My understanding is that any intermediate CA certificate
          may be logged (either as a Precertificate or after issuance)
          *in addition* to the end-entity certificate.

        


        

        
RFC6962 only requires TLS clients to validate SCTs for
          server certificates (presumably end-entity certificates), so
          SCTs for any intermediate is not very useful.

      

    

    6962 is experimental, so it's not binding. It's what this new doc
    says, when approved by the WG

    and the IESG, that counts.

    

      

        
The only case I see where an intermediate CA certificate is
          logged *instead* of a CA certificate is when a
          Name-Constrained intermediate CA cert is logged.

      

    

    I think you mean to say "The only case I see where an intermediate
    CA certificate is logged *instead* of an EE certificate ..." right?

    

      

        
In light of this, it seems that ticket 23 can be solved by
          specifying that TLS clients check all non-embedded SCTs
          against the end-entity certificate or the intermediate
          certificate with extension OID
            1.3.6.1.4.1.11129.2.4.7.

      

    

    This statement isn't as clear as it needs to be, since it talks
    about what a client does for a

    non-embedded SCT. Does a TLS client check an SCT that it encounters
    embedded in a CA cert?

    

    Steve

  


--------------030909070100010601060502--


From nobody Wed Jul 23 16:30:36 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801511A0174 for ; Wed, 23 Jul 2014 16:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 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, RP_MATCHES_RCVD=-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 AoPSrr_TMZ43 for ; Wed, 23 Jul 2014 16:30:34 -0700 (PDT)
Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265741B27B4 for ; Wed, 23 Jul 2014 16:30:34 -0700 (PDT)
Received: by mail-vc0-f178.google.com with SMTP id la4so3544578vcb.23 for ; Wed, 23 Jul 2014 16:30:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oMdgfi45OJIwiHOzVYimvr4QgPKstK53A4xBKb5+xtQ=; b=lV+WV/VDr4XJ5fhTt7fJd28H2s6asAO+8Klm6Y/BEHeLAFwxvTekASvTt32KWTpINP wgi9XZEI8KxplXvByJGLDMH+O3jjalqQv7xdn20jefF9/4v8k52YRwXEk+FMwHJGGyxi eIxAqgJDtNSVXTWSb/8xyFbw1m+RE4cF5V+dtWA9AuhjuskjsMoSqZD6j6mD5vFL2ty3 nqw1YbZJ86Ve0Ue8Ry6mrCN9NGIwtTOiI057npC9kPNemtbEXNUA1KqJOfvAf/0KVM9G 4V46jShhoKjRLCzlBeSPIN9HYxVgQDqW+KUWbH/EPH+8T1Z4XrYSHIBpt7di0wokcYAT ydaQ==
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=oMdgfi45OJIwiHOzVYimvr4QgPKstK53A4xBKb5+xtQ=; b=lnNXQeq6XCDGusrh6UW2qD1JRG67e+AIn7Ohgq+80ev4M2yPfRum6n+Jqj/uzrP9Bf v/cEdSRwiF1cvSGMGc+5ZGuXwTobWlxv8oe9Bl/O1KNOWnTKABvXsOsBq5aD36k6CbV1 qtstMd/BMh9VbozrBm/yPRlurRj1GDGdTNykmhITnPhUmsliNFxTlkUvPI2I5VXXre16 02NklCZ1ttZPxk9h3VEOn0BoOcZ33wUDroxyeuXChe8w0djEkso5TiPSd676oq5v0mkJ YxsLUDA7kFgj5eoRU5P7X5cepU6drSuW9h6j8D+KwF4SZ2P5xzG+VSughVrVagDAVkdL 00Kg==
X-Gm-Message-State: ALoCoQnbpE6lF4Ry63m+fjazEOaZyaOLCyFfJHNC5rA3Zh4ZRqVTeuS8ozYGIlofcXptu7fVVk/G
MIME-Version: 1.0
X-Received: by 10.52.228.40 with SMTP id sf8mr5887377vdc.78.1406158233210; Wed, 23 Jul 2014 16:30:33 -0700 (PDT)
Received: by 10.52.161.201 with HTTP; Wed, 23 Jul 2014 16:30:33 -0700 (PDT)
In-Reply-To: <53D0330A.9030003@bbn.com>
References:  <53D0330A.9030003@bbn.com>
Date: Thu, 24 Jul 2014 00:30:33 +0100
Message-ID: 
From: Eran Messeri 
To: Stephen Kent 
Content-Type: multipart/alternative; boundary=089e011602cefd2e1b04fee4b9cc
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/R7E4yWuHQFy2zxnfW6_PuhPSQ5k
Cc: "trans@ietf.org" 
Subject: Re: [Trans] When are non-EE certificates expected to be logged?
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, 23 Jul 2014 23:30:35 -0000

--089e011602cefd2e1b04fee4b9cc
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 23, 2014 at 11:11 PM, Stephen Kent  wrote:

>  Eran,
>
>  Following a discussion about correlating SCTs to certificates (ticket 23
> ):
>
>  My understanding is that any intermediate CA certificate may be logged
> (either as a Precertificate or after issuance) *in addition* to the
> end-entity certificate.
>
>  RFC6962 only requires TLS clients to validate SCTs for server
> certificates (presumably end-entity certificates), so SCTs for any
> intermediate is not very useful.
>
> 6962 is experimental, so it's not binding. It's what this new doc says,
> when approved by the WG
> and the IESG, that counts.
>
Sure, I simply meant this is the current situation (the wording in this
section has not changed between RFC6962 and RFC6962-bis).

>
>  The only case I see where an intermediate CA certificate is logged
> *instead* of a CA certificate is when a Name-Constrained intermediate CA
> cert is logged.
>
> I think you mean to say "The only case I see where an intermediate CA
> certificate is logged *instead* of an EE certificate ..." right?
>
> Indeed.

>  In light of this, it seems that ticket 23 can be solved by specifying
> that TLS clients check all non-embedded SCTs against the end-entity
> certificate or the intermediate certificate with extension OID
> 1.3.6.1.4.1.11129.2.4.7.
>
> This statement isn't as clear as it needs to be, since it talks about what
> a client does for a
> non-embedded SCT. Does a TLS client check an SCT that it encounters
> embedded in a CA cert?
>
That's the point - the current wording of RFC6962-bis says nothing about
the client should be doing regarding SCTs embedded in non-EE certificates.
My proposal is to say TLS clients SHOULD check SCTs against the EE
certificate OR the intermediate with said extension OID.

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

--089e011602cefd2e1b04fee4b9cc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Wed, Jul 23, 2014 at 11:11 PM, Stephen Kent &l=
t;kent@bbn.com> wrote:



 =20
   =20
 =20
  

    Eran,


    

      
Following a discussion about correlating SCTs to
        certificates (ticket
          23):
        


        

        
My understanding is that any intermediate CA certificate
          may be logged (either as a Precertificate or after issuance)
          *in addition* to the end-entity certificate.

        


        

        
RFC6962 only requires TLS clients to validate SCTs for
          server certificates (presumably end-entity certificates), so
          SCTs for any intermediate is not very useful.

      

    

    6962 is experimental, so it's not binding. It's what this new d=
oc
    says, when approved by the WG

    and the IESG, that counts.
Sure, I simply meant =
this is the current situation (the wording in this section has not changed =
between RFC6962 and RFC6962-bis).=C2=A0




    

      

        
The only case I see where an intermediate CA certificate is
          logged *instead* of a CA certificate is when a
          Name-Constrained intermediate CA cert is logged.

      

    

    I think you mean to say "The only case I see where an intermediate
    CA certificate is logged *instead* of an EE certificate ..." right=
?

Indeed.=C2=A0



    

      

        
In light of this, it seems that ticket 23 can be solved by
          specifying that TLS clients check all non-embedded SCTs
          against the end-entity certificate or the intermediate
          certificate with extension=C2=A0OID
            1.3.6.1.4.1.11129.2.4.7.

      

    

    This statement isn't as clear as it needs to be, since it talks
    about what a client does for a

    non-embedded SCT. Does a TLS client check an SCT that it encounters
    embedded in a CA cert?
That's the point =
- the current wording of RFC6962-bis says nothing about the client should b=
e doing regarding SCTs embedded in non-EE certificates. My proposal is to s=
ay TLS clients SHOULD check SCTs against the EE certificate OR the intermed=
iate with said extension OID.=C2=A0



    

    Steve

  



_______________________________________________

Trans mailing list

Trans@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/trans





--089e011602cefd2e1b04fee4b9cc--


From nobody Thu Jul 24 06:30:48 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BCB1A0345 for ; Thu, 24 Jul 2014 06:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.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 sykbnTRp_GwR for ; Thu, 24 Jul 2014 06:30:45 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7983F1A0320 for ; Thu, 24 Jul 2014 06:30:45 -0700 (PDT)
Received: by mail-ig0-f182.google.com with SMTP id c1so2660641igq.9 for ; Thu, 24 Jul 2014 06:30:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VjGI3QUCo74MguMAm18R+2NvqJXmmqg3wU3ZMT/HxYI=; b=DIziTnY//veVVj3LkW69mBjZAxMlrfeQPiZP3ZUo4v6tlH4Q9/ciz3xsag1BxMP7DF pVjoJGuAk/5wNNfDLtWIuXJcLdd0xrlvp7y/0pyQQ11SUq3LcqROnL+b+C7H9DIKrZia sakJHpwFrf5lVgTIhV5euoMYDS522M8L8PWG3X+AQ/AkB8r/hkTjEhtSJbyAFQQLZ3oC z+hwkdmC+FTxGacrHbr1+bFvOwEUFxgV8cJejLrKxUsGfmixU0IbWYQeZadHCc5s+5X5 cYSG1g5erMZXxH/8lM2hKqberiEqD90TEWSjwfTDa/3aCA83Z4WRvSrUZ02BoA9RIW6y +ZRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VjGI3QUCo74MguMAm18R+2NvqJXmmqg3wU3ZMT/HxYI=; b=JVuZracQO7Wk+fa5FR6VSNYOE8onUoq3pcReB+vH4LXvmuPWIgxxM8y6NBOecpI83R 9dwELvcCnhxgY6iOkwazGwYXSFrwN7qzRuTje3mhTQeIMH2ZmX0G/juU26vbZx2WMH9D Kb2GLQivQobExyvJKOteYmtJOuJ8l/hf5Wbnrovd/kVQEwAjnwBzYO+tkOrB29j7ki7R r4jxoURmLt7nslV5V+FVArSAR82JUOE7cE4aI/DlcSGC/JiSuexrNJR3lIbOtDwog1pV CvRXiLNN2xUBgpprXeFtSot7on295zl2KB9EYq1M7TnshkPotlNuD7Np8GPq1iH7D2Lt tXEA==
X-Gm-Message-State: ALoCoQlHftcB+6ieGT3yR8sm+qKsZnx3X0zfwJcVdxM0C8pbzEbZ5AxxHcYoDdBWJCHynWbVj2ms
MIME-Version: 1.0
X-Received: by 10.42.32.136 with SMTP id e8mr12638252icd.44.1406208644564; Thu, 24 Jul 2014 06:30:44 -0700 (PDT)
Received: by 10.64.97.65 with HTTP; Thu, 24 Jul 2014 06:30:44 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <53CFB67A.9010904@gmail.com> <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Thu, 24 Jul 2014 14:30:44 +0100
Message-ID: 
From: Ben Laurie 
To: Rick Andrews 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/oJxJlOWRZzNY3ssRPv9x6tddbhk
Cc: Melinda Shore , "trans@ietf.org" 
Subject: Re: [Trans] Contributing to the issue tracker
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, 24 Jul 2014 13:30:46 -0000

On 23 July 2014 21:27, Rick Andrews  wrote:
> Will the issues raised by Stephen Kent and Russ Housely will make it onto=
 the issue tracker, and/or be considered for Google's initial rollout next =
January?
>
> At least one of the comments suggested changing the protocol to allow for=
 easier algorithm agility in the future, and I don't see that on the tracke=
r.

We made at least one change towards that in -04 (the hash algorithm is
now chosen from a registry).

> Stephen also asked for a description of how CT would be incrementally dep=
loyed, and he doubted that a flag day would be viewed as credible.
But we're marching towards a flag day now. He also suggested trying to
simplify precertificates or come up with alternatives, and that's
captured in Ticket #26, but that's unlikely to be done in time to help
any CAs before January.

I don't think it is correct to characterise what we're doing as a flag
day. You can absolutely deploy CT before we switch it on in Chrome.
What we're marching towards is a deadline, a completely different
thing.

On precertificates, one thing I should clarify is that Google will not
be adopting 6962-bis before January, even if it is done by then, for
the obvious reason that there's not going to be enough time.

However, we are working towards supporting the private domain label
extension as a retrofit to 6962, since we've heard from CAs that it is
important to them.

>
> -Rick
>
> -----Original Message-----
> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Melinda Shore
> Sent: Wednesday, July 23, 2014 6:20 AM
> To: trans@ietf.org
> Subject: [Trans] Contributing to the issue tracker
>
> I've been reminded to remind everybody that the issue tracker
> (http://tools.ietf.org/wg/trans/trac/report/1) is currently open to addit=
ions from anybody who's got an IETF tools account.
> Please review the open tickets, but also add tickets for issues you've id=
entified that need to be resolved before 6962-bis will be ready for working=
 group last call.  (It would be helpful to start a discussion on the mailin=
g list before opening a ticket).
>
> In the event that the tracker is abused we'll restrict access, but for th=
e time being we're keeping it open.  Note that Eran Messeri is the de facto=
 issue tracker editor and can help with issue tracker questions, etc.
>
> Thanks,
>
> Melinda
>
> _______________________________________________
> 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 Thu Jul 24 07:52:12 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E821A0361 for ; Thu, 24 Jul 2014 07:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 32B_9pAJz7wB for ; Thu, 24 Jul 2014 07:52:07 -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 EB3791A03EA for ; Thu, 24 Jul 2014 07:52:06 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:47411 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XAKNI-000HjW-Tx for trans@ietf.org; Thu, 24 Jul 2014 10:52:04 -0400
Message-ID: <53D11D94.2080502@bbn.com>
Date: Thu, 24 Jul 2014 10:52:04 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: trans@ietf.org
References: <53CFB67A.9010904@gmail.com> <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/vtULhb57QrP-C-TH3x2wr_O19EE
Subject: Re: [Trans] Contributing to the issue tracker
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, 24 Jul 2014 14:52:10 -0000

Ben,

> ...
>
>> Stephen also asked for a description of how CT would be incrementally deployed, and he doubted that a flag day would be viewed as credible.
> But we're marching towards a flag day now.
Google has chosen to adopt a flag day approach for its 6962 deployment.
This WG gets to make it's own decision on this topic. But, in any case, 
6962-bis
needs to state explicitly whether it assumes a flag day or incremental 
deployment.
> He also suggested trying to
> simplify precertificates or come up with alternatives, and that's
> captured in Ticket #26, but that's unlikely to be done in time to help
> any CAs before January.
Not an issue for this WG, because you're discussing a Google-centric 
activity, not
the standard that this WG is developing, right?
> I don't think it is correct to characterise what we're doing as a flag
> day. You can absolutely deploy CT before we switch it on in Chrome.
> What we're marching towards is a deadline, a completely different
> thing.
What can be deployed before this WG is done is an implementation of an 
experimental
protocol, not the standards track protocol being developed. How is the 
deployment
of that experimental protocol relevant to the discussion of what is in the
standards track doc?
> On precertificates, one thing I should clarify is that Google will not
> be adopting 6962-bis before January, even if it is done by then, for
> the obvious reason that there's not going to be enough time.
again, I assume our ongoing discuss is about 6962-bis.
> However, we are working towards supporting the private domain label
> extension as a retrofit to 6962, since we've heard from CAs that it is
> important to them.
Wouldn't this require CAs to reissue CA certs to the private domains?
have CAs said that they view it as feasible to perform such re-issuance
in the time frame you noted? Never mind, that another 6962 topic, not a
6962-bis topic.

Steve


From nobody Thu Jul 24 08:06:08 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7CF1A0377 for ; Thu, 24 Jul 2014 08:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.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 2Bj0ytfU6rcP for ; Thu, 24 Jul 2014 08:06:01 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202921A03EB for ; Thu, 24 Jul 2014 08:04:48 -0700 (PDT)
Received: by mail-ig0-f177.google.com with SMTP id hn18so2773153igb.16 for ; Thu, 24 Jul 2014 08:04:47 -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=T/e1LOgoqZ3PVdr+4UXjcFsKcn2V7euy7we00VjjUB0=; b=OYxvh6/HEW+Ek4xYmqZdLy3cLdHpXkMoDqbFAzyDXumFg9vsrc/sIOmIdiMmBeC2sx 1SEB/ijEOs8KJoEkZjf1a7hASIOGNDwHAoQ4UqnutS1T17ntjLx+blldLeCRDdkshB73 5qmmnKNnieCJ0xWMMkgKQatz+dO12HKTQHIxJbmkmCBr4ZDOZkbVkRHLgBDu7X96fTma /5zUv2kr7SVC9u+CHNsI+qSwHh0oxgT+jH5I3y5ruqEowWhrOzJf6Uel8oz1Yn0xinee 28p6z6CQd2i0WxArcll6Sr5Q2B7X6VgH2LjWEOF8YPaNWj54rhsAgelIw+hPl/Ywl9oU 12/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=T/e1LOgoqZ3PVdr+4UXjcFsKcn2V7euy7we00VjjUB0=; b=jwJSFA67jiqG3YmxVhBwZBlOfcFWQ6TWh0H05cATHB6CGy0NxV8ExC8oKDoYhD4AdT uEoHPLDwSqsBPu1eUPmrVM3mJ3b4iXAY9tidLN1pVzNa4YPiFJsYQAUJqKQkb7Rq0IYq +e+dYnCnF32d6EzK8aKVYrEa0slDRdak8+ofxkk3UiXg4r2nNjxZqm5eT6v2DUflM090 iQLNo+MLTurCQrY4AHlQywiytvW/zjqgG95ltcca4X6/d28+kNv1OyAT3TUoiBbC7Li0 Mlbo1eWf11QXQjMW7wngn+tA4G7wUp5/DWifVOxLGGWT+hFo7q7GVCuP8eM0djCeGmLe O+MA==
X-Gm-Message-State: ALoCoQlk6byWPnrbqghy7GgXNbTDedYDCakL898FpKPOhtEpiMg4hDOF5lJPHGv6L1R+BVgEFkbV
MIME-Version: 1.0
X-Received: by 10.42.96.132 with SMTP id j4mr13329978icn.16.1406214287052; Thu, 24 Jul 2014 08:04:47 -0700 (PDT)
Received: by 10.64.97.65 with HTTP; Thu, 24 Jul 2014 08:04:46 -0700 (PDT)
In-Reply-To: <53D11D94.2080502@bbn.com>
References: <53CFB67A.9010904@gmail.com> <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53D11D94.2080502@bbn.com>
Date: Thu, 24 Jul 2014 16:04:46 +0100
Message-ID: 
From: Ben Laurie 
To: Stephen Kent 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ferQi_sLv5uRnmIgEA2tx8HG_LQ
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Contributing to the issue tracker
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, 24 Jul 2014 15:06:06 -0000

On 24 July 2014 15:52, Stephen Kent  wrote:
> Ben,
>
>> ...
>>
>>
>>> Stephen also asked for a description of how CT would be incrementally
>>> deployed, and he doubted that a flag day would be viewed as credible.
>>
>> But we're marching towards a flag day now.
>
> Google has chosen to adopt a flag day approach for its 6962 deployment.
> This WG gets to make it's own decision on this topic. But, in any case,
> 6962-bis
> needs to state explicitly whether it assumes a flag day or incremental
> deployment.
>
>> He also suggested trying to
>> simplify precertificates or come up with alternatives, and that's
>> captured in Ticket #26, but that's unlikely to be done in time to help
>> any CAs before January.
>
> Not an issue for this WG, because you're discussing a Google-centric
> activity, not
> the standard that this WG is developing, right?

Well, it looks like it might be a good idea to do it for -bis.

>> I don't think it is correct to characterise what we're doing as a flag
>> day. You can absolutely deploy CT before we switch it on in Chrome.
>> What we're marching towards is a deadline, a completely different
>> thing.
>
> What can be deployed before this WG is done is an implementation of an
> experimental
> protocol, not the standards track protocol being developed. How is the
> deployment
> of that experimental protocol relevant to the discussion of what is in the
> standards track doc?

What I mean is that the protocol as specified so far (in 6962-bis)
does not require a flag day. Is your point that this needs to be
explicitly stated?

>> On precertificates, one thing I should clarify is that Google will not
>> be adopting 6962-bis before January, even if it is done by then, for
>> the obvious reason that there's not going to be enough time.
>
> again, I assume our ongoing discuss is about 6962-bis.

Indeed, I am just clarifying what we're implementing.


From nobody Thu Jul 24 09:39:27 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9348D1A0444 for ; Thu, 24 Jul 2014 09:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 h6jAwTTmdXoV for ; Thu, 24 Jul 2014 09:39:15 -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 BB97E1A043D for ; Thu, 24 Jul 2014 09:39:15 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:45540 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XAM30-000L8V-Jv; Thu, 24 Jul 2014 12:39:14 -0400
Message-ID: <53D136B2.7000706@bbn.com>
Date: Thu, 24 Jul 2014 12:39:14 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Laurie 
References: <53CFB67A.9010904@gmail.com>	<544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>		<53D11D94.2080502@bbn.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/OK8HagrVjbv2749J8KfPCzYAfMs
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Contributing to the issue tracker
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, 24 Jul 2014 16:39:19 -0000

Ben,


> ...
> But we're marching towards a flag day now.
>> Google has chosen to adopt a flag day approach for its 6962 deployment.
>> This WG gets to make it's own decision on this topic. But, in any case,
>> 6962-bis
>> needs to state explicitly whether it assumes a flag day or incremental
>> deployment.
>>
>>> He also suggested trying to
>>> simplify precertificates or come up with alternatives, and that's
>>> captured in Ticket #26, but that's unlikely to be done in time to help
>>> any CAs before January.
>> Not an issue for this WG, because you're discussing a Google-centric
>> activity, not
>> the standard that this WG is developing, right?
> Well, it looks like it might be a good idea to do it for -bis.
What is the "it" to which you refer? a different pre-cert model?
>>> I don't think it is correct to characterise what we're doing as a flag
>>> day. You can absolutely deploy CT before we switch it on in Chrome.
>>> What we're marching towards is a deadline, a completely different
>>> thing.
>> What can be deployed before this WG is done is an implementation of an
>> experimental
>> protocol, not the standards track protocol being developed. How is the
>> deployment
>> of that experimental protocol relevant to the discussion of what is in the
>> standards track doc?
> What I mean is that the protocol as specified so far (in 6962-bis)
> does not require a flag day. Is your point that this needs to be
> explicitly stated?
The protocol, as currently specified in 6962-bis, does not seem compatible
with incremental deployment, yet it also does not state that a flag day is
required. For example, if a TLS client MUST reject a cert with an 
accompanying
SCT, how does this work in an incremental deployment scenario?
>>> On precertificates, one thing I should clarify is that Google will not
>>> be adopting 6962-bis before January, even if it is done by then, for
>>> the obvious reason that there's not going to be enough time.
>> again, I assume our ongoing discuss is about 6962-bis.
> Indeed, I am just clarifying what we're implementing.
A discussion of what Google is implementing, based on an Experimental 
RFC, ought
not be construed as relevant to what a standards track RFC will mandate. 
Or, are
you saying that Google feels that browser vendors, CAs and log operators 
will be
reluctant to deploy a standard that deviates in significant ways from 
the Experimental
protocol?

Steve


From nobody Thu Jul 24 11:03:00 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715ED1ABB27 for ; Thu, 24 Jul 2014 11:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 5v2V9E0lNTp4 for ; Thu, 24 Jul 2014 11:02:50 -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 DE73F1A03C4 for ; Thu, 24 Jul 2014 11:02:37 -0700 (PDT)
X-AuditID: a66201d2-f795d6d000007f82-51-53d14a3c9172
Received: from ecl1mtahubpin01.ges.symantec.com (ecl1mtahubpin01.ges.symantec.com [10.48.69.201]) by ecl1mtaoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id A6.C2.32642.C3A41D35; Thu, 24 Jul 2014 18:02:36 +0000 (GMT)
Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1XANLf-0000UO-S8; Thu, 24 Jul 2014 18:02:36 +0000
Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Thu, 24 Jul 2014 11:02:35 -0700
From: Rick Andrews 
To: Stephen Kent , Ben Laurie 
Date: Thu, 24 Jul 2014 11:02:33 -0700
Thread-Topic: [Trans] Contributing to the issue tracker
Thread-Index: Ac+nXdgrl+ficceEQ3S4TLYEy/i3jgACEx+A
Message-ID: <544B0DD62A64C1448B2DA253C011414607CD6A16B0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <53CFB67A.9010904@gmail.com> <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53D11D94.2080502@bbn.com>  <53D136B2.7000706@bbn.com>
In-Reply-To: <53D136B2.7000706@bbn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsXCZeB6UtfG62KwQU+jksWGz9fYLDbOZrRY +/giiwOzx9TzoR4LNpV6LFnykymAOYrLJiU1J7MstUjfLoEr4/y8FuaC60oVLWsfMzUw/pfu YuTkkBAwkZjzdjUzhC0mceHeerYuRi4OIYF3jBLHjz9igXBeMUq8PtHHDuGsYpRYt/obC0gL m4CexJbHV9hBbBEBW4kLB6YzgtjMAqoS244+BYuzANkf5kxk7WLk4BAWMJPY9d4Xotxc4svs DYwQtpHExAkfwEbyCkRJbJn0H+qKg0wS8/9vZQJJcAqoSyxduIgVxGYEOvX7qTVMELvEJW49 mc8E8YKAxJI956HeEZV4+fgfVL2oxJ329VC36Ugs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSf hWTsLCQts5C0zELSsoCRZRWjTGpyjmFuSWJ+aUlBaoWBkV5xZW4iMOaS9ZLzczcxAuNuWRLj pR2M9w/rHmIU4GBU4uHVdrsYLMSaWAZUeYhRgoNZSYRX1RooxJuSWFmVWpQfX1Sak1p8iFGa g0VJnLdb+0SwkEB6YklqdmpqQWoRTJaJg1OqgTE748eimsslEXmn07yZY/J1z366td2zoqHx XLWLzatZxldKGPepLDwYcGmB+wdFRtf+kpfXq5IV9xS8ZQrdKKOoeMF86xou7jXBF0q37TbN veh5Kse035FDJX5v6MML5Xlz/oS8X/TgUIq8cNGlj6r5Uwsm/n79YZ33lOIT6hvWsfzLkL3G nKfEUpyRaKjFXFScCAAc5+YKtwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/iBSeWjqrOeHXgm7QO8Y7Qnl22Q0
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Contributing to the issue tracker
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, 24 Jul 2014 18:02:55 -0000

I'm relatively new to the ways of the IETF, so I apologize if this discussi=
on is out of scope for this list.

Google began the CT process by producing an Experimental RFC within the IET=
F. Google then asked CAs to build what's specified in that Experimental RFC=
. Some issues were uncovered and discussed; issues and resolutions have bee=
n tracked in the IETF issues tracker for 6962-bis. I think that's how I got=
 confused into thinking that we should be discussing deployment concerns in=
 the Trans working group. Up until recently, I had thought that we were exp=
ected to build 6962-bis by January, not 6962.

I speak for a number of CAs when I say that many of us are confused about e=
xactly how to build CT. We have no single reference spec to follow. Ben has=
 said that we should follow 6962, but not 6962-bis except for Ticket #1 and=
 the language in 6962-bis for that Ticket. But I guess we're supposed to ig=
nore the other tickets and the rest of the -bis document.

Since what we're building for January seems to be out of scope for this wor=
king group, I think it would be extremely helpful if Google would produce a=
 single document that we can all march to. Maybe that should be circulated =
through the CA/Browser Forum, although not all CAs are represented there, b=
ut there seem to be more there than in the Trans working group.

Finally, to paraphrase Steve, I would say I'm "reluctant to deploy an Exper=
imental protocol that may deviate in significant ways from the eventual sta=
ndard".

-Rick

-----Original Message-----
From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Kent
Sent: Thursday, July 24, 2014 9:39 AM
To: Ben Laurie
Cc: trans@ietf.org
Subject: Re: [Trans] Contributing to the issue tracker

Ben,


> ...
> But we're marching towards a flag day now.
>> Google has chosen to adopt a flag day approach for its 6962 deployment.
>> This WG gets to make it's own decision on this topic. But, in any=20
>> case, 6962-bis needs to state explicitly whether it assumes a flag=20
>> day or incremental deployment.
>>
>>> He also suggested trying to
>>> simplify precertificates or come up with alternatives, and that's=20
>>> captured in Ticket #26, but that's unlikely to be done in time to=20
>>> help any CAs before January.
>> Not an issue for this WG, because you're discussing a Google-centric=20
>> activity, not the standard that this WG is developing, right?
> Well, it looks like it might be a good idea to do it for -bis.
What is the "it" to which you refer? a different pre-cert model?
>>> I don't think it is correct to characterise what we're doing as a=20
>>> flag day. You can absolutely deploy CT before we switch it on in Chrome=
.
>>> What we're marching towards is a deadline, a completely different=20
>>> thing.
>> What can be deployed before this WG is done is an implementation of=20
>> an experimental protocol, not the standards track protocol being=20
>> developed. How is the deployment of that experimental protocol=20
>> relevant to the discussion of what is in the standards track doc?
> What I mean is that the protocol as specified so far (in 6962-bis)=20
> does not require a flag day. Is your point that this needs to be=20
> explicitly stated?
The protocol, as currently specified in 6962-bis, does not seem compatible =
with incremental deployment, yet it also does not state that a flag day is =
required. For example, if a TLS client MUST reject a cert with an accompany=
ing SCT, how does this work in an incremental deployment scenario?
>>> On precertificates, one thing I should clarify is that Google will=20
>>> not be adopting 6962-bis before January, even if it is done by then,=20
>>> for the obvious reason that there's not going to be enough time.
>> again, I assume our ongoing discuss is about 6962-bis.
> Indeed, I am just clarifying what we're implementing.
A discussion of what Google is implementing, based on an Experimental RFC, =
ought not be construed as relevant to what a standards track RFC will manda=
te.=20
Or, are
you saying that Google feels that browser vendors, CAs and log operators wi=
ll be reluctant to deploy a standard that deviates in significant ways from=
 the Experimental protocol?

Steve

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


From nobody Thu Jul 24 11:08:52 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6B21A03D1 for ; Thu, 24 Jul 2014 11:08: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 zLgj4mIv7Oea for ; Thu, 24 Jul 2014 11:08:45 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35DC1A024F for ; Thu, 24 Jul 2014 11:08:14 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id at20so2644585iec.39 for ; Thu, 24 Jul 2014 11:08:14 -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=DGsv0UhXmR5WQUo7skiO0Fiwq/bjrjfbWrflUq2nbi0=; b=NMl8RhH86qS4BJJN2AKXy+a3pSo6bUAVyf6o73tBsu3LmoQFgTbm1vDOQtJpOLQN6M 2QKq0G0nlRRyvXvRnj7fkEl8J1zeJKa0G7DUB6ckSZhKYBNMb4MEzPWn5lJQYOLGUvdu tegMTNWthme8mXWD4Bf5j2gJO4rRcNLkglko4Y4g+UdiV3FTg0o280tobC7/JnpwRgzY m9RVrxFELcNNiGqHTAYD+0VUmNgAar2p4Y7JNpXWEHs4zZyxRgTdEpPa6noXhwTsnl3I j2ObO5dOZuobAEpTP/wY71q5vUGSKl2QKkSYDXOfLecTcM8s0hOnzkLcpAbdLx0DL7KA NozQ==
X-Received: by 10.42.154.132 with SMTP id q4mr14565467icw.4.1406225294005; Thu, 24 Jul 2014 11:08:14 -0700 (PDT)
Received: from dhcp-a6fd.meeting.ietf.org (dhcp-a6fd.meeting.ietf.org. [31.133.166.253]) by mx.google.com with ESMTPSA id y14sm302589igg.0.2014.07.24.11.08.13 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 11:08:13 -0700 (PDT)
Message-ID: <53D14B8C.7090609@gmail.com>
Date: Thu, 24 Jul 2014 14:08:12 -0400
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: trans@ietf.org
References: <53CFB67A.9010904@gmail.com> <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53D11D94.2080502@bbn.com>  <53D136B2.7000706@bbn.com> <544B0DD62A64C1448B2DA253C011414607CD6A16B0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CD6A16B0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/llVjbMVFD_jnwSRIyxbUGlggt38
Subject: Re: [Trans] Contributing to the issue tracker
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, 24 Jul 2014 18:08:47 -0000

On 7/24/14, 2:02 PM, Rick Andrews wrote:
> Maybe that
> should be circulated through the CA/Browser Forum, although not all
> CAs are represented there, but there seem to be more there than in
> the Trans working group.
> Finally, to paraphrase Steve, I would say I'm "reluctant to deploy an
> Experimental protocol that may deviate in significant ways from the
> eventual standard".

If there's interest, we can use the working group wiki to
maintain deployment information (as well as deployment
reports).

Melinda


From nobody Thu Jul 24 12:00:54 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0C91B2870 for ; Thu, 24 Jul 2014 12:00:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.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 z7XcsWWNvXNC for ; Thu, 24 Jul 2014 12:00:51 -0700 (PDT)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B2A1B27FF for ; Thu, 24 Jul 2014 12:00:47 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id rp18so2702770iec.33 for ; Thu, 24 Jul 2014 12:00:47 -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=ODne5wpC6dwmuj5XFE6kicfm7kdHcNUjKkttw+ph7Gs=; b=d5ezxn2g/3Wz8sWUAMJpP4E8e+tECI8x2zOI0dqywBd8dU30BsLeLoEIZDeJ0inJ0b uv8Opl43RlqwWLJ3t4g/WPQjVua7dm8Ge5DBvACq6DB3KJg+KO3+Qw5oFh/t/edQ2Gvk PsdkcYVf4bP/9sAn0YqiBdeCAVdN7WOct082y9l+rAtPS1YoCWqB6XAD+r1r+u5BnLV8 6W+151df1tfQGeF+0p7HpcCR0kHUjvkqBmxAWGxXRdPpeToVkk6X/sVQZ/OcDb38G4xY UV0lWz1cIt/k8V8mJCMRcq4b02/BFWw5ZpQcUsRiS77E1OcgS7cOftllrLFzvfWKtCqr YgxA==
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=ODne5wpC6dwmuj5XFE6kicfm7kdHcNUjKkttw+ph7Gs=; b=Ti9reL2yQ5FMKAtd7r4Y/xIHoxsaY1W6Fzm9WngyQNJQa3ProuUoQutqGkucvxYRzQ hZf+nu+fvKi4UVJwBDR3LDJNzexscIn6k77cVyRPhgrm/bEM0BaFPiyC4jdrbbXOPCbL FShTOoFyOyInpz8ApE+q3xqKzU7+SavttWds7rUnZYgqLk91UcSaKqjvm+CibZTsoKy6 7EgE2+Trtv+G6x5LCZZESnOkajtp1Q5w5BalUQQdmahy9Ii82PT6hlL8/MDb7O5KoFq5 ERmXMxorjRV/gfWUHRFF8Xp3bQuGMBA+589lSwl+07l8nFdu22wVh2926wpdaTT/jaFF Sa8Q==
X-Gm-Message-State: ALoCoQk3ebhcDkxBbcL0ZT0pzQnNG0kTkraXhI+lir3KBak4pQiRSrxm0tEsytVleadVp5acBgSi
MIME-Version: 1.0
X-Received: by 10.50.164.202 with SMTP id ys10mr17739314igb.6.1406228446774; Thu, 24 Jul 2014 12:00:46 -0700 (PDT)
Received: by 10.64.97.65 with HTTP; Thu, 24 Jul 2014 12:00:46 -0700 (PDT)
In-Reply-To: <53D136B2.7000706@bbn.com>
References: <53CFB67A.9010904@gmail.com> <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53D11D94.2080502@bbn.com>  <53D136B2.7000706@bbn.com>
Date: Thu, 24 Jul 2014 20:00:46 +0100
Message-ID: 
From: Ben Laurie 
To: Stephen Kent 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/YFGqJqjBNA3XoDgoMCRoYrShZKI
Cc: "trans@ietf.org" 
Subject: Re: [Trans] Contributing to the issue tracker
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, 24 Jul 2014 19:00:52 -0000

On 24 July 2014 17:39, Stephen Kent  wrote:
> Ben,
>
>
>> ...
>>
>> But we're marching towards a flag day now.
>>>
>>> Google has chosen to adopt a flag day approach for its 6962 deployment.
>>> This WG gets to make it's own decision on this topic. But, in any case,
>>> 6962-bis
>>> needs to state explicitly whether it assumes a flag day or incremental
>>> deployment.
>>>
>>>> He also suggested trying to
>>>> simplify precertificates or come up with alternatives, and that's
>>>> captured in Ticket #26, but that's unlikely to be done in time to help
>>>> any CAs before January.
>>>
>>> Not an issue for this WG, because you're discussing a Google-centric
>>> activity, not
>>> the standard that this WG is developing, right?
>>
>> Well, it looks like it might be a good idea to do it for -bis.
>
> What is the "it" to which you refer? a different pre-cert model?

Yes.

>>>> I don't think it is correct to characterise what we're doing as a flag
>>>> day. You can absolutely deploy CT before we switch it on in Chrome.
>>>> What we're marching towards is a deadline, a completely different
>>>> thing.
>>>
>>> What can be deployed before this WG is done is an implementation of an
>>> experimental
>>> protocol, not the standards track protocol being developed. How is the
>>> deployment
>>> of that experimental protocol relevant to the discussion of what is in
>>> the
>>> standards track doc?
>>
>> What I mean is that the protocol as specified so far (in 6962-bis)
>> does not require a flag day. Is your point that this needs to be
>> explicitly stated?
>
> The protocol, as currently specified in 6962-bis, does not seem compatible
> with incremental deployment, yet it also does not state that a flag day is
> required. For example, if a TLS client MUST reject a cert with an
> accompanying
> SCT, how does this work in an incremental deployment scenario?

I think you mean "without an accompanying SCT". And yes, that's a fair
point, there would need to be a period when that requirement was
relaxed.

>>>> On precertificates, one thing I should clarify is that Google will not
>>>> be adopting 6962-bis before January, even if it is done by then, for
>>>> the obvious reason that there's not going to be enough time.
>>>
>>> again, I assume our ongoing discuss is about 6962-bis.
>>
>> Indeed, I am just clarifying what we're implementing.
>
> A discussion of what Google is implementing, based on an Experimental RFC,
> ought
> not be construed as relevant to what a standards track RFC will mandate. Or,
> are
> you saying that Google feels that browser vendors, CAs and log operators
> will be
> reluctant to deploy a standard that deviates in significant ways from the
> Experimental
> protocol?

No, I mentioned it only because it appears to be a point of confusion.


From nobody Thu Jul 24 12:49:02 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428D61A037D for ; Thu, 24 Jul 2014 12:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Ejj-tcSuCpNe for ; Thu, 24 Jul 2014 12:48:58 -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 DBE5E1A0444 for ; Thu, 24 Jul 2014 12:48:57 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:39012 helo=dhcp-a77c.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XAP0Z-000Pt7-QA for trans@ietf.org; Thu, 24 Jul 2014 15:48:55 -0400
Message-ID: <53D16326.3070805@bbn.com>
Date: Thu, 24 Jul 2014 15:48:54 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: trans@ietf.org
References: <53CFB67A.9010904@gmail.com> <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53D11D94.2080502@bbn.com>  <53D136B2.7000706@bbn.com> 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/QcJpuiz4d6PzJZFHfnFgv3vv8Oo
Subject: Re: [Trans] Contributing to the issue tracker
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, 24 Jul 2014 19:49:00 -0000

Ben,

> ...
>> What is the "it" to which you refer? a different pre-cert model?
> Yes.
Thanks for the clarification.
>
>>> ..
>> The protocol, as currently specified in 6962-bis, does not seem compatible
>> with incremental deployment, yet it also does not state that a flag day is
>> required. For example, if a TLS client MUST reject a cert with an
>> accompanying
>> SCT, how does this work in an incremental deployment scenario?
> I think you mean "without an accompanying SCT". And yes, that's a fair
> point, there would need to be a period when that requirement was
> relaxed.
yes, I meant "without." Glad to see we agree that the doc will need to 
explain
how to deal with incremental deployment, and thus the "MUST have an SCT" 
is too
simple to deal with this deployment scenario.
>>> ..
>> A discussion of what Google is implementing, based on an Experimental RFC,
>> ought
>> not be construed as relevant to what a standards track RFC will mandate. Or,
>> are
>> you saying that Google feels that browser vendors, CAs and log operators
>> will be
>> reluctant to deploy a standard that deviates in significant ways from the
>> Experimental
>> protocol?
> No, I mentioned it only because it appears to be a point of confusion.
Thanks for the clarification. So long as the folks (other than Google) 
deploying 6962
don't object to the fact that 6962-bis may have a number of differences, OK.

Steve


From nobody Thu Jul 24 12:49:47 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6A81A0AC7 for ; Thu, 24 Jul 2014 12:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.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 mncGhh5ynGDF for ; Thu, 24 Jul 2014 12:49:40 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1399F1A0AAD for ; Thu, 24 Jul 2014 12:49:40 -0700 (PDT)
Received: by mail-ig0-f174.google.com with SMTP id c1so6897492igq.7 for ; Thu, 24 Jul 2014 12:49:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gtSJP5ewsaYklFwfeA33BhXXqoKdDeKBVamAvjn6DU4=; b=LzEYHVhzShzSDlHxMb/vPQRt2T+lr3ZlA6jG3wNagOds4yCnDx57YRjjbE1fmruG7C 7/WGg6uxkvxrvWJTTJAUIS/F3Gk1AxF6SSSuavHr13Hyoch6YFZYDDiuynd+T+JU90Zs xfq/LjVm21U+3bRiB4k+kakcQiegndpTuTp3l36oZdXMr24xWueKWhDMi/VQ1xt/VR/q KsHhzgs7TFCe/JnThFn8JpUGr0bp6DblC9Y/j3bv+MC+lbN8Y5WLBWk2sG5wGwjZqPQY jY3gINMjyjCbpcByTBF9KFZGa5Mz6RMaumqXdN/TmEbUfYSj+VTxV4jvKZ4Mz2gp+xm7 8AeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gtSJP5ewsaYklFwfeA33BhXXqoKdDeKBVamAvjn6DU4=; b=iUD1XyK8mZ0/6hcuryQQaYruhw87Rz7VxqxGsdmSD5+MCcgk0akzbqanD/MkZ7Yn3e B/NpyFFz4QqYHYidtFA+ROepWGJWE16MTnBn6yuUUctb3bmQIgbayS4VlZxM7KemP1YU yURfdvI5NJoI5ny80NorzGc2DqhTu4pRLYuGB4ej3/8sl6jwkGN8W0XJP8e4xY18y+H5 yxJIXsKzmYpuFFoALCArbZUdqn0ePFlQD2O56KJcC7Z/gYT6CoiUoNvLV+z+0Jqvporv Xu7+YJTEUphy20pvoMZj09jtgA6gGjg2OFPuWEq+r0YZEZaHypHbGeaMpq7B9/15RgjS fZ7g==
X-Gm-Message-State: ALoCoQmKP0v8XlS1opS2YyxIhLex/Z8kmTkE2zbTVu+NLtwZeiZam5PFMir409azr2WdTdQDrzDe
MIME-Version: 1.0
X-Received: by 10.50.56.38 with SMTP id x6mr18181909igp.30.1406231379258; Thu, 24 Jul 2014 12:49:39 -0700 (PDT)
Received: by 10.64.97.65 with HTTP; Thu, 24 Jul 2014 12:49:39 -0700 (PDT)
In-Reply-To: <544B0DD62A64C1448B2DA253C011414607CD6A16B0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
References: <53CFB67A.9010904@gmail.com> <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53D11D94.2080502@bbn.com>  <53D136B2.7000706@bbn.com> <544B0DD62A64C1448B2DA253C011414607CD6A16B0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>
Date: Thu, 24 Jul 2014 20:49:39 +0100
Message-ID: 
From: Ben Laurie 
To: Rick Andrews 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/72tefvhUY61Ow4sJKytSl3oYULE
Cc: "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] Contributing to the issue tracker
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, 24 Jul 2014 19:49:41 -0000

On 24 July 2014 19:02, Rick Andrews  wrote:
> I'm relatively new to the ways of the IETF, so I apologize if this discus=
sion is out of scope for this list.
>
> Google began the CT process by producing an Experimental RFC within the I=
ETF. Google then asked CAs to build what's specified in that Experimental R=
FC. Some issues were uncovered and discussed; issues and resolutions have b=
een tracked in the IETF issues tracker for 6962-bis. I think that's how I g=
ot confused into thinking that we should be discussing deployment concerns =
in the Trans working group. Up until recently, I had thought that we were e=
xpected to build 6962-bis by January, not 6962.
>
> I speak for a number of CAs when I say that many of us are confused about=
 exactly how to build CT. We have no single reference spec to follow. Ben h=
as said that we should follow 6962, but not 6962-bis except for Ticket #1 a=
nd the language in 6962-bis for that Ticket. But I guess we're supposed to =
ignore the other tickets and the rest of the -bis document.

This is a fair point, but you are right this is not the venue for it.

> Since what we're building for January seems to be out of scope for this w=
orking group, I think it would be extremely helpful if Google would produce=
 a single document that we can all march to. Maybe that should be circulate=
d through the CA/Browser Forum, although not all CAs are represented there,=
 but there seem to be more there than in the Trans working group.

I agree that it would be helpful to produce that document. It is not
for this WG, so clearly this is not the right venue. Like you, I am
not sure where we can actually reach all CAs - and, indeed, it is not
only of interest to CAs - but we'll obviously try to circulate it as
widely as possible.

> Finally, to paraphrase Steve, I would say I'm "reluctant to deploy an Exp=
erimental protocol that may deviate in significant ways from the eventual s=
tandard".

We (Google) are not going to derail our current plans to wait for a
standard that may or may not do what we need with an uncertain
delivery date.

>
> -Rick
>
> -----Original Message-----
> From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Stephen Kent
> Sent: Thursday, July 24, 2014 9:39 AM
> To: Ben Laurie
> Cc: trans@ietf.org
> Subject: Re: [Trans] Contributing to the issue tracker
>
> Ben,
>
>
>> ...
>> But we're marching towards a flag day now.
>>> Google has chosen to adopt a flag day approach for its 6962 deployment.
>>> This WG gets to make it's own decision on this topic. But, in any
>>> case, 6962-bis needs to state explicitly whether it assumes a flag
>>> day or incremental deployment.
>>>
>>>> He also suggested trying to
>>>> simplify precertificates or come up with alternatives, and that's
>>>> captured in Ticket #26, but that's unlikely to be done in time to
>>>> help any CAs before January.
>>> Not an issue for this WG, because you're discussing a Google-centric
>>> activity, not the standard that this WG is developing, right?
>> Well, it looks like it might be a good idea to do it for -bis.
> What is the "it" to which you refer? a different pre-cert model?
>>>> I don't think it is correct to characterise what we're doing as a
>>>> flag day. You can absolutely deploy CT before we switch it on in Chrom=
e.
>>>> What we're marching towards is a deadline, a completely different
>>>> thing.
>>> What can be deployed before this WG is done is an implementation of
>>> an experimental protocol, not the standards track protocol being
>>> developed. How is the deployment of that experimental protocol
>>> relevant to the discussion of what is in the standards track doc?
>> What I mean is that the protocol as specified so far (in 6962-bis)
>> does not require a flag day. Is your point that this needs to be
>> explicitly stated?
> The protocol, as currently specified in 6962-bis, does not seem compatibl=
e with incremental deployment, yet it also does not state that a flag day i=
s required. For example, if a TLS client MUST reject a cert with an accompa=
nying SCT, how does this work in an incremental deployment scenario?
>>>> On precertificates, one thing I should clarify is that Google will
>>>> not be adopting 6962-bis before January, even if it is done by then,
>>>> for the obvious reason that there's not going to be enough time.
>>> again, I assume our ongoing discuss is about 6962-bis.
>> Indeed, I am just clarifying what we're implementing.
> A discussion of what Google is implementing, based on an Experimental RFC=
, ought not be construed as relevant to what a standards track RFC will man=
date.
> Or, are
> you saying that Google feels that browser vendors, CAs and log operators =
will be reluctant to deploy a standard that deviates in significant ways fr=
om the Experimental protocol?
>
> Steve
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans


From nobody Thu Jul 24 14:20:17 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947E11B2815 for ; Thu, 24 Jul 2014 14:20:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.313
X-Spam-Level: 
X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, SPF_SOFTFAIL=0.665] 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 r_J5P8H_4jLC for ; Thu, 24 Jul 2014 14:20:14 -0700 (PDT)
Received: from mail.hezmatt.org (mpalmer-1-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:9e6::2]) by ietfa.amsl.com (Postfix) with ESMTP id CE4431B280C for ; Thu, 24 Jul 2014 14:20:14 -0700 (PDT)
Received: from mistress.home.hezmatt.org (unknown [10.6.66.6]) by mail.hezmatt.org (Postfix) with ESMTP id A5EBB282E0B for ; Fri, 25 Jul 2014 07:20:13 +1000 (EST)
Received: by mistress.home.hezmatt.org (Postfix, from userid 1000) id D62B29FB95; Fri, 25 Jul 2014 07:20:12 +1000 (EST)
Date: Fri, 25 Jul 2014 07:20:12 +1000
From: Matt Palmer 
To: trans@ietf.org
Message-ID: <20140724212012.GK5739@hezmatt.org>
References: <53CFB67A.9010904@gmail.com> <544B0DD62A64C1448B2DA253C011414607CD6A0ECF@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>  <53D11D94.2080502@bbn.com>  <53D136B2.7000706@bbn.com>  <53D16326.3070805@bbn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53D16326.3070805@bbn.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/E7L4pyTZOzoVXIWtRwdLpXgQjgc
Subject: Re: [Trans] Contributing to the issue tracker
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, 24 Jul 2014 21:20:16 -0000

On Thu, Jul 24, 2014 at 03:48:54PM -0400, Stephen Kent wrote:
> >>A discussion of what Google is implementing, based on an Experimental
> >>RFC, ought not be construed as relevant to what a standards track RFC
> >>will mandate.  Or, are you saying that Google feels that browser
> >>vendors, CAs and log operators will be reluctant to deploy a standard
> >>that deviates in significant ways from the Experimental protocol?
> >
> >No, I mentioned it only because it appears to be a point of confusion.
>
> Thanks for the clarification. So long as the folks (other than Google)
> deploying 6962 don't object to the fact that 6962-bis may have a number of
> differences, OK.

As someone who is planning on providing a public 6962-compatible log server
and monitor/auditor well in advance of the Google CT deadline, I do not
object to the fact that 6962-bis may have a number of differences.

- Matt


From nobody Fri Jul 25 08:59:57 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6261E1B2961 for ; Fri, 25 Jul 2014 08:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P--4XlG9X_dR for ; Fri, 25 Jul 2014 08:59:55 -0700 (PDT)
Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42531B295F for ; Fri, 25 Jul 2014 08:59:54 -0700 (PDT)
Received: by mail-oi0-f48.google.com with SMTP id h136so3497290oig.35 for ; Fri, 25 Jul 2014 08:59:54 -0700 (PDT)
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=VY5vi64yFQhCfh+XAo83pVS3SZZAuTUX5c7/XuHDV20=; b=EXMVWzbcZJJPhCTKtQJvoyE31PA39joUTiYYp0/H4pN1JPGw17K/HUSo42mKowiIqR K/KL1o6N6OtiKZBv3g63xGt3cE+1w2q67Fi7JrJ8SyogDjoFM0qSoH83PfL9+gERUr2j OeEmyA/iYiRwPNWsYVs28BAw/Oa01377zgBbx9KtWp94Mt1m3l3YnhgRoJ7Fi5g2+HDL tT1PKejahLaWvlGnVYTYMweFV62GN5/E7ZfxCgnk3mVQHW8hTqD/bJi8iSId989geyXj yYMxEtLVGVnIZT3DN0rwhdYbQ3uUV/wKWvoDO+s8VSInVgb99ouaKiLmCXPsLE2JWKN6 I6jA==
X-Gm-Message-State: ALoCoQkBpOeLBNtNDa5TbE13VfZJMsxFY2LTEu4E3imnE8uXrCp9GzppTGC8pWZZp5MaC5pGrcm8
MIME-Version: 1.0
X-Received: by 10.182.126.233 with SMTP id nb9mr24433955obb.46.1406303994007;  Fri, 25 Jul 2014 08:59:54 -0700 (PDT)
Received: by 10.60.92.1 with HTTP; Fri, 25 Jul 2014 08:59:53 -0700 (PDT)
Date: Fri, 25 Jul 2014 11:59:53 -0400
Message-ID: 
From: Richard Barnes 
To: trans@ietf.org
Content-Type: multipart/alternative; boundary=001a11c1e550027d5904ff06aa3a
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4MDQmTiUmHY29DT5mvhsYLJbc8U
Subject: [Trans] DANE transparency
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, 25 Jul 2014 15:59:56 -0000

--001a11c1e550027d5904ff06aa3a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I didn't get my thoughts put together in time to get to the mic in the
meeting today, but here's roughly what I was going to say:

tl;dr: Spam on CT logs is the only major problem to solve here, and
protocol is probably not the way to solve it.

Doing transparency for the whole of DNSSEC is an unsolvable problem.  It's
massive, like Wes pointed out, and littered with tautological pitfalls.  I
could imagine some form of "DNSSEC pinning" allowing subordinates to impose
hysteresis on frequently-accessed domains, but going further than that
quickly approaches the madness that St=C3=A9phane noted.

Instead of focusing on the internals of DNSSEC, we should focus on the
things that actually impact protocol, i.e., the TLSA records at the leaf.
Normal CT is totally sufficient for these -- certs/pubkeys asserted in TLSA
are still certs/pubkeys.  If we need to change the syntax to capture things
slightly differently, we should do that, but it seems straightforward.

The only reason that chains are needed in CT is to defend against spam.
With DANE, the potential spammer is the authority, so he can make as many
spam domains as he wants.  So the "DNSSEC chain" is useless for spam
mitigation.  It's all so possible that DANE-asserted certs will change more
often, so again, we might want to tweak what's logged (e.g., to log the
public key).  Fairly minor change.

We're left with the question of how to prevent spam.  I'm not sure there's
a protocol mechanism here.  It seems like you could have a local policy at
the log to, say, limit the rate of updates that are accepted.

So I think we should:
1. Forget about solving DNSSEC transparency generally
2. Focus on getting CT ready for DANE
3. Identify any tweaks that are necessary to support DANE-asserted certs
4. Maybe write some guidelines for anti-spam

--Richard

--001a11c1e550027d5904ff06aa3a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I didn't get my thoughts put toget=
her in time to get to the mic in the meeting today, but here's roughly =
what I was going to say:

tl;dr: Spam on CT logs is the on=
ly major problem to solve here, and protocol is probably not the way to sol=
ve it.



Doing transparency for the whole of DNSSEC is an unsol=
vable problem.=C2=A0 It's massive, like Wes pointed out, and littered w=
ith tautological pitfalls.=C2=A0 I could imagine some form of "DNSSEC =
pinning" allowing subordinates to impose hysteresis on frequently-acce=
ssed domains, but going further than that quickly approaches the madness th=
at St=C3=A9phane noted.


Instead of focusing on the internals of DNSSEC, we should focus o=
n the things that actually impact protocol, i.e., the TLSA records at the l=
eaf.=C2=A0 Normal CT is totally sufficient for these -- certs/pubkeys asser=
ted in TLSA are still certs/pubkeys.=C2=A0 If we need to change the syntax =
to capture things slightly differently, we should do that, but it seems str=
aightforward.


The only reason that chains are needed in CT is to defend against=
 spam.=C2=A0 With DANE, the potential spammer is the authority, so he can m=
ake as many spam domains as he wants.=C2=A0 So the "DNSSEC chain"=
 is useless for spam mitigation.=C2=A0 It's all so possible that DANE-a=
sserted certs will change more often, so again, we might want to tweak what=
's logged (e.g., to log the public key).=C2=A0 Fairly minor change.


We're left with the question of how to prevent spam.=C2=
=A0 I'm not sure there's a protocol mechanism here.=C2=A0 It seems =
like you could have a local policy at the log to, say, limit the rate of up=
dates that are accepted. 



So I think we should:
1. Forget abo=
ut solving DNSSEC transparency generally
2. Focus on getting =
CT ready for DANE
3. Identify any tweaks that are necessary t=
o support DANE-asserted certs


4. Maybe write some guidelines for anti-spam

-=
-Richard



--001a11c1e550027d5904ff06aa3a--


From nobody Mon Jul 28 12:15:30 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B811B28B6 for ; Mon, 28 Jul 2014 12:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.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 GVFEauQRXN3M for ; Mon, 28 Jul 2014 12:15:27 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3E91B28A6 for ; Mon, 28 Jul 2014 12:15:26 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id y20so7217281ier.27 for ; Mon, 28 Jul 2014 12:15:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FBYauZeCsSoFoo0m7U6XLvrApZekeaN81xSRWmrq3lo=; b=bHJb4NTRL1tp1Ka1sixJ8+IkT2KDUGOjlbqbUCkTy2RyWXn+WYslNq9ztDxs0YNgNl wiIMoa7Cu3aKe7oB1UJR6OKCdn+6IS31rxUeGVLM3lLBE34pmFlcQM4VXYlI6uOIykZq qu6WVvINIJv6n2k5ruIaXm2FzNlP6VSfGTWWrkMRbdv6QZAs2AVTJt7aAmUyPvSzl4Xp k5DoJOs+vyD2xPXqJR0hM759AY9g9ROiPeU6LskUQSYvFBaswXMieIObRB75H6tDYpDp ENRy+d7KEdy2cl2+HtFRUGzQOJ1TYVRjXVPvDas5heAkr6JMaUjds/k3yYjXb5HHx+Q3 5zBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FBYauZeCsSoFoo0m7U6XLvrApZekeaN81xSRWmrq3lo=; b=B3ctPZYlLlD/znkjhy4QAl4619lcAxUNiDwUILA2TRyAn4phARG4ILorfAF0ePCk2/ 9/4c1XX9qTX/vUEPmzwnnxfv8MU4j3Bz6pld2D8zpeNYyPkBo9SEW64reQ670hKkW1NL XWFHZoY4RasTrMWkn2RPtAQjQQC6PEmvnskWf3NLhHwj8JiDbMxyHJcz6kr5+lQZINKY FvnXsjJKtKkhyVve0YHwu/Tk1DW1BU6Y+82Rn2od1a8ucjHV2XRWpdCLIIfMFmB6e53K Y4OFvgRti9t8gPrCTTe0EZqhEr4CqPagrJtvZ0fvNINSY2qjixteMtQTtWLvuFGlouVT JZyA==
X-Gm-Message-State: ALoCoQn2+7XiP3e7Vjuq2NscE7FZKQASNCSfwgrw3yzL0myv2x2Ium39lZsx373KgRoG74pJPeKj
MIME-Version: 1.0
X-Received: by 10.50.56.38 with SMTP id x6mr35385068igp.30.1406574926281; Mon, 28 Jul 2014 12:15:26 -0700 (PDT)
Received: by 10.64.97.65 with HTTP; Mon, 28 Jul 2014 12:15:26 -0700 (PDT)
In-Reply-To: 
References: 
Date: Mon, 28 Jul 2014 15:15:26 -0400
Message-ID: 
From: Ben Laurie 
To: Richard Barnes 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/moTFSYjPUr62_0VMW6j1IIl5IFw
Cc: "trans@ietf.org" 
Subject: Re: [Trans] DANE transparency
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, 28 Jul 2014 19:15:28 -0000

On 25 July 2014 11:59, Richard Barnes  wrote:
> I didn't get my thoughts put together in time to get to the mic in the
> meeting today, but here's roughly what I was going to say:
>
> tl;dr: Spam on CT logs is the only major problem to solve here, and proto=
col
> is probably not the way to solve it.
>
> Doing transparency for the whole of DNSSEC is an unsolvable problem.  It'=
s
> massive, like Wes pointed out, and littered with tautological pitfalls.  =
I
> could imagine some form of "DNSSEC pinning" allowing subordinates to impo=
se
> hysteresis on frequently-accessed domains, but going further than that
> quickly approaches the madness that St=C3=A9phane noted.
>
> Instead of focusing on the internals of DNSSEC, we should focus on the
> things that actually impact protocol, i.e., the TLSA records at the leaf.
> Normal CT is totally sufficient for these -- certs/pubkeys asserted in TL=
SA
> are still certs/pubkeys.  If we need to change the syntax to capture thin=
gs
> slightly differently, we should do that, but it seems straightforward.
>
> The only reason that chains are needed in CT is to defend against spam.
> With DANE, the potential spammer is the authority, so he can make as many
> spam domains as he wants.  So the "DNSSEC chain" is useless for spam
> mitigation.  It's all so possible that DANE-asserted certs will change mo=
re
> often, so again, we might want to tweak what's logged (e.g., to log the
> public key).  Fairly minor change.
>
> We're left with the question of how to prevent spam.  I'm not sure there'=
s a
> protocol mechanism here.  It seems like you could have a local policy at =
the
> log to, say, limit the rate of updates that are accepted.
>
> So I think we should:
> 1. Forget about solving DNSSEC transparency generally
> 2. Focus on getting CT ready for DANE
> 3. Identify any tweaks that are necessary to support DANE-asserted certs
> 4. Maybe write some guidelines for anti-spam

Two points:

1. In the limit, is there really a noticable difference between doing
transparency for DANE and doing transparency for all of DNSSEC?

2. DNSSEC surely exists for reasons other than to secure TLSA records.
I therefore don't buy that there's no point to making the rest of
DNSSEC transparent.

Which is not to say that a DANE-specific transparency project isn't
worth pursuing, but I don't think doing so removes the value of a
general DNSSEC transparency project.


From nobody Mon Jul 28 12:42:31 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59C21A036B for ; Mon, 28 Jul 2014 12:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 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, 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 v344cPTTSc9R for ; Mon, 28 Jul 2014 12:42:21 -0700 (PDT)
Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7BB1B27F9 for ; Mon, 28 Jul 2014 12:42:13 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id d1so4999313wiv.13 for ; Mon, 28 Jul 2014 12:42:11 -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=9q8CqSV4r6ZwjoTtoZ2yZVAuswe2/R9I56CHE356ZHs=; b=edGhnlnTPo1Ffvpd9nouxLpIBp2XY7OarD1uQbDU1RifjROEKmRx2VNSed7IJQCaGP 2tWEclsV6KAHfinfjRMJcHfZA/KXoc+DE3n7ZBTlqDVYhi5Ik/+H+OPZG7Q07netCW5A MaKIrISKNbeSsgR8AUetNlwBv3wZ+YotorZ4JgWLFS9dIT/KrLNsiBEXidF0w2HyoJdj jx06YsDcNK9f+FJMObvAF1qtTfnOgptMLb+7JPmyeWQXmCyMAUp+EXLjD+H2M3x1pUVi ShcG0qnJXbprsdyPaptEaiTxS+7LuBK44DZsfyzRzH325V80aNvjMefV+mLZ4XSeZU0x CkpQ==
MIME-Version: 1.0
X-Received: by 10.180.104.42 with SMTP id gb10mr33798161wib.65.1406576529698;  Mon, 28 Jul 2014 12:42:09 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.194.71.103 with HTTP; Mon, 28 Jul 2014 12:42:09 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 28 Jul 2014 15:42:09 -0400
X-Google-Sender-Auth: 6PGU879T7VczH7Ta9yx8wTAV6d0
Message-ID: 
From: Phillip Hallam-Baker 
To: Ben Laurie 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/wjGDte2Dt7T4JeTQhq5s7uiN6XI
Cc: Richard Barnes , "trans@ietf.org" 
Subject: Re: [Trans] DANE transparency
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, 28 Jul 2014 19:42:23 -0000

On Mon, Jul 28, 2014 at 3:15 PM, Ben Laurie  wrote:

> Two points:
>
> 1. In the limit, is there really a noticable difference between doing
> transparency for DANE and doing transparency for all of DNSSEC?
>
> 2. DNSSEC surely exists for reasons other than to secure TLSA records.
> I therefore don't buy that there's no point to making the rest of
> DNSSEC transparent.
>
> Which is not to say that a DANE-specific transparency project isn't
> worth pursuing, but I don't think doing so removes the value of a
> general DNSSEC transparency project.

+1

Unless DANE is bjorked, it should be easier to apply DANE to the
DNSSEC system and then DANE rather than just DANE/TLS.

The only advantage to doing it piecemeal is that you have more wiggle
room. Which is very useful when dealing with an infrastructure like
SMTP where the biggest problem you always face is the deployed legacy
base.

Using wiggle room when you shouldn't need it is going to result in a
spec that is stovepiped to one application and will be very hard to
port to anything else.

On top of which, DANE's achilles heel is the problem of deployment.
Getting all the folk who need to move in one direction is really hard.
We will have a functioning TRANS system operational long before
DNSSEC. So using TRANS as leverage to deploy DNSSEC makes a lot more
sense than waiting around.


From nobody Mon Jul 28 13:58:27 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91FD1A0217 for ; Mon, 28 Jul 2014 13:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, 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 3nbLJJAhSpD7 for ; Mon, 28 Jul 2014 13:58:23 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (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 E43F81A013B for ; Mon, 28 Jul 2014 13:58:22 -0700 (PDT)
Received: (qmail 4930 invoked by uid 1000); 28 Jul 2014 20:58:19 -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, 28 Jul 2014 21:58:19 +0100
Message-ID: <53D6B96A.7000600@comodo.com>
Date: Mon, 28 Jul 2014 21:58:18 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Eran Messeri 
References:  <53D0330A.9030003@bbn.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/BX-c3dGDlJLMHx6WIWuuN4Zt09k
Cc: "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] When are non-EE certificates expected to be logged?
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, 28 Jul 2014 20:58:26 -0000

On 24/07/14 00:30, Eran Messeri wrote:
> On Wed, Jul 23, 2014 at 11:11 PM, Stephen Kent wrote:

>>     In light of this, it seems that ticket 23 can be solved by
>>     specifying that TLS clients check all non-embedded SCTs against
>>     the end-entity certificate or the intermediate certificate with
>>     extension OID 1.3.6.1.4.1.11129.2.4.7.
>     This statement isn't as clear as it needs to be, since it talks
>     about what a client does for a
>     non-embedded SCT. Does a TLS client check an SCT that it encounters
>     embedded in a CA cert?
>
> That's the point - the current wording of RFC6962-bis says nothing about
> the client should be doing regarding SCTs embedded in non-EE
> certificates. My proposal is to say TLS clients SHOULD check SCTs
> against the EE certificate OR the intermediate with said extension OID.

There could be multiple intermediate certs containing said extension OID 
in the chain up to the root cert.  There could even be multiple 
certificate chains from the EE cert to 1 or more root certs, and more 
than one of those chains could contain intermediate cert(s) with said 
extension OID!

What do you think about my alternative idea (see the comments on ticket 23)?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Mon Jul 28 14:31:00 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0661B1B2830 for ; Mon, 28 Jul 2014 14:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, 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 4JJvtQw2VxNC for ; Mon, 28 Jul 2014 14:30:48 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (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 B25D11B2848 for ; Mon, 28 Jul 2014 14:30:47 -0700 (PDT)
Received: (qmail 26204 invoked by uid 1000); 28 Jul 2014 21:30:45 -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, 28 Jul 2014 22:30:45 +0100
Message-ID: <53D6C104.4020301@comodo.com>
Date: Mon, 28 Jul 2014 22:30:44 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Stephen Kent , trans@ietf.org
References: <00b701cf802e$81893ea0$849bbbe0$@globalsign.com>  <53B2F131.6030606@bbn.com>  <53B7F4B0.7060306@bbn.com>  <53D00F89.7040007@bbn.com>
In-Reply-To: <53D00F89.7040007@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-Q_xb3kwTuFkIftwRadci07Ur6g
Subject: Re: [Trans] Using a Precertificate Signing Certificate to sign TBScertificates for CT
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, 28 Jul 2014 21:30:50 -0000

On 23/07/14 20:39, Stephen Kent wrote:

>> Precerts are critical because otherwise server s/w has to be updated
>> to deliver SCTs to clients. We know that isn't going to happen
>> universally any time soon. I agree the I-D should mention this.
>
> So, the designer have decided that it is appropriate to require CAs to
> change their software, rather than asking server software developers
> to change theirs.

Actually, RFC6962 and 6962-bis do ask server software developers to 
change their software too.

> I acknowledge that there are more servers in operation than CAs, but
> that's not really the right metric. The issue is how many sources of
> server software are used by the vast majority of servers.

The vast majority of deployed servers are running old versions of the 
server software.  And in many cases, the server operators would find it 
very difficult to upgrade to the latest version even if they really, 
really wanted to.  e.g. Linux distros that still ship Apache httpd 2.2.x 
and not 2.4.x, and which are very unlikely to ship 2.6.x until N years 
after its initial release.

According to [1], the IETF's mission includes (emphasis mine):
   - Identifying, and proposing solutions to, _pressing_ operational and 
technical problems in the Internet.
   - Specifying the development or usage of protocols and the 
_near-term_ architecture to solve such technical problems for the Internet.

[1] http://www.ietf.org/tao.html

> I'm guessing that that number is small, especially compared to the
> number of CAs, many of which have had to write all or most of their
> provisining software.

Google can incentivize CAs to implement CT, simply by changing the rules 
for CAs that have trust anchors in Chrome.  Google have no such power 
over the server software authors or server software users, AFAICT.

The CAs that have written all or most of their provisioning software are 
the CAs that should find it easiest to add CT support to their 
platforms.  (It's only the CAs that use third-party CA software that 
aren't in control of this part of their own destiny).

I think it's clear that updating CA software is the only way we're 
likely to see CT deployed in the _near-term_.  Do you disagree?

> This  is a critical design decision that ought to be articulated in the
> document,  and agreed upon by the WG, not just the CT design team.

Well, if this WG is going to disagree with the very idea of 
Precertificates, then it would be nice to know sooner rather than later!

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Wed Jul 30 08:47:53 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CB51A00DA for ; Wed, 30 Jul 2014 08:47:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 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, RP_MATCHES_RCVD=-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 LaizDpxo_xaP for ; Wed, 30 Jul 2014 08:47:47 -0700 (PDT)
Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEA81A005C for ; Wed, 30 Jul 2014 08:47:47 -0700 (PDT)
Received: by mail-vc0-f176.google.com with SMTP id id10so2077210vcb.21 for ; Wed, 30 Jul 2014 08:47:46 -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=7oiYAW9rXl2r+nCZ1Fg0Mk+89SBuDkzb1978B/ghws8=; b=Jium24HLYgSlkx1z9SO6PmBrudfbzTy9Rf+zfHZVrTwBzIoza/zVzDr0D38FZyR2Ua nXSvUfpTbrP/el76m6g2Dd5wVkgi1CqA0vWRHMVy3pNqjCrFsse1PRstKlHpRA2I6rgn l5s8LAViR3P9GAkoUceafTENU+1nwab30BWvvUn7nxBgqXSvjRIH2KOj/Z73QK/2k81w 55kwVikkcWd2Fg7xYW+xceEFWV7yxiwn4JmKLIUFo0pSvVozECjfrYXgN4Lkb60pKv++ fZc4+yei/HlWVyxoWTFRbsT1t11aI6v/E5GReYLXVc1F1RE1UwIiBG45Z5q8PIPvnInR cwWQ==
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=7oiYAW9rXl2r+nCZ1Fg0Mk+89SBuDkzb1978B/ghws8=; b=LQlQoiLlTZLi+E2OBsxiMR6lhGSDXkwMmk4FcEu3kTBkdFyON7W4WB7V1IkWcDlMMk 6YGVSHPWmnM7OfG51xH1cGDjWsf6VfNyq1iYGearbd86Sc84qVh0o0UNyT7yM5gAo2qb kTXVBofNpQiCZcNkchhdPxWvYtAaF0+IWWOQ4Bb+EVKM22aJ/DFnxJxR8u4IO1PXvnsI 8KzJUqOfHa+LhgekmYmW6Kfp9uhkC3WymOQZnY++e/8RE0vli4ny8A7Sr4FIrCEBJfH1 WKXysdkxxZBze/ZooypkOgxPwzLYHRPc0OkzeoKw5z/2TrfmNERYUz+8VzJcxrIu7c6y hJVQ==
X-Gm-Message-State: ALoCoQmqIswePb1Eenqw9Ps5jRLeOL7CmHaoff2Laf3sXwjfT1y3eaV9PJ81YQYa0qKjUMyExiNw
MIME-Version: 1.0
X-Received: by 10.52.120.83 with SMTP id la19mr3244890vdb.68.1406735266147; Wed, 30 Jul 2014 08:47:46 -0700 (PDT)
Received: by 10.52.24.82 with HTTP; Wed, 30 Jul 2014 08:47:46 -0700 (PDT)
In-Reply-To: <53D6B96A.7000600@comodo.com>
References:  <53D0330A.9030003@bbn.com>  <53D6B96A.7000600@comodo.com>
Date: Wed, 30 Jul 2014 16:47:46 +0100
Message-ID: 
From: Eran Messeri 
To: Rob Stradling 
Content-Type: multipart/alternative; boundary=089e0122f12ed50c5404ff6b135b
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/0a7CN76g1caozRCLfgaSIV9z3Lg
Cc: "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] When are non-EE certificates expected to be logged?
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, 30 Jul 2014 15:47:50 -0000

--089e0122f12ed50c5404ff6b135b
Content-Type: text/plain; charset=UTF-8

On Mon, Jul 28, 2014 at 9:58 PM, Rob Stradling 
wrote:

> On 24/07/14 00:30, Eran Messeri wrote:
>
>> On Wed, Jul 23, 2014 at 11:11 PM, Stephen Kent wrote:
>>
> 
>
>      In light of this, it seems that ticket 23 can be solved by
>>>     specifying that TLS clients check all non-embedded SCTs against
>>>     the end-entity certificate or the intermediate certificate with
>>>     extension OID 1.3.6.1.4.1.11129.2.4.7.
>>>
>>     This statement isn't as clear as it needs to be, since it talks
>>     about what a client does for a
>>     non-embedded SCT. Does a TLS client check an SCT that it encounters
>>     embedded in a CA cert?
>>
>> That's the point - the current wording of RFC6962-bis says nothing about
>> the client should be doing regarding SCTs embedded in non-EE
>> certificates. My proposal is to say TLS clients SHOULD check SCTs
>> against the EE certificate OR the intermediate with said extension OID.
>>
>
> There could be multiple intermediate certs containing said extension OID
> in the chain up to the root cert.  There could even be multiple certificate
> chains from the EE cert to 1 or more root certs, and more than one of those
> chains could contain intermediate cert(s) with said extension OID!
>
> What do you think about my alternative idea (see the comments on ticket
> 23)?

Given the cases you've mentioned above, I think it'd make sense to use the
metadata addition to the data structure you proposed.
I'll merge ticket 23 with ticket 10.


>
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>

--089e0122f12ed50c5404ff6b135b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Mon, Jul 28, 2014 at 9:58 PM, Rob Stradling &l=
t;rob.stradli=
ng@comodo.com> wrote:


On 24/07/14 00:30, Eran Messeri wrote:



On Wed, Jul 23, 2014 at 11:11 PM, Stephen Kent wrote:



<snip>




=C2=A0 =C2=A0 In light of this, it seems that ticket 23 can be solved by
=C2=A0 =C2=A0 specifying that TLS clients check all non-embedded SCTs again=
st

=C2=A0 =C2=A0 the end-entity certificate or the intermediate certificate wi=
th

=C2=A0 =C2=A0 extension OID 1.3.6.1.4.1.11129.2.4.7.



=C2=A0 =C2=A0 This statement isn't as clear as it needs to be, since it=
 talks

=C2=A0 =C2=A0 about what a client does for a

=C2=A0 =C2=A0 non-embedded SCT. Does a TLS client check an SCT that it enco=
unters

=C2=A0 =C2=A0 embedded in a CA cert?



That's the point - the current wording of RFC6962-bis says nothing abou=
t

the client should be doing regarding SCTs embedded in non-EE

certificates. My proposal is to say TLS clients SHOULD check SCTs

against the EE certificate OR the intermediate with said extension OID.





There could be multiple intermediate certs containing said extension OID in=
 the chain up to the root cert. =C2=A0There could even be multiple certific=
ate chains from the EE cert to 1 or more root certs, and more than one of t=
hose chains could contain intermediate cert(s) with said extension OID!




What do you think about my alternative idea (see the comments on ticket 23)=
?
Given the cases you've mentioned above, I think it&#=
39;d make sense to use the metadata addition to the data structure you prop=
osed.


I'll merge ticket 23 with ticket 10.
=C2=A0




-- 

Rob Stradling

Senior Research & Development Scientist

COMODO - Creating Trust Online





--089e0122f12ed50c5404ff6b135b--


From nobody Wed Jul 30 08:53:45 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D401A00E9 for ; Wed, 30 Jul 2014 08:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level: 
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, 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 hRFiKUbE4nxT for ; Wed, 30 Jul 2014 08:53:39 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (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 EC20D1A00DA for ; Wed, 30 Jul 2014 08:53:38 -0700 (PDT)
Received: (qmail 19432 invoked by uid 1000); 30 Jul 2014 15:53:36 -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, 30 Jul 2014 16:53:36 +0100
Message-ID: <53D91500.3070701@comodo.com>
Date: Wed, 30 Jul 2014 16:53:36 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Eran Messeri 
References:  <53D0330A.9030003@bbn.com>  <53D6B96A.7000600@comodo.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/7K2p6MgQQFa3RMeITTWDoJwzE-I
Cc: "trans@ietf.org" , Stephen Kent 
Subject: Re: [Trans] When are non-EE certificates expected to be logged?
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, 30 Jul 2014 15:53:42 -0000

On 30/07/14 16:47, Eran Messeri wrote:

> Given the cases you've mentioned above, I think it'd make sense to use
> the metadata addition to the data structure you proposed.
> I'll merge ticket 23 with ticket 10.

Thanks Eran.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From nobody Wed Jul 30 10:32:24 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D69C1A0183 for ; Wed, 30 Jul 2014 10:32:21 -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 NPBQQ4MFxQGk for ; Wed, 30 Jul 2014 10:32:20 -0700 (PDT)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B751A017A for ; Wed, 30 Jul 2014 10:32:15 -0700 (PDT)
Received: by mail-pd0-f178.google.com with SMTP id w10so1810806pde.37 for ; Wed, 30 Jul 2014 10:32:15 -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 :content-type:content-transfer-encoding; bh=+G/cSkyRnL2XnB+uVDlkI0U2reN8cwFYS55q8DTC8N8=; b=JIsDcG0bWl/2CvqCKXtzsNj1kMg5SaxdJJ4cYR8vCtcPdVF0ILpl5XWAXaWv3L95Ai rtosh1QNEUWeENpaUzSlndu8ihAyFNkh+FkQSCqIjEXTLazXKmJspv9MqNirUQTHIXA8 gXogIw+NeG6hkB7ZTot/RgnKBM1oCA+2isclNPpgI20EWyiFEzQnkDy9QL7O1+DcyTAP 68qv+nR0mlhPAutMlgxr+79Dygf5XcPIqBQlXjT+0Wk6hSxQq+BeGxSL1K3Ll0LmKTD0 x4qkI+3XqKNjD/0SrDcuOZj7kfk/VjDfZkeuuYiSW1HMOcR82wu4+TNpUySMa57obAuz VBRg==
X-Received: by 10.68.247.137 with SMTP id ye9mr6625926pbc.69.1406741535581; Wed, 30 Jul 2014 10:32:15 -0700 (PDT)
Received: from spandex.local (216-67-50-63-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.50.63]) by mx.google.com with ESMTPSA id l3sm2950450pbq.8.2014.07.30.10.32.14 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 10:32:14 -0700 (PDT)
Message-ID: <53D92C1D.8030309@gmail.com>
Date: Wed, 30 Jul 2014 09:32:13 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "trans@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/qiOwyhTmSN26MUOt-BJk7kCqIQ8
Subject: [Trans] Follow-up from Toronto
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, 30 Jul 2014 17:32:21 -0000

Hi, all:

Many thanks for a productive meeting last Friday.  We'll be getting
minutes posted ASAP, but in the meantime the audio recording of the
meeting has been posted here:
http://www.ietf.org/audio/ietf90/ietf90-manitoba-20140725-0900-am1.mp3.
We'll also get the link to the Meetecho recording sent out once
it's posted (Friday sessions are not up yet).

Over the next few days we'll be bringing follow-up questions from
the session to the mailing list.  We're also interested in getting
high-level feedback about the two new logging proposals, but the
focus will remain on making progress on the -bis document.

Thanks again,

Melinda & Paul


From nobody Wed Jul 30 14:13:55 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726331A04A1 for ; Wed, 30 Jul 2014 14:13: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 ew86pemldl3u for ; Wed, 30 Jul 2014 14:13:51 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAAC61A046A for ; Wed, 30 Jul 2014 14:13:51 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id y10so2138501pdj.0 for ; Wed, 30 Jul 2014 14:13:51 -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 :content-type:content-transfer-encoding; bh=Gv0zL8OUIiLB/76opbEZt7Sbk7RsqDb1nhj7AF+YCf0=; b=xEZFhkTCalOnATnjAcASkpiwkyn0Vt55ZrxsyQbWEXAdjhpIAzccCi4kc6C0LPip7J BbkZumoMQkMU1fXVlp+qj3CcdYIqBU4JREd9oXAw/KHbb50GOTRYhXjYJ33yL4yzjNyg h06mqhje6pQRrUcqofaKEl7/6Q8BA+T23xjzCFs2hFI5lj+U6hah6n/+rb8t9gscQYYx LN1RTZeqqyRV8HbUf/sL524BVm/5PRSSesTX8zupi21CO5BU28FO8AacN1gTCMPUbu6b hvRLYr2Ez7QWT28RwJ1j9CtOIIUUPljvfhNoXhOl1aYwNgKMVfcseLa6yl33kUw80QEM MNHw==
X-Received: by 10.66.163.65 with SMTP id yg1mr7729296pab.33.1406754831299; Wed, 30 Jul 2014 14:13:51 -0700 (PDT)
Received: from spandex.local (216-67-50-63-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.50.63]) by mx.google.com with ESMTPSA id oo3sm4981776pdb.19.2014.07.30.14.13.49 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 14:13:50 -0700 (PDT)
Message-ID: <53D9600C.6040805@gmail.com>
Date: Wed, 30 Jul 2014 13:13:48 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "trans@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/NN6W9ofraREZCo-R_4782qRGplw
Subject: [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, 30 Jul 2014 21:13:53 -0000

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 Jul 30 14:52:44 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD831A0113 for ; Wed, 30 Jul 2014 14:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 KGS4raIXaMQ6 for ; Wed, 30 Jul 2014 14:52:40 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618921A00A6 for ; Wed, 30 Jul 2014 14:52:40 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway1.nyi.internal (Postfix) with ESMTP id 9833524994 for ; Wed, 30 Jul 2014 17:52:38 -0400 (EDT)
Received: from web2 ([10.202.2.212]) by compute3.internal (MEProxy); Wed, 30 Jul 2014 17:52:38 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= tom-fitzhenry.me.uk; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=mesmtp; bh=ogCc56vNIAMi21Da4bBEz6/23AE=; b=prpBts Ba8p9rpMITVAK1/nnvexj1Q3ql/CzGkNMQV/d7A9MhC7Grh+zVQQl+Kl7q6MpCXb wybVSG2r1lDzQcG0+ZoOZ60xmW4pCxuEmWvPIQ5tSoOGIfsqDrF08qPfuV3wJz3m o/s1bs/Az0FmV/01E+CLFQ//NziK/lc7JYw3k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=ogCc56vNIAMi21Da4bBEz6/23AE=; b=CC4Yr neHirxmJerQfBky+GgCGFqavddtNef0iIgMPExsRLQyNoeS7MxYteLgW+Mi6tomr +Z1YighWLuNoKFlx7/kO7FkQzfjC3oOJKe8ljUiqTmwOMjHFiwSBjBLewz8ogS/y B2+bBul0cewAEPymLJai0MagWW2jiYXg6OTMys=
Received: by web2.nyi.internal (Postfix, from userid 99) id 7B4DC54010F; Wed, 30 Jul 2014 17:52:38 -0400 (EDT)
Message-Id: <1406757158.1295591.147462486.432B0FF0@webmail.messagingengine.com>
X-Sasl-Enc: tvIM9/ooSFr9TvBL5VKIAJG9leBCv+ok2I3MIvks8NtT 1406757158
From: Tom Fitzhenry 
To: trans@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
X-Mailer: MessagingEngine.com Webmail Interface - ajax-36a9b403
Date: Wed, 30 Jul 2014 14:52:38 -0700
In-Reply-To: <53D9600C.6040805@gmail.com>
References: <53D9600C.6040805@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5sTvRtB3iyDwblzN0BMAU33TNY8
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, 30 Jul 2014 21:52:42 -0000

http://ct-watch.tom-fitzhenry.me.uk/ is an incomplete implementation of
monitoring/auditing.

Source code: https://github.com/certificate-transparency-watch

Feel free to mention it wherever.

-- 
Tom Fitzhenry


From nobody Wed Jul 30 15:21:20 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DE61A050E for ; Wed, 30 Jul 2014 15:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 gl7zdv17w2Sp for ; Wed, 30 Jul 2014 15:21:07 -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 415031A00E8 for ; Wed, 30 Jul 2014 15:21:07 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51222) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCcFL-0009k5-8o for trans@ietf.org; Wed, 30 Jul 2014 18:21:19 -0400
Message-ID: <53D96FD2.2090607@bbn.com>
Date: Wed, 30 Jul 2014 18:21:06 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "trans@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/AePmNwbUcVmiy7_nXckgqAUTN98
Subject: [Trans] tickets
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, 30 Jul 2014 22:21:09 -0000

I created a set of tickets, based on a small subset of the comments I 
provided
in messages I sent before the Toronto meeting.

Steve


From nobody Wed Jul 30 15:36:09 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C771E1A0264 for ; Wed, 30 Jul 2014 15:36:07 -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 1RxhByMQdvYr for ; Wed, 30 Jul 2014 15:36:06 -0700 (PDT)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27C51A0111 for ; Wed, 30 Jul 2014 15:36:06 -0700 (PDT)
Received: by mail-pa0-f52.google.com with SMTP id bj1so2336277pad.25 for ; Wed, 30 Jul 2014 15:36:06 -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=vUjAOMLi52vg2dKUl95gVHs0cR2BlCiJ0J0+uunx5wo=; b=bH9itJL2mM1RvPE02b3AlMfNsYi4P5ABWZvbNsx9jzB1jbmu86EhGRmI9b93GD/3uP thHhaDz6l5tLJSGoFIktdP65tkAlhoefTg8WiGcQc2touyGWlqIHw4Eff60K2srQLEFZ kDuUMwgwEqeuscjh5V15SfADU+4s38KJIeaHRh68DR/AShIBWf8M3QOUWacDPFj5ch6e YM8NJzAZnSZ3I0Qxh1mxmr/9AJZnqXNNyJp2FDPbIvGg9WXLaWlhhUl2wjBIhEM7cUut v9dB6vX4/3jyqjALZG8UrVj5b3gxtXPLgheQLUnprBRsohwPmct1TM5lrqGAqo3N/6+U 4Flg==
X-Received: by 10.69.17.230 with SMTP id gh6mr57444pbd.0.1406759766301; Wed, 30 Jul 2014 15:36:06 -0700 (PDT)
Received: from spandex.local (216-67-50-63-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.50.63]) by mx.google.com with ESMTPSA id iq10sm3418124pbc.14.2014.07.30.15.36.04 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 15:36:05 -0700 (PDT)
Message-ID: <53D97353.7060702@gmail.com>
Date: Wed, 30 Jul 2014 14:36:03 -0800
From: Melinda Shore 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Stephen Kent , "trans@ietf.org" 
References: <53D96FD2.2090607@bbn.com>
In-Reply-To: <53D96FD2.2090607@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/viK2M5D5NpB91y8HnWG6RotkF2k
Subject: Re: [Trans] tickets
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, 30 Jul 2014 22:36:07 -0000

On 7/30/14 2:21 PM, Stephen Kent wrote:
> I created a set of tickets, based on a small subset of the comments I
> provided
> in messages I sent before the Toronto meeting.

Excellent - thank you.

Melinda



From nobody Thu Jul 31 05:11:46 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525001A8BB0 for ; Thu, 31 Jul 2014 05:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.871
X-Spam-Level: 
X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, SPF_NEUTRAL=0.779] 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 3YhGaJr9qJkr for ; Thu, 31 Jul 2014 05:11:35 -0700 (PDT)
Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08351B27B4 for ; Thu, 31 Jul 2014 05:09:48 -0700 (PDT)
Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s6VC9kBb019326 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 Jul 2014 14:09:46 +0200
Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id s6VC9hvQ002252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 Jul 2014 12:09:45 GMT
VBR-Info: md=nordu.net; mc=all; mv=swamid.se
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1406808586; bh=N0uPIu8oxNGB6LYzCb5gJR2tzcTvcIHrVAaBbrfnwE0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=kMRUogC5TiWf9Epsb4zlw5UVjawBbScoov1TARfnEH5ZI/EPrPls2v0PZiogGvzCQ ooXXtsDSNP7hDB2WDzDxh3I+eLTsYYmojp3OVYuZL2Itd+lAJjpibfZhjIjUPEy/PL GpLWtzVAycgwWbuszgzAnHcC82UaX4aJtkE/Enrg=
X-Footer: bm9yZHUubmV0
Received: from flogsta.nordberg.se ([193.10.5.129]) (authenticated user linus@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher AES128-GCM-SHA256 (128 bits)); Thu, 31 Jul 2014 14:09:44 +0200
From: Linus Nordberg 
To: Melinda Shore 
Organization: NORDUnet A/S
References: <53D9600C.6040805@gmail.com>
Date: Thu, 31 Jul 2014 14:09:56 +0200
In-Reply-To: <53D9600C.6040805@gmail.com> (Melinda Shore's message of "Wed, 30 Jul 2014 13:13:48 -0800")
Message-ID: <871tt191bf.fsf@nordberg.se>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Scanned-By: CanIt (www . roaringpenguin . com)
X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32
X-p0f-Info: os=unknown unknown, link=Ethernet or modem
X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6
X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default)
X-Canit-Stats-ID: 0aMx09Kzr - bdd110151a21 - 20140731
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/_hO0dkInsdiIYGfKxSzsja9JZls
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: Thu, 31 Jul 2014 12:11:43 -0000

Melinda Shore  wrote
Wed, 30 Jul 2014 13:13:48 -0800:

| 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.

We (NORDUnet) are working on a log. I've put some information together
at https://www.ct.nordu.net/ where pointers to code, current status and
contact info can be found.

Please contact me on or off list(s) if you have any feedback or
questions, contributions or requests. We're quite interested to hear
from people who are into this whole detection through public logs field.

Thanks,
Linus


From nobody Thu Jul 31 06:36:41 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51BC1B280B for ; Thu, 31 Jul 2014 06:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level: 
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.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 p9EFn6VnmuWo for ; Thu, 31 Jul 2014 06:36:37 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C281B280A for ; Thu, 31 Jul 2014 06:36:37 -0700 (PDT)
Received: by mail-qg0-f48.google.com with SMTP id i50so3772908qgf.21 for ; Thu, 31 Jul 2014 06:36:36 -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=Iv/+bBV1GGlmr1uBf9I3xLouSsPhTo18+Fh1oVRyTXQ=; b=buN1NDNSNuLMhFRD2sq5MCtCrZFngOiW36usUuz8Pjzota7esLh6TLpFtaFhsH1P6Y 2saWrafluekpugeieueO4EyZNsW2UtAg9rMn80uAR9FucGOZn/aorW26YNNDjlkw7wjx b2lhGcK4iIwaY3DIyo+LivWGQnmK1myRsH4OXoX3pRCBDofXnaZaJ1lJvU2HS/W7xdBF h6T57yaEyezQepCDqYSXdSkgwwzZaUyyGfXLicRU/taHwhJ2Fa9WI9J4QlFw9LrbfGAO zT2UlAzd1zdziIYIDjs4UarHwafltwMPJOc70PM57Wx1ULdKVRWALVSUnEESgTjQtpbr 0QNA==
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=Iv/+bBV1GGlmr1uBf9I3xLouSsPhTo18+Fh1oVRyTXQ=; b=MouS74O9Q9BCwKATYhsX1hCUne73IDOFJyxanCQw8HhTsQ6P5IY9uvuOWOtjRjSAYD hVzJ9STycArzhMl8Hlc6DLiSodVP0U06mMi+q2MyiBpY+w2MrFJasKqW5KWqSTv8U0YV LCXPv1orU0yv0Z/YKhPfvYpKeG83rb6GmtP5187LPB/ROUPXmmfLNw/bGucTE/2DGOQ8 sFk1jz5N8p4sHkmAnAPubrWWAgFCZij2ZoYjGL9GHIBGQwBIkyOju/vqMDFTNS8798lY SoY1jOZ6N9YpKn2IrUk2ag2Rj3R3QZiWlK07Ev5WL+ye5DaRkMf1rKP5ZJ5l/LJvYnEs GL1g==
X-Gm-Message-State: ALoCoQmLgYcDYcef1drPBWgQQrJd94lqJCLkrhVbB7EHo1cYplyOb+AizzbdSybY48mw/4ojByNi
MIME-Version: 1.0
X-Received: by 10.140.105.72 with SMTP id b66mr17076650qgf.30.1406813795878; Thu, 31 Jul 2014 06:36:35 -0700 (PDT)
Received: by 10.229.162.15 with HTTP; Thu, 31 Jul 2014 06:36:35 -0700 (PDT)
In-Reply-To: <53D9600C.6040805@gmail.com>
References: <53D9600C.6040805@gmail.com>
Date: Thu, 31 Jul 2014 09:36:35 -0400
Message-ID: 
From: Ben Laurie 
To: Melinda Shore 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/h6OnffINAt-dcunCXj1qU2xleW0
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: Thu, 31 Jul 2014 13:36:39 -0000

On 30 July 2014 17: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.

Obviously(?) Google has an open source implementation here:
https://github.com/google/certificate-transparency.

We also have two internal production implementations, both of which
share as much code as is feasible with the open source. No current
plan to release source that is not already released.

Feel free to mention them on a wiki page.

>
> Thanks again,
>
> Melinda
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans


From nobody Thu Jul 31 08:14:06 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8039D1B290A for ; Thu, 31 Jul 2014 08:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Vg5nD-9-j1Ck for ; Thu, 31 Jul 2014 08:13: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 B92DE1A00E2 for ; Thu, 31 Jul 2014 08:13:46 -0700 (PDT)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51267) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1XCs37-00077F-9u for trans@ietf.org; Thu, 31 Jul 2014 11:13:45 -0400
Message-ID: <53DA5D29.7040208@bbn.com>
Date: Thu, 31 Jul 2014 11:13:45 -0400
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "trans@ietf.org" 
References: <53D96FD2.2090607@bbn.com> <53D97353.7060702@gmail.com>
In-Reply-To: <53D97353.7060702@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hi3Vt0DFVBlcs59ic-da5kkJO5U
Subject: Re: [Trans] tickets
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, 31 Jul 2014 15:13:54 -0000

I also should have noted that I didn't create a ticket for every comment 
in my set of
messages because Eran seem to be addressing a number of them in his 
revisions of
6962-bis, e.g., in v4 vs. v3. It appears that he is working from front 
to back
(as would I), so it's not surprising that early sections of the doc have 
been
modified to address some of the issues I raised, while latter sections 
have not (yet).

Thanks Eran,

Steve


From nobody Thu Jul 31 08:50:09 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576D51B2941 for ; Thu, 31 Jul 2014 08:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 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, RP_MATCHES_RCVD=-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 ho4bzaP-2Ydf for ; Thu, 31 Jul 2014 08:49:49 -0700 (PDT)
Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A1B1B2950 for ; Thu, 31 Jul 2014 08:49:48 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id lf12so4455814vcb.40 for ; Thu, 31 Jul 2014 08:49:47 -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=NBXeDm9JRq+rTS6VJqQyHIVY1qmVkocuQ/9pgMYA1ME=; b=m1+CDPJNiHW8kuuukkQOvedJptnyBb0EpWK99CPO+e8i820pc8EKvnmC50AwBDoh9b KhJqlYeBdtTRirukcF94TglAN3mnZfmByd1eD3WXpc4Zg8SCYci3Y2GOqMR55BXPSgM5 sU1bLXkAKFBAEaWth8FyJXhWPxywNgF1JFShdTZ2AsLpa9zJp7XXxQ+AqTlBoxN+WW3m 9lHiUCmEHBvd04S/ZDQaOESnhOc2b0Ua1dsClgu4uMMc/a3j85Mb3/Z8viu2Ad95GITG XBnM2WIxBizVWzE8Y74gGOEYJRFCEfNH7vRv1OLpkqAggN/44Uv5q+6E3kll3aWMOw6+ u0hw==
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=NBXeDm9JRq+rTS6VJqQyHIVY1qmVkocuQ/9pgMYA1ME=; b=VmRjnGPIRGZRqZkUts9/IlQoTXyyPI/ywPZeKVL1u7vRmMugAONYsVjBRkgk45sMgr nH8zbw2MoKh0UDLjuFDFD2w4md8SqfDcaWzcpEMzSi6PF8Mevk+yqXMfXT2Bkn2VuMlW f1X4Qvt8KHXymb8JzSxsa/sVtvaZw6+Jt+X9AgFp2ONpWdX7r+XlAvXwchjD3xaAHyAf 6mf9uENBMpDTcoRo8YKLH7pLkJNqO12fr/4pfiYWNRFJn91VttahrWvRVd+rk873/p2K Q8mM+YSmL4K9dbUe0c1D4vbbBX+Q9DNOIic0CxAiAV3FHRXJGcMYJ5/LIzKGdIIiQ+0d r1nQ==
X-Gm-Message-State: ALoCoQmAzaDpvMdOZ7ADqHkZvwYAXa2Vx6+f2lTsH8Vy8oGNB/Bi03OUnuLt3gY0rCa4dSW5Wlvv
MIME-Version: 1.0
X-Received: by 10.220.17.145 with SMTP id s17mr3013333vca.77.1406821787298; Thu, 31 Jul 2014 08:49:47 -0700 (PDT)
Received: by 10.52.24.82 with HTTP; Thu, 31 Jul 2014 08:49:47 -0700 (PDT)
In-Reply-To: <53DA5D29.7040208@bbn.com>
References: <53D96FD2.2090607@bbn.com> <53D97353.7060702@gmail.com> <53DA5D29.7040208@bbn.com>
Date: Thu, 31 Jul 2014 16:49:47 +0100
Message-ID: 
From: Eran Messeri 
To: Stephen Kent 
Content-Type: multipart/alternative; boundary=001a11c3bfb2e5111504ff7f3858
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/zaFCBUOTus5OyPSiRwXH-_yYaIw
Cc: "trans@ietf.org" 
Subject: Re: [Trans] tickets
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, 31 Jul 2014 15:49:50 -0000

--001a11c3bfb2e5111504ff7f3858
Content-Type: text/plain; charset=UTF-8

That's almost accurate - Ben is the one addressing many of the comments :)

Overall my intention is that each comment made on the list will either be
resolved on a list or documented in a Trac ticket for further discussion.

Eran


On Thu, Jul 31, 2014 at 4:13 PM, Stephen Kent  wrote:

> I also should have noted that I didn't create a ticket for every comment
> in my set of
> messages because Eran seem to be addressing a number of them in his
> revisions of
> 6962-bis, e.g., in v4 vs. v3. It appears that he is working from front to
> back
> (as would I), so it's not surprising that early sections of the doc have
> been
> modified to address some of the issues I raised, while latter sections
> have not (yet).
>
> Thanks Eran,
>
> Steve
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>

--001a11c3bfb2e5111504ff7f3858
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


That's almost accurate - Ben is the one addressing man=
y of the comments :)

Overall my intention is that each c=
omment made on the list will either be resolved on a list or documented in =
a Trac ticket for further discussion.



Eran


On Thu, Jul 31, 2014 at 4:13 PM, Stephen Kent <kent@bbn.=
com> wrote:


I also should have noted that I didn't c=
reate a ticket for every comment in my set of

messages because Eran seem to be addressing a number of them in his revisio=
ns of

6962-bis, e.g., in v4 vs. v3. It appears that he is working from front to b=
ack

(as would I), so it's not surprising that early sections of the doc hav=
e been

modified to address some of the issues I raised, while latter sections have=
 not (yet).



Thanks Eran,



Steve




_______________________________________________

Trans mailing list

Trans@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/trans





--001a11c3bfb2e5111504ff7f3858--


From nobody Thu Jul 31 12:44:21 2014
Return-Path: 
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF581A0022; Thu, 31 Jul 2014 12:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level: 
X-Spam-Status: No, score=-1.044 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, 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 04mvR3Fe0im3; Thu, 31 Jul 2014 12:44:17 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA591A000F; Thu, 31 Jul 2014 12:44:17 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 4D191202022; Thu, 31 Jul 2014 12:44:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5C9t/rgKGTb+7nczZeVE izRymwg=; b=aNrAXw5HtA9kWs49d1iO2YkOfd+1s6T0nepxIm4iFdmK6LdsMA9k ///3Lzy0rIi2ZVgUsqhtG+pl7sKiey61Rl52YyWFGva+lgUQsHakn9Hq9DehiWx+ tQWyBTaXFG0fghzsHoESXnCc8DW4EjlSBZMATlKrqXL/4tLM74ogZD4=
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 9B9BE202018; Thu, 31 Jul 2014 12:44:16 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id n3so176349wiv.7 for ; Thu, 31 Jul 2014 12:44:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.37.241 with SMTP id b17mr950032wik.70.1406835855246; Thu, 31 Jul 2014 12:44:15 -0700 (PDT)
Received: by 10.217.98.6 with HTTP; Thu, 31 Jul 2014 12:44:15 -0700 (PDT)
In-Reply-To: 
References: <1d002b9795bf8f9946f1375fef78abd6@triangulum.uberspace.de>   <1B773935-7CE3-4507-A196-EAC4D7B21C5F@ogud.com> <0af38c6c3987f9537d16a7c20f517665@triangulum.uberspace.de>  <20140730132106.432C11B1536F@rock.dv.isc.org> <9442c2a6edad0cdc971e78aaa4b50b70@triangulum.uberspace.de> <201407311822.s6VIM2lO024077@new.toad.com> 
Date: Thu, 31 Jul 2014 14:44:15 -0500
Message-ID: 
From: Nico Williams 
To: Paul Wouters 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/sXJNa-AdL-RO6RbeS7Ko0daEtsU
Cc: "trans@ietf.org" , John Gilmore , dane@ietf.org
Subject: Re: [Trans] [dane] Manipulation of DNSSEC by US government possible?
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, 31 Jul 2014 19:44:19 -0000

On Thu, Jul 31, 2014 at 1:29 PM, Paul Wouters  wrote:
> That's what transaparancy for DNSSEC is about that is being discussed in
> the trans working group now. It's stil in the preliminairy stages, and
> likely will take a back seat to the more urgent certificate transparency
> which needs an audit log much more than DNSSEC.

And which is a good chance to remind everyone that this topic is
off-topic here.  This should be discussed there [trans].

Nico
--