From paul.hoffman@vpnc.org Fri Oct 5 14:11:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278A721F8647 for ; Fri, 5 Oct 2012 14:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnRCXKpuQaRl for ; Fri, 5 Oct 2012 14:10:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 941DB21F862A for ; Fri, 5 Oct 2012 14:10:59 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q95LAtVa005625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 5 Oct 2012 14:10:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> Date: Fri, 5 Oct 2012 14:10:56 -0700 To: "therightkey@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [therightkey] Certrans BoF planning X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 21:11:00 -0000 Greetings again. The certrans BoF is tentatively scheduled for Tuesday = afternoon at the IETF meeting; see = . I'll put together the agenda in a few weeks; I don't want to = short-circuit free-flowing ideas, even if things are a bit quiet right = now. I'll base the agenda around Internet-Drafts, and so far we have = draft-laurie-pki-sunlight. If you have another draft that you think = should be on the agenda, bring it to the list soon. --Paul Hoffman, temporary leadership stuckee From paul.hoffman@vpnc.org Wed Oct 17 07:44:01 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8E921F8551 for ; Wed, 17 Oct 2012 07:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0SYZQaPpDj7Y for ; Wed, 17 Oct 2012 07:44:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8C40921F854E for ; Wed, 17 Oct 2012 07:44:00 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9HEhvAN076571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 17 Oct 2012 07:43:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> Date: Wed, 17 Oct 2012 07:43:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> To: "therightkey@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: [therightkey] Call for agenda items for certrans BoF X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 14:44:01 -0000 Greetings again. The certrans BoF is scheduled for Tuesday after lunch = at the IETF meeting; see = . We have two = hours, and we may not need all that time. This is a call for agenda items. At the moment, we only have = draft-laurie-pki-sunlight, but if anyone turned in any relevant drafts = that I missed, please say so here. It would be *very* useful if people continued to discuss = draft-laurie-pki-sunlight and other drafts before the meeting. Meetings = are more valuable for discussing topics that have already been brought = up rather than "here's a presentation on a draft you should have already = read". --Paul Hoffman= From hallam@gmail.com Wed Oct 17 08:23:46 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDD721F8512 for ; Wed, 17 Oct 2012 08:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.903 X-Spam-Level: X-Spam-Status: No, score=-3.903 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzLiUWwdquvy for ; Wed, 17 Oct 2012 08:23:45 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 44CBC21F84E2 for ; Wed, 17 Oct 2012 08:23:45 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so9115633oag.31 for ; Wed, 17 Oct 2012 08:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MMYLlNI5L9vn/BJr0PAyfbgGtMpH8QAMQhJV8KFwp1k=; b=DHPHYX6CM4CQBHsPXyYi2ODEEe5n++7mSp/3rybkDabhJ6CpPxBSPDRY1wlFGyaqd2 NXTpChfY3ACTEbywQZbfldftAxTbfBW7kYyLKePFwPSbZIs3P9USlli4xIwk6fjcgEyY 1v99cRUFxcibS1/kWmA/gT2h5ihXpKj8o/qLYPDPIxPHYJRe0XxZKWSlLOCsnWNLH/OE H9C0JWiXMNNLE1GB7MXBu+XKbL/dKxMnlrbEImgHLzqyFjs4r2wTVhTUdg6ZutLU8GG2 8EFggEuTuJorHVAv4JDSBy8crjPuwhGEybT21dnL2D0dgpnUEBlr/87m5unH2KXZ8Af+ wJ4g== MIME-Version: 1.0 Received: by 10.60.7.41 with SMTP id g9mr15243450oea.18.1350487424898; Wed, 17 Oct 2012 08:23:44 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Wed, 17 Oct 2012 08:23:44 -0700 (PDT) In-Reply-To: <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> Date: Wed, 17 Oct 2012 11:23:44 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=e89a8fb205923c14b704cc42db94 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Call for agenda items for certrans BoF X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:23:46 -0000 --e89a8fb205923c14b704cc42db94 Content-Type: text/plain; charset=ISO-8859-1 One draft that might be relevant here is my TLS security policy draft which I will update later today and the OCSP 'Does not exist' response proposal which I don't think made it to a draft. http://tools.ietf.org/html/draft-hallambaker-tlssecuritypolicy-01 The relevance of TLS security policy is that it is a slightly more general version of the proposed 'OCSP Must staple' certificate extension. The idea is that a server puts this extension in a CSR when requesting a certificate and this is then included in the certificate produced. The server knows what version of TLS it supports and whether OCSP stapling is supported and if so whether it is turned on. Putting these in a certificate extension means that an OCSP client that does not get a stapled OCSP response can reject the certificate immediately and hardfail without having to try an OCSP request against the CA server which might be blocked by an attacker or alternatively enable a DoS attack. Including the version might not be strictly necessary but is by far the biggest downgrade attack concern on TLS itself. The relevance to CT is that this extension makes it practical to deliver the CT proofs in the OCSP token rather than the certificate. That in turn means that deployment of CT (1) has far less impact on CA operations and (2) could potentially include a complete and current notary proof that is up to date to the current day. The reason I moved to the more general TLS policy rather than just doing MUST STAPLE is that it is quite possible that we might want to propose new TLS extensions to allow stapling of CT related data such as meta-notary data. The interest in a 'does not exist' response in OCSP is that it allows CAs to deploy a weak form of transparency almost immediately. By weak transparency I mean that a third party can audit the behavior of the CA from public data alone but the requirements of this audit make it unsuitable for incorporation into a client. If an OCSP responder is required to distinguish 'this cert does not exist' from 'this cert is valid' then a third party can check to see if the CA knows which certificates have been issued and which are not by generating requests for random serial numbers. While most CAs would likely deliver the response as unsigned or sign it on the fly (volume should be very small) the use of a scope scheme like I proposed back in 1995 (and there is earlier prior art) allows the 'does not exist' responses to be static as well. The reason this was not done back in 1995 was that people raised objections similar to zone walking. With CT we are asserting that public certs are public knowledge anyway. I would also like to suggest that as an interim step we define a simple JSON format that CAs would use to report the list of all certificates issued in the past hour. This is again a form of weak transparency but I think having that data will make it a lot easier to get to a workable system. The idea of publishing certs is pretty straightforward, the idea of analyzing the published certs is pretty straightforward. Both deliver a significant value that can be realized in a 12 month timeframe. Design of the notary chains and making it possible for clients to do validation is a much harder task. Not saying that it is impossible, just that it will take us some time to do. From a design point of view it is a lot harder than DANE which is now in what, its third year? I would like us to have something that CAs can do right now rather than wait three years before we approach them asking them for action. Three years is a long time in business and people change jobs. If we end up waiting three years before we ask people for action it is quite likely that the people who are saying yes or maybe now will have moved on and we will have to start the argument from scratch. On Wed, Oct 17, 2012 at 10:43 AM, Paul Hoffman wrote: > Greetings again. The certrans BoF is scheduled for Tuesday after lunch at > the IETF meeting; see . > We have two hours, and we may not need all that time. > > This is a call for agenda items. At the moment, we only have > draft-laurie-pki-sunlight, but if anyone turned in any relevant drafts that > I missed, please say so here. > > It would be *very* useful if people continued to discuss > draft-laurie-pki-sunlight and other drafts before the meeting. Meetings are > more valuable for discussing topics that have already been brought up > rather than "here's a presentation on a draft you should have already read". > > --Paul Hoffman > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --e89a8fb205923c14b704cc42db94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One draft that might be relevant here is my TLS security policy draft which= I will update later today and the OCSP 'Does not exist' response p= roposal which I don't think made it to a draft.


The relevance of TLS security policy is that it is a sl= ightly more general version of the proposed 'OCSP Must staple' cert= ificate extension. The idea is that a server puts this extension in a CSR w= hen requesting a certificate and this is then included in the certificate p= roduced.=A0

The server knows what version of TLS it supports and wh= ether OCSP stapling is supported and if so whether it is turned on. Putting= these in a certificate extension means that an OCSP client that does not g= et a stapled OCSP response can reject the certificate immediately and hardf= ail without having to try an OCSP request against the CA server which might= be blocked by an attacker or alternatively enable a DoS attack.

Including the version might not be strictly necessary b= ut is by far the biggest downgrade attack concern on TLS itself.=A0


The relevance to CT is that this extension= makes it practical to deliver the CT proofs in the OCSP token rather than = the certificate. That in turn means that deployment of CT (1) has far less = impact on CA operations and (2) could potentially include a complete and cu= rrent notary proof that is up to date to the current day.

The reason I moved to the more general TLS policy rathe= r than just doing MUST STAPLE is that it is quite possible that we might wa= nt to propose new TLS extensions to allow stapling of CT related data such = as meta-notary data.


The interest in a 'does not exist= 9; response in OCSP is that it allows CAs to deploy a weak form of transpar= ency almost immediately. By weak transparency I mean that a third party can= audit the behavior of the CA from public data alone but the requirements o= f this audit make it unsuitable for incorporation into a client.

If an OCSP responder is required to distinguish 'th= is cert does not exist' from 'this cert is valid' then a third = party can check to see if the CA knows which certificates have been issued = and which are not by generating requests for random serial numbers.=A0

While most CAs would likely deliver the response as uns= igned or sign it on the fly (volume should be very small) the use of a scop= e scheme like I proposed back in 1995 (and there is earlier prior art) allo= ws the 'does not exist' responses to be static as well.

The reason this was not done back in 1995 was that peop= le raised objections similar to zone walking. With CT we are asserting that= public certs are public knowledge anyway.


I would also like to suggest that as an interim step we define a= simple JSON format that CAs would use to report the list of all certificat= es issued in the past hour. This is again a form of weak transparency but I= think having that data will make it a lot easier to get to a workable syst= em. The idea of publishing certs is pretty straightforward, the idea of ana= lyzing the published certs is pretty straightforward. Both deliver a signif= icant value that can be realized in a 12 month timeframe.

Design of the notary chains and making it possible for = clients to do validation is a much harder task. Not saying that it is impos= sible, just that it will take us some time to do. From a design point of vi= ew it is a lot harder than DANE which is now in what, its third year?

I would like us to have something that CAs can do right= now rather than wait three years before we approach them asking them for a= ction. Three years is a long time in business and people change jobs. If we= end up waiting three years before we ask people for action it is quite lik= ely that the people who are saying yes or maybe now will have moved on and = we will have to start the argument from scratch.


On Wed, Oct 17, 2012 at = 10:43 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings again. The certrans BoF is scheduled for Tuesday after lunch at t= he IETF meeting; see <https://datatracker.ietf.org/meeting/85/age= nda.html>. We have two hours, and we may not need all that time.

This is a call for agenda items. At the moment, we only have draft-laurie-p= ki-sunlight, but if anyone turned in any relevant drafts that I missed, ple= ase say so here.

It would be *very* useful if people continued to discuss draft-laurie-pki-s= unlight and other drafts before the meeting. Meetings are more valuable for= discussing topics that have already been brought up rather than "here= 's a presentation on a draft you should have already read".

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



-- Website: http://hallambaker.com/<= br>
--e89a8fb205923c14b704cc42db94-- From paul.hoffman@vpnc.org Thu Oct 18 09:27:27 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95AC21F878E for ; Thu, 18 Oct 2012 09:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDAdRu+YQ6GU for ; Thu, 18 Oct 2012 09:27:25 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 537BC21F883B for ; Thu, 18 Oct 2012 09:27:22 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9IGRJU9029089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 09:27:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 18 Oct 2012 09:27:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org Subject: Re: [therightkey] Call for agenda items for certrans BoF X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:27:27 -0000 On Oct 17, 2012, at 8:23 AM, Phillip Hallam-Baker = wrote: > One draft that might be relevant here is my TLS security policy draft = which I will update later today and the OCSP 'Does not exist' response = proposal which I don't think made it to a draft. >=20 > http://tools.ietf.org/html/draft-hallambaker-tlssecuritypolicy-01 The BoF description is: This non-WG forming BoF will discuss plans to specify mechanisms and = techniques that allow Internet applications to monitor and verify the = issuance of public X.509 certificates such that all issued certificates = are available to applications, and each certificate seen by an = application can be efficiently shown to be in the log of issued = certificates. Furthermore, it should be possible to cryptographically = verify the correct operation of the log. The draft says it is an extension to PKIX certs "to prevent downgrade = attacks that are not otherwise prevented by the TLS protocol". > The relevance of TLS security policy is that it is a slightly more = general version of the proposed 'OCSP Must staple' certificate = extension. The idea is that a server puts this extension in a CSR when = requesting a certificate and this is then included in the certificate = produced. . . . The draft is focused on current use of OCSP and TLS. That seems possibly = relevant for the PKIX or TLS WGs, but not here. > The interest in a 'does not exist' response in OCSP is that it allows = CAs to deploy a weak form of transparency almost immediately. By weak = transparency I mean that a third party can audit the behavior of the CA = from public data alone but the requirements of this audit make it = unsuitable for incorporation into a client. New work on weak transparency through OCSP would be relevant to this = BoF, but probably not that useful unless we believed that the PKIX WG = would actually allow those changes to OCSP. > I would also like to suggest that as an interim step we define a = simple JSON format that CAs would use to report the list of all = certificates issued in the past hour. This is again a form of weak = transparency but I think having that data will make it a lot easier to = get to a workable system. The idea of publishing certs is pretty = straightforward, the idea of analyzing the published certs is pretty = straightforward. Both deliver a significant value that can be realized = in a 12 month timeframe. I recognize that you don't have an Internet Draft on that specific = topic, but if you could put together a short presentation on it, it = would be useful for the BoF. --Paul Hoffman= From benl@google.com Thu Oct 18 11:26:59 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3905C21F8522 for ; Thu, 18 Oct 2012 11:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oceoKFnKoLqr for ; Thu, 18 Oct 2012 11:26:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6F921F8519 for ; Thu, 18 Oct 2012 11:26:58 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so10215852vbb.31 for ; Thu, 18 Oct 2012 11:26: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 :content-type:x-system-of-record; bh=Mf5ztjjmTS4+XRCTr7JRZIZedSsnNzHnFU85ryHl7zk=; b=MwD8pgPsrBtTtg3L1Ks5wwDsRU9FD0twn5CubXOrIh2EeQGf8NrlVH0U6mFxKIJ1q4 2U0WIRGpTNTc5CPK6rTbvOj+VxNWkAbiT7WkiWOkYXvBYaINsLbAz6EWFpNhoP8/2QYq wviqUMg+yz408mO+m++RUgRi6k7E3Mh39aYuqBXIBDbq7peM8OAkgKU2iispzhIz2SzC AG9IyVdrEwlylPuBaqSFbgqnpD8Y/J7CFKkP95krsSIBd/wUSuxYvOLpVF/z9K6QLuXn aG6qrw6hLAwBPaV3GOplWylB4ML6GSvshmnfRgdpCx9+DrT84Ep6ZC+QVU6YgrsO1ea1 0Qsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record:x-gm-message-state; bh=Mf5ztjjmTS4+XRCTr7JRZIZedSsnNzHnFU85ryHl7zk=; b=V6Ewc5GTSMDRTZOoXJF35smS/G4/UbLu2yQUWIFasC+duP4vK5TSlNqM38aTXo/CsK CA5a4l+YlMAbmrfNwODjNe76JAtpLJmfKnwAm6NGUWq/+jeS+x+vZf8d3HIOLJVvEFL1 DsrXvCAVu/pQkJjhKug/JWpDvfoJeIUSSx2W82ob+D45SLVTqSfgB1EnqBNbp2PA4Z/S kGkxEfbE08+0dWxI52ELNbdxdy2qBLmh3sAAdw1DfLSleqH8MiQ5B9o3kfnR3XFaW+nG fmDY7jBMi77gcgRWyQmfrsMXFBHTWz2UaKuX8PT777GdtXlgyJF4tPI7bUYHJVXFu8e0 swFA== MIME-Version: 1.0 Received: by 10.58.162.130 with SMTP id ya2mr17316496veb.2.1350584817739; Thu, 18 Oct 2012 11:26:57 -0700 (PDT) Received: by 10.220.155.132 with HTTP; Thu, 18 Oct 2012 11:26:57 -0700 (PDT) In-Reply-To: <20121018171954.30690.8320.idtracker@ietfa.amsl.com> References: <20121018171954.30690.8320.idtracker@ietfa.amsl.com> Date: Thu, 18 Oct 2012 19:26:57 +0100 Message-ID: From: Ben Laurie To: certificate-transparency@googlegroups.com, therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk177jdrB2NFBVSZQyIGqToD37iwEWJJJ8YvfhYyJhhO8Ejp5TKcepiUxZcwi9gKAJR67awjcrdCKvlUhTZYhA3INMMk8CUQpjHe418RXKPfW1DGgG6fCtl8ZbmYbdqgkOgh8tTo6TViUpFxU8Y0d5/7Np7hqueV9CAPsO8RvnUXeHwphzs77ItTd3i9GpZYKtobbOO Subject: [therightkey] Fwd: New Version Notification for draft-laurie-pki-sunlight-02.txt X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 18:26:59 -0000 ---------- Forwarded message ---------- From: Date: 18 October 2012 18:19 Subject: New Version Notification for draft-laurie-pki-sunlight-02.txt To: benl@google.com Cc: ekasper@google.com, agl@google.com A new version of I-D, draft-laurie-pki-sunlight-02.txt has been successfully submitted by Ben Laurie and posted to the IETF repository. Filename: draft-laurie-pki-sunlight Revision: 02 Title: Certificate Transparency Creation date: 2012-10-18 WG ID: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-laurie-pki-sunlight-02.txt Status: http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight Htmlized: http://tools.ietf.org/html/draft-laurie-pki-sunlight-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-laurie-pki-sunlight-02 Abstract: The aim of Certificate Transparency is to have every public end- entity and intermediate TLS certificate issued by a known Certificate Authority recorded in one or more certificate logs. In order to detect mis-issuance of certificates, all logs are publicly auditable. In particular, domain owners or their agents will be able to monitor logs for certificates issued on their own domain. To protect clients from unlogged mis-issued certificates, logs sign all recorded certificates, and clients can choose not to trust certificates that are not accompanied by an appropriate log signature. For privacy and performance reasons log signatures are embedded in the TLS handshake via the TLS authorization extension [RFC5878], or in the certificate itself via an X.509v3 certificate extension [RFC5280]. To ensure a globally consistent view of the log, logs also provide a global signature over the entire log. Any inconsistency of logs can be detected through cross-checks on the global signature. Consistency between any pair of global signatures, corresponding to snapshots of the log at different times, can be efficiently shown. Logs are only expected to certify that they have seen a certificate, and thus we do not specify any revocation mechanism for log signatures in this document. Logs are append-only, and log signatures will be valid indefinitely. The IETF Secretariat From alex@net-me.net Mon Oct 22 01:44:08 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D6821F84E2 for ; Mon, 22 Oct 2012 01:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfoWKFhmKVHB for ; Mon, 22 Oct 2012 01:44:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EAEA521F846B for ; Mon, 22 Oct 2012 01:44:06 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so2950235vbb.31 for ; Mon, 22 Oct 2012 01:44:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=5k/yY4OFyvuEKHMKOSrCHYtNfKs3kybkqUA+BuIwnYM=; b=DTjaBe0ckJ4kx3FJvvGXNzLhEBt2/ss1gzaiQEWxXpa/GcXOKbglX33nqcyXRC7IJd RTHmXkZJMg1ECS9AA5IYDYWxo3OXEcutHIGvbhvlrZ01+py0OiXZ81oq1sGbJEByXHsM 73luOhNdJ4oUz+kHFIXhhhBlwSfQ7sn9tq2zhieOPcQdCGlXnihdCl5AsSXQGlDr5KKq 1mWj+A3/GJGMOh1UtfkHOEXez8Q1CidmhRlJn5WPKZTE4KvpplHXJEKzz/E8E7SAsSAC PVs/rowcez2qaL6LpUsdiGEUFOE4n3dK0CVTc2qjujfelMXtBebMPFCFzBbZcgVkQDj9 4QuA== MIME-Version: 1.0 Received: by 10.58.94.109 with SMTP id db13mr14647946veb.39.1350895446230; Mon, 22 Oct 2012 01:44:06 -0700 (PDT) Received: by 10.58.162.135 with HTTP; Mon, 22 Oct 2012 01:44:06 -0700 (PDT) X-Originating-IP: [194.90.125.170] In-Reply-To: References: Date: Mon, 22 Oct 2012 10:44:06 +0200 Message-ID: From: Alexander Gurvitz To: therightkey@ietf.org Content-Type: multipart/alternative; boundary=047d7b6dcba833856504cca1db54 X-Gm-Message-State: ALoCoQmbCBOApeseWO6p57PxzjUudZ+P4Ky8QBLfhlGB3kayROV9PJB3siW3Z7xSaloYmv93dq7F X-Mailman-Approved-At: Mon, 22 Oct 2012 03:00:29 -0700 Subject: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 08:44:08 -0000 --047d7b6dcba833856504cca1db54 Content-Type: text/plain; charset=ISO-8859-1 Hello. I don't quite understand what is the purpose of Cert. Usage 0 and 1 TLSA records ("CA constraint" and "Service Certificate Constraint"). If we trust DNSSEC and TLSA, we need no CA at all, and if we don't trust DNSSEC/TLSA, what's the purpose of having any information in the TLSA ? The only place such CA/cert. constraint makes sense to me is the certificate itself, HSTS, or some checkbox in a browser setup. Alexander Gurvitz, net-me.net --047d7b6dcba833856504cca1db54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello.

I don't quite understand what is the purpose of Cert. Usage = 0 and 1 TLSA records ("CA constraint" and "Service Certifica= te Constraint"). If we trust DNSSEC and TLSA, we need no CA at all, an= d if we don't trust DNSSEC/TLSA, what's the purpose of having any i= nformation in the TLSA ? The only place such CA/cert. constraint makes sens= e to me is the certificate itself, HSTS, or some checkbox in a browser setu= p.

Alexander Gurvitz,


--047d7b6dcba833856504cca1db54-- From benl@google.com Mon Oct 22 04:42:35 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B6821F8BD2 for ; Mon, 22 Oct 2012 04:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.969 X-Spam-Level: X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2YrxAiXkxVG for ; Mon, 22 Oct 2012 04:42:35 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2E121F8BCC for ; Mon, 22 Oct 2012 04:42:34 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so1944893wib.13 for ; Mon, 22 Oct 2012 04:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=zCMEQQKlhtM8tx3a2ZpKBu9DpK7BP5eBFoMwyTkbRWM=; b=Ypp7xdBW8yVmDjuPCHtmXWAI88zpcU4MpN25fvO3d/s82u+SK9Sf0KT+3PbAOZLvnR 5aiRxQe2CTuB6FyTOb1CziCGFf6Kco0NOpZsuWFwgiW3RpNcdwaS3ND9TsBp0VGPeDI2 IS23lkEoA4qqpj0h1h59xXE97SQRkMhk+nBF15ftHFFU+S7INOiC10Rcp2MtSwxS+GjR I2RYEgH5cuOx/pqUHIHTBFSSTD0NJjH2RgMYcAFlIybicBrvkGocOX1sEeHTlY5yuixe was7IvNykXxdGodf5SuRg38T/jN5NMRjR4H5sS1DgZ/hv5Ln5oCk+UHpCHFpf9IwY71b TA/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=zCMEQQKlhtM8tx3a2ZpKBu9DpK7BP5eBFoMwyTkbRWM=; b=dJszBaEs4JjC4Et0l9w+I7LVSXpLqp0Xtkv0bCN7qohxemeKPrEifn4/a3k8dOe6bw Xxs+lfVJmjgEQH7s4CqWEKG2LzHjxGUhLcLWFOmExonYDTGR7hCs64W5er0UKwfaP2nr Q1JpziX+SoIUC6wlWGrtz0kJA+YnFPFrJT1TQt7agV0m/xhUp2Htpt/H921U6wKyx8Gq LhrIx2484B7gErz3ORGvaH1ag9rZQDp5AGEpgpMgJnPS1uB47pQ5vYjWoSuQZ0/hWVnn OTJCGK4VXPbfJ5HFxWwLvmuEgthTdZtqe5aQWOPkRTsGvod9IJzQARsHWk34pgSrXgvg w4/Q== MIME-Version: 1.0 Received: by 10.180.80.33 with SMTP id o1mr20645590wix.14.1350906153504; Mon, 22 Oct 2012 04:42:33 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Mon, 22 Oct 2012 04:42:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Oct 2012 12:42:33 +0100 Message-ID: From: Ben Laurie To: Alexander Gurvitz Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlN/4MS24d2xXKnKWBI/TUPS59L0uKF8ZyrxWyXTzg7NP+E8Jc2TlXeNDTVuovuNxL+Osy3iuLfvvnWxFeHDPwvdN5KLXAWk2DDizghJvM/Jss/rFAS1IqvZIETYh62Tm16XEwX2swhkkE/CP/xq1KtfxRvbObMLSeE/kTPIw5Nh9IS9ZImJSbnsXkn6pIgphKGnFAA Cc: therightkey@ietf.org Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 11:42:35 -0000 On 22 October 2012 09:44, Alexander Gurvitz wrote: > Hello. > > I don't quite understand what is the purpose of Cert. Usage 0 and 1 TLSA > records ("CA constraint" and "Service Certificate Constraint"). If we trust > DNSSEC and TLSA, we need no CA at all, and if we don't trust DNSSEC/TLSA, > what's the purpose of having any information in the TLSA ? The only place > such CA/cert. constraint makes sense to me is the certificate itself, HSTS, > or some checkbox in a browser setup. Two of these three don't make any sense to me! A CA/cert constraint in the certificate seems pointless - for a start, the cert is already signed by some particular CA, and secondly, why would an evil certificate constrain itself into non-operation? Likewise, checkbox in browser setup - what would this checkbox do? Pick a CA for every site on the 'net? How? CAs have been arguing in other venues that using TLSA to validate in the browser is inferior to using CAs because CAs are prepared to revoke certificates that are used for bad things, whereas DNS registrars/ICANN are not. OTOH, CAs don't necessarily even no they've issued a cert to revoke, if we look at history. And, of course, not all CAs have the same view of what is bad. This is, of course, why Certificate Transparency exists, so everyone can see what's going on. Neither TLSA nor CAs are adequate, IMO. From cloos@jhcloos.com Mon Oct 22 05:24:57 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2084221F8B71 for ; Mon, 22 Oct 2012 05:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MNdboiPpp+T for ; Mon, 22 Oct 2012 05:24:56 -0700 (PDT) Received: from eagle.jhcloos.com (eagle.jhcloos.com [IPv6:2001:1938:12d::53]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6F321F8B6C for ; Mon, 22 Oct 2012 05:24:56 -0700 (PDT) Received: by eagle.jhcloos.com (Postfix, from userid 10) id 4DE8940107; Mon, 22 Oct 2012 12:24:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=eagle; t=1350908695; bh=2Ooz54+TTSDTBvlO3X0/XOB9WbOy6YvVDFO+M6DVSeY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=anaLtbcPUMH3mMLIa3y3Ofm026ktcZfcoJsWUVoOKDDa9H4T9RVCsldju/eN+LGuf ZpGNGjo2n8/FHpLrUVcrm1cONe2UV+h8LMxBucoH4+VSGSHBoBs5o/tULA6eeNJqDQ TMMBEJuA5MyCAlY3SfncfTCeghUulBONuMEXpAbo= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C5BDB4004A; Mon, 22 Oct 2012 12:22:52 +0000 (UTC) From: James Cloos To: Alexander Gurvitz In-Reply-To: (Alexander Gurvitz's message of "Mon, 22 Oct 2012 10:44:06 +0200") References: User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2012 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 22 Oct 2012 08:22:52 -0400 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:121022:alex@net-me.net::lLtLV11DFX4BN6Qx:0Migug X-Hashcash: 1:30:121022:therightkey@ietf.org::M8EO0mp0nuedupuA:0000000000000000000000000000000000000000DhLPW Cc: therightkey@ietf.org Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:24:57 -0000 >>>>> "AG" == Alexander Gurvitz writes: AG> I don't quite understand what is the purpose of Cert. Usage 0 and 1 AG> TLSA records ("CA constraint" and "Service Certificate Constraint"). The idea was for something akin to pinning. Some only wanted to prevent rogue CAs in the bowsers' sets from affecting them. Others of us wanted to replace the CA concept with a trust path to the dnssec root. The four possible usage types are the resulting compromise. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From alex@net-me.net Mon Oct 22 05:37:40 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6370F21F87DF for ; Mon, 22 Oct 2012 05:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql+cVB6drsF5 for ; Mon, 22 Oct 2012 05:37:39 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 624DE21F889F for ; Mon, 22 Oct 2012 05:37:39 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3197953vbb.31 for ; Mon, 22 Oct 2012 05:37:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=0UMdc53qZib2VeoAi/pPVQSeAkzjlOuk/ZPYZeNVhvE=; b=b7Pu7evEnTV72XxVMC03VwylDiBhLybb/gXIYmQ/NISMUosuEE4O2MhN1MqTmKQlV2 KCKjuzZMsa45DXEFXJ/eEC2/FdRg4LfW4+Dh7s6LBna5NGjOGLSgVGaZQPMeoDrFCgk3 SpwvCdFthAmhDxcaHIz1iNqOvoiqRVEbag2i2Yg8JP+KygIv69nGGbpwo9JK/yHkPM/G 5/yP8gbE9BCObKHMNvJQCKGy6nizAPTNVghhXjTNuC/9NwRtqqfhMkPbOSf4uwLOg2Rb bVJw7/1Jq12+z7U8KdkPlOw/iBfBleg43Cqk8XGiG1HoeQprc3FWJ6xClrHIhjygk3ua gXsg== MIME-Version: 1.0 Received: by 10.52.64.209 with SMTP id q17mr11557569vds.32.1350909458817; Mon, 22 Oct 2012 05:37:38 -0700 (PDT) Received: by 10.58.162.135 with HTTP; Mon, 22 Oct 2012 05:37:38 -0700 (PDT) X-Originating-IP: [194.90.125.170] In-Reply-To: References: Date: Mon, 22 Oct 2012 14:37:38 +0200 Message-ID: From: Alexander Gurvitz To: Ben Laurie , therightkey@ietf.org Content-Type: multipart/alternative; boundary=20cf307f3a9e6aa1fb04cca51e0d X-Gm-Message-State: ALoCoQmVoGeejb+Zt8mkMzHYtNWQhTD8cmc/aT9K1SEgtZq7vhiSU7VhKgnO1bUNL2gLIXvkOmRi Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 12:37:40 -0000 --20cf307f3a9e6aa1fb04cca51e0d Content-Type: text/plain; charset=ISO-8859-1 Hello As of the checkbox I meant something like - [ ] Trust DANE w/o CAs [ ] Trust CAs w/o DANE I.e. globally, not per domain. I admit it's not very practical. As for self-constrained cert, assume the private key is compromised. Now I tell my CA to revoke the certificate, and with DNSSEC I can't revoke and have to wait. If the certificate "constrains itself" to require a CA validation, having signed TLSA will not prevent me from revoking it. Actually now I see that this is also answers my own question why we need usages 0 and 1 - they allow CA-based revocation in case of the private key compromise. I wonder if it's the only scenario which benefits from usage 0/1 ? Actually what made me ask is the following statement in http://tools.ietf.org/html/rfc6394#section-3.1 > Continuing to require PKIX validation also limits the degree to which > DNS operators (as distinct from the holders of domains) can interfere > with TLS authentication through this mechanism. As above, even if a > DNS operator falsifies DANE records, it cannot masquerade as the > target server unless it can also obtain a certificate for the target > domain. I wonder how the fact that I created one record with use case 0, prevents my DNS operator from creating a false record with use case 2. Alex --20cf307f3a9e6aa1fb04cca51e0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello

As of the checkbox I meant something like -=A0
<= div>[ ] Trust DANE w/o CAs
[ ] Trust CAs w/o DANE
I.e. = globally, not per domain.=A0I admit it's not very practical.

As for self-constrained cert, assume the private key is compromi= sed.=A0
Now I tell my CA to revoke the certificate, and with DNSS= EC I can't revoke and have to wait.
If the certificate "= constrains itself" to require a CA validation, having signed TLSA will= not prevent me from revoking it.

Actually now I see that this is also answers my own que= stion why we need usages 0 and 1 - they allow CA-based revocation=A0
<= div>in case of the private key compromise.

I wonder if it's the only scenario which benefits from usage 0/1 ?

Actually what made me ask is the following statement i= n=A0http://tools.ietf.org/html/rfc6394#section-3.1
Continuing to require PKIX validation also limits the= degree to which
DNS operators (as distinct from the holders of domains) can interfere with TLS authentication through this mechanism. As above, even if a DNS operator falsifies DANE records, it cannot masquerade as the
target server unless it can also obtain a certificate for the target
= domain.
I wonder how the fact that I created one = record with use case 0,
prevents my=A0DNS operator from creating = a=A0false=A0record with use case 2.

Alex
--20cf307f3a9e6aa1fb04cca51e0d-- From hallam@gmail.com Mon Oct 22 07:00:01 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE8F21F8566 for ; Mon, 22 Oct 2012 07:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.906 X-Spam-Level: X-Spam-Status: No, score=-3.906 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-d6X6WVH6qh for ; Mon, 22 Oct 2012 06:59:59 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A40B221F8546 for ; Mon, 22 Oct 2012 06:59:57 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so2981410oag.31 for ; Mon, 22 Oct 2012 06:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wX9CTEdnPQytEK0NsVMPAoNCGCR+Wgpm8dbJIjKLBPQ=; b=xKRGEnhhKiFH+kQ/WJzSkE5cXrWk6nnEeENWGvoO52qG+syBgDaQDpD7murrIJA5Oj m6Amy47XB0qiJWpMjH0ASYLNI8vmeFvob4Gb/B6PToW8NLUplRDtXau3MUR0X6SEQGB+ uyrMB0gzSEqD8E8xgxwgRErKmvBIL/ZeIPxVcI8AB1xGxQ3Fp6/O/bWrBmYudFPi7xMQ 3d7B/k87XEMr8dQSRTUmz/9HRYyxqi+pcxRDDYpV6pu+f4AjFOhNxuobwepOuGW/r6rJ oCUECvS+6cJeJOVEw2rZFBz7L1qiSO9iz75flA0cblR+e0mhn3ZVE04VfdyEn44pScGT Uvxw== MIME-Version: 1.0 Received: by 10.60.7.41 with SMTP id g9mr8015829oea.18.1350914397246; Mon, 22 Oct 2012 06:59:57 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Mon, 22 Oct 2012 06:59:57 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Oct 2012 09:59:57 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8fb20592c5140c04cca64474 Cc: Alexander Gurvitz , therightkey@ietf.org Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:00:01 -0000 --e89a8fb20592c5140c04cca64474 Content-Type: text/plain; charset=ISO-8859-1 None of them make any sense to me. The problem with DANE is that they had two agendas and only made one public when they asked for the group to be formed. What they purported to be doing was to make it possible to use the DNSSEC to establish keys. What they were really about was trying to replace CAs. One consequence of that positioning was that they could not accept any advice from any of the people who work with CAs as they imagined all such advice was designed to sabotage their efforts. Which meant that they began by cutting themselves off from all advice from people with practical experience of what they were attempting to do. The key usages are the product of their ideological baggage. The descriptions are confused because the thinking behind them is confused. It is one of those plans that begins 'well first lets knock down all the buildings and then decide what to replace them with'. Problem is that people who start with that sort of plan rarely get beyond the first stage of knocking everything down. Downtown Niagra being a prime example of the result of that type of thinking. CT seems a much better idea because it is designed to reinforce the existing infrastructure rather than define it as the problem. The big problem with DANE is that it relies on people putting correct information into the DNS and keeping it correct even when it is going to have (initially) marginal impact on functionality. Information in DANE could be useful for some parties to use to curate certificate data in combination with other data but it isn't viable for client enforcement in an end to end model. CT data is much better for enforcement as it is going to be managed by a small circle of parties who are specialists in managing that type of data. Any plan that relies on the typical Webmaster doing anything different is unlikely to succeed. They already have more problems than anyone in IETF land can imagine. On Mon, Oct 22, 2012 at 7:42 AM, Ben Laurie wrote: > On 22 October 2012 09:44, Alexander Gurvitz wrote: > > Hello. > > > > I don't quite understand what is the purpose of Cert. Usage 0 and 1 TLSA > > records ("CA constraint" and "Service Certificate Constraint"). If we > trust > > DNSSEC and TLSA, we need no CA at all, and if we don't trust DNSSEC/TLSA, > > what's the purpose of having any information in the TLSA ? The only place > > such CA/cert. constraint makes sense to me is the certificate itself, > HSTS, > > or some checkbox in a browser setup. > > Two of these three don't make any sense to me! > > A CA/cert constraint in the certificate seems pointless - for a start, > the cert is already signed by some particular CA, and secondly, why > would an evil certificate constrain itself into non-operation? > > Likewise, checkbox in browser setup - what would this checkbox do? > Pick a CA for every site on the 'net? How? > > CAs have been arguing in other venues that using TLSA to validate in > the browser is inferior to using CAs because CAs are prepared to > revoke certificates that are used for bad things, whereas DNS > registrars/ICANN are not. > > OTOH, CAs don't necessarily even no they've issued a cert to revoke, > if we look at history. And, of course, not all CAs have the same view > of what is bad. > > This is, of course, why Certificate Transparency exists, so everyone > can see what's going on. Neither TLSA nor CAs are adequate, IMO. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --e89a8fb20592c5140c04cca64474 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable None of them make any sense to me.

The problem with DANE= is that they had two agendas and only made one public when they asked for = the group to be formed. What they purported to be doing was to make it poss= ible to use the DNSSEC to establish keys. What they were really about was t= rying to replace CAs.

One consequence of that positioning was that they could= not accept any advice from any of the people who work with CAs as they ima= gined all such advice was designed to sabotage their efforts. Which meant t= hat they began by cutting themselves off from all advice from people with p= ractical experience of what they were attempting to do.

The key usages are the product of their ideological bag= gage. The descriptions are confused because the thinking behind them is con= fused. It is one of those plans that begins 'well first lets knock down= all the buildings and then decide what to replace them with'. Problem = is that people who start with that sort of plan rarely get beyond the first= stage of knocking everything down. Downtown Niagra being a prime example o= f the result of that type of thinking.


CT seems a much better idea because it i= s designed to reinforce the existing infrastructure rather than define it a= s the problem.=A0

The big problem with DANE is that it relies on peo= ple putting correct information into the DNS and keeping it correct even wh= en it is going to have (initially) marginal impact on functionality. Inform= ation in DANE could be useful for some parties to use to curate certificate= data in combination with other data but it isn't viable for client enf= orcement in an end to end model.

CT data is much better for enforcement as it is going t= o be managed by a small circle of parties who are specialists in managing t= hat type of data.

Any plan that relies on the typi= cal Webmaster doing anything different is unlikely to succeed. They already= have more problems than anyone in IETF land can imagine.



On Mon, Oct 22, 2012 at 7:42 AM, Ben= Laurie <benl@google.com> wrote:
On 22 October 2012 09:44, Alexander= Gurvitz <alex@net-me.net> wro= te:
> Hello.
>
> I don't quite understand what is the purpose of Cert. Usage 0 and = 1 TLSA
> records ("CA constraint" and "Service Certificate Const= raint"). If we trust
> DNSSEC and TLSA, we need no CA at all, and if we don't trust DNSSE= C/TLSA,
> what's the purpose of having any information in the TLSA ? The onl= y place
> such CA/cert. constraint makes sense to me is the certificate itself, = HSTS,
> or some checkbox in a browser setup.

Two of these three don't make any sense to me!

A CA/cert constraint in the certificate seems pointless - for a start,
the cert is already signed by some particular CA, and secondly, why
would an evil certificate constrain itself into non-operation?

Likewise, checkbox in browser setup - what would this checkbox do?
Pick a CA for every site on the 'net? How?

CAs have been arguing in other venues that using TLSA to validate in
the browser is inferior to using CAs because CAs are prepared to
revoke certificates that are used for bad things, whereas DNS
registrars/ICANN are not.

OTOH, CAs don't necessarily even no they've issued a cert to revoke= ,
if we look at history. And, of course, not all CAs have the same view
of what is bad.

This is, of course, why Certificate Transparency exists, so everyone
can see what's going on. Neither TLSA nor CAs are adequate, IMO.
_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey



--
Website: http://hallambaker.com/

--e89a8fb20592c5140c04cca64474-- From paul@nohats.ca Mon Oct 22 07:52:44 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D3A21F8976 for ; Mon, 22 Oct 2012 07:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkmD6vv5w-Ck for ; Mon, 22 Oct 2012 07:52:43 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2402121F85E2 for ; Mon, 22 Oct 2012 07:52:43 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id A233F80391; Mon, 22 Oct 2012 10:52:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9A059802A5; Mon, 22 Oct 2012 10:52:07 -0400 (EDT) Date: Mon, 22 Oct 2012 10:52:07 -0400 (EDT) From: Paul Wouters To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: therightkey@ietf.org Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 14:52:44 -0000 On Mon, 22 Oct 2012, Phillip Hallam-Baker wrote: > One consequence of that positioning was that they could not accept any advice from > any of the people who work with CAs as they imagined all such advice was designed > to sabotage their efforts. Which meant that they began by cutting themselves off > from all advice from people with practical experience of what they were attempting > to do. We listened Phillip. In fact, we bend over backwards for the PKIX people, and you got various Usage types specifically to support the CA model. The fact that this model has diminishing returns is something you can behind bring up at CABforum's reconfirmed closed doors. > The big problem with DANE is that it relies on people putting correct information > into the DNS and keeping it correct Luckilly, people already need to do that and have years of experience of putting the right data in DNS. > even when it is going to have (initially) > marginal impact on functionality. Information in DANE could be useful for some > parties to use to curate certificate data in combination with other data but it > isn't viable for client enforcement in an end to end model. Now who's levelling downtown Niagra? > Any plan that relies on the typical Webmaster doing anything different is unlikely > to succeed. The webmaster just needs to stick to the same "CA", whether a private one, or one from CABforum. I fail to see the rocket science here, though there is clearly the appearance of a smoke screen here. Paul From paul@nohats.ca Mon Oct 22 09:01:01 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F95421F8C31 for ; Mon, 22 Oct 2012 09:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-WnJr8TGt5J for ; Mon, 22 Oct 2012 09:01:00 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 72EB021F8C2D for ; Mon, 22 Oct 2012 09:00:59 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 03AB480391; Mon, 22 Oct 2012 12:00:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EB874802A5; Mon, 22 Oct 2012 12:00:25 -0400 (EDT) Date: Mon, 22 Oct 2012 12:00:25 -0400 (EDT) From: Paul Wouters To: Ben Laurie In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: therightkey@ietf.org Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:01:01 -0000 On Mon, 22 Oct 2012, Ben Laurie wrote: > CAs have been arguing in other venues that using TLSA to validate in > the browser is inferior to using CAs because CAs are prepared to > revoke certificates that are used for bad things, whereas DNS > registrars/ICANN are not. Of course, the registrant/DNS hoster itself _can_ and _should_ remove the TLSA record from DNS. Either when it used TLSA for pinning and the CA got compromised, or when the DNS provider itself got compromised. > This is, of course, why Certificate Transparency exists, so everyone > can see what's going on. Neither TLSA nor CAs are adequate, IMO. I haven't yet read the draft. The tricky thing of not trusting the publisher of the certificate data (eg the DNS hoster or web admin) is one of timing, false positives and delegated (implicit) trust to more third parties. Paul From hallam@gmail.com Mon Oct 22 09:12:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E4E21F86EB for ; Mon, 22 Oct 2012 09:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.903 X-Spam-Level: X-Spam-Status: No, score=-3.903 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k9xdoAYorxF for ; Mon, 22 Oct 2012 09:12:06 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26C4221F84C9 for ; Mon, 22 Oct 2012 09:12:06 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so3153199oag.31 for ; Mon, 22 Oct 2012 09:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AulHNiVgil9oMJ35RAOcmEPgGUz3jh0WEAKN3YeKxd4=; b=dF3cELRbQG5XotAxpdgFPTQfwT0uKPZ9xJVqOM1nliV8Wz6htIbqlEC8Qj6s+U0DDO jAqOPYupPg4NKi5Jima8IYsnsyI+RIL30TSdXPho3JKwSEkqkQVlZaqzAuLujgLfj6LE c3yrK4xAuLeeaBjGBkj8mbSLu7Cn11JrlhdS0HHk6vdDZRk6DhLFGq+GcjLcLZB1Rein Ki6hPctm3cB2D30jda+A0RZ/7SVmjl/43e++D+096bwxdztzFgpvPvqAjAhbiTO4LI1t f+wv32yNWAxIAQZfqvQ3TnDt3oIj+aXQVqlA0Ii6XWAjPbIcV6Lk/rwgoJklYgi7w82B THLA== MIME-Version: 1.0 Received: by 10.60.19.168 with SMTP id g8mr6071552oee.101.1350922325733; Mon, 22 Oct 2012 09:12:05 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Mon, 22 Oct 2012 09:12:05 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Oct 2012 12:12:05 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Wouters Content-Type: multipart/alternative; boundary=e89a8fb2062c5832cd04cca81d7f Cc: therightkey@ietf.org Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 16:12:07 -0000 --e89a8fb2062c5832cd04cca81d7f Content-Type: text/plain; charset=ISO-8859-1 Well you listened and then made sure you did the opposite. So I decided that engagement was counterproductive. One of the things I have learned in the crypto world is that getting people to use crypto is very very hard. In fact we are both using email right now, we both know plenty of ways to use signatures and encryption but neither of us is doing that. Creating an ecosystem in which people use crypto is much much harder than making the out of pocket cost zero. PGP had that 25 years ago and look where use of GPG is today. On Mon, Oct 22, 2012 at 10:52 AM, Paul Wouters wrote: > On Mon, 22 Oct 2012, Phillip Hallam-Baker wrote: > > One consequence of that positioning was that they could not accept any >> advice from >> any of the people who work with CAs as they imagined all such advice was >> designed >> to sabotage their efforts. Which meant that they began by cutting >> themselves off >> from all advice from people with practical experience of what they were >> attempting >> to do. >> > > We listened Phillip. In fact, we bend over backwards for the PKIX people, > and you got various Usage types specifically to support the CA model. The > fact that this model has diminishing returns is something you can behind > bring up at CABforum's reconfirmed closed doors. > > > The big problem with DANE is that it relies on people putting correct >> information >> into the DNS and keeping it correct >> > > Luckilly, people already need to do that and have years of experience of > putting the right data in DNS. > > > even when it is going to have (initially) >> marginal impact on functionality. Information in DANE could be useful for >> some >> parties to use to curate certificate data in combination with other data >> but it >> isn't viable for client enforcement in an end to end model. >> > > Now who's levelling downtown Niagra? > > > Any plan that relies on the typical Webmaster doing anything different is >> unlikely >> to succeed. >> > > The webmaster just needs to stick to the same "CA", whether a private > one, or one from CABforum. I fail to see the rocket science here, though > there is clearly the appearance of a smoke screen here. > > Paul > -- Website: http://hallambaker.com/ --e89a8fb2062c5832cd04cca81d7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well you listened and then made sure you did the opposite. So I decided tha= t=A0engagement=A0was counterproductive.

One of the thing= s I have learned in the crypto world is that getting people to use crypto i= s very very hard. In fact we are both using email right now, we both know p= lenty of ways to use signatures and encryption but neither of us is doing t= hat.

Creating an ecosystem in which people use crypto is muc= h much harder than making the out of pocket cost zero. PGP had that 25 year= s ago and look where use of GPG is today.=A0


On Mon, Oct 22, 2012 at 10:52 AM, Paul Wouters <paul@nohats.ca>= wrote:
On Mon, 22 Oct 2012, Phillip Hallam-Baker wrote:

One consequence of that positioning was that they could not accept any advi= ce from
any of the people who work with CAs as they imagined all such advice was de= signed
to sabotage their efforts. Which meant that they began by cutting themselve= s off
from all advice from people with practical experience of what they were att= empting
to do.

We listened Phillip. In fact, we bend over backwards for the PKIX people, and you got various Usage types specifically to support the CA model. The fact that this model has diminishing returns is something you can behind bring up at CABforum's reconfirmed closed doors.


The big problem with DANE is that it relies on people putting correct infor= mation
into the DNS and keeping it correct

Luckilly, people already need to do that and have years of experience of putting the right data in DNS.


even when it is going to have (initially)
marginal impact on functionality. Information in DANE could be useful for s= ome
parties to use to curate certificate data in combination with other data bu= t it
isn't viable for client enforcement in an end to end model.

Now who's levelling downtown Niagra?


Any plan that relies on the typical Webmaster doing anything different is u= nlikely
to succeed.

The webmaster just needs to stick to the same "CA", whether a pri= vate
one, or one from CABforum. I fail to see the rocket science here, though there is clearly the appearance of a smoke screen here.

Paul



-- Website: http://hallambaker.com/<= br>
--e89a8fb2062c5832cd04cca81d7f-- From Rick_Andrews@symantec.com Mon Oct 22 14:54:14 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A66221F847C for ; Mon, 22 Oct 2012 14:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FZGNVsmdPVj for ; Mon, 22 Oct 2012 14:54:14 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) by ietfa.amsl.com (Postfix) with ESMTP id D12E721F846B for ; Mon, 22 Oct 2012 14:54:13 -0700 (PDT) X-AuditID: d80ac3f3-b7f446d000002959-35-5085c084f8e7 Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id 9D.16.10585.480C5805; Mon, 22 Oct 2012 21:54:13 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1TQPwq-0001dB-Cr; Mon, 22 Oct 2012 21:54:12 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([172.24.185.246]) with mapi; Mon, 22 Oct 2012 14:54:12 -0700 From: Rick Andrews To: Paul Wouters , Ben Laurie Date: Mon, 22 Oct 2012 14:54:10 -0700 Thread-Topic: [therightkey] TLSA Cert. Usage Thread-Index: Ac2wbnXjnRBMQKVTQaO6HH7F6ev3AQALqd4Q Message-ID: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsXCZeB6Srf1QGuAwfy5nBYbPl9js3h/6xKT xccLP1kcmD0WbCr1WLLkJ5PH93lMAcxRXDYpqTmZZalF+nYJXBlTG44zFnwXq3jybQdrA+Ma oS5GTg4JAROJSY1PmSBsMYkL99azdTFycQgJvGOUWHillQnCecUo0XjgKpSzilHi276dLCAt bAJ6ElseX2HvYuTgEBGwl+g6bgYSZhYwlFhzag87iM0ioCqxtncbM4gtLKAt8eXPabBWEQEd iTtTljBB2EYS/cufgtXzCkRJrF6zgxli11QmiQWXjrGCJDgFHCW6L7aCNTMCnfr91BomiGXi EreezId6QUBiyZ7zzBC2qMTLx/9YIepFJe60r2eEqNeRWLD7ExuErS2xbOFrZojFghInZz5h mcAoPgvJ2FlIWmYhaZmFpGUBI8sqRpmS0mLD4tyS/NKSgtQKA2O94srcRGDUJesl5+duYgRG 3g2uw593MC78oX+IUYCDUYmH125va4AQa2IZUOUhRgkOZiURXuUAoBBvSmJlVWpRfnxRaU5q 8SFGaQ4WJXFeQafoACGB9MSS1OzU1ILUIpgsEwenVAOjI2ftfNH0Y+dqbPz8izljCp0dd1Ue /e8nevTko93uU3vfBXl/u3wzxEBs66WNzI8y5987yxB5bGrnTJ9ZKyXV2q/9arj65fWWY+U2 4cb76qNTVZf7//35wrSeaeFa3Qn6nRJXVc915XpvZcnVZZ0sIiXIPP0Ld9+lRXGLj3xq/PC9 6HhT7vZGJZbijERDLeai4kQAWXgNk7gCAAA= Cc: "therightkey@ietf.org" Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 21:54:14 -0000 > On Mon, 22 Oct 2012, Ben Laurie wrote: >=20 > > CAs have been arguing in other venues that using TLSA to validate in > > the browser is inferior to using CAs because CAs are prepared to > > revoke certificates that are used for bad things, whereas DNS > > registrars/ICANN are not. >=20 > Of course, the registrant/DNS hoster itself _can_ and _should_ remove > the TLSA record from DNS. Either when it used TLSA for pinning and the > CA got compromised, or when the DNS provider itself got compromised. I'm one of the CAs that have been arguing in other venues that using TLSA w= /o PKIX validation is inferior to using CAs (w/ PKIX validation). Having an= established mechanism for revocation is just one of the reasons I believe = this. There are other reasons: - CA-issued certs will conform to CABF Baseline Requirements (minimum key s= ize, strong signing and hashing algorithm, acceptable validity period, prop= er extensions). Most people would agree that an SSL cert shouldn't be used = for more than a few years, but there's no provision in DANE for preventing = long-term use of a single key. - CA-issued certs would be very likely to have undergone automated checks f= or weak keys, weak exponents, not on Debian weak key list, not on internal = phish lists, etc.) But with DANE w/o PKIX, it's almost certain that no chec= king was performed for weak keys. The person who generated the key probably= won't, and the DNS operator probably won't either, because they're not req= uired to.=20 - If you move away from the CA model to a DNSSEC-based DANE w/o PKI, you're= shifting your trust to the operators of the various DNS zones and domains = (for DNSSEC PKI) and to millions of individual domain owners (for generatin= g and maintaining their keys). None of those entities are subject to audit = like the CAs are, and it's reasonable to assume that without standards we'l= l have good ones and bad ones. That makes the end user less safe, in my opi= nion. I actually like DANE. I think that it's a great addition to PKIX validation= , but not a substitute for it. If we allow sites to use DANE w/o PKIX, I be= lieve we're opening the door to poor PKI practices (which arguably have bee= n tightened up over the past few years by CABF). We're also allowing attack= ers/phishers to create fraudulent web sites with SSL certs that appear to b= e as trusted as legitimate sites. > > This is, of course, why Certificate Transparency exists, so everyone > > can see what's going on. Neither TLSA nor CAs are adequate, IMO. I presume that CT will allow an auditor to see the actual cert that was iss= ued, so an auditor could take over some of the functions that a CA currentl= y performs (checking for key size, weak exponent, Debian, key lifetime, etc= .). But CT doesn't require anyone to do that, nor does it impose any requir= ements on the auditor. -Rick=20 From paul@nohats.ca Mon Oct 22 15:15:53 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB9511E80E4 for ; Mon, 22 Oct 2012 15:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-5pPpnha8Mg for ; Mon, 22 Oct 2012 15:15:53 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 08EEE11E80E5 for ; Mon, 22 Oct 2012 15:15:53 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 32C208101E; Mon, 22 Oct 2012 18:15:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 25365802A5; Mon, 22 Oct 2012 18:15:19 -0400 (EDT) Date: Mon, 22 Oct 2012 18:15:19 -0400 (EDT) From: Paul Wouters To: Rick Andrews In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "therightkey@ietf.org" Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:15:53 -0000 On Mon, 22 Oct 2012, Rick Andrews wrote: >> Of course, the registrant/DNS hoster itself _can_ and _should_ remove >> the TLSA record from DNS. Either when it used TLSA for pinning and the >> CA got compromised, or when the DNS provider itself got compromised. > > I'm one of the CAs that have been arguing in other venues that using TLSA w/o PKIX validation is inferior to using CAs (w/ PKIX validation). Having an established mechanism for revocation is just one of the reasons I believe this. How is replacing the TLSA record not equal to revocation, except within the middle man delays? > - CA-issued certs will conform to CABF Baseline Requirements (minimum key size, strong signing and hashing algorithm, acceptable validity period, proper extensions). Most people would agree that an SSL cert shouldn't be used for more than a few years, but there's no provision in DANE for preventing long-term use of a single key. That seems more like a local policy to me. It has also been called "Frequent Rollover Syndrome" by some. > - CA-issued certs would be very likely to have undergone automated checks for weak keys, weak exponents, not on Debian weak key list, not on internal phish lists, etc.) But with DANE w/o PKIX, it's almost certain that no checking was performed for weak keys. The person who generated the key probably won't, and the DNS operator probably won't either, because they're not required to. Systems now would "very likely" not generate insecure stuff. CA's have been pretty good at issuing bad certificates. I find this argument pretty weak. The market has shown a strong preference for the CA with the least amount of checks, delivering a cert in seconds rather then hours or days - not a mechanism to build up security. > - If you move away from the CA model to a DNSSEC-based DANE w/o PKI, you're shifting your trust to the operators of the various DNS zones and domains (for DNSSEC PKI) and to millions of individual domain owners (for generating and maintaining their keys). None of those entities are subject to audit like the CAs are, and it's reasonable to assume that without standards we'll have good ones and bad ones. That makes the end user less safe, in my opinion. Yes, and you are right we are adding new risk points. But those are much fewer (root, .com, registrar webgui, DNS hoster) then the plethora of CA's. But still, DANE allows you to do both, so we can all be hapy. Maintaining TLS certificates actually becomes _easier_, because people don't have to frantically read the openssl man page to generate a new certificate when the old one suddenly expired without anyone noticing before the complains hit the help desk. > I actually like DANE. I think that it's a great addition to PKIX validation, but not a substitute for it. If we allow sites to use DANE w/o PKIX, I believe we're opening the door to poor PKI practices (which arguably have been tightened up over the past few years by CABF). We're also allowing attackers/phishers to create fraudulent web sites with SSL certs that appear to be as trusted as legitimate sites. If only CABF was open, I could actually try and reason with you to see if you are right. Unfortunately, CABF recently comitted to remain closed. As for your "if we allow DANE w/o PKIX" comment, the DANE RFC does allow it, and with good reason. Contrary to your claim, it will actually _increase_ TLS security by being able to phase out self-signed cert popups for those people who can't or don't want to pay the CA industry. The payment system is frankly the main course of reduced TLS security, and DANE fixes that nicely. This does not stop you from your business model. You can remain issuing EV certs, browsers can provide additional colouring signifying the additional checks done by CABF, and people can add TLSA records to pin it to a single CA to not be affected by another CA's compromise. Saying the masses can't have 'secure websites' because it would enable the bad guys to have 'secure websites' is not a strong argument. Following that, we get governments banning encryption altogether. Paul From ryan-ietf@sleevi.com Mon Oct 22 15:25:13 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8368421F8512 for ; Mon, 22 Oct 2012 15:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azzUCcxLWKyT for ; Mon, 22 Oct 2012 15:25:12 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 78BED21F84FE for ; Mon, 22 Oct 2012 15:25:12 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 414FC1DE070; Mon, 22 Oct 2012 15:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=v5Iot/3Nzii2rFyGjTqBA2RoaGA=; b=TaryXs2FQA93rN4t0 B2PiFfQxytOlvThABLVeqO0KnhjpFK8fgeCzCPEMUm6RU3HER236Xj5r/AXOau9h 5pUF6+nCER20FesNlh4l69PRa99gtrYNkBZ1NhdlZm8UaELuVfOU8kHtRUJGbfUA /rWCGw7enarlJdwkPWNpeytkJI= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id DF13A1DE060; Mon, 22 Oct 2012 15:25:11 -0700 (PDT) Received: from 216.239.45.4 (proxying for 216.239.45.4) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Mon, 22 Oct 2012 15:25:36 -0700 Message-ID: In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Mon, 22 Oct 2012 15:25:36 -0700 From: "Ryan Sleevi" To: "Rick Andrews" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" , Paul Wouters , Ben Laurie Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietf@sleevi.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:25:13 -0000 On Mon, October 22, 2012 2:54 pm, Rick Andrews wrote: > > On Mon, 22 Oct 2012, Ben Laurie wrote: > > > > > CAs have been arguing in other venues that using TLSA to validate i= n > > > the browser is inferior to using CAs because CAs are prepared to > > > revoke certificates that are used for bad things, whereas DNS > > > registrars/ICANN are not. > > > > Of course, the registrant/DNS hoster itself _can_ and _should_ remove > > the TLSA record from DNS. Either when it used TLSA for pinning and th= e > > CA got compromised, or when the DNS provider itself got compromised. > > I'm one of the CAs that have been arguing in other venues that using T= LSA > w/o PKIX validation is inferior to using CAs (w/ PKIX validation). Hav= ing > an established mechanism for revocation is just one of the reasons I > believe this. There are other reasons: > > - CA-issued certs will conform to CABF Baseline Requirements (minimum = key > size, strong signing and hashing algorithm, acceptable validity period= , > proper extensions). Most people would agree that an SSL cert shouldn't= be > used for more than a few years, but there's no provision in DANE for > preventing long-term use of a single key. Nor is there any effective provision in the CA model for key cryptoperiods. If a CA denies reissuance to a customer because they tried to reuse an existing key, the end user need simply go to another CA. Give= n that nearly all CAs are equal in trustworthiness from the client perspective, this is not in fact an active mitigation provided by CAs. Keysize and hashing requirements are already implemented in clients - Chromium, Safari, Mozilla, and Microsoft have moved to deprecate MD5 and = < 1024 bit certificates. I imagine that these requirements will continue to roll forward - primarily gated by the limitations of the existing deploye= d infrastructure and the need to not break all of the sites with legitimately-issued WebPKI certificates. > > - CA-issued certs would be very likely to have undergone automated che= cks > for weak keys, weak exponents, not on Debian weak key list, not on > internal phish lists, etc.) But with DANE w/o PKIX, it's almost certai= n > that no checking was performed for weak keys. The person who generated= the > key probably won't, and the DNS operator probably won't either, becaus= e > they're not required to. Agreed. This is an understandable benefit of having a third-party mediate key issuance. > > - If you move away from the CA model to a DNSSEC-based DANE w/o PKI, > you're shifting your trust to the operators of the various DNS zones a= nd > domains (for DNSSEC PKI) and to millions of individual domain owners (= for > generating and maintaining their keys). None of those entities are sub= ject > to audit like the CAs are, and it's reasonable to assume that without > standards we'll have good ones and bad ones. That makes the end user l= ess > safe, in my opinion. Out of curiosity, given that both DV and EV ultimately rely on the validity of the domain registration information, what is to prevent a malicious DNS zone from compromising or otherwise maliciously requesting = a certificate? That is, as the zone operator for .com, is there any more or less risk with DNSSEC that I may lie about who owns victim.com? If I can lie about who owns victim.com, I can induce a WebPKI CA to issue a (domai= n validated) certificate for victim.com. The DNS zone operator remains in a privileged position in the PKIX world, since PKIX ultimately relies on the validity of the DNS registry as a key part of performing validation checks. Yes, EV improves these checks, but there is still an inherent reliance on "party X is authorized to request for victim.com" As far as being vulnerable to the millions of sites' key management practice - again, how is that different than the existing PKIX model? Wit= h the exception of EV Code Signing, no documents produced by the CA/B Forum require, for end-entity certificates, the use of an HSM or otherwise secure key management. I can appreciate the concern for /usability/ - which is, indeed, a clear and real issue with ANY form of key management. But the suggestion of audit being part of the concern, given that the vast majority of sites happily store the private key unencrypted on the web host machine, seems like a bit of a stretch. > I actually like DANE. I think that it's a great addition to PKIX > validation, but not a substitute for it. If we allow sites to use DANE= w/o > PKIX, I believe we're opening the door to poor PKI practices (which > arguably have been tightened up over the past few years by CABF). We'r= e > also allowing attackers/phishers to create fraudulent web sites with S= SL > certs that appear to be as trusted as legitimate sites. Has the work been to tighten up the poor PKI practices of end users, or the poor PKI practices of CAs? From Rick_Andrews@symantec.com Mon Oct 22 15:35:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EB711E80F9 for ; Mon, 22 Oct 2012 15:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOH2EDSLbxwY for ; Mon, 22 Oct 2012 15:35:24 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1B45311E80F8 for ; Mon, 22 Oct 2012 15:35:24 -0700 (PDT) X-AuditID: d80ac3f1-b7fa66d0000032a8-76-5085ca2a5d5c Received: from ecl1mtahubpin01.ges.symantec.com (ecl1mtahubpin01.ges.symantec.com [10.48.69.201]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 18.79.12968.B2AC5805; Mon, 22 Oct 2012 22:35:23 +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 1TQQag-0002Fo-N4; Mon, 22 Oct 2012 22:35:22 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Mon, 22 Oct 2012 15:35:22 -0700 From: Rick Andrews To: Paul Wouters Date: Mon, 22 Oct 2012 15:35:21 -0700 Thread-Topic: [therightkey] TLSA Cert. Usage Thread-Index: Ac2wos4abAi3wTS8R62NehHYqC8YUQAAeD+g Message-ID: <544B0DD62A64C1448B2DA253C0114146069D2C2E89@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsXCZeB6Ulf7VGuAwetV0hbvb11isvh44SeL A5PHkiU/mTy+z2MKYIrisklJzcksSy3St0vgyjj9/ydTwSmOillbUxoY37J1MXJySAiYSNz8 vYwZwhaTuHBvPVCci0NI4B2jxLln/UwQzitGiSWHeqCcVYwSzc8ugbWwCehJbHl8hR3EFhFQ lJh05hELiM0sYCix5tQesDiLgKrE/2sdYOuEBbQlvvw5zQJRryNxZ8oSJgjbSGLBxu1gNbwC URI7Z95ggVg2h1ni57uPrCAJTgEHibbu22CLGYFu/X5qDRPEMnGJW0/mM0H8ICCxZM95qH9E JV4+/scKUS8qcad9PSNEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEbxWUjGzkLSMgtJyywk LQsYWVYxypSUFhsW55bkl5YUpFYYGOoVV+YmAmMsWS85P3cTIzDObnAd/riD8fpSxUOMAhyM Sjy8bIdbA4RYE8uAKg8xSnAwK4nwKgcAhXhTEiurUovy44tKc1KLDzFKc7AoifMKOkUHCAmk J5akZqemFqQWwWSZODilGhhZM+bl6oXJmAvMVf/aGvnMM7PWc909zTPqhyYppQf4p1z4r6kx L9Zpmc+1W06vKwwYWOM547ymnN509Y6T8EqZXQIrnV/tKgz4p+zxoGRd55ZN1t2HdJwv/eV7 sof3adsmh+TcRw/SD5m6WNZl2M/65tRoUelivtx0m8W6x22nzzfPragWfq7EUpyRaKjFXFSc CAALmVBurwIAAA== Cc: "therightkey@ietf.org" Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:35:25 -0000 > > I'm one of the CAs that have been arguing in other venues that using > TLSA w/o PKIX validation is inferior to using CAs (w/ PKIX validation). > Having an established mechanism for revocation is just one of the > reasons I believe this. >=20 > How is replacing the TLSA record not equal to revocation, except within > the middle man delays? It's similar, except that all CAs document their revocation process and rea= sons in their CPS documents. It's very transparent and understood. Have DNS= providers documented their process and reasons for removing a TLSA record?= Who monitors them to make sure they're doing it properly, or at least doin= g it according to a documented process? > If only CABF was open, I could actually try and reason with you to see > if you are right. Unfortunately, CABF recently comitted to remain > closed. This is a mischaracterization. The CABF did not recently commit to remain c= losed. It became more open, just not open enough for some people. Even if w= e disagree on that, why can't we discuss this issue in this forum? -Rick From palmer@google.com Mon Oct 22 15:56:49 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E384211E811D for ; Mon, 22 Oct 2012 15:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hax7AqQwgMb for ; Mon, 22 Oct 2012 15:56:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF3BB11E811B for ; Mon, 22 Oct 2012 15:56:48 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so2301628lbo.31 for ; Mon, 22 Oct 2012 15:56: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:x-system-of-record; bh=BI/NVjOSPEZgFeJ09rN7y9r1+HORWHlHdFl/DuaETCg=; b=QrLkPKR7ITbAd9G/Tq2U8+ojUxv48x7q8PVHQ/5FH5AT6zYzRvSLsyTeaM1/pNHBFo 9qZWkRSnbvmdZfm9+aKtD1jEw40sz1V73jbkECO3AvwdbcBdPT8xXEnkbzKA4k2h0762 o2tcNy2ttD/vspPmK8TmlRvi0eNS6i5D2x2q8ES7QfLrjmcNjUpmwqihspf/6tSMvKmj qgNRgboIEPDtVeYg11lF1xXHOZwYILIPqaWN6NWkJ0y78LZlp7b4hk8Ios+QOu996wSo BjdtWkahmXjynojeLNyxJvhVtTMuG+yY7y2kbdyIIakCFN504XCjfrnPOqRQlo12Fots JDWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=BI/NVjOSPEZgFeJ09rN7y9r1+HORWHlHdFl/DuaETCg=; b=jldCahdUmzjT/A1WVrbZwBYsdKD/7lbsalCXlH3pTB4SjfFM1cRYPZVN1pRDZc6/97 UtMwIu//tCBiSjMjU652t/VSqdc5wWHSnWeg2NYdX+YPZ+hmNNxsvxGcb0UD22LweRWx rjQkakpHTEhZg8dzDG+4UJJKJ0kBtZLg6nXidXBJEkS8AliiRl9TDWhaKYyhxDNVtMVS 1WqEGoKDdHQpDJSt1rmh4Wht9swpXxnE/S45imgSIkj2eCD7NiaL6IaWfsfTN0dmM0Vl PTnCwt2H5VnN+lhGV4Lz0dxFnJGudhPfM90sFX47EdspcCU37PlyA535SUr/LVsUHH2d SM8A== MIME-Version: 1.0 Received: by 10.152.122.11 with SMTP id lo11mr9668925lab.3.1350946607658; Mon, 22 Oct 2012 15:56:47 -0700 (PDT) Received: by 10.112.39.226 with HTTP; Mon, 22 Oct 2012 15:56:47 -0700 (PDT) In-Reply-To: References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Mon, 22 Oct 2012 15:56:47 -0700 Message-ID: From: Chris Palmer To: Paul Wouters Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkrw03UJNCj7iutpZZ466LRc3krfpvk5QpZ+8jGvGL322QqOmPWNQ0ilXCAR2f9ADseEwYsiNtdlJ/p0YxFLB7wUloYmPvKv6yGzGFqGT6SfUDcjZRXMMk3Obl4hB25RmBp2xyE+BitR69UtN56/3xZZuTzGO+kv/gQYa5IVjAGeJJBa/CxgAc1+bTruGGNuv+0lvHZ Cc: "therightkey@ietf.org" , Rick Andrews Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 22:56:50 -0000 On Mon, Oct 22, 2012 at 3:15 PM, Paul Wouters wrote: > If only CABF was open, I could actually try and reason with you to see > if you are right. Unfortunately, CABF recently comitted to remain > closed. There is a public mailing list, where real stuff is discussed, and it's worth joining. https://cabforum.org/mailman/listinfo/public https://cabforum.org/pipermail/public/ I personally wanted and worked for more of a change, but what we did get is better than the previous status quo. From paul@nohats.ca Mon Oct 22 16:03:05 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9600321F8909 for ; Mon, 22 Oct 2012 16:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlANM+ooMqFP for ; Mon, 22 Oct 2012 16:03:04 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id D58D121F8906 for ; Mon, 22 Oct 2012 16:03:04 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 9C7DB8101E; Mon, 22 Oct 2012 19:02:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8E202802A5; Mon, 22 Oct 2012 19:02:23 -0400 (EDT) Date: Mon, 22 Oct 2012 19:02:23 -0400 (EDT) From: Paul Wouters To: Rick Andrews In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D2C2E89@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D2C2E89@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "therightkey@ietf.org" Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:03:05 -0000 On Mon, 22 Oct 2012, Rick Andrews wrote: >> How is replacing the TLSA record not equal to revocation, except within >> the middle man delays? > > It's similar, except that all CAs document their revocation process and reasons in their CPS documents. It's very transparent and understood. Have DNS providers documented their process and reasons for removing a TLSA record? Who monitors them to make sure they're doing it properly, or at least doing it according to a documented process? The registrant either is the DNS operator, or has sourced it out to a DNS operator that already has full control to take over the sites, document changelogs, etc. For the registrant, this adds no new requirement. The reason the CA's need such documentation, is because it is an addition to the process the registrant needs to be able to audit. >> If only CABF was open, I could actually try and reason with you to see >> if you are right. Unfortunately, CABF recently comitted to remain >> closed. > > This is a mischaracterization. The CABF did not recently commit to remain closed. It became more open, just not open enough for some people. Even if we disagree on that, why can't we discuss this issue in this forum? We can discuss it, but statements on how well CAs do certain things is something I cannot validate. That's all I was saying. Paul From carl@redhoundsoftware.com Mon Oct 22 16:10:51 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6491721F8B98 for ; Mon, 22 Oct 2012 16:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Skg0REO+74li for ; Mon, 22 Oct 2012 16:10:50 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD6F21F8B97 for ; Mon, 22 Oct 2012 16:10:50 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so1983722wey.31 for ; Mon, 22 Oct 2012 16:10:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=QLJ3RFRvje6QXnVA1085YZ4Lg1kt8KE0GTdEyO7i+mU=; b=P1HqbCUNwhsEd+g1tqi/ZIN7QC9rKyZrQxEEEubSSa16ZGUN59kGMq0Z41M6digPue /UGk01z4GIfuRUK2NvxAjywHGaRzGCuC0zGKLHlYspz/4GOMYryFJAVWMCUtjNRVCFVP GnuMpialrahAU2tnqGG+ISR8nFTc1qAmKYdNfX1S9r3aydP8vmNKwwrih1FrDCxuHSo+ VVNoDZEwslk2+w4KLZ0a8BegJ5xPkAKqH0rQzHMNmAJqpeCYt6q/2FZj4GUybfQYggxq BaRT8IqKOSNqiapdfiTYN95WKxmr1EkKPm6CBznbqiCHxbvC3U6lPwGG/SdDusu8oHEC 8zOw== Received: by 10.180.87.42 with SMTP id u10mr24541420wiz.0.1350947449413; Mon, 22 Oct 2012 16:10:49 -0700 (PDT) Received: from [10.71.7.189] (94-194-207-64.zone8.bethere.co.uk. [94.194.207.64]) by mx.google.com with ESMTPS id eq2sm24491176wib.1.2012.10.22.16.10.47 (version=SSLv3 cipher=OTHER); Mon, 22 Oct 2012 16:10:48 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Tue, 23 Oct 2012 00:10:40 +0100 From: Carl Wallace To: Chris Palmer , Paul Wouters Message-ID: Thread-Topic: [therightkey] TLSA Cert. Usage In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQkIk/AmS2yZknnU8zVBz4d3T8CyheO8MP3USjS0Vo8S+UbaSIoiQk3QBLdHZLrnG2nZ5FdG Cc: "therightkey@ietf.org" , Rick Andrews Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:10:51 -0000 On 10/22/12 11:56 PM, "Chris Palmer" wrote: >On Mon, Oct 22, 2012 at 3:15 PM, Paul Wouters wrote: > >> If only CABF was open, I could actually try and reason with you to see >> if you are right. Unfortunately, CABF recently comitted to remain >> closed. > >There is a public mailing list, where real stuff is discussed, and >it's worth joining. It's worth noting that "for the time being, the list is read-only for non-members." From palmer@google.com Mon Oct 22 16:41:52 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9453B11E80E8 for ; Mon, 22 Oct 2012 16:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ha8lLShFPFAR for ; Mon, 22 Oct 2012 16:41:51 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 80E7D21F8612 for ; Mon, 22 Oct 2012 16:41:51 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2266310lam.31 for ; Mon, 22 Oct 2012 16:41: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:x-system-of-record; bh=NuraQtZsa2kgQExrta+n2vvXIEFyt2XShWKZXCekS2Y=; b=gismwdjpVPuxumjk0Ga9893Pd9vWmO0OgA0ujqfmwH5+FwdlLsANrnNvPfGikcaPeB bUEuASe81bsPYt8s/kFSezrcT8XeBNkanaB4u19QsY3+hxGhvDr+xOFcF0GEb/QbyQkn P9frGUaR3lBO7G290H0BKh1SXvm0TYyfJ18xsNr5ih/BbeZfJn6lJZTMBb/WK6EwSZ6V X+BHjIcCSrR1UbwJ6LfA/lsu8bRoYG/l5SYDqgKGF1888teqi3YDQs0ATksrjlExkH1C vY2sMeDfzh/kkkX8baw5ntVVNtEmnjT062JHk87a5gWNqwdr7eOJ5VDCIH+C3wzW1QKG +Hkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=NuraQtZsa2kgQExrta+n2vvXIEFyt2XShWKZXCekS2Y=; b=O+GjAzOdxQAeoSetuawvhjMIKKBAgf0ttkXXQhXAcdsTo9ZVpgEDG1qNrCI2Nl99PY XtqQQ80wWYP0ATvoofG+loo0wdT/qHt2Ro4AClcZqJ99FFuoxUan1Cq23OCmKnnKaCpP aCXhhOEjhQzEK21JFcU+f8dHAc0q9BXKrKq27BWQNVmanj47QJYz7zlPnKFrTJjSF1ol DwzKCaEfDkP5EZUPUNqupUOiUJGbjDhw+ZxUn4JWkt+9cu0/9NeVMkY/hG0UWgDpJzEW LYllX5tyfcjSJGB7bKKhTiD1n/mPREZYYM49R1ydeS0WGBCssX2fSZA15i9Uc1eFB9MM pZ2A== MIME-Version: 1.0 Received: by 10.112.48.133 with SMTP id l5mr4313920lbn.53.1350949310382; Mon, 22 Oct 2012 16:41:50 -0700 (PDT) Received: by 10.112.39.226 with HTTP; Mon, 22 Oct 2012 16:41:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Oct 2012 16:41:50 -0700 Message-ID: From: Chris Palmer To: Carl Wallace Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmxLHQGEfbongWMOutnE8pRu0uiUkDUbkujv04CJV/1ycxBJCqot9W6fPjA1nRy6T8PNbVPTiy0fAnyOeosEuctJ/Ziy7d9eMd1BX7rd8wgZn/vQtLDEbyPp4hSP+HEaxd3AxwMF1oKwQLhvv0TA1DPd4+JKNBZaxohbA5cRY9QlDLZh0C6P9EQRGaZWr/6KzMX6ynE Cc: "therightkey@ietf.org" , Paul Wouters , Rick Andrews Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:41:52 -0000 On Mon, Oct 22, 2012 at 4:10 PM, Carl Wallace wrote: > It's worth noting that "for the time being, the list is read-only for > non-members." Yep, that's a bummer. Ultimately the CABF is planning to allow read-write access, after subscribers have clicked through an IP rights agreement. But that is also pending, alas. From stephen.farrell@cs.tcd.ie Mon Oct 22 17:30:47 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D68911E8099 for ; Mon, 22 Oct 2012 17:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Msm7ukx52QC for ; Mon, 22 Oct 2012 17:30:46 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF7E1F0429 for ; Mon, 22 Oct 2012 17:30:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1563510398A; Tue, 23 Oct 2012 01:30:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1350952245; bh=QfZEsRR+Zi/Mqs K/t1UGh16mjGZ6eMaYOhjVdziJHwA=; b=Z1cAPPS56rdvLOA8wA8QESJHmBxgOC 85Ik1WW0Um3qIkSXYVEob/9wspCxbeO/ZV4yXh7hcqAbAEvCNX+2wMUO5pPqCPCc GBO1tq/FSvBQ9KcrWcOLJdw7odQjt0+zOwg9hEb4L9Tk3Fv/b5NBUukQ52YWQvTt wjelkdo8WXAvenO+xp83h5E8pTobgyXwbL2/VMJ4DWPYOewXH2OQ6zY1GUwvamnj SoI5Ow0/8JK1oh/8tf2svhpac+jW7cB+FBJgsSfTalv1mOAjjbESFlpgbucR70fl FbXn9VgMrhPbYIhzY7yW6NEbea/YNH4IdnY9a2FB8i7SEQUXpbDCiHGA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 1FlAbITnzckC; Tue, 23 Oct 2012 01:30:45 +0100 (IST) Received: from [10.87.48.4] (unknown [86.45.58.1]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CAE94103988; Tue, 23 Oct 2012 01:30:40 +0100 (IST) Message-ID: <5085E530.7090103@cs.tcd.ie> Date: Tue, 23 Oct 2012 01:30:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: Chris Palmer References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Paul Wouters , Carl Wallace , Rick Andrews Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 00:30:47 -0000 I think we've wandered off-topic here folks. CAB forum might be wonderful, or they might not be, but that's not our business nor is it something that ought drive the CT Bof which is the op-topic thing for this list right now. Feel free to argue with me about that, but off-list please. Thanks, S. On 10/23/2012 12:41 AM, Chris Palmer wrote: > On Mon, Oct 22, 2012 at 4:10 PM, Carl Wallace wrote: > >> It's worth noting that "for the time being, the list is read-only for >> non-members." > > Yep, that's a bummer. Ultimately the CABF is planning to allow > read-write access, after subscribers have clicked through an IP rights > agreement. But that is also pending, alas. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > From gerv@mozilla.org Tue Oct 23 01:41:15 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAD021F86B4 for ; Tue, 23 Oct 2012 01:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpaPDnDQWiHC for ; Tue, 23 Oct 2012 01:41:15 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1C21F86BE for ; Tue, 23 Oct 2012 01:41:15 -0700 (PDT) Received: from [10.20.5.72] (unknown [82.113.183.190]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 88CC4F25BB; Tue, 23 Oct 2012 01:41:13 -0700 (PDT) Message-ID: <50865827.8090300@mozilla.org> Date: Tue, 23 Oct 2012 09:41:11 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0a2 MIME-Version: 1.0 To: Paul Wouters References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Rick Andrews Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 08:41:15 -0000 On 22/10/12 23:15, Paul Wouters wrote: > Maintaining TLS certificates actually becomes _easier_, because people > don't have to frantically read the openssl man page to generate a new > certificate when the old one suddenly expired without anyone noticing > before the complains hit the help desk. They have to read other documentation about how to update their DNS instead... On the above point, incidentally, for those who are not capable of putting an entry in their calendars for a year or two years in advance, then the following Firefox addon (rough and ready, but functional) might be useful: https://addons.mozilla.org/en-US/firefox/addon/expiry-canary/ Gerv From benl@google.com Tue Oct 23 02:08:33 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C041921F86C7 for ; Tue, 23 Oct 2012 02:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3KlljIj+lb9 for ; Tue, 23 Oct 2012 02:08:33 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE94821F86BC for ; Tue, 23 Oct 2012 02:08:32 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2197096wey.31 for ; Tue, 23 Oct 2012 02:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=4xjBC+RHkW8tTOV1efI+wd+H5VYzbL3kr9/sCc2Dvjs=; b=FUo4917DdUeXkHK1GJRj5XFbyNw56lhxpHvko8xuFyC/GNUeRB4R6blF67z5i7MRT5 2e9++m0dy7WX32EczXaMkXx3xFK8g8QG32T7dT/QBXeaoCNID5fApy/Xbikp/UxdbxG3 ye1FwNek3JoxgalVJRcqAJGuMepHJwKIgCOhkcLAMLp9JN18Pb8L0lX1K2pI+jsEeCkF ZCkgYdW1E9vqebd26dLxkmK8KiYc7p+dNH8sKvKQw11I0hp0qc/k9JMpoYoChEtt99VX GTodocX2k5pX5jI2aUtP7pLAiz+Zi6MWKrroUdhsSpZca9q+tLjdrWz86g4dt08K2ZCk qHtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=4xjBC+RHkW8tTOV1efI+wd+H5VYzbL3kr9/sCc2Dvjs=; b=iVQcmiWRUGIlG5AfjBQTloa6G3U4vOXZW8yvgHVEvSx3B5Hv7yXtYrU1R7da0E648u eGIlFYWmc8StKEtmS8fTNvxfvEZPZ+oeJiXZn/tYZKFY6RxbclpqTkXwNWxGVB2E34oI YuLT3wyQg8EtyzL1thgwzzgtIH1Pbx7HUiZGf0+183bAU2vt7Qlhw7cd1lXV0eO/xqVe rLeuqKoN1mYR+h64HmwIJeGPR1c5XyM0sXgD3N+QNLFdTxcBS32/10FGFNEZR4nsifgQ sjw7hd5eVYGmV8iWDhzl+aLDQx2s6VoAZgISjKCJllhgTIp3gBqodJZHMfW52ZfwosId G9JA== MIME-Version: 1.0 Received: by 10.180.100.101 with SMTP id ex5mr43272251wib.16.1350983311643; Tue, 23 Oct 2012 02:08:31 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Tue, 23 Oct 2012 02:08:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Oct 2012 10:08:31 +0100 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkzDI3TjVm5feXddD0ZLbq12pvLEnWfd4+vhlpthT50/QFTB8NSlynpn7uLbxph9fWQjQ6FdSfdq4YgRgtPYU05yCSoWENWD1P06BkDUi8T64ziUQhTOrc3f/Q6EvYUq8YfkNzJelO1IK6qhMH7WyI+qA3D1z390eLDIo7EJ+QVnzOJpv9gDPMwsawEK6IFNayAlPXX Cc: therightkey@ietf.org Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:08:33 -0000 On 22 October 2012 17:00, Paul Wouters wrote: > On Mon, 22 Oct 2012, Ben Laurie wrote: > >> CAs have been arguing in other venues that using TLSA to validate in >> the browser is inferior to using CAs because CAs are prepared to >> revoke certificates that are used for bad things, whereas DNS >> registrars/ICANN are not. > > > Of course, the registrant/DNS hoster itself _can_ and _should_ remove > the TLSA record from DNS. Why would a criminal revoke their own certificate? > Either when it used TLSA for pinning and the > CA got compromised, or when the DNS provider itself got compromised. > > >> This is, of course, why Certificate Transparency exists, so everyone >> can see what's going on. Neither TLSA nor CAs are adequate, IMO. > > > I haven't yet read the draft. The tricky thing of not trusting the > publisher of the certificate data (eg the DNS hoster or web admin) > is one of timing, false positives and delegated (implicit) trust to > more third parties. > > Paul From benl@google.com Tue Oct 23 02:14:18 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A4A21F8468 for ; Tue, 23 Oct 2012 02:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.812 X-Spam-Level: X-Spam-Status: No, score=-102.812 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOXT7z5z6p91 for ; Tue, 23 Oct 2012 02:14:17 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6C721F8461 for ; Tue, 23 Oct 2012 02:14:16 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so2807606wib.13 for ; Tue, 23 Oct 2012 02:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=8bXF5Ocu80PdiWjqffFeC/elv+VGI/PE4hh8fArvqQE=; b=NWLHaRzU1JTGDSN7HJcgQfBWIyjJ/hqnf5Fe3nZRqliXa9EqCErwGHn65jTMx1b4be mpHqSrbdkDQRUvJRXbjB0zya1fP0PUQ4Fc7QjD4Ip1zvyDTNZXrOCe8uL9IxEGOMICQw 006MmrazMtxykjIZsCOAGhcQlIdALwCas28R61vkX/O5VuWV74EM73Tb0/92xNiiW16a A3wPMriGyGpOTBLZZ3QyoFVCMB/yAPR8utujnEYjtOBY9amLwJTUW+4s6FCnK8FDEITs hggEm1+ZRGCLBRMXapnRyXLSr9OxIlqbCKuYQSzr+BB8sfonHRfSFV0jkG9zXwMmIfN3 YY7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=8bXF5Ocu80PdiWjqffFeC/elv+VGI/PE4hh8fArvqQE=; b=NSYqWCQh41H4mmmTZxcqL03c1R6g+OSnA7orkcoN1bqZH8cb4yBvR2CqjqnLfiXWoX +Oe7b4+/Dav45N2FQkugxP/hHqxbk5kGKP5TaBvx8zBm1viG+fM/NAS4Dnkwsq79meDC sgq4c/aHE3B0XxmYDYi6QCK1leIGZnm+VCi5rV5QVxtjRt905WCis36Jc8oZYHYmbLWU oFfTDSAbju2wbBcHL83qQ6snjOuF2gAdmlbivLa3xIima8KGYymA6RTECk1vk2SoYG2P FXv0j9qezx+Wh5GhbCuCVONfYa8TSvdQioNiz0m2gi1+NtpiLxSkv9jBp9jvY3L3gYwg JOYg== MIME-Version: 1.0 Received: by 10.216.193.220 with SMTP id k70mr7619304wen.35.1350983650851; Tue, 23 Oct 2012 02:14:10 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Tue, 23 Oct 2012 02:14:10 -0700 (PDT) In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Tue, 23 Oct 2012 10:14:10 +0100 Message-ID: From: Ben Laurie To: Rick Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkacKG449zaxukl74Hx22EQm6hQJU3Qa3zIkItYUUNhSPoU8aRHu136ZPk8qxOkRIoAvAE+s5E71YYA0PL3AwxP5Pk31bsypB/ARCv1tLoPq2TY93rWbirHenvngWgbWkWzPozjRf+yA8G7+eiIg4FNgIn4NefUMezpkmPdNpPyfGL4oIxVejqlTQaCpiGC5kVuB+Xi Cc: "therightkey@ietf.org" , Paul Wouters Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:14:18 -0000 On 22 October 2012 22:54, Rick Andrews wrote: >> On Mon, 22 Oct 2012, Ben Laurie wrote: >> >> > CAs have been arguing in other venues that using TLSA to validate in >> > the browser is inferior to using CAs because CAs are prepared to >> > revoke certificates that are used for bad things, whereas DNS >> > registrars/ICANN are not. >> >> Of course, the registrant/DNS hoster itself _can_ and _should_ remove >> the TLSA record from DNS. Either when it used TLSA for pinning and the >> CA got compromised, or when the DNS provider itself got compromised. > > I'm one of the CAs that have been arguing in other venues that using TLSA= w/o PKIX validation is inferior to using CAs (w/ PKIX validation). Having = an established mechanism for revocation is just one of the reasons I believ= e this. There are other reasons: > > - CA-issued certs will conform to CABF Baseline Requirements (minim= um key size, strong signing and hashing algorithm, acceptable validity peri= od, proper extensions). Most people would agree that an SSL cert shouldn't = be used for more than a few years, but there's no provision in DANE for pre= venting long-term use of a single key. > > - CA-issued certs would be very likely to have undergone automated = checks for weak keys, weak exponents, not on Debian weak key list, not on i= nternal phish lists, etc.) But with DANE w/o PKIX, it's almost certain that= no checking was performed for weak keys. The person who generated the key = probably won't, and the DNS operator probably won't either, because they're= not required to. > > - If you move away from the CA model to a DNSSEC-based DANE w/o PKI= , you're shifting your trust to the operators of the various DNS zones and = domains (for DNSSEC PKI) How is this different from DV certs? In some ways DV is worse, surely, since an attacker only has to own my domain temporarily and locally (to the CA) to get a DV cert issued. > and to millions of individual domain owners (for generating and maintaini= ng their keys). Domain owners already generate their keys, don't they? > None of those entities are subject to audit like the CAs are, and it's re= asonable to assume that without standards we'll have good ones and bad ones= . That makes the end user less safe, in my opinion. We appear to have bad CAs despite standards. > I actually like DANE. I think that it's a great addition to PKIX validati= on, but not a substitute for it. If we allow sites to use DANE w/o PKIX, I = believe we're opening the door to poor PKI practices (which arguably have b= een tightened up over the past few years by CABF). We're also allowing atta= ckers/phishers to create fraudulent web sites with SSL certs that appear to= be as trusted as legitimate sites. > >> > This is, of course, why Certificate Transparency exists, so everyone >> > can see what's going on. Neither TLSA nor CAs are adequate, IMO. > > I presume that CT will allow an auditor to see the actual cert that was i= ssued, Something very like the cert, anyway - where the SCT is issued from a pre-certificate, then that's what the log records, not the actual certificate. > so an auditor could take over some of the functions that a CA currently p= erforms (checking for key size, weak exponent, Debian, key lifetime, etc.).= But CT doesn't require anyone to do that, nor does it impose any requireme= nts on the auditor. CT _could_ impose requirements. I suspect people will monitor these things anyway, though. From benl@google.com Tue Oct 23 02:15:31 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961C821F86B1 for ; Tue, 23 Oct 2012 02:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbqPMi5aXLCY for ; Tue, 23 Oct 2012 02:15:31 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAC6A21F86AD for ; Tue, 23 Oct 2012 02:15:30 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2200634wey.31 for ; Tue, 23 Oct 2012 02:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=ZE7p9s76nVY8vzkzXOuJTeSWr32g93+evR+TMuakEe0=; b=niUAAKWIn+RpnGR2gufVryYckDIPuy8Vm4Y43w5Rw9mJsewM4uMUTvgkcdnsGdr2X0 jAk5vvlB780E5WsdQPBIkIuHkeiNlq95abH7dF3pDjpMlz5kYT6y+R3lggkwPETSmN3H Xc6ODuMtaBOb9xTS9L8oaP88XhjFyoPHTXuQWkBgT8ZzCjy796H/HibS8OBDk066CLcp zBKijNzpyKpE3rRg4knWNVnakTi4zgIvS5TkOniYnezNTKZUlqiHE5Aj8Rd6yRv8zrZk gf7Ad6V3bwpPymoNc6/3JrvY+8tzVL5WbZy7aur4d2fQ3onV0WOXiJl5Z0QvSlEGc54W jr6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ZE7p9s76nVY8vzkzXOuJTeSWr32g93+evR+TMuakEe0=; b=ObJ/IYAVq5TtP745bQ6XTPIkSiG6YDaKyFEB9+ohXIJijXHFKmMzN90QYfH47FwoKc AKhA4XqfKrUnz8kD0YveItGUg+SypBIZCqK/xjtk2JYJN+YDIi0hOGaYiY5UHcXxqTEu tSOXJAlsQlMIqqpQbSndSemMsTJFZiV77ppZXtZPLTzcTRr59mywhg95688/wWGw7Kh8 gO1+m0f+p+J8tzgUIIfK8XpUvMcYzWm7cgz9xMwlXODmE/y6Nl/ZDw5BttigWu/5S1x3 nCkjGLuyZHTP7AxuhxFZbdk3yZ8BHovzgRHfsR4eWsjg+PU+7tPj7qp9MBsbO7CIl8Pi ru7g== MIME-Version: 1.0 Received: by 10.216.140.205 with SMTP id e55mr6763290wej.2.1350983729958; Tue, 23 Oct 2012 02:15:29 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Tue, 23 Oct 2012 02:15:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Oct 2012 10:15:29 +0100 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn79jxfXfqhKxAMDlh70/y9M3yNEN7fVQpcWjZiTX/LvU0HdEgRxGR/OOlyRlnXUS4KAygyPdAM0zk1lkrdnULsPV3z+DwzNLNUN9Yo3Odk+TKJr6dLZXFBA7g1BycFIHW0MbjvyIiJiS5OaitvOgAjBSNLaHia9lDSGQbH8vNIcBaH6qkTcSh78IZGHCzd+n/aTSP6 Cc: therightkey@ietf.org Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 09:15:31 -0000 On 22 October 2012 17:00, Paul Wouters wrote: > On Mon, 22 Oct 2012, Ben Laurie wrote: > >> CAs have been arguing in other venues that using TLSA to validate in >> the browser is inferior to using CAs because CAs are prepared to >> revoke certificates that are used for bad things, whereas DNS >> registrars/ICANN are not. > > > Of course, the registrant/DNS hoster itself _can_ and _should_ remove > the TLSA record from DNS. Either when it used TLSA for pinning and the > CA got compromised, or when the DNS provider itself got compromised. > > >> This is, of course, why Certificate Transparency exists, so everyone >> can see what's going on. Neither TLSA nor CAs are adequate, IMO. > > > I haven't yet read the draft. Well, you should. > The tricky thing of not trusting the > publisher of the certificate data (eg the DNS hoster or web admin) > is one of timing, false positives and delegated (implicit) trust to > more third parties. I'm not sure if this is a comment on the draft you haven't read, or something else? > > Paul From Rick_Andrews@symantec.com Tue Oct 23 10:35:20 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35841F0425 for ; Tue, 23 Oct 2012 10:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOBF-PSv0mqR for ; Tue, 23 Oct 2012 10:35:20 -0700 (PDT) Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) by ietfa.amsl.com (Postfix) with ESMTP id C90FF1F0419 for ; Tue, 23 Oct 2012 10:35:19 -0700 (PDT) X-AuditID: a66201d1-b7f066d00000553b-76-5086d556b624 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 31.9A.21819.655D6805; Tue, 23 Oct 2012 17:35:18 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by tus1smtintpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1TQiNn-0000gZ-U2; Tue, 23 Oct 2012 17:35:15 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Tue, 23 Oct 2012 10:35:01 -0700 From: Rick Andrews To: Ben Laurie Date: Tue, 23 Oct 2012 10:35:00 -0700 Thread-Topic: [therightkey] TLSA Cert. Usage Thread-Index: Ac2w/sXkPD5EiGnnRC+nwRheQdygRwAQ/kOQ Message-ID: <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsVyYMX1NN2wq20BBm9fWlhs+HyNzeL9rUtM Fh8v/GRxYPZYsKnUY8mSn0we3+cxBTBHcdmkpOZklqUW6dslcGVcXz2DpeCQesWx2S2MDYxz 5LsYOTgkBEwkOs8qdTFyApliEhfurWfrYuTiEBL4yCjx+XMnE4TzilFi+px1UJlVjBLNLduZ QFrYBPQktjy+wg5iiwgoSFz918MCYjMLBEn0/3vACGKzCKhKvOj5xQxiCwtoS3z5c5oFol5H 4s6UJUwQtpHEogkbweK8AlESlxaA1IAsW8ss8eTqKrBmToFAias7N7GB2IxAt34/tYYJYpm4 xK0n85kgfhCQWLLnPDOELSrx8vE/Voh6UYk77esZIep1JBbs/sQGYWtLLFv4mhlisaDEyZlP WCYwis9CMnYWkpZZSFpmIWlZwMiyilEmNTnHMLckMb+0pCC1wsBQr7gyNxEYdcl6yfm5mxiB kbcsifHiDsYLh3UPMQpwMCrx8PodagsQYk0sA6o8xCjBwawkwpt9ESjEm5JYWZValB9fVJqT WnyIUZqDRUmc91ZpVICQQHpiSWp2ampBahFMlomDU6qBcW6csvqM7V39KpN9Vk0WsKoQEGPw Fw2dMiP/M3vwr4ZZGXFfJ0tK1V2+e3DXpZXSey+krv7APdn//Nc1vna3wlY+2tWdUnOzZY5r mcSD+3Grlhgc/MHKuHnxx5cX7+soHhLizXFPa5M3kO/dkDn/Z3fRuW+fX3484PVp6wfT+CNZ El9vT27P/KzEUpyRaKjFXFScCAD5vPQKuAIAAA== Cc: "therightkey@ietf.org" , Paul Wouters Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:35:21 -0000 > -----Original Message----- > From: Ben Laurie [mailto:benl@google.com] > Sent: Tuesday, October 23, 2012 2:14 AM > To: Rick Andrews > Cc: Paul Wouters; therightkey@ietf.org > Subject: Re: [therightkey] TLSA Cert. Usage >=20 > On 22 October 2012 22:54, Rick Andrews > wrote: > >> On Mon, 22 Oct 2012, Ben Laurie wrote: > >> > >> > CAs have been arguing in other venues that using TLSA to validate > in > >> > the browser is inferior to using CAs because CAs are prepared to > >> > revoke certificates that are used for bad things, whereas DNS > >> > registrars/ICANN are not. > >> > >> Of course, the registrant/DNS hoster itself _can_ and _should_ > remove > >> the TLSA record from DNS. Either when it used TLSA for pinning and > the > >> CA got compromised, or when the DNS provider itself got compromised. > > > > I'm one of the CAs that have been arguing in other venues that using > TLSA w/o PKIX validation is inferior to using CAs (w/ PKIX validation). > Having an established mechanism for revocation is just one of the > reasons I believe this. There are other reasons: > > > > - CA-issued certs will conform to CABF Baseline Requirements > (minimum key size, strong signing and hashing algorithm, acceptable > validity period, proper extensions). Most people would agree that an > SSL cert shouldn't be used for more than a few years, but there's no > provision in DANE for preventing long-term use of a single key. > > > > - CA-issued certs would be very likely to have undergone > automated checks for weak keys, weak exponents, not on Debian weak key > list, not on internal phish lists, etc.) But with DANE w/o PKIX, it's > almost certain that no checking was performed for weak keys. The person > who generated the key probably won't, and the DNS operator probably > won't either, because they're not required to. > > > > - If you move away from the CA model to a DNSSEC-based DANE w/o > PKI, you're shifting your trust to the operators of the various DNS > zones and domains (for DNSSEC PKI) >=20 > How is this different from DV certs? In some ways DV is worse, surely, > since an attacker only has to own my domain temporarily and locally > (to the CA) to get a DV cert issued. DV is no better at preventing attacks from those who can subvert DNS. The p= oint I was trying to make is that with any CA-issued cert, a set of checks = will be performed on the key and other cert contents that will not happen i= f the cert is self-signed. > > and to millions of individual domain owners (for generating and > maintaining their keys). >=20 > Domain owners already generate their keys, don't they? Yes, but with DANE w/o PKIX I have to trust that the domain owners with sel= f-signed certs did everything right when generating their keys and certs, b= ecause no one is checking them. =20 > > None of those entities are subject to audit like the CAs are, and > it's reasonable to assume that without standards we'll have good ones > and bad ones. That makes the end user less safe, in my opinion. >=20 > We appear to have bad CAs despite standards. True, and groups like OTA and CABF are trying to improve standards. I'm adv= ocating improving the existing system rather than throwing it out and bring= ing in a new one that is not arguably less trustworthy. This is a bit of a tangent, but IMO the browser vendors have not helped muc= h to improve the status quo. They created a trust system in which all CAs a= re trusted equally, and they are reluctant to remove any CA's trusted roots= from their browser. I'd like to brainstorm how those issues can be address= ed. > > I actually like DANE. I think that it's a great addition to PKIX > validation, but not a substitute for it. If we allow sites to use DANE > w/o PKIX, I believe we're opening the door to poor PKI practices (which > arguably have been tightened up over the past few years by CABF). We're > also allowing attackers/phishers to create fraudulent web sites with > SSL certs that appear to be as trusted as legitimate sites. > > > >> > This is, of course, why Certificate Transparency exists, so > everyone > >> > can see what's going on. Neither TLSA nor CAs are adequate, IMO. > > > > I presume that CT will allow an auditor to see the actual cert that > was issued, >=20 > Something very like the cert, anyway - where the SCT is issued from a > pre-certificate, then that's what the log records, not the actual > certificate. >=20 > > so an auditor could take over some of the functions that a CA > currently performs (checking for key size, weak exponent, Debian, key > lifetime, etc.). But CT doesn't require anyone to do that, nor does it > impose any requirements on the auditor. >=20 > CT _could_ impose requirements. I suspect people will monitor these > things anyway, though. I agree fully that CT would allow lots of actors to monitor everything. But= what if you build it and they don't come? -Rick From ajs@anvilwalrusden.com Tue Oct 23 10:52:21 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE84E11E80EC for ; Tue, 23 Oct 2012 10:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbqJRQhNg9uP for ; Tue, 23 Oct 2012 10:52:20 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 6F82D11E80EF for ; Tue, 23 Oct 2012 10:52:12 -0700 (PDT) Received: from mx1.yitter.info (dhcp-222-230.meetings.nanog.org [199.187.222.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3EE9A8A031 for ; Tue, 23 Oct 2012 17:52:11 +0000 (UTC) Date: Tue, 23 Oct 2012 13:52:02 -0400 From: Andrew Sullivan To: therightkey@ietf.org Message-ID: <20121023175202.GD51219@mx1.yitter.info> References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:52:21 -0000 On Tue, Oct 23, 2012 at 10:35:00AM -0700, Rick Andrews wrote: > > Yes, but with DANE w/o PKIX I have to trust that the domain owners with self-signed certs did everything right when generating their keys and certs, because no one is checking them. > This is a bizarre claim. You seem to be arguing that the TLSA operation is somehow intriniscally harder than configuring the DNS correctly or doing DNSSEC. What makes TLSA peculiarly hard? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From Rick_Andrews@symantec.com Tue Oct 23 11:04:24 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3253A21F859D for ; Tue, 23 Oct 2012 11:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6gu5DY6WVJg for ; Tue, 23 Oct 2012 11:04:23 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) by ietfa.amsl.com (Postfix) with ESMTP id 72F2D21F855A for ; Tue, 23 Oct 2012 11:04:23 -0700 (PDT) X-AuditID: d80ac3f3-b7fab6d000000e20-b6-5086dc26d134 Received: from tus1smtintpin02.ges.symantec.com (tus1smtintpin02.ges.symantec.com [192.168.215.102]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id F8.9E.03616.62CD6805; Tue, 23 Oct 2012 18:04:22 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by tus1smtintpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1TQipw-0005n1-FM; Tue, 23 Oct 2012 18:04:20 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Tue, 23 Oct 2012 11:04:23 -0700 From: Rick Andrews To: Andrew Sullivan , "therightkey@ietf.org" Date: Tue, 23 Oct 2012 11:04:21 -0700 Thread-Topic: [therightkey] TLSA Cert. Usage Thread-Index: Ac2xRzGn0ZLAsrr0RGyZPriBq/lB0wAAR5eA Message-ID: <544B0DD62A64C1448B2DA253C0114146069D2C35F6@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20121023175202.GD51219@mx1.yitter.info> In-Reply-To: <20121023175202.GD51219@mx1.yitter.info> 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+NgFprIIsWRmVeSWpSXmKPExsVyYMX1NF21O20BBsvfWloc+HyNyeLjhZ8s Dkwez06+YvdYsuQnUwBTFJdNSmpOZllqkb5dAlfG82vHWQrmc1d8673G3MDYx9nFyMkhIWAi sWJKOwuELSZx4d56ti5GLg4hgY+MEld29EA5rxgl7t25AuWsYpS41XGXDaSFTUBPYsvjK+wg tohArMTuK1/AbBYBVYmNb18xgdjCAtoSX/6cZoGo0ZG4M2UJUJwDyDaSuDXNBSTMKxAl8fvE TKj5K1kk9h98DlbPKWAqse/mXFYQmxHovO+n1oDNZBYQl7j1ZD4TxNkCEkv2nGeGsEUlXj7+ B1UvKnGnfT0jRL2OxILdn9ggbG2JZQtfM0MsFpQ4OfMJywRGsVlIxs5C0jILScssJC0LGFlW McqUlBYbFueW5JeWFKRWGBjrFVfmJgKjKVkvOT93EyMwom5wHf68g3HhD/1DjAIcjEo8vKG3 2gKEWBPLgCoPMUpwMCuJ8GZfBArxpiRWVqUW5ccXleakFh9ilOZgURLnFXSKDhASSE8sSc1O TS1ILYLJMnFwSjUweizSSVsmd66b63zr4367BLVMqW/11s/PnHhz2iddqjKqna3hhNJppdWx U+v46xTd0wJfvivYdmXnJEsbTx33pBbhdVUmE35MCWYXvSYU+OmlTeH+9xmr+Zj1e7Qz1uhP cI87apJz+m2FZGKSWE247OKOy0btU9V57I9NfsC8p7xns6sP30clluKMREMt5qLiRABEZpQh pAIAAA== Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:04:24 -0000 Andrew, I'm not arguing about TLSA at all. I'm saying that even before the site own= er asks their DNS provider to set up a TLSA record, if they create their ow= n self-signed cert, no one verifies anything about this key or the cert con= tents. I have to trust that they did everything right (didn't use an unpatc= hed Debian system, didn't reuse the same key they've been using for 10 year= s, didn't put misleading info into the DN, etc.) -Rick > -----Original Message----- > From: therightkey-bounces@ietf.org [mailto:therightkey- > bounces@ietf.org] On Behalf Of Andrew Sullivan > Sent: Tuesday, October 23, 2012 10:52 AM > To: therightkey@ietf.org > Subject: Re: [therightkey] TLSA Cert. Usage >=20 > On Tue, Oct 23, 2012 at 10:35:00AM -0700, Rick Andrews wrote: > > > > Yes, but with DANE w/o PKIX I have to trust that the domain owners > with self-signed certs did everything right when generating their keys > and certs, because no one is checking them. > > >=20 > This is a bizarre claim. You seem to be arguing that the TLSA > operation is somehow intriniscally harder than configuring the DNS > correctly or doing DNSSEC. What makes TLSA peculiarly hard? >=20 > Best, >=20 > A >=20 > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From hallam@gmail.com Tue Oct 23 11:21:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D2B11E810F for ; Tue, 23 Oct 2012 11:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.89 X-Spam-Level: X-Spam-Status: No, score=-3.89 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPxckPetvna3 for ; Tue, 23 Oct 2012 11:21:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC6A811E80FD for ; Tue, 23 Oct 2012 11:21:02 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so4531367obq.31 for ; Tue, 23 Oct 2012 11:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4M4AocmAoTsLjkJg/656/Rbu60NdYR9ZhyEOyZ9oIVA=; b=JClwt0MkwKpooLosH5R8SiOeo2QX08JO2VCbmvukhfkMGkD8mIp6kZbFJ7EXZ7cjRo QvH7pESELkZ7zNktq2WvxCWUd+ShWTnUgIM0KKccphPfd5wpg0dZO3dHPx5WSsetdZ4h 4Flgamw63l6oxAR6EvIFQ5Yk0D0VTfuZnE5MOtyk5PUoygYPbZ6IfpYZPV4G/QvpOffW C8y0AJFNaNHfLG+pZENA1OcrtWYBwJ13BueoPPqHpn24jsLz28YLZMRxWSpvzBQZrL// PK9UTjGBifhY1iTG+DfRtMzLEE62sJlxe1EB2ERy5yebmmaMP387h/Iumc998547t4GN kr+Q== MIME-Version: 1.0 Received: by 10.182.113.5 with SMTP id iu5mr10788346obb.36.1351016462309; Tue, 23 Oct 2012 11:21:02 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Tue, 23 Oct 2012 11:21:02 -0700 (PDT) In-Reply-To: <20121023175202.GD51219@mx1.yitter.info> References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20121023175202.GD51219@mx1.yitter.info> Date: Tue, 23 Oct 2012 14:21:02 -0400 Message-ID: From: Phillip Hallam-Baker To: Andrew Sullivan Content-Type: multipart/alternative; boundary=f46d0447f18852590104ccbe081a Cc: therightkey@ietf.org Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:21:07 -0000 --f46d0447f18852590104ccbe081a Content-Type: text/plain; charset=ISO-8859-1 Any administrative procedure that crosses between multiple services in the same organization has always proved to be very hard to pull off. Maybe it should not be that way but that has been the experience. DNSSEC could in theory just be a command line option to BIND. But putting SSL certs in the zone file requires the admins of the Web server to talk to the people running the DNS. And that proves to be very hard and it also proves to be unreliable. On Tue, Oct 23, 2012 at 1:52 PM, Andrew Sullivan wrote: > On Tue, Oct 23, 2012 at 10:35:00AM -0700, Rick Andrews wrote: > > > > Yes, but with DANE w/o PKIX I have to trust that the domain owners with > self-signed certs did everything right when generating their keys and > certs, because no one is checking them. > > > > This is a bizarre claim. You seem to be arguing that the TLSA > operation is somehow intriniscally harder than configuring the DNS > correctly or doing DNSSEC. What makes TLSA peculiarly hard? > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --f46d0447f18852590104ccbe081a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Any administrative procedure that crosses between multiple services in the = same organization has always proved to be very hard to pull off.=A0Maybe it= should not be that way but that has been the experience.

DNSSEC could in theory just be a command line option to BIND. But putting S= SL certs in the zone file requires the admins of the Web server to talk to = the people running the DNS. And that proves to be very hard and it also pro= ves to be unreliable.


On Tue, Oct 23, 201= 2 at 1:52 PM, Andrew Sullivan <ajs@anvilwalrusden.com> = wrote:
On Tue, Oct 23, 2012 at 10= :35:00AM -0700, Rick Andrews wrote:
>
> Yes, but with DANE w/o PKIX I have to trust that the domain owners wit= h self-signed certs did everything right when generating their keys and cer= ts, because no one is checking them.
>

This is a bizarre claim. =A0You seem to be arguing that the TLSA
operation is somehow intriniscally harder than configuring the DNS
correctly or doing DNSSEC. =A0What makes TLSA peculiarly hard?

Best,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________= __________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey



--
= Website: http://hallambaker.com/
--f46d0447f18852590104ccbe081a-- From dkg@fifthhorseman.net Tue Oct 23 11:41:53 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9CC1F042A for ; Tue, 23 Oct 2012 11:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Rtl3oCjU4zc for ; Tue, 23 Oct 2012 11:41:52 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 78C741F0425 for ; Tue, 23 Oct 2012 11:41:52 -0700 (PDT) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 4910BF970 for ; Tue, 23 Oct 2012 14:41:46 -0400 (EDT) Message-ID: <5086E4E6.6060508@fifthhorseman.net> Date: Tue, 23 Oct 2012 14:41:42 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.9) Gecko/20121015 Icedove/10.0.9 MIME-Version: 1.0 To: therightkey@ietf.org References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20121023175202.GD51219@mx1.yitter.info> In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE60F09604E885A56D9A99CC9" Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "therightkey@ietf.org" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:41:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE60F09604E885A56D9A99CC9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/23/2012 02:21 PM, Phillip Hallam-Baker wrote: > DNSSEC could in theory just be a command line option to BIND. But putti= ng > SSL certs in the zone file requires the admins of the Web server to tal= k to > the people running the DNS. And that proves to be very hard and it also= > proves to be unreliable. Putting IP addresses into the zone file also requires the admins of the web server to talk to the people running the DNS, but most people somehow manage to get it done. Those who don't, don't have a working web server, because people can't find it on the 'net. By extension, if DANE works, then those same web server admins who somehow figured out how to communicate their IP addresses to the DNS admins will also figure out how to communicate their public keys to those same DNS admins. Those who don't, don't have a working HTTPS server, because people with DANE-enabled clients won't be able to connect to it. I'm not saying DANE is a perfect solution (i particularly don't like the concentration of hierarchical power represented by the DNS), but the objections raised here recently are pretty underwhelming. --dkg --------------enigE60F09604E885A56D9A99CC9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJQhuTmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpCZoP/0nQc6L0jDH0rgqQh2wZLUyN vOqFK4fs24W9dOf8Rs02758GoQmhPjbDuRRmLiSaKQ9UJvrRzH9wyVqHSF4kknBF yetIPh1cpz2PIDR5U/X6OGCrXxgL7gPk3kzKobJhp603FTnnfVip9mo9XSbubqlp KAA15Fn8krs+XHoyqURdpU7aSJs9c6Bqr+DR732slBeY4jroJbD79E3cnXNDNNYJ n198n38k1OwWTUS8l4HymoheRrOljVeACJjQ9FsrChhQOdRf1V+GBm2we8gajsgr eRkh3cN6KOmNCLqe4dEl20Gyox/RKpesSL+K5S2UZsb56H7mszIrtfDW+0cvI+Bv UxRWvgYa6UENx6vE3TyrgcgW8bj9aAKgzktiafo3nBs1/BcCtJS2x54d8gq+m4Fw /SH74N5uoArUcRaky9wrdh0DnpZr4v312atXChzUErW3XjsCtbMQcTHukBAraonN LXJyGffGVJuaiMcscFMalwXP06B+m0j1GiW3/PjYWvsIgV7XmJLAO9Kk8fTJA+8Q kWN02qNivu8gHItiTYolvf483p/aczQbwk5j/TeDvL4ONkeZWG0r23UB6VzeeV+w wbDikZfyA6/x4WzHCL3K7D2n3YHJV/B1wCgY15/V7xdY91xKFTIg2JPcEh9O92FF q0wOf+Sdf8eEi7+AIOaJ =IXg3 -----END PGP SIGNATURE----- --------------enigE60F09604E885A56D9A99CC9-- From frantz@pwpconsult.com Tue Oct 23 11:45:58 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E601F0CA5 for ; Tue, 23 Oct 2012 11:45:58 -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.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuIgYvOeAOdV for ; Tue, 23 Oct 2012 11:45:57 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAA91F0CA4 for ; Tue, 23 Oct 2012 11:45:57 -0700 (PDT) Received: from [174.252.45.30] (helo=Williams-MacBook-Pro.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TQjUC-0001fJ-2z for therightkey@ietf.org; Tue, 23 Oct 2012 14:45:56 -0400 Date: Tue, 23 Oct 2012 11:46:02 -0700 From: Bill Frantz To: therightkey@ietf.org X-Priority: 3 In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79c2c642c9ea5658387821efcb298a232e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.252.45.30 Subject: [therightkey] Improving Trust X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:45:58 -0000 On 10/23/12 at 10:35 AM, Rick_Andrews@symantec.com (Rick=20 Andrews) wrote: >... IMO the browser vendors have not helped much to improve the=20 >status quo. They created a trust system in which all CAs are=20 >trusted equally, and they are reluctant to remove any CA's=20 >trusted roots from their browser. I'd like to brainstorm how=20 >those issues can be addressed. Trust is such a nebulous idea. For example, I could trust by=20 cousin to abuse alcohol before he died from alcohol-related causes. What I think we are trying to do is ensure that the user can=20 rely on the normal clues to people use to correctly identify a=20 web site (or other computer-mediated communication). Probably=20 users use different visual, and possibly audible clues, but=20 probably the primary clue they use is the look and feel of the=20 web page. How do we get our public key based trust system to=20 separate out the fishing sites? We have tried to train users to look at the browser's crome. To=20 the extent we have been successful, we can now discuss how to=20 improve both the use interface from the crome, and the=20 underlying trust model that supports that interface. If we are=20 going to assign differently levels of assurance to different=20 CAs, we will need to reflect those different levels in the=20 chrome UI. One way to improve the underlying trust model is to use more=20 that one identification technique. We currently use only the=20 PKIX/CA system. As Rick points out, all CAs are equal as far as=20 our trust model is implemented. If we could notice that the last=20 time we visited this site, it had the same public key, that=20 would improve trust, giving us two paths of recognition. If we=20 also got the same information through DANE, that would give us=20 three paths. When these paths disagree, we have a problem. What do we do when=20 the CA has issued a CRL with the site, but the public key is the=20 same as the last time, and the site doesn't use DANE. What if=20 site uses DANE and it says the key belongs to the site? Should=20 we have more paths to establish identity, the number of=20 possibilities will grow rapidly. Consider a nearly real world trust establishment problem. My son=20 is driving from California to Pittsburg PA to go to collage. I=20 receive a communication from him saying the car has needed major=20 repairs and to please send him $2000. How do I establish trust=20 in this communication. If the communication is two-way, a phone call for example, I can=20 engage in a dialog similar to the security questions requested=20 by web sites. If it is a voice call, I can use my built in voice=20 recognition system. If the "send to" address for the money in on a logical route=20 between CA and PA, I'll react differently than if it is in Nigeria. Etc. etc. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Airline peanut bag: "Produced | Periwinkle (408)356-8506 | in a facility that processes | 16345=20 Englewood Ave www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos,=20 CA 95032 From paul@nohats.ca Tue Oct 23 13:18:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5CC1F0C91 for ; Tue, 23 Oct 2012 13:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuZI-WLsUzww for ; Tue, 23 Oct 2012 13:18:07 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 63E2A21F8646 for ; Tue, 23 Oct 2012 13:18:07 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id B11228101E; Tue, 23 Oct 2012 16:17:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A2D1A802A5 for ; Tue, 23 Oct 2012 16:17:31 -0400 (EDT) Date: Tue, 23 Oct 2012 16:17:31 -0400 (EDT) From: Paul Wouters To: "therightkey@ietf.org" In-Reply-To: <5086E4E6.6060508@fifthhorseman.net> Message-ID: References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20121023175202.GD51219@mx1.yitter.info> <5086E4E6.6060508@fifthhorseman.net> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 20:18:08 -0000 On Tue, 23 Oct 2012, Daniel Kahn Gillmor wrote: > I'm not saying DANE is a perfect solution (i particularly don't like the > concentration of hierarchical power represented by the DNS) The hierarchical problem is pretty much an enigma case. If the root key or the com key ever gets abused, for instance by providing custom records with signatures to target someone specifically, and such a record ever leaks out for us to verify, they will lose that trust forever, and the UN or some other body will step in with a new method and trust model. If these keys get "stolen", I think everyone will probably assume what really happened is the above paragraph. That's why I trust the root key and Verisgn to do a good job. This is the same principle where Queen Beatrix of The Netherlands in theory can fire the government, while in practise it would be her last time she could. (unlike Harper in Canada, but I digress) What we will see in practise, is Registrar and Registry compromises, where people simple add or replace DS records. I expect any fortune500 company to monitor their DNS for such abuse. Paul From paul@nohats.ca Tue Oct 23 13:56:16 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B48D1F0C8F for ; Tue, 23 Oct 2012 13:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE9e7ZShdp3m for ; Tue, 23 Oct 2012 13:56:15 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id BBA0E1F0424 for ; Tue, 23 Oct 2012 13:56:15 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id C18888101E; Tue, 23 Oct 2012 16:55:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B5E43802A5; Tue, 23 Oct 2012 16:55:41 -0400 (EDT) Date: Tue, 23 Oct 2012 16:55:41 -0400 (EDT) From: Paul Wouters To: Gervase Markham In-Reply-To: <50865827.8090300@mozilla.org> Message-ID: References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <50865827.8090300@mozilla.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "therightkey@ietf.org" , Rick Andrews Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 20:56:16 -0000 On Tue, 23 Oct 2012, Gervase Markham wrote: > On 22/10/12 23:15, Paul Wouters wrote: >> Maintaining TLS certificates actually becomes _easier_, because people >> don't have to frantically read the openssl man page to generate a new >> certificate when the old one suddenly expired without anyone noticing >> before the complains hit the help desk. > > They have to read other documentation about how to update their DNS > instead... No they do not. Because there is no _expiry date_. By being in the TLSA record in DNS, it is self-declared valid. No mysterious outages in 1 or 2 years from now when the certificat expired and the original guy who know the openssl commandline left the company. This is another reason for TLS bare key certificates that just contain the bare public key as SBKI. To get rid of that obsolete container information (and new CA invoice). Until those are common practise, define the certificate to be valid for 100 years, and you should be good till retirement. Paul From dkg@fifthhorseman.net Tue Oct 23 15:54:11 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FBA1F0C95 for ; Tue, 23 Oct 2012 15:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-4qMZGndl8m for ; Tue, 23 Oct 2012 15:54:10 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 67FAE1F0C3A for ; Tue, 23 Oct 2012 15:54:10 -0700 (PDT) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 0092BF970 for ; Tue, 23 Oct 2012 18:54:05 -0400 (EDT) Message-ID: <50872008.5020902@fifthhorseman.net> Date: Tue, 23 Oct 2012 18:54:00 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.9) Gecko/20121015 Icedove/10.0.9 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20121023175202.GD51219@mx1.yitter.info> <5086E4E6.6060508@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigB5762CC0BDEC4E9AB787BC68" Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "therightkey@ietf.org" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 22:54:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB5762CC0BDEC4E9AB787BC68 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/23/2012 04:17 PM, Paul Wouters wrote: > On Tue, 23 Oct 2012, Daniel Kahn Gillmor wrote: >=20 >> I'm not saying DANE is a perfect solution (i particularly don't like t= he >> concentration of hierarchical power represented by the DNS) >=20 > The hierarchical problem is pretty much an enigma case. If the root key= > or the com key ever gets abused, for instance by providing custom recor= ds > with signatures to target someone specifically, and such a record ever > leaks out for us to verify, they will lose that trust forever, and the > UN or some other body will step in with a new method and trust model. The global experience with CAs suggests that failure to prevent secret key material abuse does not result in negative consequences for those CAs that are "too big to fail". I don't see why that experience wouldn't repeat itself for the key that signs the root zone or any of the popular TLDs. Anyway, cryptographic failures are only one part of the problem. Political failures are at least as important, and the DNS has already shown itself to be vulnerable to manipulation by powerful actors [0]. i see no reason to believe that this sort of manipulation would stop short of malicious DS record insertion once DNSSEC is in widespread use. Regards, --dkg [0] https://www.muckrock.com/foi/united-states-of-america-10/domain-name-seiz= ures-329/#445469-responsive-documents --------------enigB5762CC0BDEC4E9AB787BC68 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJQhyAIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpFBoP/j+Y8C3wNZKnEUtJtlvFpAOj 2y7b3MyFaojcbtL0hzhTtf429ay8CexGGQQiSjZ1iUFe5NG3yDopZTt2M2OM3zHK kntN5uPiNgmCk7mUs1c2ozInymlW+NAjRni3eSNUZCGbJA/xdIpLlc7wHeVYY8Mh 9IP3lsiNKn0so7Y90VYMIWdrxLm2I0OeVyfza+KrqNzWpFvSSzs8RcuNDEfx9EvY Mfzvply7M8DBqC6D9QZg7z0qeQpncF4MuTJbmiNV84fmI7shgp6mX1n6u7jltJ6d NI+NvqIVg61Qlnv/ZExGe4+Fv1JkJ63LDM0ZzmwASNdT3p5aPiVQ3I0XlMkzFNNo RsWopYJhnbKHmtNd4fhas25RlN6aOC1b+NaUMRabdWa4QcJCMyFdhCnDnKQhSP6O eXrwokvIZBSQ4DGAPe98Kb9b8XHPH0JOk/2YI/dY/oxzrctksjWqaEAZcXu5AFGN nQ2dzgbnT9M2RB72hIXPfJd/VMEb2BtNIlO5UQXwyorvMEIYwy4OKsXVHhVNK/qG SpXVvlXEcZp4TLMtDemNstNiRyV8+Wjb6tkcv26ABl5ipfcspv2B471twENiBOby 7O2P9hPSmuy6ow9cVLimKY98CDU402A8Vzzy6koEDM6p6zAsepLQtuSXjlCIt1J5 dfKrnDIeH5MhBWiGdm5e =YlQb -----END PGP SIGNATURE----- --------------enigB5762CC0BDEC4E9AB787BC68-- From bergtau@gmail.com Tue Oct 23 16:21:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328051F0C3A for ; Tue, 23 Oct 2012 16:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QSw8Sw3iUgR for ; Tue, 23 Oct 2012 16:21:06 -0700 (PDT) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11FAA1F0CB7 for ; Tue, 23 Oct 2012 16:21:03 -0700 (PDT) Received: by mail-ia0-f172.google.com with SMTP id o25so3979987iad.31 for ; Tue, 23 Oct 2012 16:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=wRKH4Uj08Fk2MoK6AlAWm8H/whtIvDsAMCpI7PtActI=; b=qxRuIE4Gj0H+qbEW+C+REmlk7Dw46/PKDBbr84YVc0W7shCnn5V+iW43I6qReQxZHp rgqTpoJRzhaHrCXi8dI7lJuPE94Dn9T5aFCxiNkH3lkcjYPXa3LeBRz1HJv5IhC2VudQ J1HXdai6x4Kbd3a93oFMtj6Ei8BUwymjkCtZg/XVtprdn24LBEMSzfCO+RtBXiX2kOB6 A6iZ+OAnvvYNuUBhjX3FdLCQE61EBSrVrL0qai8Q3ZMqAv5MQtL175rI/EyHejgi8ulk W6KJTSDiVNArJPejWQKXk8SrfxT7G1PJcwGm+CtfAp3XMUfapOXpdUsEzQhAdp4uFAJI 7pEQ== MIME-Version: 1.0 Received: by 10.50.193.161 with SMTP id hp1mr773906igc.27.1351034463521; Tue, 23 Oct 2012 16:21:03 -0700 (PDT) Received: by 10.64.11.1 with HTTP; Tue, 23 Oct 2012 16:21:03 -0700 (PDT) In-Reply-To: References: <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Tue, 23 Oct 2012 19:21:03 -0400 Message-ID: From: Michael Jenkins To: therightkey@ietf.org Content-Type: multipart/alternative; boundary=14dae9340df7470ca004ccc23914 Subject: Re: [therightkey] Improving Trust X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:21:07 -0000 --14dae9340df7470ca004ccc23914 Content-Type: text/plain; charset=ISO-8859-1 I don't think trust is that nebulous an idea for many things that people do with browsers. We've got to stop convincing people that "this certificate is okay", and start informing them "it's okay to enter a credit card number here". I often wonder why the browser doesn't have the ability for me to label my trust anchors with labels like "bank" and "school", and then indicate to me when a certificate validation has terminated in a labeled trust anchor. How I apply those labels is my policy - based on prior experience, or obtaining a "fingerprint" from a letter from the bank, or what have you. It doesn't even prevent me from working with other banks, unless I want to limit myself. This would be even more useful for device apps, that could be initialized to only use one trust anchor from the list. There have got to be ways to do this that are fairly straightforward, not too tedious for youth and not too complicated for elderly folks. [Have I insulted everyone yet? Alrighty then.] Mike On Tue, Oct 23, 2012 at 2:46 PM, Bill Frantz wrote: > On 10/23/12 at 10:35 AM, Rick_Andrews@symantec.com (Rick Andrews) wrote: > > ... IMO the browser vendors have not helped much to improve the status >> quo. They created a trust system in which all CAs are trusted equally, and >> they are reluctant to remove any CA's trusted roots from their browser. I'd >> like to brainstorm how those issues can be addressed. >> > > Trust is such a nebulous idea. For example, I could trust by cousin to > abuse alcohol before he died from alcohol-related causes. > > What I think we are trying to do is ensure that the user can rely on the > normal clues to people use to correctly identify a web site (or other > computer-mediated communication). Probably users use different visual, and > possibly audible clues, but probably the primary clue they use is the look > and feel of the web page. How do we get our public key based trust system > to separate out the fishing sites? > > We have tried to train users to look at the browser's crome. To the extent > we have been successful, we can now discuss how to improve both the use > interface from the crome, and the underlying trust model that supports that > interface. If we are going to assign differently levels of assurance to > different CAs, we will need to reflect those different levels in the chrome > UI. > > One way to improve the underlying trust model is to use more that one > identification technique. We currently use only the PKIX/CA system. As Rick > points out, all CAs are equal as far as our trust model is implemented. If > we could notice that the last time we visited this site, it had the same > public key, that would improve trust, giving us two paths of recognition. > If we also got the same information through DANE, that would give us three > paths. > > When these paths disagree, we have a problem. What do we do when the CA > has issued a CRL with the site, but the public key is the same as the last > time, and the site doesn't use DANE. What if site uses DANE and it says the > key belongs to the site? Should we have more paths to establish identity, > the number of possibilities will grow rapidly. > > > Consider a nearly real world trust establishment problem. My son is > driving from California to Pittsburg PA to go to collage. I receive a > communication from him saying the car has needed major repairs and to > please send him $2000. How do I establish trust in this communication. > > If the communication is two-way, a phone call for example, I can engage in > a dialog similar to the security questions requested by web sites. If it is > a voice call, I can use my built in voice recognition system. > > If the "send to" address for the money in on a logical route between CA > and PA, I'll react differently than if it is in Nigeria. > > Etc. etc. > > Cheers - Bill > > ------------------------------**------------------------------** > ------------- > Bill Frantz | Airline peanut bag: "Produced | Periwinkle > (408)356-8506 | in a facility that processes | 16345 Englewood Ave > www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, CA 95032 > > ______________________________**_________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/**listinfo/therightkey > --14dae9340df7470ca004ccc23914 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think trust is that nebulous an idea for many things that peopl= e do with browsers. We've got to stop convincing people that "this= certificate is okay", and start informing them "it's okay to= enter a credit card number here".

I often wonder why the browser doesn't have the ability = for me to label my trust anchors with labels like "bank" and &quo= t;school", and then indicate to me when a certificate validation has t= erminated in a labeled trust anchor. How I apply those labels is my policy = - based on prior experience, or obtaining a "fingerprint" from a = letter from the bank, or what have you. It doesn't even prevent me from= working with other banks, unless I want to limit myself.

This would be even more useful for device apps, that co= uld be initialized to only use one trust anchor from the list.=A0

There have got to be ways to do this that are fairly straig= htforward, not too tedious for youth and not too complicated for elderly fo= lks. [Have I insulted everyone yet? Alrighty then.]=A0

Mike

On Tue, Oct 23, = 2012 at 2:46 PM, Bill Frantz <frantz@pwpconsult.com> wro= te:
On 10/23/12 at 10:35 AM, Rick_Andrews@symantec.com (= Rick Andrews) wrote:

... IMO the browser vendors have not helped much to improve the status quo.= They created a trust system in which all CAs are trusted equally, and they= are reluctant to remove any CA's trusted roots from their browser. I&#= 39;d like to brainstorm how those issues can be addressed.

Trust is such a nebulous idea. For example, I could trust by cousin to abus= e alcohol before he died from alcohol-related causes.

What I think we are trying to do is ensure that the user can rely on the no= rmal clues to people use to correctly identify a web site (or other compute= r-mediated communication). Probably users use different visual, and possibl= y audible clues, but probably the primary clue they use is the look and fee= l of the web page. How do we get our public key based trust system to separ= ate out the fishing sites?

We have tried to train users to look at the browser's crome. To the ext= ent we have been successful, we can now discuss how to improve both the use= interface from the crome, and the underlying trust model that supports tha= t interface. If we are going to assign differently levels of assurance to d= ifferent CAs, we will need to reflect those different levels in the chrome = UI.

One way to improve the underlying trust model is to use more that one ident= ification technique. We currently use only the PKIX/CA system. As Rick poin= ts out, all CAs are equal as far as our trust model is implemented. If we c= ould notice that the last time we visited this site, it had the same public= key, that would improve trust, giving us two paths of recognition. If we a= lso got the same information through DANE, that would give us three paths.<= br>
When these paths disagree, we have a problem. What do we do when the CA has= issued a CRL with the site, but the public key is the same as the last tim= e, and the site doesn't use DANE. What if site uses DANE and it says th= e key belongs to the site? Should we have more paths to establish identity,= the number of possibilities will grow rapidly.


Consider a nearly real world trust establishment problem. My son is driving= from California to Pittsburg PA to go to collage. I receive a communicatio= n from him saying the car has needed major repairs and to please send him $= 2000. How do I establish trust in this communication.

If the communication is two-way, a phone call for example, I can engage in = a dialog similar to the security questions requested by web sites. If it is= a voice call, I can use my built in voice recognition system.

If the "send to" address for the money in on a logical route betw= een CA and PA, I'll react differently than if it is in Nigeria.

Etc. etc.

Cheers - Bill

-------------------------------------------------------------= ------------
Bill Frantz =A0 =A0 =A0 =A0| Airline peanut bag: "Produced =A0| Periwi= nkle
= (408)356-8506=A0 =A0 =A0 | in a facility that processes =A0 | 16345 Eng= lewood Ave
www.pwpconsult.com<= /a> | peanuts and other nuts." - Duh | Los Gatos, CA 95032

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

--14dae9340df7470ca004ccc23914-- From carl@redhoundsoftware.com Tue Oct 23 16:33:19 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F21711E80A4 for ; Tue, 23 Oct 2012 16:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWH2I6J015-i for ; Tue, 23 Oct 2012 16:33:15 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D11C911E810B for ; Tue, 23 Oct 2012 16:33:14 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2453420wgb.13 for ; Tue, 23 Oct 2012 16:33:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:x-gm-message-state; bh=QWl4WssYYCbw2CoLMgG924ZGHg/d+CU8ohRRQARDxDk=; b=nj2xABESP6xsUQ4uKuYqC3Nu+fBlGM8FLE6BwQr8lVNLhJC8BjYXgJqFTEM7OZWqkb 7cQeynFFZPRIR3u5l0KPxuLh6FltWrndXfjCV1mxopdz69DbinWg2wcjbmz8e4YF1Zsf JWJM9CwSm3kBWNr+5gOvL5Y6UWZUf973OaNHL2JY6MI3jeYApyWt4G6rKD02wyc/CGYO IlR+QHND1RJVpTitiSLwnzSce938fSvzwC7Q4RmaSHt8HcCgVAsTmd+HV6Tg5aNRXroy UPWoma7oDNcT2ph+P7QTGYmHuliOLEoTukEgFzhB+xNSSuUMMx95go8RqiIuPk18muYU YtJg== Received: by 10.180.73.76 with SMTP id j12mr1386443wiv.11.1351035193947; Tue, 23 Oct 2012 16:33:13 -0700 (PDT) Received: from [10.71.7.189] (46-37-46-202.dsl.cnl.uk.net. [46.37.46.202]) by mx.google.com with ESMTPS id cn6sm1409839wib.9.2012.10.23.16.33.09 (version=SSLv3 cipher=OTHER); Tue, 23 Oct 2012 16:33:13 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.4.120824 Date: Wed, 24 Oct 2012 00:33:07 +0100 From: Carl Wallace To: Michael Jenkins , Message-ID: Thread-Topic: [therightkey] Improving Trust In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3433883595_5843596" X-Gm-Message-State: ALoCoQnCcST5tiWZ9oiIvRmq+N3yM3l5YdaeMIqOwconD4RTZMO+bQUqPbbE0itnNDWlCBBNPXEK Subject: Re: [therightkey] Improving Trust X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:33:19 -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_3433883595_5843596 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable From: Mike Jenkins Date: Wednesday, October 24, 2012 12:21 AM To: Subject: Re: [therightkey] Improving Trust > I don't think trust is that nebulous an idea for many things that people = do > with browsers. We've got to stop convincing people that "this certificate= is > okay", and start informing them "it's okay to enter a credit card number > here". >=20 > I often wonder why the browser doesn't have the ability for me to label m= y > trust anchors with labels like "bank" and "school", and then indicate to = me > when a certificate validation has terminated in a labeled trust anchor. H= ow I > apply those labels is my policy - based on prior experience, or obtaining= a > "fingerprint" from a letter from the bank, or what have you. It doesn't e= ven > prevent me from working with other banks, unless I want to limit myself. This is along the lines of a browser feature I've wanted for a while =AD the means for the user to indicate the nature of what they are doing =AD i.e., I'= m shopping or banking or doing medical stuff, etc. A narrow trust anchor store associated with purposes like these could allow the posture of the browser to vary based on what the user says they are doing. >=20 > This would be even more useful for device apps, that could be initialized= to > only use one trust anchor from the list. >=20 > There have got to be ways to do this that are fairly straightforward, not= too > tedious for youth and not too complicated for elderly folks. [Have I insu= lted > everyone yet? Alrighty then.] >=20 > Mike >=20 > On Tue, Oct 23, 2012 at 2:46 PM, Bill Frantz wrot= e: >> On 10/23/12 at 10:35 AM, Rick_Andrews@symantec.com (Rick Andrews) wrote: >>=20 >>> ... IMO the browser vendors have not helped much to improve the status = quo. >>> They created a trust system in which all CAs are trusted equally, and t= hey >>> are reluctant to remove any CA's trusted roots from their browser. I'd = like >>> to brainstorm how those issues can be addressed. >>=20 >> Trust is such a nebulous idea. For example, I could trust by cousin to a= buse >> alcohol before he died from alcohol-related causes. >>=20 >> What I think we are trying to do is ensure that the user can rely on the >> normal clues to people use to correctly identify a web site (or other >> computer-mediated communication). Probably users use different visual, a= nd >> possibly audible clues, but probably the primary clue they use is the lo= ok >> and feel of the web page. How do we get our public key based trust syste= m to >> separate out the fishing sites? >>=20 >> We have tried to train users to look at the browser's crome. To the exte= nt we >> have been successful, we can now discuss how to improve both the use >> interface from the crome, and the underlying trust model that supports t= hat >> interface. If we are going to assign differently levels of assurance to >> different CAs, we will need to reflect those different levels in the chr= ome >> UI. >>=20 >> One way to improve the underlying trust model is to use more that one >> identification technique. We currently use only the PKIX/CA system. As R= ick >> points out, all CAs are equal as far as our trust model is implemented. = If we >> could notice that the last time we visited this site, it had the same pu= blic >> key, that would improve trust, giving us two paths of recognition. If we= also >> got the same information through DANE, that would give us three paths. >>=20 >> When these paths disagree, we have a problem. What do we do when the CA = has >> issued a CRL with the site, but the public key is the same as the last t= ime, >> and the site doesn't use DANE. What if site uses DANE and it says the ke= y >> belongs to the site? Should we have more paths to establish identity, th= e >> number of possibilities will grow rapidly. >>=20 >>=20 >> Consider a nearly real world trust establishment problem. My son is driv= ing >> from California to Pittsburg PA to go to collage. I receive a communicat= ion >> from him saying the car has needed major repairs and to please send him >> $2000. How do I establish trust in this communication. >>=20 >> If the communication is two-way, a phone call for example, I can engage = in a >> dialog similar to the security questions requested by web sites. If it i= s a >> voice call, I can use my built in voice recognition system. >>=20 >> If the "send to" address for the money in on a logical route between CA = and >> PA, I'll react differently than if it is in Nigeria. >>=20 >> Etc. etc. >>=20 >> Cheers - Bill >>=20 >> ------------------------------------------------------------------------= - >> Bill Frantz | Airline peanut bag: "Produced | Periwinkle >> (408)356-8506 | in a facility that process= es >> | 16345 Englewood Ave >> www.pwpconsult.com | peanuts and other nuts= ." - >> Duh | Los Gatos, CA 95032 >>=20 >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> >=20 > _______________________________________________ therightkey mailing list > therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey --B_3433883595_5843596 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

From: Mike Jenkins <= bergtau@gmail.com>
Date: We= dnesday, October 24, 2012 12:21 AM
To: <therightkey@ietf.org><= br>Subject: Re: [therightkey] Improvi= ng Trust

I don't think trust is that nebulous an idea for many things that people= do with browsers. We've got to stop convincing people that "this certificat= e is okay", and start informing them "it's okay to enter a credit card numbe= r here".

I often wonder why the browser doesn't have the = ability for me to label my trust anchors with labels like "bank" and "school= ", and then indicate to me when a certificate validation has terminated in a= labeled trust anchor. How I apply those labels is my policy - based on prio= r experience, or obtaining a "fingerprint" from a letter from the bank, or w= hat have you. It doesn't even prevent me from working with other banks, unle= ss I want to limit myself.

This= is along the lines of a browser feature I've wanted for a while – the= means for the user to indicate the nature of what they are doing – i.= e., I'm shopping or banking or doing medical stuff, etc.  A narrow trus= t anchor store associated with purposes like these could allow the posture o= f the browser to vary based on what the user says they are doing.  


This would be even more useful for d= evice apps, that could be initialized to only use one trust anchor from the = list. 

There have got to be ways to do this th= at are fairly straightforward, not too tedious for youth and not too complic= ated for elderly folks. [Have I insulted everyone yet? Alrighty then.] =

Mike

On Tue, Oct 2= 3, 2012 at 2:46 PM, Bill Frantz <frantz@pwpconsult.com> wrote:
On 10/23/12 at 10:35 AM, Rick_Andrews@symantec.com (Rick Andr= ews) wrote:

... IMO the browser vendors have not helped much to improve the status quo.= They created a trust system in which all CAs are trusted equally, and they = are reluctant to remove any CA's trusted roots from their browser. I'd like = to brainstorm how those issues can be addressed.

Trust is such a nebulous idea. For example, I could trust by cousin to abus= e alcohol before he died from alcohol-related causes.

What I think we are trying to do is ensure that the user can rely on the no= rmal clues to people use to correctly identify a web site (or other computer= -mediated communication). Probably users use different visual, and possibly = audible clues, but probably the primary clue they use is the look and feel o= f the web page. How do we get our public key based trust system to separate = out the fishing sites?

We have tried to train users to look at the browser's crome. To the extent = we have been successful, we can now discuss how to improve both the use inte= rface from the crome, and the underlying trust model that supports that inte= rface. If we are going to assign differently levels of assurance to differen= t CAs, we will need to reflect those different levels in the chrome UI.
<= br> One way to improve the underlying trust model is to use more that one ident= ification technique. We currently use only the PKIX/CA system. As Rick point= s out, all CAs are equal as far as our trust model is implemented. If we cou= ld notice that the last time we visited this site, it had the same public ke= y, that would improve trust, giving us two paths of recognition. If we also = got the same information through DANE, that would give us three paths.
When these paths disagree, we have a problem. What do we do when the CA has= issued a CRL with the site, but the public key is the same as the last time= , and the site doesn't use DANE. What if site uses DANE and it says the key = belongs to the site? Should we have more paths to establish identity, the nu= mber of possibilities will grow rapidly.


Consider a nearly real world trust establishment problem. My son is driving= from California to Pittsburg PA to go to collage. I receive a communication= from him saying the car has needed major repairs and to please send him $20= 00. How do I establish trust in this communication.

If the communication is two-way, a phone call for example, I can engage in = a dialog similar to the security questions requested by web sites. If it is = a voice call, I can use my built in voice recognition system.

If the "send to" address for the money in on a logical route between CA and= PA, I'll react differently than if it is in Nigeria.

Etc. etc.

Cheers - Bill

-------------------------------------------------------------= ------------
Bill Frantz        | Airline peanut bag: "Produced &nbs= p;| Periwinkle
(408)356-8506      | in a facility that proces= ses   | 16345 Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Ga= tos, CA 95032

_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listi= nfo/therightkey

_______________________________________________ therightkey mailing list therightkey@ietf.org https://www.iet= f.org/mailman/listinfo/therightkey
--B_3433883595_5843596-- From dkg@fifthhorseman.net Tue Oct 23 16:42:59 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5EE11E80AD for ; Tue, 23 Oct 2012 16:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK7sQy9uxnrm for ; Tue, 23 Oct 2012 16:42:58 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4465511E80A4 for ; Tue, 23 Oct 2012 16:42:58 -0700 (PDT) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 65640F970; Tue, 23 Oct 2012 19:42:55 -0400 (EDT) Message-ID: <50872B7A.4000503@fifthhorseman.net> Date: Tue, 23 Oct 2012 19:42:50 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.9) Gecko/20121015 Icedove/10.0.9 MIME-Version: 1.0 To: Michael Jenkins References: <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigFD0A55F472235400705F5A18" Cc: therightkey@ietf.org Subject: Re: [therightkey] Improving Trust X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:42:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFD0A55F472235400705F5A18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/23/2012 07:21 PM, Michael Jenkins wrote: > I don't think trust is that nebulous an idea for many things that peopl= e do > with browsers. We've got to stop convincing people that "this certifica= te > is okay", and start informing them "it's okay to enter a credit card nu= mber > here". browsers should not try to indicate "it's okay to enter a credit card number here" without asking for a lot more information from the user -- even if you could determine that a given business was "official", there's no way for a browser to know that this business is one that the user actually is willing to give their credit card to. The same word of caution holds for many other kinds of communication beyond financial details. Different users face different threats and have different perceptions of acceptable risk. > I often wonder why the browser doesn't have the ability for me to label= my > trust anchors with labels like "bank" and "school", and then indicate t= o me > when a certificate validation has terminated in a labeled trust anchor.= How > I apply those labels is my policy - based on prior experience, or obtai= ning > a "fingerprint" from a letter from the bank, or what have you. It doesn= 't > even prevent me from working with other banks, unless I want to limit > myself. What you describe is known as "petnames" [0]. There was even a browser plugin for it, back in the day [1]. If you want this functionality, perhaps resurrecting that plugin would be a useful course of action? Regards, --dkg [0] http://www.skyhunter.com/marcs/petnames/IntroPetNames.html [1] http://www.waterken.com/user/PetnameTool/ --------------enigFD0A55F472235400705F5A18 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJQhyt7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpGYcP+gKbX+88/fIT/IuGsLA91K4F 4qd+ckpoUD68iJPT2xwqPdhN1bHfIMr7ILk1/ND9VTMfZztP3ddBx5/A+JEUR64Y EAJQnJkXdkoxEBr+z/4Ci6+zuBFva8MHqDAB2qD88Na7RLPzr/mMzNBw+JDVeZcS Kv9GJAical+r3Z8Rp3PfnkBCIyryL9kPztrNNDlZ+ThhdEf/YjdigS4UxCebc8GH K3DmGAAAWzT7leh4WqGRftymqoyvITsq60aZjIZegev13ODosAqwqYWMHYKWiEuO AOfj2pMmL2PJcFJb2NTieK1lLWxj/iO7OJS1Ikv3d7yFyILsgUSvSGpaODbNShNg nt3Tb17XiNYAZUbYtJ4+Az3wI5YB5s+gk0auTfRQUwUl1A00mfGxKUf6OUSx0h5g DiBr6eTfmWihU6fV5vf0a2S1Z4mamo/56XEdPcPm0f/Dkkzd+XZeB0jKmYWUXjVw n5+r0FJL3EXO1jInVaz6bmf5UTa3SWcrwbhrPiP4DFInzlrF3CrtBbqvEfeTC/uf NiAFFOnombh+wuNLBq375Pu7o054uVTyH6utvKYz/DseQT6f5iui4+HGiAuTCmH4 9J1N7nDjf8QS2faVWzfUPL3WZ+1s7rgZiP9V7EpNhjHLkD2AvJ1o4vumoEAyZc0c aUZFwY+kM+eFr2APaQgy =9GZM -----END PGP SIGNATURE----- --------------enigFD0A55F472235400705F5A18-- From sm@resistor.net Tue Oct 23 16:45:16 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A011F0CB5 for ; Tue, 23 Oct 2012 16:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pf+YliZHmC5 for ; Tue, 23 Oct 2012 16:45:15 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4CC1F0CB1 for ; Tue, 23 Oct 2012 16:45:15 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q9NNjA2V022587; Tue, 23 Oct 2012 16:45:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1351035915; bh=JBE0Wdi0aym6fZV9OG9vlDUrsNqE7eUyuofdkeJy+bM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bwtJIN8TuE6g2EsuxReoc+0+6mder2SXcGSzoNZftGjqGWBav8lfaAPmvMqkjR3AQ 6OcfK6BoOYyFzWGuBNK8YrAeIO001tXa56xf/Or1JLaUz4hgzyL5ZExJd0rMc21fqC Yt4J/PWukdNfZ3ynu8SwU8DIeumhlBeVBbkG7ayQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1351035915; i=@resistor.net; bh=JBE0Wdi0aym6fZV9OG9vlDUrsNqE7eUyuofdkeJy+bM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zBS7az5EX0zCGHD4S/jfBYfErjEJqQjZOhaKa0+vyXglJHKH41UnzcZBs8CJXMP4P E0Pen/7zhUDycS9qVldNFGMOHPowmf/lmXBaWLu8ZlXcnT7xTktGZUMcTpQV8IuyIt BDCpLDE5y7kYMT9XdhfG9VaXsWD6Xtb5KB4trzD8= Message-Id: <6.2.5.6.2.20121023163718.0abefd70@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 23 Oct 2012 16:44:48 -0700 To: Paul Wouters From: SM In-Reply-To: References: <544B0DD62A64C1448B2DA253C0114146069D2C2DD0@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D2C3569@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <20121023175202.GD51219@mx1.yitter.info> <5086E4E6.6060508@fifthhorseman.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: therightkey@ietf.org Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:45:16 -0000 Hi Paul, At 13:17 23-10-2012, Paul Wouters wrote: >The hierarchical problem is pretty much an enigma case. If the root key >or the com key ever gets abused, for instance by providing custom records >with signatures to target someone specifically, and such a record ever >leaks out for us to verify, they will lose that trust forever, and the Yes. Regards, -sm From paul.hoffman@vpnc.org Tue Oct 23 18:17:48 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7C011E814B for ; Tue, 23 Oct 2012 18:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPbQFojdkM4b for ; Tue, 23 Oct 2012 18:17:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F083F11E8149 for ; Tue, 23 Oct 2012 18:17:47 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9O1HjrH075564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 23 Oct 2012 18:17:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Tue, 23 Oct 2012 18:17:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> To: "therightkey@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [therightkey] Call for agenda items for certrans BoF X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 01:17:48 -0000 Proposed agenda is at = Discuss any proposed changes here. --Paul Hoffman= From hallam@gmail.com Tue Oct 23 18:41:45 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB61511E815C for ; Tue, 23 Oct 2012 18:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.884 X-Spam-Level: X-Spam-Status: No, score=-3.884 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWAUrFy0Pq8X for ; Tue, 23 Oct 2012 18:41:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3687811E8153 for ; Tue, 23 Oct 2012 18:41:44 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so6399obq.31 for ; Tue, 23 Oct 2012 18:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rlqGEwagJkTlK85NTQK/FS7STybscl446tObbmY0siQ=; b=vNZpp76XLSn60lauVXJLAqlsOnfLCB3LP4mjoHgaIwJO/OD2n/7ZTdX7P1aG2ifjUP MplNlRZW8zAhhHgaifQeX6p5XMFI2m0qZ5qT9kCXCpc6kRYs5+TIp8dwOvbZys7uxlmW WgRYSu5PSfF6aFmeQkTMwAZt0A+FAj4fIiLSbFNr5kFe/H3lkIo6EnqesFzpGd/Mrt+L QfST0P2QBQOS1G9VEI8ZQpmBamUVFDxDtoMPPQ4+SJ8bDcaTWLbIQFvw4gS8avqeMVqg M2mzPQ7GSyQBtVKQmIw/47bO/3DFrrbZG8T8Dg4OA3dWyG5pVG4HXSDVrJjHgEQRsNUa M3TA== MIME-Version: 1.0 Received: by 10.60.14.198 with SMTP id r6mr12364590oec.115.1351042903816; Tue, 23 Oct 2012 18:41:43 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Tue, 23 Oct 2012 18:41:43 -0700 (PDT) In-Reply-To: <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> Date: Tue, 23 Oct 2012 21:41:43 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=e89a8fb1f72c5bb97904ccc430f5 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Call for agenda items for certrans BoF X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 01:41:45 -0000 --e89a8fb1f72c5bb97904ccc430f5 Content-Type: text/plain; charset=ISO-8859-1 One of the key issues as far as acceptability to CAs is concerned is impact on issue processes. In particular it has to be possible to deploy any experimental infrastructure without touching the certificate issue code. I think this is going to mean that CT proofs have to end up being embedded in something other than the cert they relate to. I can't see the precert idea as viable. Transporting the CT proofs in OCSP is viable though - provided some changes are made there. I don't mind if we discuss this as part of Ben's 60 mins or not but we do need to discuss. On Tue, Oct 23, 2012 at 9:17 PM, Paul Hoffman wrote: > Proposed agenda is at < > https://datatracker.ietf.org/meeting/85/agenda/certrans/> > > Discuss any proposed changes here. > > --Paul Hoffman > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --e89a8fb1f72c5bb97904ccc430f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One of the key issues as far as acceptability to CAs is concerned is impact= on issue processes. In particular it has to be possible to deploy any expe= rimental infrastructure without touching the certificate issue code.

I think this is going to mean that CT proofs have to end up = being embedded in something other than the cert they relate to. I can't= see the precert idea as viable. Transporting the CT proofs in OCSP is viab= le though - provided some changes are made there.

I don't mind if we discuss this as part of Ben'= s 60 mins or not but we do need to discuss.


On Tue, Oct 23, 2012 at 9:17 PM, Paul Hoffman <paul.hoff= man@vpnc.org> wrote:
Proposed agenda is at <https:= //datatracker.ietf.org/meeting/85/agenda/certrans/>

Discuss any proposed changes here.

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



--
= Website: http://hallambaker.com/
--e89a8fb1f72c5bb97904ccc430f5-- From paul.hoffman@vpnc.org Tue Oct 23 19:02:17 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D4411E811F for ; Tue, 23 Oct 2012 19:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN6Lyx4kR3Sx for ; Tue, 23 Oct 2012 19:02:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id EE6D111E80E9 for ; Tue, 23 Oct 2012 19:02:16 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9O22CNF076474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Oct 2012 19:02:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Tue, 23 Oct 2012 19:02:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1499) Cc: "therightkey@ietf.org" Subject: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 02:02:17 -0000 [[ I changed the subject line because this should be discussed on the = list *before* the meeting. It is not a separate agenda item, yet. ]] On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker = wrote: > One of the key issues as far as acceptability to CAs is concerned is = impact on issue processes. In particular it has to be possible to deploy = any experimental infrastructure without touching the certificate issue = code. >=20 > I think this is going to mean that CT proofs have to end up being = embedded in something other than the cert they relate to. I can't see = the precert idea as viable. Transporting the CT proofs in OCSP is viable = though - provided some changes are made there. >=20 From benl@google.com Wed Oct 24 03:18:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A620E21F8941 for ; Wed, 24 Oct 2012 03:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlsZQwuSpUyC for ; Wed, 24 Oct 2012 03:18:25 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 93C8D21F8B86 for ; Wed, 24 Oct 2012 03:18:24 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so262677wib.13 for ; Wed, 24 Oct 2012 03:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=9/XZS1JGLC7UQF8EtFgT5Kkw0DD5Lv7N1DX6K3Wi12Y=; b=CYSSN8pChFhXv20h5O1mTBWmWW+adNmLhT7kZSexl0dAOpuRa9eYuc1mw+BC7J45L3 eOuk7u4qwECC3XSQSVCC2NZPo/bC2Ls4HS+42+pJCYnUS0chYIiEoRlsDg5cjGM42VrY TKRkIFn97hkP+Jvv/bbn7XLqRCBQg0hQXQ0Y1CvQkWwYCu6vu7pOI+IdYzfU4qsy7Ifs pIVUTyR4HMVnA7QrUt5mW4Y6OWbf102iwuczcBm7QGm1DgJ4VBfT8+j2eJimwrN0qtmo Xn4+YOOzDv6hKYhzEEaTzFgZBn/lgLWMcsxi6R/iCdWT1OSs6Oz/QvKHAVS3vuWqWVHc f/iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=9/XZS1JGLC7UQF8EtFgT5Kkw0DD5Lv7N1DX6K3Wi12Y=; b=FMl+MFkwvkTdyE9te789OJrnbN1TZtc3FadDdiag39sBEKB00ZowJLksfANkwNwsMU QxxzdDbdISjzxx57PdmYbs5OXS9/DBHSaX+LdyBHBIEDFVLRBz8fOMKomD8fGfF/24iz S4s9aPebdmmHTih9TvjYmCTytz8sqbjlrshrIIVGVeAQ91POjwFFfqjLhQWZKrOy3rxW CtmCt1tSHge4CBhY5TgK9DvQ/n3n+SN1riKkPWuFhVT8cflCjMcPLnRWvk3dpzcqMT0b M1FpGAdkCU2nEoOdQzvHN1ya+Oi05f0biDCf3Re6eqvlEl3AB57aJJJAo1Ikjx690fHa Gr8Q== MIME-Version: 1.0 Received: by 10.216.140.205 with SMTP id e55mr8813566wej.2.1351073899091; Wed, 24 Oct 2012 03:18:19 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Wed, 24 Oct 2012 03:18:19 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> Date: Wed, 24 Oct 2012 11:18:19 +0100 Message-ID: From: Ben Laurie To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnxg9fAe4J1I6Ft0PxesTk8QSK3jSy8KpA5rKjgo2WgMHi+mFOgb7g/ZQZ4wNxVl2+ilws8Shnp7u1t4DwCeYST4s4EOxshs+MTplh9q2uoF5pxJxY4Fw5A2+rEExJzP8n0p6Xk0PHnTKBv9BoCsyMjhfbwQG8rEYrHAtIIPD91oHiR6iA1nBwKDl6bAhMUC2cXfIHb Cc: "therightkey@ietf.org" , Phillip Hallam-Baker Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 10:18:25 -0000 On 24 October 2012 03:02, Paul Hoffman wrote: > [[ I changed the subject line because this should be discussed on the lis= t *before* the meeting. It is not a separate agenda item, yet. ]] > > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker wrot= e: > >> One of the key issues as far as acceptability to CAs is concerned is imp= act on issue processes. In particular it has to be possible to deploy any e= xperimental infrastructure without touching the certificate issue code. What? Why? Are you saying CAs can't test modified issuance code? >> I think this is going to mean that CT proofs have to end up being embedd= ed in something other than the cert they relate to. I can't see the precert= idea as viable. Transporting the CT proofs in OCSP is viable though - prov= ided some changes are made there. What changes? >> > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From hallam@gmail.com Wed Oct 24 04:17:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E2C21F86C9 for ; Wed, 24 Oct 2012 04:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.882 X-Spam-Level: X-Spam-Status: No, score=-3.882 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30NMHUugkZ-4 for ; Wed, 24 Oct 2012 04:17:00 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E264321F86BE for ; Wed, 24 Oct 2012 04:16:59 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so383986obq.31 for ; Wed, 24 Oct 2012 04:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PFURJesgEdzVbNoyPpCI6vRAFqcjlfM6VDbsxSRCjdw=; b=i0YwECG80FY2UK/TbdbuwhNUfGERJ5yuf2hAB0QTLQAeoRYe/mYxFWqo4RkI5YjKpY OcLw0vxjw0Sm34zki8r/hvoW0eRug1Ht81Hjp+rw3WRwpxOtKXF0sJtpLCgKVPfJbGvq coz23UPnSVtzMjgF0V0LeKzSlKuEFBPVDkkCmjvw6HNSw6VOsRh4b4nc+QThfSxyxQO5 wyB0T8KVxmxL3oR5ebjUDc7eCgAYI3Fn9koxwoSm2d23O5mfYxMtJjQdpiAvrOx7UHk+ lO/HnJbfwexu9q0R+lg2EbCg9YzQEQ8vdnJzng5lZJ5F4ozOLctA/ZmoasY3g8t65nRa 9NFw== MIME-Version: 1.0 Received: by 10.60.19.168 with SMTP id g8mr10990364oee.101.1351077419476; Wed, 24 Oct 2012 04:16:59 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Wed, 24 Oct 2012 04:16:59 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> Date: Wed, 24 Oct 2012 07:16:59 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8fb2062ca6e5a504cccc39f5 Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:17:01 -0000 --e89a8fb2062ca6e5a504cccc39f5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie wrote: > On 24 October 2012 03:02, Paul Hoffman wrote: > > [[ I changed the subject line because this should be discussed on the > list *before* the meeting. It is not a separate agenda item, yet. ]] > > > > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker > wrote: > > > >> One of the key issues as far as acceptability to CAs is concerned is > impact on issue processes. In particular it has to be possible to deploy > any experimental infrastructure without touching the certificate issue code. > > What? Why? Are you saying CAs can't test modified issuance code? Proposing to change that code is like you proposing to change the Google search algorithm to make CT work. Just not going to happen. That is an audited system. It has a very complex and elaborate QA. It extends across the resellers that take the orders and the CA issue center. If CT had been proposed twenty years ago it might be viable to put the proof in the cert. Any change now has to work around the existing infrastructure. -- Website: http://hallambaker.com/ --e89a8fb2062ca6e5a504cccc39f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 24, 2012 at 6:18 AM, Ben Lau= rie <benl@google.com> wrote:
On 24 October 2012 03:02, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> [[ I changed the subject line because this should be discussed on the = list *before* the meeting. It is not a separate agenda item, yet. ]]
>
> On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
>> One of the key issues as far as acceptability to CAs is concerned = is impact on issue processes. In particular it has to be possible to deploy= any experimental infrastructure without touching the certificate issue cod= e.

What? Why? Are you saying CAs can't test modified issuance code?<= /blockquote>

Proposing to change that code is like you p= roposing to change the Google search algorithm to make CT work. Just not go= ing to happen.

That is an audited system. It has a very complex and el= aborate QA. It extends across the resellers that take the orders and the CA= issue center.

If CT had been proposed twenty year= s ago it might be viable to put the proof in the cert. Any change now has t= o work around the existing infrastructure.



--
Website: http://hallambaker.com/

--e89a8fb2062ca6e5a504cccc39f5-- From rob.stradling@comodo.com Wed Oct 24 04:25:29 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5296921F89F4 for ; Wed, 24 Oct 2012 04:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV4YTwfdWipF for ; Wed, 24 Oct 2012 04:25:28 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5F37621F8A07 for ; Wed, 24 Oct 2012 04:25:28 -0700 (PDT) Received: (qmail 28296 invoked from network); 24 Oct 2012 11:25:26 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 24 Oct 2012 11:25:26 -0000 Received: (qmail 13800 invoked by uid 1000); 24 Oct 2012 11:25:26 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 24 Oct 2012 12:25:26 +0100 Message-ID: <5087D030.1010100@comodo.com> Date: Wed, 24 Oct 2012 12:25:36 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Ben Laurie , Paul Hoffman Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:25:29 -0000 On 24/10/12 12:16, Phillip Hallam-Baker wrote: > > On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie > wrote: > > On 24 October 2012 03:02, Paul Hoffman > wrote: > > [[ I changed the subject line because this should be discussed on > the list *before* the meeting. It is not a separate agenda item, yet. ]] > > > > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker > > wrote: > > > >> One of the key issues as far as acceptability to CAs is > concerned is impact on issue processes. In particular it has to be > possible to deploy any experimental infrastructure without touching > the certificate issue code. > > What? Why? Are you saying CAs can't test modified issuance code? > > Proposing to change that code is like you proposing to change the Google > search algorithm to make CT work. Just not going to happen. > > That is an audited system. It has a very complex and elaborate QA. It > extends across the resellers that take the orders and the CA issue center. > > If CT had been proposed twenty years ago it might be viable to put the > proof in the cert. Any change now has to work around the existing > infrastructure. FWIW, as lead developer of Comodo's issuance code and as one of the first people to propose both the pre-cert idea [1] and the idea of embedding CT proofs in OCSP Responses [2], I intend to seek permission from Comodo Management to implement both. They might say "no", of course. ;-) [1] http://www.ietf.org/mail-archive/web/pkix/current/msg30146.html [2] Message posted to the non-public CABForum list on 5th April 2012. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From benl@google.com Wed Oct 24 04:28:47 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A739E21F8A34 for ; Wed, 24 Oct 2012 04:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTJawjC12uv6 for ; Wed, 24 Oct 2012 04:28:47 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC15F21F89F4 for ; Wed, 24 Oct 2012 04:28:46 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so3917049wib.13 for ; Wed, 24 Oct 2012 04:28: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:x-system-of-record; bh=meQ0TEDgHBKudcsVHnLEH2RXCMq4YxAS92zADHci57w=; b=DoU22tlGtZXJHG5z+1p+LoWjJcyLMGdi8Etavdm0TZR8+9DtwXcqaNqsaeQmELZ61C fSXItuu0wRsmGSyFC06G6SGvSlnNmQb7n8yhg1QvRmySlhyhfLqkjjaB7oQRvFl4cp+S ppemAbO70yhYAlyBxhCOkGu3kx1a1lJz81fPtSR5n/i6CyTsyM7IUJmHTp9tMS5QEzki cZL8Bd8moTeC4tIvbzkU7Dc6WOuIDKdTppcwThM25VVBd9OHtn/GBMe3f8KkUAYlzhgw 1Q83njS8klaGpmxxaGHZnXGC0Rjsnd8/NzUW1W+j4Rcm+1xOlApOQ2L29fbDV+Tngho1 Xuqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=meQ0TEDgHBKudcsVHnLEH2RXCMq4YxAS92zADHci57w=; b=gteDKZ80E3zE3kpRGf03MLk7JpYxF0jm3jMp69RsiGyVAft/ntNKtdbg/uycOigwzE YrmIrQ7HR4WMo74k0B6j+F1tEuNRl+BhDodEVx+82xi5WqFYOdM3A638TQ6lhX6SQKsG m9qgmgMjNtN35my2qFhCRmRaIkL1Luu2o8ubcZZbmlUrY40/Gs3QVGUGc9wHSnyQcPAO 8EMtDhyDY9oCh+UE+p+PMnc7gNgSQSwEKUKYIgo6mH5XuTjWynZewLNuAHwwO7q9L199 RK6RWRf+LAoTEnLmYCHuXBBgRiqcMrTyKdBBXZKrrolrqsF2EQeMDPH/Le50jNYnrrfw GvVg== MIME-Version: 1.0 Received: by 10.216.136.23 with SMTP id v23mr9474265wei.45.1351078126068; Wed, 24 Oct 2012 04:28:46 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Wed, 24 Oct 2012 04:28:45 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> Date: Wed, 24 Oct 2012 12:28:45 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlF18G8+GqElwGQrEnC79aCfFM71/sSL84o8KsnOC7hrsj/Fc6IhvVccbvuOThzOfGsSA4CeWOMVzuVlciVGn0WbnVYLbOyif7pkUCX627YkRICDrQMqlYFL83eptmPo7izb022aexP3xMJ1MXO4lc91RxVnfpphXoz8ihAZnWbwj0QECoY4zCUQobYltcEQX2+X6wj Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 11:28:47 -0000 On 24 October 2012 12:16, Phillip Hallam-Baker wrote: > > > On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie wrote: >> >> On 24 October 2012 03:02, Paul Hoffman wrote: >> > [[ I changed the subject line because this should be discussed on the >> > list *before* the meeting. It is not a separate agenda item, yet. ]] >> > >> > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker >> > wrote: >> > >> >> One of the key issues as far as acceptability to CAs is concerned is >> >> impact on issue processes. In particular it has to be possible to deploy any >> >> experimental infrastructure without touching the certificate issue code. >> >> What? Why? Are you saying CAs can't test modified issuance code? > > > Proposing to change that code is like you proposing to change the Google > search algorithm to make CT work. Just not going to happen. That is not what I've heard from others. > That is an audited system. It has a very complex and elaborate QA. It > extends across the resellers that take the orders and the CA issue center. > > If CT had been proposed twenty years ago it might be viable to put the proof > in the cert. Any change now has to work around the existing infrastructure. If your infrastructure can't cope, fine, put it in OCSP, or in a TLS extension. I don't believe all CAs are unable to modify their software. From benl@google.com Wed Oct 24 05:02:01 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB2021F8B7E for ; Wed, 24 Oct 2012 05:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBDDvv1jRoKl for ; Wed, 24 Oct 2012 05:02:00 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1A621F89A8 for ; Wed, 24 Oct 2012 05:01:59 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so4176616wib.1 for ; Wed, 24 Oct 2012 05:01: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:x-system-of-record; bh=G30NHEi2v/vz+d+U5D9klJ02/m9kQ7Ed8lMbhVYdb30=; b=XTgB0spRB2U1EHr8FZSvfmx1vPNmoMl3i1Y0lejb8DDVH9yKoYA1ANAF2GACfGtAZK HNobdcqJ0G3rMxRqNp8RlryBZGVUmvnBuRroqu8bBBBgxQhBHiLc+sM34peweGtnXHMp fQ5hIqNT9FLM4b/OH8OuKuRugZ1kfoxkblMT/0OeyicJemD32NF6eCzcu2sGJHAW1TbF cqh9x3EqA0L8p3E2HsKDDKI0vf/LthfT29pyd60tUtXunQjmRooh6o9Qe119EyFQG7Dr a5Jkt+kHULBgqksdHEp1KK6ZuW366vm7VT9qbSwldNH6ryJEnxX4ucFvWiFeBIz/VquK fB/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=G30NHEi2v/vz+d+U5D9klJ02/m9kQ7Ed8lMbhVYdb30=; b=MO8wDQ+ZlnYizK0q86Ece7yB0xun0SYTXXAOof3R0RsrYtgXgkVEOzeAVa9toIAC/K /qLawpWowYTGbdMU2PxrclF7h9F5Ci67JQ/NqcAEXSbkrAJ8AKJ2mvbpBX6nOt0+Bm3D fYotV4El6kw6TyTxdj/IXI3De/IWmVVhW3ZjsxHa3ZF0FOKnrm41R0VKwoVTiOYVkR7c LT5Kh/VrEZfJsauNv1gQvk0zrb4rh6j8ZoqMdAA8x1sao8cTnRInfM3Ga6qx3bkEZQvP ouSpvEnYzvsPucpMe7W0XfxjrFeH8FJTNX1lyWD5ht/1hLJnkcrQPEOv5TWPBTwlUA4R zPXg== MIME-Version: 1.0 Received: by 10.216.140.205 with SMTP id e55mr8978936wej.2.1351080119105; Wed, 24 Oct 2012 05:01:59 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Wed, 24 Oct 2012 05:01:59 -0700 (PDT) In-Reply-To: <5087D030.1010100@comodo.com> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <5087D030.1010100@comodo.com> Date: Wed, 24 Oct 2012 13:01:59 +0100 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQldyMAmHi3PJWnLiyHFtRJOl4RvF0X3GXnm7Cyvyabm8uQsyz/3ZixYpVg3FVzUCFwJWozDMpn4do4G/BXYuE0Oj7C6J0KJk+Dq3WSEUHAM+ZPgXs9qp/ku+usxt7Uuo3EMww7euoQ7t9ofT99DiCA+H0mcSYkz1HfS9yQ4f6Z09znFLCO6CnHyRhbqu52VeSyzsN1K Cc: "therightkey@ietf.org" , Phillip Hallam-Baker , Paul Hoffman Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 12:02:01 -0000 On 24 October 2012 12:25, Rob Stradling wrote: > On 24/10/12 12:16, Phillip Hallam-Baker wrote: >> >> >> On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie > > wrote: >> >> On 24 October 2012 03:02, Paul Hoffman > > wrote: >> > [[ I changed the subject line because this should be discussed on >> the list *before* the meeting. It is not a separate agenda item, yet. >> ]] >> > >> > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker >> > wrote: >> > >> >> One of the key issues as far as acceptability to CAs is >> concerned is impact on issue processes. In particular it has to be >> possible to deploy any experimental infrastructure without touching >> the certificate issue code. >> >> What? Why? Are you saying CAs can't test modified issuance code? >> >> Proposing to change that code is like you proposing to change the Google >> search algorithm to make CT work. Just not going to happen. >> >> That is an audited system. It has a very complex and elaborate QA. It >> extends across the resellers that take the orders and the CA issue center. >> >> If CT had been proposed twenty years ago it might be viable to put the >> proof in the cert. Any change now has to work around the existing >> infrastructure. > > > FWIW, as lead developer of Comodo's issuance code and as one of the first > people to propose both the pre-cert idea [1] and the idea of embedding CT > proofs in OCSP Responses [2], I intend to seek permission from Comodo > Management to implement both. They might say "no", of course. ;-) Good to hear. We now have a test log server up, so any time you're ready :-) > [1] http://www.ietf.org/mail-archive/web/pkix/current/msg30146.html > [2] Message posted to the non-public CABForum list on 5th April 2012. > > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online From hallam@gmail.com Wed Oct 24 05:53:24 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA18021F8B91 for ; Wed, 24 Oct 2012 05:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.879 X-Spam-Level: X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7a4VhWcxLGb for ; Wed, 24 Oct 2012 05:53:22 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D41A821F8B9D for ; Wed, 24 Oct 2012 05:53:20 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so477791obq.31 for ; Wed, 24 Oct 2012 05:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yhIvTX7NuZa+s+hu61bAGHc1pDSA7OJ1CyjmZqyu8ig=; b=EifqltYLoJuaGrx3k1n21SDRvXnv86IBCK7H0Tr2eTf6L0ObxBKwnMSYTxUX3J+XBv fZAgk773oWOuw+yB3078iM4Q4e1s5txdnH44m7jOTdPsaQxO1SYQls3/2Z9qQwBWPQvi kXUU4njS14PwJatNG6NKbwNXUu5NOx/1sbCnNTI/z1hR/N/Pw6j7eJrXbChGaCqSYrAp V5LhQ2bCYdY6w0rUOAPt7a3o3g81gYkPiM++XLdGtrSZGN8prFlK3X2Uelac1qPBbE2M qGr6XUweKrlpuCzyNqoQDWKgIX6QoOBJ195QpIiwGXS5cF/AmrEYqKPkD6HCfZatUHjp b8BA== MIME-Version: 1.0 Received: by 10.182.152.97 with SMTP id ux1mr12764219obb.13.1351083190083; Wed, 24 Oct 2012 05:53:10 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Wed, 24 Oct 2012 05:53:10 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> Date: Wed, 24 Oct 2012 08:53:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=f46d04462c0a9b5f6104cccd912f Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 12:53:24 -0000 --f46d04462c0a9b5f6104cccd912f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 24, 2012 at 7:28 AM, Ben Laurie wrote: > On 24 October 2012 12:16, Phillip Hallam-Baker wrote: > > > > > > On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie wrote: > >> > >> On 24 October 2012 03:02, Paul Hoffman wrote: > >> > [[ I changed the subject line because this should be discussed on the > >> > list *before* the meeting. It is not a separate agenda item, yet. ]] > >> > > >> > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker > >> > wrote: > >> > > >> >> One of the key issues as far as acceptability to CAs is concerned is > >> >> impact on issue processes. In particular it has to be possible to > deploy any > >> >> experimental infrastructure without touching the certificate issue > code. > >> > >> What? Why? Are you saying CAs can't test modified issuance code? > > > > > > Proposing to change that code is like you proposing to change the Google > > search algorithm to make CT work. Just not going to happen. > > That is not what I've heard from others. Hey, I am not trying to be obstructionist here, just trying to avoid the pitfalls of previous efforts. CT itself is going to be the easy part. The devil is all going to be in the deployment. Other than Comodo and Symantec, how many CAs have a programmer on staff? > That is an audited system. It has a very complex and elaborate QA. It > > extends across the resellers that take the orders and the CA issue > center. > > > > If CT had been proposed twenty years ago it might be viable to put the > proof > > in the cert. Any change now has to work around the existing > infrastructure. > > If your infrastructure can't cope, fine, put it in OCSP, or in a TLS > extension. I don't believe all CAs are unable to modify their > software. > I think it is going to be very hard to get CAs to commit unless there is a general consensus that the other CAs will also commit. Also there is a technical cost and a political cost of making a change. IETF has a tendency to focus only on the technical cost which depends on the extent of the changes and so prefers incremental improvements that are stand alone. But the political cost tends to be more a matter of deciding to do something different and the advantage of doing it. If the political cost is the blocking factor then you will do better with one big request than a series of small ones. -- Website: http://hallambaker.com/ --f46d04462c0a9b5f6104cccd912f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 24, 2012 at 7:28 AM, Ben Lau= rie <benl@google.com> wrote:
On 24 October 2012 12:16, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
>
> On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie <benl@google.com> wrote:
>>
>> On 24 October 2012 03:02, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>> > [[ I changed the subject line because this should be discusse= d on the
>> > list *before* the meeting. It is not a separate agenda item, = yet. ]]
>> >
>> > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker <hallam@gmail.com>
>> > wrote:
>> >
>> >> One of the key issues as far as acceptability to CAs is c= oncerned is
>> >> impact on issue processes. In particular it has to be pos= sible to deploy any
>> >> experimental infrastructure without touching the certific= ate issue code.
>>
>> What? Why? Are you saying CAs can't test modified issuance cod= e?
>
>
> Proposing to change that code is like you proposing to change the Goog= le
> search algorithm to make CT work. Just not going to happen.

That is not what I've heard from others.

Hey, I am not trying to be obstructionist here, just trying to avoi= d the pitfalls of previous efforts. CT itself is going to be the easy part.= The devil is all going to be in the deployment.

Other than Comodo and Symantec, how many CAs have a pro= grammer on staff?

=A0

> That is an audited system. It has a very complex and elaborate QA. It<= br> > extends across the resellers that take the orders and the CA issue cen= ter.
>
> If CT had been proposed twenty years ago it might be viable to put the= proof
> in the cert. Any change now has to work around the existing infrastruc= ture.

If your infrastructure can't cope, fine, put it in OCSP, or in a = TLS
extension. I don't believe all CAs are unable to modify their
software.

I think it is going to be very hard to get CAs to co= mmit unless there is a general consensus that the other CAs will also commi= t.=A0

Also there is a technical cost and a political cos= t of making a change. IETF has a tendency to focus only on the technical co= st which depends on the extent of the changes and so prefers incremental im= provements that are stand alone. But the political cost tends to be more a = matter of deciding to do something different and the advantage of doing it.= If the political cost is the blocking factor then you will do better with = one big request than a series of small ones.

--f46d04462c0a9b5f6104cccd912f-- From eabalea@gmail.com Wed Oct 24 06:18:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C2E21F8B7C for ; Wed, 24 Oct 2012 06:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA5lOS3lJW-H for ; Wed, 24 Oct 2012 06:18:06 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 271B721F8B71 for ; Wed, 24 Oct 2012 06:18:05 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1190975lbo.31 for ; Wed, 24 Oct 2012 06:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3wSHK4hGD9l+jdLjnoKh4tBD++TZ5j6COCaUYCKzA9o=; b=QC5+2qrni24blS6nvKCZjlYoCzBS8cmARGOkxVL+OnGRiA5TEJSjDkJR9g48mY6Ue8 qgm8svjuX6T4HZINoWuItbrmLbb209aKozAdTMes4E+7+ZVDprVsBdTiXbB8DnbkWI9K 7q1OuwbGHHYYDBVyU/G+8TVORal5guYuqULgl6ONSccZH7ECtaijAR2A/WhBqss+FQ0B Fyw8jNFNLzziz29nFWObX8xrKPSBPG0fnzSp/pgbOWaFVzjAH+8KSY5rNVtjqCd4UPjM QW7ZGe+Uf/OR3FQysAq4pZKBi5Gd8DoovdNKMfCmUzbfsXbkcUKMKqLC1iYLNkPrBQ5v y3SQ== MIME-Version: 1.0 Received: by 10.152.123.103 with SMTP id lz7mr14311656lab.21.1351084685023; Wed, 24 Oct 2012 06:18:05 -0700 (PDT) Received: by 10.114.25.74 with HTTP; Wed, 24 Oct 2012 06:18:04 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> Date: Wed, 24 Oct 2012 15:18:04 +0200 Message-ID: From: Erwann Abalea To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=f46d042ef447b6583c04cccdea05 Cc: "therightkey@ietf.org" , Ben Laurie , Paul Hoffman Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 13:18:07 -0000 --f46d042ef447b6583c04cccdea05 Content-Type: text/plain; charset=UTF-8 2012/10/24 Phillip Hallam-Baker > > On Wed, Oct 24, 2012 at 7:28 AM, Ben Laurie wrote: > >> On 24 October 2012 12:16, Phillip Hallam-Baker wrote: >> > >> > On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie wrote: >> >> >> >> On 24 October 2012 03:02, Paul Hoffman wrote: >> >> > [[ I changed the subject line because this should be discussed on the >> >> > list *before* the meeting. It is not a separate agenda item, yet. ]] >> >> > >> >> > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker >> >> > wrote: >> >> > >> >> >> One of the key issues as far as acceptability to CAs is concerned is >> >> >> impact on issue processes. In particular it has to be possible to >> deploy any >> >> >> experimental infrastructure without touching the certificate issue >> code. >> >> >> >> What? Why? Are you saying CAs can't test modified issuance code? >> > >> > Proposing to change that code is like you proposing to change the Google >> > search algorithm to make CT work. Just not going to happen. >> >> That is not what I've heard from others. > > > Hey, I am not trying to be obstructionist here, just trying to avoid the > pitfalls of previous efforts. CT itself is going to be the easy part. The > devil is all going to be in the deployment. > > Other than Comodo and Symantec, how many CAs have a programmer on staff? > (Keynectis) I'd like to. Not just as a CA, but also as a log holder. I can only fly over it for now, though. Frustration. And we also have deployment constraints, certification constraints (CC EAL4+ and local ones), and a lot of customers to satisfy. > That is an audited system. It has a very complex and elaborate QA. It >> > extends across the resellers that take the orders and the CA issue >> center. >> > >> > If CT had been proposed twenty years ago it might be viable to put the >> proof >> > in the cert. Any change now has to work around the existing >> infrastructure. >> >> If your infrastructure can't cope, fine, put it in OCSP, or in a TLS >> extension. I don't believe all CAs are unable to modify their >> software. >> > > I think it is going to be very hard to get CAs to commit unless there is a > general consensus that the other CAs will also commit. Agreed. > Also there is a technical cost and a political cost of making a change. > IETF has a tendency to focus only on the technical cost which depends on > the extent of the changes and so prefers incremental improvements that are > stand alone. But the political cost tends to be more a matter of deciding > to do something different and the advantage of doing it. If the political > cost is the blocking factor then you will do better with one big request > than a series of small ones. > That's when IETF considers costs at all... -- Erwann. --f46d042ef447b6583c04cccdea05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2012/10/24 Phillip Hallam-Baker <hallam@gmai= l.com>

On Wed, Oct 24, 2012 at 7:= 28 AM, Ben Laurie <benl@google.com> wrote:
On 24 October 2012 12:16, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
> On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie <benl@google.com> wrote:
>>
>> On 24 October 2012 03:02, Paul Hoffman <paul.hoffman@vpnc.org> wrote: >> > [[ I changed the subject line because this should be discusse= d on the
>> > list *before* the meeting. It is not a separate agenda item, = yet. ]]
>> >
>> > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker <hallam@gmail.com>
>> > wrote:
>> >
>> >> One of the key issues as far as acceptability to CAs is c= oncerned is
>> >> impact on issue processes. In particular it has to be pos= sible to deploy any
>> >> experimental infrastructure without touching the certific= ate issue code.
>>
>> What? Why? Are you saying CAs can't test modified issuance cod= e?
>
> Proposing to change that code is like you proposing to change the Goog= le
> search algorithm to make CT work. Just not going to happen.

That is not what I've heard from others.

Hey, I am not trying to be obstructionist here, just trying t= o avoid the pitfalls of previous efforts. CT itself is going to be the easy= part. The devil is all going to be in the deployment.

Other than Comodo and Symantec, how many CAs have a pro= grammer on staff?

(Keynectis) I= 'd like to. Not just as a CA, but also as a log holder. I can only fly = over it for now, though. Frustration.
And we also have deployment constraints, certification constraints (CC= EAL4+ and local ones), and a lot of customers to satisfy.

> That is an audited system. It has a very complex and elaborate Q= A. It
> extends across the resellers that take the orders and the CA issue cen= ter.
>
> If CT had been proposed twenty years ago it might be viable to put the= proof
> in the cert. Any change now has to work around the existing infrastruc= ture.

If your infrastructure can't cope, fine, put it in OCSP, or in a = TLS
extension. I don't believe all CAs are unable to modify their
software.

I think it is going to be very hard to get CAs= to commit unless there is a general consensus that the other CAs will also= commit.=C2=A0

Agreed.
=C2=A0
Also there is a technical cost and a political cost of making a change= . IETF has a tendency to focus only on the technical cost which depends on = the extent of the changes and so prefers incremental improvements that are = stand alone. But the political cost tends to be more a matter of deciding t= o do something different and the advantage of doing it. If the political co= st is the blocking factor then you will do better with one big request than= a series of small ones.

That's when IETF considers costs= at all...

--
Erwann.
--f46d042ef447b6583c04cccdea05-- From Rick_Andrews@symantec.com Wed Oct 24 10:09:42 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494F921F86E8 for ; Wed, 24 Oct 2012 10:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHHrp5SJwvN0 for ; Wed, 24 Oct 2012 10:09:41 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAE321F85ED for ; Wed, 24 Oct 2012 10:09:41 -0700 (PDT) X-AuditID: d80ac3f3-b7fa26d000007166-f5-508820d40a28 Received: from tus1smtintpin01.ges.symantec.com (tus1smtintpin01.ges.symantec.com [192.168.215.101]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id 72.AA.29030.4D028805; Wed, 24 Oct 2012 17:09:40 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1TR4Sa-0000el-Mf; Wed, 24 Oct 2012 17:09:40 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Wed, 24 Oct 2012 10:09:37 -0700 From: Rick Andrews To: Ben Laurie , Phillip Hallam-Baker Date: Wed, 24 Oct 2012 10:09:36 -0700 Thread-Topic: [therightkey] Impact on issue processes Thread-Index: Ac2x2r7AeaVSnyZPSLaXbGG2Cak4nAALSFew Message-ID: <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsVyYMX1VN0rCh0BBps/GVps+HyNzeLq8uNM FrfWf2G1+HjhJ4sDi8fOWXfZPRZsKvVYsuQnk8fn2VeZA1iiuGxSUnMyy1KL9O0SuDJ2XJnB UtAkWtG8YwVTA+NRgS5GTg4JAROJLzs2MkLYYhIX7q1n62Lk4hAS+Mgo8e3yVHYI5xWjxJvP v1ggnFWMEstaD4K1sAnoSWx5fIUdxBYR8JTYNOc+C4jNLBApsWRDPyuIzSKgKjHt4HwmEFsY aN3OCW9YIepNJfZd6WKGsI0k3m2cAzaHVyBK4mPTOahlz1gkzqw5DVbEKRAocWzqdTYQmxHo 1u+n1jBBLBOXuPUEYoGEgIDEkj3nmSFsUYmXj/+xQtSLStxpX88IUa8jsWD3JzYIW1ti2cLX zBCLBSVOznzCMoFRfBaSsbOQtMxC0jILScsCRpZVjDIlpcWGxbkl+aUlBakVBsZ6xZW5icBo TNZLzs/dxAiMyBtchz/vYFz4Q/8QowAHoxIP7xpgpAqxJpYBVR5ilOBgVhLhnfygPUCINyWx siq1KD++qDQntfgQozQHi5I4r6BTdICQQHpiSWp2ampBahFMlomDU6qBcSpH3uNJTXI1TQ+T BWwt2D74mqppf87Z3LfnKIfE56LEr+fcnt9sPfm7+20ps6V9R2jZwgVnF2553PArbQqL/EPW VxLOuc5bgkUCSl4JOIqZWx5hWbp4q5Kw7vMbEyx/+3v9u/DnGWtR2fOiF68qFa6bR8RbPmrq qFsXf3M213ohrW/fdinnK7EUZyQaajEXFScCAAGoHIzEAgAA Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 17:09:42 -0000 > -----Original Message----- > From: therightkey-bounces@ietf.org [mailto:therightkey- > bounces@ietf.org] On Behalf Of Ben Laurie > Sent: Wednesday, October 24, 2012 4:29 AM > To: Phillip Hallam-Baker > Cc: therightkey@ietf.org; Paul Hoffman > Subject: Re: [therightkey] Impact on issue processes >=20 > On 24 October 2012 12:16, Phillip Hallam-Baker > wrote: > > > > > > On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie wrote: > >> > >> On 24 October 2012 03:02, Paul Hoffman > wrote: > >> > [[ I changed the subject line because this should be discussed on > the > >> > list *before* the meeting. It is not a separate agenda item, yet. > ]] > >> > > >> > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker > > >> > wrote: > >> > > >> >> One of the key issues as far as acceptability to CAs is concerned > is > >> >> impact on issue processes. In particular it has to be possible to > deploy any > >> >> experimental infrastructure without touching the certificate > issue code. > >> > >> What? Why? Are you saying CAs can't test modified issuance code? > > > > > > Proposing to change that code is like you proposing to change the > Google > > search algorithm to make CT work. Just not going to happen. >=20 > That is not what I've heard from others. > > > That is an audited system. It has a very complex and elaborate QA. It > > extends across the resellers that take the orders and the CA issue > center. > > > > If CT had been proposed twenty years ago it might be viable to put > the proof > > in the cert. Any change now has to work around the existing > infrastructure. >=20 > If your infrastructure can't cope, fine, put it in OCSP, or in a TLS > extension. I don't believe all CAs are unable to modify their > software. It's not a question of being unable to modify our software. As a representa= tive of Symantec, I will tell you that modifying our issuance code will be = a very tough sell, for a number of reasons: - There's no obvious direct return on investment - For some types of certificates, speed of issuance is very important. Get= ting a CT proof will slow this down and cause it to fail if the log server = isn't up 100% of the time. - It makes sense to avoid relying on external parties to fulfill part of o= ur cert issuance process. At this point, it's unclear who would even host a= log service, what SLA they would provide, how much attention they would pa= y to performance and availability, disaster recovery, etc. - Symantec would not be interested in hosting a log service because of unc= lear ROI. -Rick From mrex@sap.com Wed Oct 24 17:46:02 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FBA21F8F23 for ; Wed, 24 Oct 2012 17:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.213 X-Spam-Level: X-Spam-Status: No, score=-10.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMBgQnJnajvQ for ; Wed, 24 Oct 2012 17:46:01 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1183D21F8C43 for ; Wed, 24 Oct 2012 17:46:00 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q9P0jxef029207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 25 Oct 2012 02:45:59 +0200 (MEST) In-Reply-To: To: Paul Wouters Date: Thu, 25 Oct 2012 02:45:58 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121025004558.DD8FA1A2F3@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "therightkey@ietf.org" , Gervase Markham , Rick Andrews Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 00:46:02 -0000 Paul Wouters wrote: > > Gervase Markham wrote: > >> Paul Wouters wrote: >>> >>> Maintaining TLS certificates actually becomes _easier_, because people >>> don't have to frantically read the openssl man page to generate a new >>> certificate when the old one suddenly expired without anyone noticing >>> before the complains hit the help desk. >> >> They have to read other documentation about how to update their DNS >> instead... > > No they do not. Because there is no _expiry date_. By being in the TLSA > record in DNS, it is self-declared valid. No mysterious outages in 1 or > 2 years from now when the certificat expired and the original guy who > know the openssl commandline left the company. This will still happen if the Web Server cert was issued with a validity of only one year. > > This is another reason for > TLS bare key certificates that just contain the bare public key as SBKI. > To get rid of that obsolete container information (and new CA invoice). > > Until those are common practise, define the certificate to be valid for > 100 years, and you should be good till retirement. Uh-oh, such a recommendation runs shivers down my spine and is seriously ignorant of the real world. Due to a uncounted numbers of bugs in software, some of which get published on a monthly schedule, TLS-enabled Servers may experience break-ins, and there is absolutely no indication that this is going to ever change. So rather than making the keys last forever, the objective should be to make rekeying (a) easy to perform by the staff and (b) performed with sufficient frequency so that it will be a no-brainer for staff to rekey after an alleged or verified security breaches on the server (e.g. the virus-scanner detected malware on the machine). -Martin From palmer@google.com Wed Oct 24 17:56:55 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC5721F86C7 for ; Wed, 24 Oct 2012 17:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4AMcNvJ+qhz for ; Wed, 24 Oct 2012 17:56:54 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA6A21F86C4 for ; Wed, 24 Oct 2012 17:56:53 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so860482lam.31 for ; Wed, 24 Oct 2012 17:56: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:content-transfer-encoding:x-system-of-record; bh=T0EfFbSTBjOogY0sKLWeQ71JxGjscyDJ0UGHc7nzLpg=; b=OwZRGKN7vo7CnsNh1ZR0dhxd2DSeOR2zVu2Xr9LJHhWO018vtWGjR2r3NDmW3VL0QU 5VNpjER5RLzDyNYwhDUIo6aGtlKLtAjcu4Ap6Kn7FI4YH4k0N9ZG37wyf6WJYmfLHIij FVqWvpVOiwRr6PMPyHXX/VdJnzgbHTqKuiV46gkrvpZkj25TU7sfmz+dhIgC7/vP9N9Y fQgKwPFrDUuVL5CbI9XCWbQfw7dMh345YZoJTn0ipCArXmaz6PXQEcVy3mPwYcgf1Dto cDTAAopzswuD7IG+OkU2AwULPuZ+zU9gzXg0ey1MKfkJeTdscsp8PSDaGy0ZNf1dT+i3 iV9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=T0EfFbSTBjOogY0sKLWeQ71JxGjscyDJ0UGHc7nzLpg=; b=BOtjdpQ2Vmp2C1nmLr8LHmXkdF6jUDcxNng5m5x7gMvfmL6nTvNI1xq3SmjNcDXUF5 l9RlNzfOvCKXzu943Ec20fi6Fd7TGFmq/QXkKgXjXsjIb9MmhclvD1jkhHTLh7mYw5Ep mg36f1xHYgnUrftbHtcTv7qoBDWJDoEgXF1Sw+CsvV7ttYzudZuckt/dg1w8HH7Xegt0 Xp9+OtgROvw7GPQ+N9VwGLkqXflEG4iQ9NoUt752/c3Rn6AZrxLVqRN9MTnzMZdsFPDl ZNBJ49S5JT8lgqyPVwAzI2LQZHLIRrLG1/xyFOf0C265HBDF5TuxhBO6ZZUfJT/tyJKY Cmhw== MIME-Version: 1.0 Received: by 10.152.146.101 with SMTP id tb5mr15697218lab.44.1351126612859; Wed, 24 Oct 2012 17:56:52 -0700 (PDT) Received: by 10.112.39.226 with HTTP; Wed, 24 Oct 2012 17:56:52 -0700 (PDT) In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Wed, 24 Oct 2012 17:56:52 -0700 Message-ID: From: Chris Palmer To: Rick Andrews Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQndtxcKFf0rvPs3gCgHMOp5KfFq50eZY65q75szFvxMDAzl/AwouQrZp4GzYkGKW3BeT9Ya9yBEXc6pekPMTXgPMvdMsR3VBba5+/Jl434ZoIGsC95jIdut7PFpinwfdKQt3VR94xToNTHRAXuDLR4moikXpTvcgINj5KzU8eoT6dyRBdx4zCPY+5wNA6mIHErZ8tO7 Cc: Phillip Hallam-Baker , "therightkey@ietf.org" , Ben Laurie , Paul Hoffman Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 00:56:55 -0000 On Wed, Oct 24, 2012 at 10:09 AM, Rick Andrews wrote: > It's not a question of being unable to modify our software. As a represen= tative of Symantec, I will tell you that modifying our issuance code will b= e a very tough sell, for a number of reasons: > - There's no obvious direct return on investment > - For some types of certificates, speed of issuance is very important. G= etting a CT proof will slow this down and cause it to fail if the log serve= r isn't up 100% of the time. > - It makes sense to avoid relying on external parties to fulfill part of= our cert issuance process. At this point, it's unclear who would even host= a log service, what SLA they would provide, how much attention they would = pay to performance and availability, disaster recovery, etc. > - Symantec would not be interested in hosting a log service because of u= nclear ROI. CT makes CAs less valuable targets. I'd call that ROI. From paul@nohats.ca Wed Oct 24 19:31:22 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68BF1F0C8B for ; Wed, 24 Oct 2012 19:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ISG5Svs3eS5 for ; Wed, 24 Oct 2012 19:31:22 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 717EB1F0C7E for ; Wed, 24 Oct 2012 19:31:22 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 83CE382B63; Wed, 24 Oct 2012 22:30:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 763F782B33; Wed, 24 Oct 2012 22:30:43 -0400 (EDT) Date: Wed, 24 Oct 2012 22:30:43 -0400 (EDT) From: Paul Wouters To: Martin Rex In-Reply-To: <20121025004558.DD8FA1A2F3@ld9781.wdf.sap.corp> Message-ID: References: <20121025004558.DD8FA1A2F3@ld9781.wdf.sap.corp> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "therightkey@ietf.org" , Gervase Markham , Rick Andrews Subject: Re: [therightkey] TLSA Cert. Usage X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 02:31:23 -0000 On Thu, 25 Oct 2012, Martin Rex wrote: > Due to a uncounted numbers of bugs in software, some of which get published > on a monthly schedule, TLS-enabled Servers may experience break-ins, > and there is absolutely no indication that this is going to ever change. So replace your TLSA record in DNS to point to the new certificate. The DNS is your OCSP/CRL/Revoke/Publish mechanism, but without the middle man delay and payments. > So rather than making the keys last forever Keys, using the SPKI certificate format, have no expiry date. They don't last forever, they last as long as the DNS backs them up. Paul From benl@google.com Thu Oct 25 02:10:09 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608AA21F899B for ; Thu, 25 Oct 2012 02:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.967 X-Spam-Level: X-Spam-Status: No, score=-102.967 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Tz5p+Ht859I for ; Thu, 25 Oct 2012 02:10:08 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBFE21F8997 for ; Thu, 25 Oct 2012 02:10:07 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1151969wib.13 for ; Thu, 25 Oct 2012 02:10: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:content-transfer-encoding:x-system-of-record; bh=AVF0k+aBWKv9G1Z0CoIxrUTrl2Wac+SM+pgYFv69yfA=; b=Ab8lt9WyQfYEp1M4U9pX9ZdA6rleiYYracs5a9PfXX+5iJzO1g3YFzNBGdf4Sm+3Wb e7gMi3As7sLZfMjvHne58nsgVhUIPHqIWfKgFljeLmRAfKrf9qfC1XHGjJ2Pf6SqC1Z4 OKGuQLp3BbYhX5vd2cJ7/POQ+JdMDJlWosOrkc5Hh6vlWi/6EECnJ5j6NNPEg30dMY5p UHj/LD/ApBPiIootbyVaYIgt+aM2GSv74wf1A38BSvYJ5JPWXhaPrc+MRc0bzI0PGlva oiC/877Xvr1Wox6iaTusexdzdU1IM64dRXNT/ouYkwOvIMucp8hcRfb+1Tc5VzjnAwJ1 cHQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=AVF0k+aBWKv9G1Z0CoIxrUTrl2Wac+SM+pgYFv69yfA=; b=WY4U/mTOn1IVhRTz6dUfOGa0qvL490IMzw+gOgpTEgouqXn1voXvAuqw40mas7VtWn c/X1Lkh2IcpfSaBeuSABB6ZoQ8f0hLT7tZzWzxUkNm6JvbKCrGuLiRYYIdkbrnBP9x8Y KIqtwthQ2a6pZHvb9UrmopRnCycczhcrQyD6ulGjg44ylyPrjI6j/TZOllEUxrQatnrp l1eP5DS5j3yU1wpT/BY1M+YQQeWvosp24LGqIRqq04y6ngNSPEQy86qdgV1YpbTuhiGz OiS4owqDYP20RPalvwAobghz6al1nzyl4H8v8UHq1b9ObPekZ/dpMu/Dy07XHYWa0/eE v4Bw== MIME-Version: 1.0 Received: by 10.216.136.23 with SMTP id v23mr11316333wei.45.1351156206943; Thu, 25 Oct 2012 02:10:06 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Thu, 25 Oct 2012 02:10:06 -0700 (PDT) In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Thu, 25 Oct 2012 10:10:06 +0100 Message-ID: From: Ben Laurie To: Rick Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkv/2kRktDlWGLWun8DgwjLCSXIlEWtOLZ8/h8cfbbSIGDtwqYmSVU8GrBJpDILO51WfSjXxDRxh3+7xxfMMZvzMMdxX9Ij3Z0qU5beRvWJ0mYqw1XO1Dia+Ify+2uYBpl5UHOBOhBL/i2jYpopUKWMsC5v1+DywF+Zy0My9zdgkbcw3wwcjCEcgFu7LSvFTLFt2nCp Cc: "therightkey@ietf.org" , Phillip Hallam-Baker , Paul Hoffman Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 09:10:09 -0000 On 24 October 2012 18:09, Rick Andrews wrote: >> -----Original Message----- >> From: therightkey-bounces@ietf.org [mailto:therightkey- >> bounces@ietf.org] On Behalf Of Ben Laurie >> Sent: Wednesday, October 24, 2012 4:29 AM >> To: Phillip Hallam-Baker >> Cc: therightkey@ietf.org; Paul Hoffman >> Subject: Re: [therightkey] Impact on issue processes >> >> On 24 October 2012 12:16, Phillip Hallam-Baker >> wrote: >> > >> > >> > On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie wrote: >> >> >> >> On 24 October 2012 03:02, Paul Hoffman >> wrote: >> >> > [[ I changed the subject line because this should be discussed on >> the >> >> > list *before* the meeting. It is not a separate agenda item, yet. >> ]] >> >> > >> >> > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker >> >> >> > wrote: >> >> > >> >> >> One of the key issues as far as acceptability to CAs is concerned >> is >> >> >> impact on issue processes. In particular it has to be possible to >> deploy any >> >> >> experimental infrastructure without touching the certificate >> issue code. >> >> >> >> What? Why? Are you saying CAs can't test modified issuance code? >> > >> > >> > Proposing to change that code is like you proposing to change the >> Google >> > search algorithm to make CT work. Just not going to happen. >> >> That is not what I've heard from others. >> >> > That is an audited system. It has a very complex and elaborate QA. It >> > extends across the resellers that take the orders and the CA issue >> center. >> > >> > If CT had been proposed twenty years ago it might be viable to put >> the proof >> > in the cert. Any change now has to work around the existing >> infrastructure. >> >> If your infrastructure can't cope, fine, put it in OCSP, or in a TLS >> extension. I don't believe all CAs are unable to modify their >> software. > > It's not a question of being unable to modify our software. As a represen= tative of Symantec, I will tell you that modifying our issuance code will b= e a very tough sell, for a number of reasons: > - There's no obvious direct return on investment So protecting users is not a motivation, then? > - For some types of certificates, speed of issuance is very important. G= etting a CT proof will slow this down and cause it to fail if the log serve= r isn't up 100% of the time. I'd like to hear more about these certificates - why is speed so important? We redesigned the CT protocol precisely so that getting a proof (which actually now is just a signed timestamp) is quick, and so that we have a service that's easy to keep up. We also intend to run several instances of the log so that in the event of one being down, others can be used (for time critical issuance, you would obviously use them in parallel, and perhaps just take the first one that answers - there's no obligation to use a log's response so dropping the others on the floor would be fine). > - It makes sense to avoid relying on external parties to fulfill part of= our cert issuance process. At this point, it's unclear who would even host= a log service, what SLA they would provide, how much attention they would = pay to performance and availability, disaster recovery, etc. Google will run a log. We have not yet established an SLA, but we will have one, and certainly our aim is to make it as available as is possible. Disaster recovery is also critical, since any error in the log is indistinguishable from malfeasance, at least technically, so we are designing the system with a great deal of robustness and multiple layers of backup. We are not messing around here - the full capabilities of Google's infrastructure are being applied to this problem. > - Symantec would not be interested in hosting a log service because of u= nclear ROI. I find it interesting that trust is not considered an ROI. > > -Rick From paul.hoffman@vpnc.org Thu Oct 25 08:09:53 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179E321F89DE for ; Thu, 25 Oct 2012 08:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIvQOyyF1vKx for ; Thu, 25 Oct 2012 08:09:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 071FD21F89F5 for ; Thu, 25 Oct 2012 08:09:48 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9PF9lRA064907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 25 Oct 2012 08:09:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 25 Oct 2012 08:09:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <536F87D9-96F0-40BD-A4AA-F4ADDEE431E8@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> To: "therightkey@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:09:53 -0000 The thread from the past few days has show a few things that I hope = influence the discussion before the meeting: - Different CAs have different views about what is and is not desirable = for them to do with respect to draft-laurie-pki-sunlight - Different people within one CA have different views about what is and = is not desirable for them to do with respect to = draft-laurie-pki-sunlight - Different CAs have different views about what is and is not possible = for them to do with respect to draft-laurie-pki-sunlight Given all that, it would be grand if people spoke for themselves, and = for people to not assume that someone who is speaking is speaking for = everyone who is like them. --Paul Hoffman= From hallam@gmail.com Thu Oct 25 10:44:15 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E7321F8869 for ; Thu, 25 Oct 2012 10:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.877 X-Spam-Level: X-Spam-Status: No, score=-3.877 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4D-a46dB5kd for ; Thu, 25 Oct 2012 10:44:15 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF9421F85E7 for ; Thu, 25 Oct 2012 10:44:15 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so2093596obq.31 for ; Thu, 25 Oct 2012 10:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:from:date:message-id:subject:to :cc:content-type; bh=v1AQ43ekWVeGxXPATORO6q4/iKau/PFp2TPMme68jKc=; b=ytA7JZqHzdsZcVhM8rgkQq380hPW+Vsm8yQSKriB9BAQGO0wfop+4BK3dyGlJl73qk e39fKcPItMx/zfhnAbx8GzhljhMmRgrowoqXB4VKqUcEbW0bNh8eA3pG6i/bMtqcVhXj eSnf0k/Cr7N724DX7gdmdSk19ze3+f10HF4HxBzyljoFXhgK1z6ebmIGgy2hxRhVK6Iz zI1Mt6ttvgBswDmuoHkzUJwXyWZanGtkA72tTg26PvzQnUjj2OPR+5ALLdQfptQoijyA d5rxS5zn1S4XD3PZk/j/Yg70uDjWkdO/5uaPOE/OjCRyfb4Yk//NMq7OeFEOGY8IYotc kJbg== Received: by 10.60.170.9 with SMTP id ai9mr16883339oec.36.1351187054961; Thu, 25 Oct 2012 10:44:14 -0700 (PDT) References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <536F87D9-96F0-40BD-A4AA-F4ADDEE431E8@vpnc.org> In-Reply-To: <536F87D9-96F0-40BD-A4AA-F4ADDEE431E8@vpnc.org> Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker Date: Thu, 25 Oct 2012 12:44:14 -0500 Message-ID: <110705303576908737@unknownmsgid> To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 17:44:15 -0000 You assume here I was speaking for Comodo and about the comodo ca My experience is rather wider than one or two CAs Sent from my iPhone On Oct 25, 2012, at 10:11 AM, Paul Hoffman wrote: > The thread from the past few days has show a few things that I hope influence the discussion before the meeting: > > - Different CAs have different views about what is and is not desirable for them to do with respect to draft-laurie-pki-sunlight > > - Different people within one CA have different views about what is and is not desirable for them to do with respect to draft-laurie-pki-sunlight > > - Different CAs have different views about what is and is not possible for them to do with respect to draft-laurie-pki-sunlight > > Given all that, it would be grand if people spoke for themselves, and for people to not assume that someone who is speaking is speaking for everyone who is like them. > > --Paul Hoffman > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From paul.hoffman@vpnc.org Thu Oct 25 11:04:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7316F21F851E for ; Thu, 25 Oct 2012 11:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weWdDLb6qU8F for ; Thu, 25 Oct 2012 11:04:07 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 069B021F848D for ; Thu, 25 Oct 2012 11:04:06 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9PI44bE071066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2012 11:04:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <110705303576908737@unknownmsgid> Date: Thu, 25 Oct 2012 11:04:04 -0700 Content-Transfer-Encoding: 7bit Message-Id: <45525D73-CA59-455A-A141-EAF22557FA28@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <536F87D9-96F0-40BD-A4AA-F4ADDEE431E8@vpnc.org> <110705303576908737@unknownmsgid> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 18:04:07 -0000 On Oct 25, 2012, at 10:44 AM, Phillip Hallam-Baker wrote: > You assume here I was speaking for Comodo and about the comodo ca That is a false statement. > My experience is rather wider than one or two CAs That is a true statement, yet still irrelevant to this discussion. --Paul Hoffman From rob.stradling@comodo.com Thu Oct 25 12:41:17 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B242821F8583 for ; Thu, 25 Oct 2012 12:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sV+lROfjyrC for ; Thu, 25 Oct 2012 12:41:17 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id D64BB21F8578 for ; Thu, 25 Oct 2012 12:41:16 -0700 (PDT) Received: (qmail 5198 invoked from network); 25 Oct 2012 19:41:15 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 25 Oct 2012 19:41:15 -0000 Received: (qmail 31107 invoked by uid 1000); 25 Oct 2012 19:41:14 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 25 Oct 2012 20:41:14 +0100 Message-ID: <508995DA.1030003@comodo.com> Date: Thu, 25 Oct 2012 20:41:14 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <536F87D9-96F0-40BD-A4AA-F4ADDEE431E8@vpnc.org> <110705303576908737@unknownmsgid> <45525D73-CA59-455A-A141-EAF22557FA28@vpnc.org> In-Reply-To: <45525D73-CA59-455A-A141-EAF22557FA28@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org, Phillip Hallam-Baker Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 19:41:17 -0000 On 25/10/12 19:04, Paul Hoffman wrote: > On Oct 25, 2012, at 10:44 AM, Phillip Hallam-Baker wrote: > >> You assume here I was speaking for Comodo and about the comodo ca > > That is a false statement. Paul, in that case, would you mind explaining who you were referring to and what you meant by... "Different people within one CA have different views about what is and is not desirable for them to do with respect to draft-laurie-pki-sunlight" ? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From paul.hoffman@vpnc.org Thu Oct 25 13:05:50 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A936D21F8789 for ; Thu, 25 Oct 2012 13:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJe8PatPbo35 for ; Thu, 25 Oct 2012 13:05:50 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C7C8E21F8755 for ; Thu, 25 Oct 2012 13:05:49 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9PK5a2E076240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2012 13:05:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <508995DA.1030003@comodo.com> Date: Thu, 25 Oct 2012 13:05:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7DF21DC2-32F9-465A-B518-A734A5D42ED5@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <536F87D9-96F0-40BD-A4AA-F4ADDEE431E8@vpnc.org> <110705303576908737@unknownmsgid> <45525D73-CA59-455A-A141-EAF22557FA28@vpnc.org> <508995DA.1030003@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 20:05:50 -0000 On Oct 25, 2012, at 12:41 PM, Rob Stradling = wrote: > On 25/10/12 19:04, Paul Hoffman wrote: >> On Oct 25, 2012, at 10:44 AM, Phillip Hallam-Baker = wrote: >>=20 >>> You assume here I was speaking for Comodo and about the comodo ca >>=20 >> That is a false statement. >=20 > Paul, in that case, would you mind explaining who you were referring = to and what you meant by... > "Different people within one CA have different views about what is and = is not desirable for them to do with respect to = draft-laurie-pki-sunlight" > ? Sure. Neither you nor Phill have said you were speaking for Comodo, yet = you have over time expressed different views of what is and is not = desirable for some CAs (not just Comodo) to do with respect to = draft-laurie-pki-sunlight. Phill told me long ago to not assume that he = speaks for Comodo, and I still take him at his word for that. So, now we can return to, you know, protocol discussion? --Paul Hoffman= From Rick_Andrews@symantec.com Thu Oct 25 15:40:20 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BD921F8562 for ; Thu, 25 Oct 2012 15:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+D9mQIJudeC for ; Thu, 25 Oct 2012 15:40:19 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) by ietfa.amsl.com (Postfix) with ESMTP id 486B921F84EA for ; Thu, 25 Oct 2012 15:40:19 -0700 (PDT) X-AuditID: d80ac3f1-b7f256d00000652e-19-5089bfd29eda Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 12.2A.25902.2DFB9805; Thu, 25 Oct 2012 22:40:18 +0000 (GMT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1TRW66-0000Dz-G3; Thu, 25 Oct 2012 22:40:18 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Thu, 25 Oct 2012 15:40:18 -0700 From: Rick Andrews To: Chris Palmer , Ben Laurie Date: Thu, 25 Oct 2012 15:40:16 -0700 Thread-Topic: [therightkey] Impact on issue processes Thread-Index: Ac2yS6IaLEtWiPCRSxKfGEYd8nGtiAAs2WAw Message-ID: <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsVyYMU1Hd1L+zsDDO51qVps+HyNzeLq8uNM FqfnHGK0uLX+C6vFxws/WRxYPXbOusvusWBTqceSJT+ZPD7PvsocwBLFZZOSmpNZllqkb5fA ldG++RBTwTHxikULJ7M0MP4Q62Lk5JAQMJHYsn8uO4QtJnHh3nq2LkYuDiGBD4wSt873sEA4 rxgljr1th8qsYpTYeKGBBaSFTUBPYsvjK2DtIgJOEu/+PQGLMws0MUqcv2YDYrMIqEpM3rec DcQWBlq3c8IbVoh6U4l9V7qYIWwjiVkb3oPN4RWIkrjV3gW1+R+rxM2WG2AJToFAie2v3oAt YAS69fupNUwQy8Qlbj2ZzwTxg4DEkj3nmSFsUYmXj/+xQtSLStxpX8/YxcgBVK8psX6XPkSr osSU7odQewUlTs58wjKBUXwWkqmzEDpmIemYhaRjASPLKkaZktJiw+LckvzSkoLUCgNDveLK 3ERgTCbrJefnbmIExuUNrsMfdzBeX6p4iFGAg1GJh/fhgs4AIdbEMqDKQ4wSHMxKIry7pwKF eFMSK6tSi/Lji0pzUosPMUpzsCiJ8wo6RQcICaQnlqRmp6YWpBbBZJk4OKUaGEvSLy3b05Y4 h3erQjTj9ZK9lQuf9Hlam/63ry4Nb9XYsPZ77kyJ9ryT/1OvBpxSf1ec+jdu4aLJ7pYs/Re2 idXf3XBI20Aj45b3ijvfo/Iux1+P/5d7bEq6vfrBBkv92hv13D57A+JMNn2+Po2lpaZU/sX+ lWX/HaZf9IsS7m9jeK66aYO6vBJLcUaioRZzUXEiAMqG5nHHAgAA Cc: "therightkey@ietf.org" , Phillip Hallam-Baker , Paul Hoffman Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 22:40:20 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDaHJpcyBQYWxtZXIgW21haWx0 bzpwYWxtZXJAZ29vZ2xlLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDI0LCAyMDEy IDU6NTcgUE0NCj4gVG86IFJpY2sgQW5kcmV3cw0KPiBDYzogQmVuIExhdXJpZTsgUGhpbGxpcCBI YWxsYW0tQmFrZXI7IHRoZXJpZ2h0a2V5QGlldGYub3JnOyBQYXVsDQo+IEhvZmZtYW4NCj4gU3Vi amVjdDogUmU6IFt0aGVyaWdodGtleV0gSW1wYWN0IG9uIGlzc3VlIHByb2Nlc3Nlcw0KPiANCj4g T24gV2VkLCBPY3QgMjQsIDIwMTIgYXQgMTA6MDkgQU0sIFJpY2sgQW5kcmV3cw0KPiA8Umlja19B bmRyZXdzQHN5bWFudGVjLmNvbT4gd3JvdGU6DQo+IA0KPiA+IEl0J3Mgbm90IGEgcXVlc3Rpb24g b2YgYmVpbmcgdW5hYmxlIHRvIG1vZGlmeSBvdXIgc29mdHdhcmUuIEFzIGENCj4gcmVwcmVzZW50 YXRpdmUgb2YgU3ltYW50ZWMsIEkgd2lsbCB0ZWxsIHlvdSB0aGF0IG1vZGlmeWluZyBvdXIgaXNz dWFuY2UNCj4gY29kZSB3aWxsIGJlIGEgdmVyeSB0b3VnaCBzZWxsLCBmb3IgYSBudW1iZXIgb2Yg cmVhc29uczoNCj4gPiAgLSBUaGVyZSdzIG5vIG9idmlvdXMgZGlyZWN0IHJldHVybiBvbiBpbnZl c3RtZW50DQo+ID4gIC0gRm9yIHNvbWUgdHlwZXMgb2YgY2VydGlmaWNhdGVzLCBzcGVlZCBvZiBp c3N1YW5jZSBpcyB2ZXJ5DQo+IGltcG9ydGFudC4gR2V0dGluZyBhIENUIHByb29mIHdpbGwgc2xv dyB0aGlzIGRvd24gYW5kIGNhdXNlIGl0IHRvIGZhaWwNCj4gaWYgdGhlIGxvZyBzZXJ2ZXIgaXNu J3QgdXAgMTAwJSBvZiB0aGUgdGltZS4NCj4gPiAgLSBJdCBtYWtlcyBzZW5zZSB0byBhdm9pZCBy ZWx5aW5nIG9uIGV4dGVybmFsIHBhcnRpZXMgdG8gZnVsZmlsbA0KPiBwYXJ0IG9mIG91ciBjZXJ0 IGlzc3VhbmNlIHByb2Nlc3MuIEF0IHRoaXMgcG9pbnQsIGl0J3MgdW5jbGVhciB3aG8NCj4gd291 bGQgZXZlbiBob3N0IGEgbG9nIHNlcnZpY2UsIHdoYXQgU0xBIHRoZXkgd291bGQgcHJvdmlkZSwg aG93IG11Y2gNCj4gYXR0ZW50aW9uIHRoZXkgd291bGQgcGF5IHRvIHBlcmZvcm1hbmNlIGFuZCBh dmFpbGFiaWxpdHksIGRpc2FzdGVyDQo+IHJlY292ZXJ5LCBldGMuDQo+ID4gIC0gU3ltYW50ZWMg d291bGQgbm90IGJlIGludGVyZXN0ZWQgaW4gaG9zdGluZyBhIGxvZyBzZXJ2aWNlIGJlY2F1c2UN Cj4gb2YgdW5jbGVhciBST0kuDQo+IA0KPiBDVCBtYWtlcyBDQXMgbGVzcyB2YWx1YWJsZSB0YXJn ZXRzLiBJJ2QgY2FsbCB0aGF0IFJPSS4NCg0KQmVuLCBDaHJpcywNCg0KUHJvdGVjdGluZyB1c2Vy cyBpcyBjZXJ0YWlubHkgYSBtb3RpdmF0aW9uIGFuZCBtYWtpbmcgb3VyIGN1c3RvbWVycyBhbmQg dGhlaXIgZW5kIHVzZXJzIHNhZmVyIG9uIHRoZSBJbnRlcm5ldCBpcyBteSBtYWluIGdvYWwuIEkn bSBub3Qgb3Bwb3NlZCB0byBDVCBiZWNhdXNlIEkgZG9uJ3Qgd2FudCB0byBwcm90ZWN0IHVzZXJz IG9yIENBcy4gSSdtIGp1c3Qgbm90IGNvbnZpbmNlZCBpdCdzIHRoZSBiZXN0IHNvbHV0aW9uLg0K DQpJdCdzIGdvaW5nIHRvIGNvc3QgZW5naW5lZXJpbmcgdGltZSBhbmQgbW9uZXkgZm9yIENBcyB0 byBpbXBsZW1lbnQgQ1QuIFRoZSBiZWFuIGNvdW50ZXJzIGFuZCBleGVjcyB3aG8gY29udHJvbCB0 aGUgcHVyc2Ugc3RyaW5ncyBhcmUgZ29pbmcgdG8gYXNrIHdoYXQgdGhleSdsbCBnZXQgZm9yIHRo ZWlyICQkJC4gVGhleSdsbCBhc2sgInNvIGlmIEkgc3BlbmQgdGhpcyBtb25leSwgd2Ugd29uJ3Qg Z2V0IGhhY2tlZCwgcmlnaHQ/IiBhbmQgSSB3b3VsZCBoYXZlIHRvIHNheSBubywgaXQncyBubyBn dWFyYW50ZWUgdGhhdCB3ZSB3b3VsZG4ndCBnZXQgaGFja2VkLCBidXQgaWYgd2UgZ290IGhhY2tl ZCB3ZSB3b3VsZCBrbm93IGFib3V0IGl0Lg0KDQpDVCBpcyAqYSogc29sdXRpb24sIGJ1dCBieSBu byBtZWFucyB0aGUgb25seSBwb3NzaWJsZSBzb2x1dGlvbi4gSXMgdGhlcmUgYW5vdGhlciBzb2x1 dGlvbiB0aGF0IG1pZ2h0IGJlIGxlc3MgZXhwZW5zaXZlIGFuZCBpbnRydXNpdmUgdG8gaW1wbGVt ZW50PyBDQUEgbWlnaHQgZ2V0IHVzIDgwJSBvZiB0aGUgd2F5IHRoZXJlIGZvciBhIGZyYWN0aW9u IG9mIHRoZSBjb3N0LiBEQU5FIGFuZCBjZXJ0IHBpbm5pbmcgYWxzbyBoZWxwLCBhbmQgbWlnaHQg YmUgc2ltcGxlciB0byBpbXBsZW1lbnQuIA0KDQotUmljaw0K From paul.hoffman@vpnc.org Thu Oct 25 16:17:44 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A29B21F88AE for ; Thu, 25 Oct 2012 16:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S70-v+geeqA5 for ; Thu, 25 Oct 2012 16:17:42 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D2F3221F84F1 for ; Thu, 25 Oct 2012 16:17:41 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9PNHa9e081753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Oct 2012 16:17:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Thu, 25 Oct 2012 16:17:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> To: Rick Andrews X-Mailer: Apple Mail (2.1499) Cc: therightkey@ietf.org Subject: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 23:17:44 -0000 On Oct 25, 2012, at 3:40 PM, Rick Andrews = wrote: > Protecting users is certainly a motivation and making our customers = and their end users safer on the Internet is my main goal. I'm not = opposed to CT because I don't want to protect users or CAs. I'm just not = convinced it's the best solution. >=20 > It's going to cost engineering time and money for CAs to implement CT. = The bean counters and execs who control the purse strings are going to = ask what they'll get for their $$$. They'll ask "so if I spend this = money, we won't get hacked, right?" and I would have to say no, it's no = guarantee that we wouldn't get hacked, but if we got hacked we would = know about it. >=20 > CT is *a* solution, but by no means the only possible solution. Is = there another solution that might be less expensive and intrusive to = implement? CAA might get us 80% of the way there for a fraction of the = cost. DANE and cert pinning also help, and might be simpler to = implement.=20 I'm pretty sure CAA is only about preventing good-conscious certificate = issuance, not about preventing hacked, nor about knowing about it if you = are. How do you see CAA getting you 80% of the way to the problem? I also don't see DANE or cert pinning as solutions to that problem = either, so I guess I'm missing something in your analysis. --Paul Hoffman= From palmer@google.com Thu Oct 25 16:26:04 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08FF21F88D0 for ; Thu, 25 Oct 2012 16:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GDTcSPZQw4j for ; Thu, 25 Oct 2012 16:26:04 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA3F21F88CF for ; Thu, 25 Oct 2012 16:26:03 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1208298wgb.13 for ; Thu, 25 Oct 2012 16:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=HqplM/swclSHc8uBLMzh9fM1tPkKqMAusjUlnskNzNw=; b=bsAycqPQYo8WpkrtdMuDxSuS6N9TsoFbcT5VobOoUNiOZhvNRRAbNT1tSd2iQP3NYe kjzf6+a5s7acHB4Cv3LtuxaWwHL1NglPe58+tGkQwAniH66OJw1A3XzH4oo2TO9KrrHF pdGZOEpTyCVU5sVeR0qnlXVxTjhv+SwkFW1Cml6jTfQhoAXd4n6O6E2fY0SYC9PW5omy 37bZBDHGlnVQK6GglUMILIRKVd5hGe5vrOwOp2i3ZLhQqkT2g/rr0amfepcqKOhyIXgz lzYDiv8RaIUZ5Z0C7brbyzMwfR1pF6vyzkNoMm3CpBLv8HaEnl3jiT6qdXqbemtEZJ65 T2fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=HqplM/swclSHc8uBLMzh9fM1tPkKqMAusjUlnskNzNw=; b=EkMEeRNkqZT202t1DwbRPjaVcVXnfDDTKCzBF/XycLzNRqpEcEiPdaGhEdI+wEgVeH MWMPNj6PZD6/IjD5Ru3ejBPSDfZHhT/OkETPBQ3Pkl0zR15C22+Qz7ippvkL67nrZA1c wAMKmMk9hf2wteE1wDYWRFV40qQ4MkV9yMBxZR9uuF0NZqbFicBXpjtnYVgQP7lsz5zI l9+asoLXV2y3u654uEPcsgzF8t4ANnpdJ73fZOo1SSpbvTcuECWbkTNPl0HVQ7NU5XN0 fsVQydFuF/o8mTE/f4inV3MCW4FqdtpNWk8IpvfZ5tJs+ZPj7t0wSGPp4zcgsla3Ck6q xekw== MIME-Version: 1.0 Received: by 10.180.102.131 with SMTP id fo3mr902269wib.1.1351207563321; Thu, 25 Oct 2012 16:26:03 -0700 (PDT) Received: by 10.223.64.199 with HTTP; Thu, 25 Oct 2012 16:26:02 -0700 (PDT) In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Thu, 25 Oct 2012 16:26:02 -0700 Message-ID: From: Chris Palmer To: Rick Andrews Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnN389GCrgnnbE+ogBj4vDi5vZ6QKdy5irhz8HSJotqzVmdIbsYgCZ1eLK+LNsTY9a9InHQOavR0t8sjRekrfcfiamNQTawWHKN2A9xmdLjHT+N7hBOtJblDgiqgrsvUt7AYveNdR5vEwF3ezPSWKDAMlqtljx8KmD8mnnGMfawcJFbpR4G2LfuocDfKNECbR0o+w5A Cc: Phillip Hallam-Baker , "therightkey@ietf.org" , Ben Laurie , Paul Hoffman Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 23:26:05 -0000 On Thu, Oct 25, 2012 at 3:40 PM, Rick Andrews w= rote: > It's going to cost engineering time and money for CAs to implement CT. Th= e bean counters and execs who control the purse strings are going to ask wh= at they'll get for their $$$. They'll ask "so if I spend this money, we won= 't get hacked, right?" and I would have to say no, it's no guarantee that w= e wouldn't get hacked, but if we got hacked we would know about it. And the attackers have much less incentive to hack you. That is a really big win. Obviously the cost is not $0, but the payoff is significant. In a CT world, what does Comodo Hacker gain by causing mis-issuance? It's a looooot less than now. Tell your bean counters that. > CT is *a* solution, but by no means the only possible solution. Is there = another solution that might be less expensive and intrusive to implement? C= AA might get us 80% of the way there for a fraction of the cost. DANE and c= ert pinning also help, and might be simpler to implement. Obviously I like key pinning, but I consider CT (or a public log solution generally) as the "true", long-term solution. Pinning would probably continue to be of complementary value, as might DANE/CAA/whatever else. But I consider that CT is where we want to be. And other people are already offering to take on the really big costs. Tell your bean counters that, too: It's a collaborative effort, and other people have already started paying. It might be that all you have to do is implement somebody else's design and talk to somebody else's service (although obviously helping out sooner benefits you too). From Rick_Andrews@symantec.com Thu Oct 25 16:58:04 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B894821F88FB for ; Thu, 25 Oct 2012 16:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LgbpqAc-igw for ; Thu, 25 Oct 2012 16:58:03 -0700 (PDT) Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id A373D21F88F7 for ; Thu, 25 Oct 2012 16:58:03 -0700 (PDT) X-AuditID: a66201d2-b7fa76d0000074f9-87-5089d209dc06 Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by ecl1mtaoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 6B.DA.29945.902D9805; Thu, 25 Oct 2012 23:58:01 +0000 (GMT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1TRXJI-0001NQ-S6; Thu, 25 Oct 2012 23:58:00 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Thu, 25 Oct 2012 16:58:01 -0700 From: Rick Andrews To: Paul Hoffman Date: Thu, 25 Oct 2012 16:58:00 -0700 Thread-Topic: Other solutions to the problem Thread-Index: Ac2zBvASzTWMNsDRT/OXrxTdfLxZlQABHVsg Message-ID: <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> In-Reply-To: <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsVyYMU1bV3OS50BBg1/xS1urf/CavHxwk8W ByaPJUt+Mnl8nn2VOYApissmJTUnsyy1SN8ugSvjzju9gs3CFZ/f3WJvYFzL38XIySEhYCJx Z/F/FghbTOLCvfVsXYxcHEICHxgl1n3sYYZwXjFKvF98nxHCWcUo8fPOc7AWNgE9iS2Pr7CD 2CICGhIXHu4As5kFDCXWnNoDZrMIqEpsmvQWzBYW0JY49XQGC0S9jsSG/x/YIGwjiavbboPV 8ApEScx6vx5qWSO7xNppe1hBEpwCNhKLZkA0MALd+v3UGiaIZeISt57MZ4L4QUBiyZ7zzBC2 qMTLx/9YIepFJe60gwwFqdeRWLD7ExuErS2xbOFrZojFghInZz5hmcAoPgvJ2FlIWmYhaZmF pGUBI8sqRpnU5BzD3JLE/NKSgtQKAyO94srcRGCUJesl5+duYgRG2rIkxks7GO8f1j3EKMDB qMTDu3hPZ4AQa2IZUOUhRgkOZiUR3t1TgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5b5dGBQgJ pCeWpGanphakFsFkmTg4pRoY9WyqJBeIb65v33fN5ey76aGnhNROC33lWTe3SeP/aiENq1kP H5ywMZE2lVKOP7u2/shL44WhF+1LO8tVPXY/4toefUD0Ar+FSVmVTcQ/tzW3tkmHPW7/JW9g f9pBZ/oUCflg7WcmGh5CKze927rOZ90mge7p0Y8rF4tO+fFo39Zq3QkP7u5xUmIpzkg01GIu Kk4EAMlzNbawAgAA Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 23:58:04 -0000 > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Thursday, October 25, 2012 4:18 PM > To: Rick Andrews > Cc: therightkey@ietf.org > Subject: Other solutions to the problem >=20 > On Oct 25, 2012, at 3:40 PM, Rick Andrews > wrote: >=20 > > Protecting users is certainly a motivation and making our customers > and their end users safer on the Internet is my main goal. I'm not > opposed to CT because I don't want to protect users or CAs. I'm just > not convinced it's the best solution. > > > > It's going to cost engineering time and money for CAs to implement > CT. The bean counters and execs who control the purse strings are going > to ask what they'll get for their $$$. They'll ask "so if I spend this > money, we won't get hacked, right?" and I would have to say no, it's no > guarantee that we wouldn't get hacked, but if we got hacked we would > know about it. > > > > CT is *a* solution, but by no means the only possible solution. Is > there another solution that might be less expensive and intrusive to > implement? CAA might get us 80% of the way there for a fraction of the > cost. DANE and cert pinning also help, and might be simpler to > implement. >=20 >=20 > I'm pretty sure CAA is only about preventing good-conscious certificate > issuance, not about preventing hacked, nor about knowing about it if > you are. How do you see CAA getting you 80% of the way to the problem? >=20 > I also don't see DANE or cert pinning as solutions to that problem > either, so I guess I'm missing something in your analysis. The problem is that any CA can issue a certificate for a given domain name = and all browsers will trust it. CT allows Paypal (just an example) to detec= t that some unexpected CA issued a cert for one of their domains. If CAA is= used by the CA being hacked, their system should refuse to issue the cert = to Paypal's domain. DANE or cert pinning would allow a client to detect tha= t the certificate issued by the CA being hacked is bogus. AFAICT, for CT to really work it will require participation from every CA w= hose roots are in browsers. I think you're underestimating how hard it will= be to achieve that. Further, no one has yet brought up the privacy issue. CAs sell a lot of cer= tificates to companies for their internal use. Some of them may object to p= ublishing all their internal domain names.=20 -Rick From palmer@google.com Thu Oct 25 17:49:30 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CEE21F84AF for ; Thu, 25 Oct 2012 17:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf3Yk7dLBh2B for ; Thu, 25 Oct 2012 17:49:29 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC9D21F8493 for ; Thu, 25 Oct 2012 17:49:29 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2338528lam.31 for ; Thu, 25 Oct 2012 17:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=K94/39TqY0L/5pHXuXzxf8E1z4ix73KE54LxOfRbVlU=; b=mOVbwKJZxWSdHy8uStjRcG80XZUWfzOKo3uxqUkg5Mhx0vNDUh0L3pzA7sO9BWiMw+ vq2vIKIto5fpttBiqjQsrgTlWhUpz3VY1G1o06xTyWWb2RR+fx8D6P+N+2ddoVz6mpdq AnRT4B2xrz7ToXGkGAa/ce6Q+9Hn+j1TU4CJYkULuAlq6soHPwq76W3NyRDxXsDT4met EraijCY2qrz9g4auiar6qlmM39upY+uQK640IkWgFFpMdZ4mAlcOm3wVF3XdliqRHHh+ ppoLDo+RfykOLbdVv7D5EWkAHVun397KkPOOXBJOYkk+bpCw0J7trCpQ7L6009vqVOgV 1OZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=K94/39TqY0L/5pHXuXzxf8E1z4ix73KE54LxOfRbVlU=; b=JaVTGUE4tSGbEXUb6tQ01L8wZo4oRHsTZhCgJ/Ez35OiIltejetFKi2wyaO3BFOqJh 5KWr1xcQ+/dvvbjK+DjGB7TALbDmBO9jC8lIkOsWdcmCGExwv9uqPoR/wD1OQiyq1sMp uJ0XXXAuGTzocpk4O98iwkFXWcVQQj13Ncng/Ls7YLlRyi2kcZSrvbGRBWO0ttWn19gu dA8FaoaWG/gWfLFBqpIKw+raApJBQdDrpmoyXn21XtHNFKWSP7VdY+mr1Zow1OW7yVS5 qj1xxd95S5eO0Pgefk2SWI+VLEsn2UVpRmcNwkGpdM9S/2jW3UajLS/foq5BoW+pK+Op vPTg== MIME-Version: 1.0 Received: by 10.152.133.140 with SMTP id pc12mr18967169lab.53.1351212568255; Thu, 25 Oct 2012 17:49:28 -0700 (PDT) Received: by 10.112.39.226 with HTTP; Thu, 25 Oct 2012 17:49:28 -0700 (PDT) In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Thu, 25 Oct 2012 17:49:28 -0700 Message-ID: From: Chris Palmer To: Rick Andrews Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQllRbGKyWeepuyJHbPLa2PDq+s90gZKHxyD296Of2pe0sDddApD8fkC6Q5YVrUtawW8jwj6YRPM1Jp6BMZAGUGLXDPmrq6PQpeXK9MmBpjMuFLXErz63vzrzzv63tkxZ7Bh+xoGXn9JIoLKxc6bgLpEkCw2c917tE3OoquR11l9ACTHtVcIPltNUEBvvvhsNddQ+ccH Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 00:49:30 -0000 On Thu, Oct 25, 2012 at 4:58 PM, Rick Andrews wrote: > Further, no one has yet brought up the privacy issue. CAs sell a lot of certificates to companies for their internal use. Some of them may object to publishing all their internal domain names. I'm still fuzzy on why people can't use private issuers for private domains. Seems not only obvious, but preferable for everyone. From ynir@checkpoint.com Thu Oct 25 22:58:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C730221F8620 for ; Thu, 25 Oct 2012 22:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.587 X-Spam-Level: X-Spam-Status: No, score=-10.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxFeWb-jHR46 for ; Thu, 25 Oct 2012 22:58:00 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E873521F84C7 for ; Thu, 25 Oct 2012 22:57:59 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q9Q5vjDE003740; Fri, 26 Oct 2012 07:57:46 +0200 X-CheckPoint: {508A2430-1A-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 26 Oct 2012 07:57:45 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 26 Oct 2012 07:57:45 +0200 From: Yoav Nir To: Chris Palmer Date: Fri, 26 Oct 2012 07:57:44 +0200 Thread-Topic: [therightkey] Other solutions to the problem Thread-Index: Ac2zPtFnu3t1s6gRTqKwWrESB0p6mg== Message-ID: <727FAEF2-49E5-4B23-849A-626EA2C0A6BB@checkpoint.com> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "therightkey@ietf.org" , Paul Hoffman , Rick Andrews Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 05:58:00 -0000 On Oct 26, 2012, at 2:49 AM, Chris Palmer wrote: > On Thu, Oct 25, 2012 at 4:58 PM, Rick Andrews = wrote: >=20 >> Further, no one has yet brought up the privacy issue. CAs sell a lot of = certificates to companies for their internal use. Some of them may object t= o publishing all their internal domain names. >=20 > I'm still fuzzy on why people can't use private issuers for private > domains. Seems not only obvious, but preferable for everyone. It avoids the hassle of adding the private issuer to the browser of every s= ingle device that uses the web. It's fairly easy to do so for all the Windo= ws machines connected to a Windows domain. But then you get a lot of helpde= sk tickets for the people with Macs, the people who use Firefox on any plat= form, the people with iPhones, Android phones, Linux desktops, a Chromebook= and something called a Wetab. It's worth the little extra expense of getting a certificate from a known i= ssuer to avoid getting warning screens on all other devices. Yoav From rob.stradling@comodo.com Fri Oct 26 01:24:41 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490E221F84D8 for ; Fri, 26 Oct 2012 01:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8p-+QQUgzTy for ; Fri, 26 Oct 2012 01:24:40 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC3A21F84D4 for ; Fri, 26 Oct 2012 01:24:39 -0700 (PDT) Received: (qmail 11471 invoked from network); 26 Oct 2012 08:24:37 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 26 Oct 2012 08:24:37 -0000 Received: (qmail 4140 invoked by uid 1000); 26 Oct 2012 08:24:37 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 26 Oct 2012 09:24:37 +0100 Message-ID: <508A48C5.9070005@comodo.com> Date: Fri, 26 Oct 2012 09:24:37 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Rick Andrews References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:24:41 -0000 On 26/10/12 00:58, Rick Andrews wrote: > AFAICT, for CT to really work it will require participation from every CA whose roots are in browsers. I think you're underestimating how hard it will be to achieve that. Rick, Ultimately, assuming the RFC5878 TLS extension gains widespread support in server and client software, CT won't _require_ participation from any CA. Each certificate holder will be able to configure their server to send their certificate's CT proof to each client. But with participation from the CAs, it should be possible to realize the CT dream far sooner. And (even in a future world where RFC5878 is supported everywhere) if the CA takes care of CT proof distribution, then that makes life easier for the certificate holder. > Further, no one has yet brought up the privacy issue. CAs sell a lot of certificates to companies for their internal use. Some of them may object to publishing all their internal domain names. This has been a concern for Comodo too, so I spoke to AGL about it a few weeks ago. AIUI, the plan is that CT clients will have a user-configurable whitelist (empty by default) of domain names for which CT proofs will not be required. Participating CAs should allow customers to opt-out from having their certs automatically logged with CT. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From benl@google.com Fri Oct 26 01:51:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0C421F84F6 for ; Fri, 26 Oct 2012 01:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMG76NFehsQE for ; Fri, 26 Oct 2012 01:51:00 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 801F621F84F3 for ; Fri, 26 Oct 2012 01:50:59 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1389698wgb.13 for ; Fri, 26 Oct 2012 01:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=mMJHT4MG6MTnTJv/8gZ9y3dmzUK5Zz4vlWN9shWVWa4=; b=D2K4m5kjylIpPo9rA3SZhpZymaHVxxpkB1hu15WmPODoZZm88GMKfoVJi0mWpJuWPl xbiumPVQ1S94ZTmx37/CwHQ3tQd2z6t6LC5VyGk9N7g0h+WMhGDkFQpioxoNbK9KVNOX D0k6xw3zbh+R4AGjdR/2Pp4N07o2AR7WtVUjDR1HkcEJy5CEZjTZSg0WlnINZhLbKOGB p3xUh5Fa3J/A5MsGjMN9Svw9lP/47gNR96Wznehkmjs2zLi/R2JrB5BWixtlcZSXrfHb Y1wwywVME4trFkyqEy2bRCqVYZTdWP/nEIZKhQHR3525lnmo1MWmfb6VRquZyLJ6Z/fr 0VkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=mMJHT4MG6MTnTJv/8gZ9y3dmzUK5Zz4vlWN9shWVWa4=; b=d483/WsAdTzT2UQPKzWQcUhuK5fECyLzPk4oahdrV9/S+TxCaPII18jmXRBspZ+hkn WBuWsjEUFAuBAdjc2uf1Tf2S73eZ+O2BvDCvRfeZ5Xt6PbSHZWKaHEPgC3x7If8GfRsr lDtVsouRtyni7XbpXwYnoBrCo+d3t5CJfIlN/35/glMFxLB145OKtH22UI7N1QgB9vmb +GmHqzc70aSbEgnN1F8yUlaXIYoVuyNPA6t/llhd09wCSrh9Ki2t/1sUrVQDczhOJ3Bc yO8L25EkBYGy37ej3QGoQ7BHV6i+Qr2qh4VOppJI6ZAHTtHtqttTNCmffzmq/P+JdUJG 4pEw== MIME-Version: 1.0 Received: by 10.180.94.226 with SMTP id df2mr3598535wib.11.1351241455627; Fri, 26 Oct 2012 01:50:55 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Fri, 26 Oct 2012 01:50:55 -0700 (PDT) In-Reply-To: <508A48C5.9070005@comodo.com> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> Date: Fri, 26 Oct 2012 09:50:55 +0100 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl8yxNZJERcGB28jln+B6hZ/v5eBUlTSvIQYBxA9yWbVFf6z/ZTaWujKhuoeqPOdOLK0TJatZHQhIBR5IpEUrjg0bvJNBI7vOKwD/M695jADV7kve72lcfngdOFMr2rgznatX6tXhFxLk8iudBqliPEocMx8KeC7x2RCZYWACGfv1l6MYIZYlNxn4G9ssCdO7sK1aSP Cc: "therightkey@ietf.org" , Paul Hoffman , Rick Andrews Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:51:00 -0000 On 26 October 2012 09:24, Rob Stradling wrote: > On 26/10/12 00:58, Rick Andrews wrote: > > >> AFAICT, for CT to really work it will require participation from every CA >> whose roots are in browsers. I think you're underestimating how hard it will >> be to achieve that. > > > Rick, > > Ultimately, assuming the RFC5878 TLS extension gains widespread support in > server and client software, CT won't _require_ participation from any CA. > Each certificate holder will be able to configure their server to send their > certificate's CT proof to each client. > > But with participation from the CAs, it should be possible to realize the CT > dream far sooner. And (even in a future world where RFC5878 is supported > everywhere) if the CA takes care of CT proof distribution, then that makes > life easier for the certificate holder. > > >> Further, no one has yet brought up the privacy issue. CAs sell a lot of >> certificates to companies for their internal use. Some of them may object to >> publishing all their internal domain names. > > > This has been a concern for Comodo too, so I spoke to AGL about it a few > weeks ago. AIUI, the plan is that CT clients will have a user-configurable > whitelist (empty by default) of domain names for which CT proofs will not be > required. Participating CAs should allow customers to opt-out from having > their certs automatically logged with CT. I think there are at least three options 1. As you say, users (or admins might be a little safer) configure domains to be opted-out. 2. Private certs are issued by private CAs (I mean the CA certificate, of course) which are marked "do not log". This option will not be available for default CAs. 3. Private certs are issued under a name-constrained intermediate which is logged. BTW, Rick, this has come up before, I thought on public lists, but perhaps I am misremembering. I prefer 3, BTW, because it is not a mechanism which users can be conned into invoking. From benl@google.com Fri Oct 26 01:56:55 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324AA21F84FA for ; Fri, 26 Oct 2012 01:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.967 X-Spam-Level: X-Spam-Status: No, score=-102.967 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt-GqXkl6GLL for ; Fri, 26 Oct 2012 01:56:54 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 365E121F84F3 for ; Fri, 26 Oct 2012 01:56:53 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so182462wib.13 for ; Fri, 26 Oct 2012 01:56: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:content-transfer-encoding:x-system-of-record; bh=RGaTj65R27389+6PLrWCuwFp0P4kHCDevkS6h0JRxww=; b=S0Y1uW/b5j/hS+4msSPDBQWvPVPUDBgxi0HZkMdzsBzMeRaGLBtsK9rE7Xet+Sdsy8 L6/K0dOsc2KuyWyTZCpmTdHH5eZPo8VYy/phD18mVwWaOnwnSbiZnfsfIF2uRt/FrIDe xJC8cLmRDVT4ttTJo2ObIHA9eNdAMsiam7qvRikFkH9ll0aMmCkle0ZRKj3OusSzY0JX nrFKDtcF6axGJ/GjpsgHTGqCcTp2cgqFEdxDHz+JgM80V/+sEh9Xkku73O3P1qYJWW7s 4PN/7ECRyDzfc+MzCzylSH8TjPN2juD+STG1qfOYKP0iHx5hNgnXMuiPUTw5UnDQc6/a VwmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=RGaTj65R27389+6PLrWCuwFp0P4kHCDevkS6h0JRxww=; b=OXWHoSxYcu4cwr1FVIs2Cho9XzGwBiqb2hIruz/CjfEWju0R5BH4dmiG0P9ORPOCj1 8ncn5u/l+ZyDOPYpdcktpf+FuWY4hLHSQuI7tpx2VfHAKSGDtJx8BlVWpfwzPc/2YZw1 fDHTtA7UoEj8tdLfeKQwHr84VMBvL+rl/ZFhKhJDP+7tFPl0AQ2Xb2/pr5G7cYIvAymz kf73nVBkXItKBSjs34zw1lmWvrpRhcKzjiEr52AxSGysw1gXIeI+DD9wqia+Kb9IXDCl 62cgHZpAz+sWvpQp2qeENLhwT6pmwXHP4hTvxgEAyWI7jSU4oiZT8m4xpBJTHVyzIrGP IArw== MIME-Version: 1.0 Received: by 10.216.140.205 with SMTP id e55mr12546218wej.2.1351241812895; Fri, 26 Oct 2012 01:56:52 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Fri, 26 Oct 2012 01:56:52 -0700 (PDT) In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Fri, 26 Oct 2012 09:56:52 +0100 Message-ID: From: Ben Laurie To: Rick Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlG9/ZBNlz+ey8CZltot+r4h1x9TWs9Fu9eQK7sMR2Mc5CmANd8/95vYfAq5KNIqO8JX815wI2HeIH0lf8BA9bNmb4HV1HoG754oUb87oQdO1F04WHMkDqHBClzrbGimZjaBHChCDKmploBzP6wRO5uLHWywtb7Mv97zhbgYTK2ZyJgkrE5w58mLCFiwKCVELcoSju+ Cc: "therightkey@ietf.org" , Phillip Hallam-Baker , Paul Hoffman , Chris Palmer Subject: Re: [therightkey] Impact on issue processes X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:56:55 -0000 On 25 October 2012 23:40, Rick Andrews wrote: >> -----Original Message----- >> From: Chris Palmer [mailto:palmer@google.com] >> Sent: Wednesday, October 24, 2012 5:57 PM >> To: Rick Andrews >> Cc: Ben Laurie; Phillip Hallam-Baker; therightkey@ietf.org; Paul >> Hoffman >> Subject: Re: [therightkey] Impact on issue processes >> >> On Wed, Oct 24, 2012 at 10:09 AM, Rick Andrews >> wrote: >> >> > It's not a question of being unable to modify our software. As a >> representative of Symantec, I will tell you that modifying our issuance >> code will be a very tough sell, for a number of reasons: >> > - There's no obvious direct return on investment >> > - For some types of certificates, speed of issuance is very >> important. Getting a CT proof will slow this down and cause it to fail >> if the log server isn't up 100% of the time. >> > - It makes sense to avoid relying on external parties to fulfill >> part of our cert issuance process. At this point, it's unclear who >> would even host a log service, what SLA they would provide, how much >> attention they would pay to performance and availability, disaster >> recovery, etc. >> > - Symantec would not be interested in hosting a log service because >> of unclear ROI. >> >> CT makes CAs less valuable targets. I'd call that ROI. > > Ben, Chris, > > Protecting users is certainly a motivation and making our customers and t= heir end users safer on the Internet is my main goal. I'm not opposed to CT= because I don't want to protect users or CAs. I'm just not convinced it's = the best solution. > > It's going to cost engineering time and money for CAs to implement CT. Th= e bean counters and execs who control the purse strings are going to ask wh= at they'll get for their $$$. They'll ask "so if I spend this money, we won= 't get hacked, right?" and I would have to say no, it's no guarantee that w= e wouldn't get hacked, but if we got hacked we would know about it. > > CT is *a* solution, but by no means the only possible solution. Is there = another solution that might be less expensive and intrusive to implement? C= AA might get us 80% of the way there for a fraction of the cost. DANE and c= ert pinning also help, and might be simpler to implement. I think the answer is that, no, there isn't another solution that is easier. Getting 80% of the way might as well be getting none of the way - unless _all_ CAs (or other issuers) are constrained, the problem is not solved. DANE and CAA, even if they were deployable, still leave you open to trusted third parties, and we've seen how that's gone. Pinning has its own issues - and in any case is available now and has not fixed the problem. From benl@google.com Fri Oct 26 08:10:20 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81E921F84D3 for ; Fri, 26 Oct 2012 08:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.967 X-Spam-Level: X-Spam-Status: No, score=-102.967 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI-Snm9Dfv0y for ; Fri, 26 Oct 2012 08:10:20 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1824221F849B for ; Fri, 26 Oct 2012 08:10:19 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so503941wib.1 for ; Fri, 26 Oct 2012 08:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=JH3U35K5Y0h23rmosk/wHoTdY8RTdC2s4Tuj5qcCNqs=; b=I6nQ1OEdIH2e0UWX/BYZ+1uk4sDDAXvzm55CVu6tE3GA9EbteYRnudUrVyniQkYrp/ KWvDpycXFaS5Lb7dmr3HZu79+S/dunaAGSAv9b+kAzzjYXx7CzSFL15RToFEZ8uLVIL2 qPL+hZkPV1Cai19fk5Orhm6WufsU54fOOcUKxdE+NBvrJ00po0KrvBiVW976K4L0/l2R sBd8oIpPyZikXmH8ob2t3oLrIOgiSsc/oJ11vAQ0ud6VPvxpCmzjJalEiDg2FHSabxX2 rjFZSjTe4Q+XEOIUiBpZuPRcZDVB6Dt75C/kN8ytsDk3C4OONQEJoTseh5jUV7/dLgSs ohXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=JH3U35K5Y0h23rmosk/wHoTdY8RTdC2s4Tuj5qcCNqs=; b=LmKiXQbkz7gpq2EwmRBoOK0t581dF2wR9nQK6XMyAhiBqUIWPdBoglLQ53DrsjLa1L Tsyxi8KwUq6X2FhuLohJaiS5hfGUzpfnJ3e1hTtf1oI8I2XKcfI6S1Wk+Dh+UH3yQfKL RyTG3PVidLPQmFBQcYl3hmnJTpgD3zTYDmFPV/Vz/VAOEgDw8cn+tDfXg9aDIW6ioQa4 GTmiwU6KqRGuoMuR9eCXbcAOQz4upMqs8AeS2D/i0Hp7cDaSqAivAHLLtrsXkuv/Z/+n 8lhPh9X/FewXEr8A3znk7OCwd3HXQLKRbyHr8xTVxoIbHDCQ00xpQn4DtuS3KVjCPtMC NW5g== MIME-Version: 1.0 Received: by 10.216.193.220 with SMTP id k70mr14601612wen.35.1351264216467; Fri, 26 Oct 2012 08:10:16 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Fri, 26 Oct 2012 08:10:16 -0700 (PDT) In-Reply-To: <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> Date: Fri, 26 Oct 2012 16:10:16 +0100 Message-ID: From: Ben Laurie To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlS905fDav7kWaBT5uuklI2Pltjqs/hG31Z9S31fTrVxC0t6i+g5QLL5aNk8mrXF1iJsi2sEBjNGpzs7OTnINa4vNcywfJ/1DhQYeaaYvQy3AEIEZcjhf643M3ixKNxBNGnOSFxeYwSwdTZ4jQKoLWfzK9NnftQH/IWjy5GnoXSMgIxxsR3chd6SWRdpZMW2VKset4G Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Call for agenda items for certrans BoF X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 15:10:21 -0000 On 17 October 2012 15:43, Paul Hoffman wrote: > Greetings again. The certrans BoF is scheduled for Tuesday after lunch at the IETF meeting; see . We have two hours, and we may not need all that time. Correction: Adam Langley, and probably Stephen McHenry, from the Certificate Transparency team at Google will be representing us at the BoF. From stephen.farrell@cs.tcd.ie Fri Oct 26 09:17:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BE221F8662 for ; Fri, 26 Oct 2012 09:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mClVRztqjNQ for ; Fri, 26 Oct 2012 09:16:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F1C1221F8661 for ; Fri, 26 Oct 2012 09:16:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EA0AAC79A for ; Fri, 26 Oct 2012 17:16:36 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E762yB2gSyQ for ; Fri, 26 Oct 2012 17:16:36 +0100 (IST) Received: from [10.87.48.4] (unknown [86.42.191.229]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5DE1AC790 for ; Fri, 26 Oct 2012 17:16:36 +0100 (IST) Message-ID: <508AB760.7050803@cs.tcd.ie> Date: Fri, 26 Oct 2012 17:16:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: "therightkey@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [therightkey] How many documents? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:17:00 -0000 Hiya, I know we're not having a wg-forming BoF but there's a thing I think I'd like to see discussed at or before the BoF that'd normally be part of a wg-forming BoF but is still worth doing now. (Discussing this on the list since we've all read the draft is even better of course:-) Assuming for the moment that we do go ahead and standardise CT, how many documents (RFCs) ought be used to document that? If the answer turns out to be one, then it might be more efficient to process CT as an AD sponsored draft, so if your answer to the above is 1, then I'd like input about doing that or not doing that. If the answer is more than one, then what might those be, and are there dependencies on other IETF WGs or external groups? Clearly, if the answer is more than one non-wg draft, that means that AD sponsoring is less likely and a WG is likely needed. If you think this is the case, it'd be good to see your suggestion for what RFCs ought be produced. I guess I'm sort of asking for suggestions as to what milestones a WG might adopt if we were to form one. I do realise that this is only part of the discussion that we need to have, and is contingent on us wanting to do something with CT, but I've not seen it raised so far, so thought I'd kick that off. If you're not sure about the process parts of the above (e.g. "AD sponsored") please just ask. Paul or I can answer that. Thanks, S. PS: Its ok to give your answer to this even if you think that CT should not be standardised in the IETF. If that's the case maybe say so if you want. From Rick_Andrews@symantec.com Fri Oct 26 14:31:21 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F8A21F8666 for ; Fri, 26 Oct 2012 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSj-cxzSuPXc for ; Fri, 26 Oct 2012 14:31:21 -0700 (PDT) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) by ietfa.amsl.com (Postfix) with ESMTP id C87EA21F865C for ; Fri, 26 Oct 2012 14:31:20 -0700 (PDT) X-AuditID: d80ac3f2-b7f096d000007ada-bf-508b01270011 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 AF.23.31450.7210B805; Fri, 26 Oct 2012 21:31:19 +0000 (GMT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1TRrUt-0004UY-T0; Fri, 26 Oct 2012 21:31:19 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.146]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Fri, 26 Oct 2012 14:31:19 -0700 From: Rick Andrews To: Ben Laurie , Rob Stradling Date: Fri, 26 Oct 2012 14:31:18 -0700 Thread-Topic: [therightkey] Other solutions to the problem Thread-Index: Ac2zVwS/FsGQs4YZTOmEYOz0RrNLaQAaTGFQ Message-ID: <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsVyYMU1HV0Nxu4AgyZ2iw2fr7FZ3Fr/hdVi UeNiVouPF36yOLB4XFoym9FjwaZSjyVLfjJ5fJ59lTmAJYrLJiU1J7MstUjfLoErY9fLa2wF MyUrum9+Y2pg/CzcxcjJISFgIrHn3ksWCFtM4sK99WxdjFwcQgIfGCVuXO9jgnBeMUq8fnyY HcJZxSjRPquDHaSFTUBPYsvjK2C2iICXxL+Vt8FGMQtESizZ0M8KYrMIqEpMu9oBFhcWsJQ4 eOQzG0S9lcS3PU2MELaRxOlrR5lAbF6BKIlp+5ugNu/kkGg/cRZsAadAoMTchTOZQWxGoFu/ n1rDBLFMXOLWk/lMED8ISCzZc54ZwhaVePn4HytEvajEnfb1jBD1OhILdn9ig7C1JZYtfM0M sVhQ4uTMJywTGMVnIRk7C0nLLCQts5C0LGBkWcUoU1JabFicW5JfWlKQWmFgpFdcmZsIjMVk veT83E2MwHi8wXX40w7GG0sVDzEKcDAq8fBKvO0KEGJNLAOqPMQowcGsJMJbdAwoxJuSWFmV WpQfX1Sak1p8iFGag0VJnFfQKTpASCA9sSQ1OzW1ILUIJsvEwSnVwOgUNf/AYsb46+Iz0iOa 9zJrvDspOmctb/+Cec82HmLZeMyFa98U+8O3OZn2BwlUZ03Y9P/77jQNBxYN/knz581+I5+i HVN4VfHHDMc5ctESid8mpP/t0rc1zTa9fiGoIEnU4+zrkt28eeZ1T7c8f3K18szxGMfL9X/S tvxy3HvsvOY67YrrEdeUWIozEg21mIuKEwFsyQxLwwIAAA== Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 21:31:21 -0000 > -----Original Message----- > From: Ben Laurie [mailto:benl@google.com] > Sent: Friday, October 26, 2012 1:51 AM > To: Rob Stradling > Cc: Rick Andrews; therightkey@ietf.org; Paul Hoffman > Subject: Re: [therightkey] Other solutions to the problem >=20 > On 26 October 2012 09:24, Rob Stradling > wrote: > > On 26/10/12 00:58, Rick Andrews wrote: > > > > > >> AFAICT, for CT to really work it will require participation from > every CA > >> whose roots are in browsers. I think you're underestimating how hard > it will > >> be to achieve that. > > > > > > Rick, > > > > Ultimately, assuming the RFC5878 TLS extension gains widespread > support in > > server and client software, CT won't _require_ participation from any > CA. > > Each certificate holder will be able to configure their server to > send their > > certificate's CT proof to each client. I see, so the certificate holder can submit their newly-minted certificate = to a log server to get a CT proof. Instead of requiring the participation o= f every CA, you now require the participation of every certificate holder. = You might say that not every certificate holder will need or want CT, but I= would guess that the number that would want the protection would be far gr= eater than the number of CAs. > > But with participation from the CAs, it should be possible to realize > the CT > > dream far sooner. And (even in a future world where RFC5878 is > supported > > everywhere) if the CA takes care of CT proof distribution, then that > makes > > life easier for the certificate holder. > > > > > >> Further, no one has yet brought up the privacy issue. CAs sell a lot > of > >> certificates to companies for their internal use. Some of them may > object to > >> publishing all their internal domain names. > > > > > > This has been a concern for Comodo too, so I spoke to AGL about it a > few > > weeks ago. AIUI, the plan is that CT clients will have a user- > configurable > > whitelist (empty by default) of domain names for which CT proofs will > not be > > required. Participating CAs should allow customers to opt-out from > having > > their certs automatically logged with CT. I believe in your plan each browser will be a CT client. Aside from the fac= t that the white list is an attractive target for hackers, I don't see how = the average user is going to know how to configure this white list. I'm rem= inded of Adam's arguments against Convergence (http://www.imperialviolet.or= g/2011/09/07/convergence.html). > I think there are at least three options >=20 > 1. As you say, users (or admins might be a little safer) configure > domains to be opted-out. >=20 > 2. Private certs are issued by private CAs (I mean the CA certificate, > of course) which are marked "do not log". This option will not be > available for default CAs. >=20 > 3. Private certs are issued under a name-constrained intermediate > which is logged. >=20 > BTW, Rick, this has come up before, I thought on public lists, but > perhaps I am misremembering. I prefer 3, BTW, because it is not a > mechanism which users can be conned into invoking. From leifj@mnt.se Sat Oct 27 03:56:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3648C21F849B for ; Sat, 27 Oct 2012 03:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeAiJMBy4qAC for ; Sat, 27 Oct 2012 03:56:06 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58B2921F8458 for ; Sat, 27 Oct 2012 03:55:56 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3197250lam.31 for ; Sat, 27 Oct 2012 03:55:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=VNEmRPpCrzKCKmb5C7IiSQwR7JszTnZ6HtQminwOhy0=; b=WWzT+NGUq4/TeXssvvjVEpC2DK4Oc4UtOcUUJsNDW94V+fLSQnh2RgWk5mP0dieMrL r+bYFN2TSDvCLmg23CTZEpIH09d5kgFZJH0sUQwdb2MjNA2HNyQdcEuNMuxNDQZIunYJ ebLJSVhrjLyBcqxmu0m40BAeBxGXT0fluGYJka8hnYe0ElJLoCRMXfASLS3BlHUJuMQy PhQub/vNaEOF/Bp+prx8VGXRl4ZWYITeX03hqLwXP9byv7XQEQhlpTqIoFCaGb5CyZH2 VEO9FUx0zM9Bh6Kwa1FVQ445KEZw4xZLXAOyHxJ4FcrV+FixJK+GfoKl5IctBardvdtf pEVw== Received: by 10.112.47.228 with SMTP id g4mr9251230lbn.21.1351335356081; Sat, 27 Oct 2012 03:55:56 -0700 (PDT) Received: from [2.65.107.195] (2.65.107.195.mobile.tre.se. [2.65.107.195]) by mx.google.com with ESMTPS id b8sm1247983lbn.8.2012.10.27.03.55.53 (version=SSLv3 cipher=OTHER); Sat, 27 Oct 2012 03:55:55 -0700 (PDT) References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Mime-Version: 1.0 (1.0) In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <33430510-0B20-441F-85EF-43B05C6E1BE0@mnt.se> X-Mailer: iPhone Mail (10A403) From: Leif Johansson Date: Sat, 27 Oct 2012 12:55:50 +0200 To: Rick Andrews X-Gm-Message-State: ALoCoQkycWmBoKjR/WIpIilzbtxjL88QT59mPAsxGIsmuoVhvy3CVru2A5vrrqwPclpFZCJ+g7fI Cc: "therightkey@ietf.org" , Paul Hoffman Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 10:56:07 -0000 >=20 > The problem is that any CA can issue a certificate for a given domain name= and all browsers will trust it. CT allows Paypal (just an example) to detec= t that some unexpected CA issued a cert for one of their domains. If CAA is u= sed by the CA being hacked, their system should refuse to issue the cert to P= aypal's domain. DANE or cert When a CA is hacked I think we can safely assume that the 'system' can be tr= icked into doing whatever the attacker wants it to do. Including overriding C= AA policy. Leif= From benl@google.com Mon Oct 29 03:10:20 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB14321F854C for ; Mon, 29 Oct 2012 03:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.563 X-Spam-Level: X-Spam-Status: No, score=-100.563 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9228noN-7haW for ; Mon, 29 Oct 2012 03:10:20 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD1D21F8495 for ; Mon, 29 Oct 2012 03:10:19 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1665983wib.13 for ; Mon, 29 Oct 2012 03:10: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:content-transfer-encoding:x-system-of-record; bh=oqSwJeZX5bLXLkbAxqxgmkG/LTdkKWyOniKD/QlQVZg=; b=T05QTEJXz8nAc/pktVy0Nmr7+5ooQMByIanJWL9wfYUgoptiOdFtUBvOqjclcG6QaK HG/LJ9ThH5a5RHNbRy+lfLGWul9jhVW+KPqYk13/z6Mb8/O5M/QmUCYlONva1IugnZDJ 0SqclGnZURhd/MCOoQJaqLZkiYUlqQzfHIkc2hlTFEVPxc8VOJrc2pNG8bvteEqt6wHn nIzM4vaK2Blqz1DYo06dN85IZKCnS+pm82oCP/JPCGlTpQAxRq4Dv6lQFo3ZIYh19Iuj FzNTeK5Sce8YrEr07oaOZgSjJUq6JNL69cNxtoSTkQTcNuPouXRVMvcG0r8ItmjH4543 uplA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=oqSwJeZX5bLXLkbAxqxgmkG/LTdkKWyOniKD/QlQVZg=; b=O+7agWjVFBTkXzRmbQJ1xAJ9oPemiDyZU7P7GME9YGJ54Ub/iZTjkzi+ruenGhMoW5 migQOc03zIrpjn+z2ZRjziKzI420ySJgB9BEnnJjBRzPklMcuappS9uGwuGj4yZkE94D ypfRvoMtpWRtQGDw9gjH2NzZw9alcXDrp69RVt/d/kjq8mkydssoHnZ28u7HHQRP3sHv oWjgdsuBNKK544GBvS3T3T4z0QAPJiM2Ty9cCQRMcaj/qbf3kCUMiGgg3wWXU+xye8Ks 8iUu88BN23vuyFDScDTJ0cyvs1UFR3QE/2Gi8E02usClyz6TdOae7WOTH9+FmJoJVnhq rIKQ== MIME-Version: 1.0 Received: by 10.180.94.226 with SMTP id df2mr14289830wib.11.1351505418578; Mon, 29 Oct 2012 03:10:18 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Mon, 29 Oct 2012 03:10:18 -0700 (PDT) In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Mon, 29 Oct 2012 10:10:18 +0000 Message-ID: From: Ben Laurie To: Rick Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQn7BHXbzD9uOF4XA/U5asRcYW22RALCkgLMjFtO9PQg59k/cYa0LzpcvC8Jt8oodPbAyE7rCWa0ff0fJGJFTdpniQ1olPu36192HBjufS4lRkFmQT+ZTdwujTlGG4KCmFm3RWuWD5YBkEdjPH5Bv3plmkhrYjofSROoWjNGhQgweAHy6CyT/7wZ+vPccpz6npJJMt87 Cc: "therightkey@ietf.org" , Rob Stradling , Paul Hoffman Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 10:10:21 -0000 On 26 October 2012 22:31, Rick Andrews wrote: >> -----Original Message----- >> From: Ben Laurie [mailto:benl@google.com] >> Sent: Friday, October 26, 2012 1:51 AM >> To: Rob Stradling >> Cc: Rick Andrews; therightkey@ietf.org; Paul Hoffman >> Subject: Re: [therightkey] Other solutions to the problem >> >> On 26 October 2012 09:24, Rob Stradling >> wrote: >> > On 26/10/12 00:58, Rick Andrews wrote: >> > >> > >> >> AFAICT, for CT to really work it will require participation from >> every CA >> >> whose roots are in browsers. I think you're underestimating how hard >> it will >> >> be to achieve that. >> > >> > >> > Rick, >> > >> > Ultimately, assuming the RFC5878 TLS extension gains widespread >> support in >> > server and client software, CT won't _require_ participation from any >> CA. >> > Each certificate holder will be able to configure their server to >> send their >> > certificate's CT proof to each client. > > I see, so the certificate holder can submit their newly-minted certificat= e to a log server to get a CT proof. Instead of requiring the participation= of every CA, you now require the participation of every certificate holder= . No, it is an option. >You might say that not every certificate holder will need or want CT, but = I would guess that the number that would want the protection would be far g= reater than the number of CAs. Given that the plan is browsers will refuse non-CTed certs, I imagine most holder of certificates used by the public will want CT. >> > But with participation from the CAs, it should be possible to realize >> the CT >> > dream far sooner. And (even in a future world where RFC5878 is >> supported >> > everywhere) if the CA takes care of CT proof distribution, then that >> makes >> > life easier for the certificate holder. >> > >> > >> >> Further, no one has yet brought up the privacy issue. CAs sell a lot >> of >> >> certificates to companies for their internal use. Some of them may >> object to >> >> publishing all their internal domain names. >> > >> > >> > This has been a concern for Comodo too, so I spoke to AGL about it a >> few >> > weeks ago. AIUI, the plan is that CT clients will have a user- >> configurable >> > whitelist (empty by default) of domain names for which CT proofs will >> not be >> > required. Participating CAs should allow customers to opt-out from >> having >> > their certs automatically logged with CT. > > I believe in your plan each browser will be a CT client. Aside from the f= act that the white list is an attractive target for hackers, I don't see ho= w the average user is going to know how to configure this white list. I'm r= eminded of Adam's arguments against Convergence (http://www.imperialviolet.= org/2011/09/07/convergence.html). This is why I think the best solution is to issue private certs through a name constrained intermediate which is logged. >> I think there are at least three options >> >> 1. As you say, users (or admins might be a little safer) configure >> domains to be opted-out. >> >> 2. Private certs are issued by private CAs (I mean the CA certificate, >> of course) which are marked "do not log". This option will not be >> available for default CAs. >> >> 3. Private certs are issued under a name-constrained intermediate >> which is logged. >> >> BTW, Rick, this has come up before, I thought on public lists, but >> perhaps I am misremembering. I prefer 3, BTW, because it is not a >> mechanism which users can be conned into invoking. From benl@google.com Mon Oct 29 03:13:02 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38C021F85E4 for ; Mon, 29 Oct 2012 03:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.77 X-Spam-Level: X-Spam-Status: No, score=-101.77 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yV5Qfdn8XVBE for ; Mon, 29 Oct 2012 03:13:02 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id C166E21F8470 for ; Mon, 29 Oct 2012 03:13:01 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1667677wib.13 for ; Mon, 29 Oct 2012 03:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=maOzH0zVFD5N2pUq6yFBzlW2NPOpjj3ZMHkLhYoj/zw=; b=UQRL5BcUXTsqeUA3adpUaKNIeW4kmjZckgbOOt08L6+CCQvpYm/d2Zi8ithRnOSzu1 5xHTQtSdeR1w+0xYUWBy9nZIDV7iJg9HkKBuxz5THFhbart4F7LBIyMbEKl7TZUWvsxz Dm79QRURpzQIO9X3UoIf6aB64VEzIs0j+4uy2NjuHVE6k5pXoU121N9RDoFLEr/a1Dd+ 9zePYODoVDB728FmagfI7BHZ4/2TVBXezLmhUjX2z7u6ZtaGCOsTGpyKZlcDcOQLnBlq 2uX99cC3UB9x+D1WF3rAsvZ11p58EWoiIz4Vb7YavfGi2cDKD7zhosZYuZVVJcFW7J8g 5ycA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=maOzH0zVFD5N2pUq6yFBzlW2NPOpjj3ZMHkLhYoj/zw=; b=WAhzw7QQ+o07peB02hBq+dXOJ80DuCHAb2SdDUuPbCIIUFDQNQPGd4lIcnzwUeRKeF Ck2axAFZwKdVRlSXK7xPYqXFkoy1xRgTxGydISzFB9eR2ijeF97Yuva2hfdbDgwbGOXY s3xHfOOMmfs5hD0SaAWnNQQfuODkyGvpvTxubep5nen8+boxi0WJ4Z9cbG4xtCxRvZ+U QVuDay5u+UNZPBBYOQtkOkm7QJdD8crUCmRPuxQGzgz/eY4hoz0zH0bxFHiCN1Ucy3F9 ZWriATsJc8+iU5q++BhrOOyX+Ko3w3GHHsHo5Jlnd0MYH0Ulawx/SG+ehmHhGZ/HxCN5 NtIQ== MIME-Version: 1.0 Received: by 10.216.140.205 with SMTP id e55mr15109386wej.2.1351505580848; Mon, 29 Oct 2012 03:13:00 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Mon, 29 Oct 2012 03:13:00 -0700 (PDT) In-Reply-To: References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> Date: Mon, 29 Oct 2012 10:13:00 +0000 Message-ID: From: Ben Laurie To: Rick Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkGif1id/BAZ1MkQItbWdPYx17rnD396CJt7UhLXa6qyiDy1fcWPIJNZhfjFXbzvzKrk+gER0lT8X3bK/ZeZe9320wjUs2mKynLe22WhYJO9IQ5qNYy2F5ENXIwQ9eVHchGmsa0u9GrXO8vbcjNe5WIkiD7WqiyTyg0f40KIuSjGlikXdnh7UW5t8RCz8Ik0e/Hz/dT Cc: "therightkey@ietf.org" , Rob Stradling , Paul Hoffman Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 10:13:02 -0000 On 29 October 2012 10:10, Ben Laurie wrote: >> I believe in your plan each browser will be a CT client. Aside from the = fact that the white list is an attractive target for hackers, I don't see h= ow the average user is going to know how to configure this white list. I'm = reminded of Adam's arguments against Convergence (http://www.imperialviolet= .org/2011/09/07/convergence.html). > > This is why I think the best solution is to issue private certs > through a name constrained intermediate which is logged. Or, as I mentioned above, through a private CA which is marked as "do not log". I would not expect users to configure this, rather the sysadmins of their corp machines. BTW, a domain whitelist seems like a terrible idea: then attackers could freely forge certificates in that whitelist, even if it was configured correctly. > >>> I think there are at least three options >>> >>> 1. As you say, users (or admins might be a little safer) configure >>> domains to be opted-out. >>> >>> 2. Private certs are issued by private CAs (I mean the CA certificate, >>> of course) which are marked "do not log". This option will not be >>> available for default CAs. >>> >>> 3. Private certs are issued under a name-constrained intermediate >>> which is logged. >>> >>> BTW, Rick, this has come up before, I thought on public lists, but >>> perhaps I am misremembering. I prefer 3, BTW, because it is not a >>> mechanism which users can be conned into invoking. From rob.stradling@comodo.com Mon Oct 29 04:00:30 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8E821F85BB for ; Mon, 29 Oct 2012 04:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSYqisugH+1S for ; Mon, 29 Oct 2012 04:00:29 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2A40521F85B8 for ; Mon, 29 Oct 2012 04:00:28 -0700 (PDT) Received: (qmail 23672 invoked from network); 29 Oct 2012 11:00:27 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 29 Oct 2012 11:00:27 -0000 Received: (qmail 29100 invoked by uid 1000); 29 Oct 2012 11:00:26 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 29 Oct 2012 11:00:26 +0000 Message-ID: <508E61C9.2060001@comodo.com> Date: Mon, 29 Oct 2012 11:00:25 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <508AB760.7050803@cs.tcd.ie> In-Reply-To: <508AB760.7050803@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] How many documents? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 11:00:30 -0000 Hi Stephen. Last month Ben posted this: "Emilia Kasper and I came up with a mechanism for providing revocation transparency. We currently have no plans to implement it, but the mechanism is interesting. Blog post here: http://www.links.org/?p=1272 Paper here: http://sump2.links.org/files/RevocationTransparency.pdf" And in his draft charter he wrote: "Optionally, do the same for certificate revocations." CT will only be effective if: 1. "browsers will refuse non-CTed certs" (to quote Ben). 2. Effective revocation mechanisms exist, so that dodgy certs brought to light by CT can be effectively dealt with. I think RT would definitely be a good project for a Transparency WG to take on after CT. I don't have a strong opinion about this, but I think it might make sense to split up the CT standardization effort into multiple documents, because different audiences will be interested in different aspects of CT. i.e. - One document aimed at the people who will implement and/or operate CT log servers. - One document aimed at CAs who will implement pre-certs and/or embed proofs into OCSP Responses. - One document aimed at browser authors who will write code to verify proofs. - One document aimed at webserver authors who will need to understand the importance of implementing RFC5878 and/or OCSP Stapling (RFC6066). - One document aimed at auditors who will need to know how to verify that a CT log has not been compromised. - One document aimed at domain owners who will need to know i) how to discover if any certs have been misissued to their domain names and ii) what to do about any detected misissuances. Given the imminent closure of the PKIX WG, I'm tempted to also suggest... - One document that will define requirements for "Effective revocation mechanisms". On 26/10/12 17:16, Stephen Farrell wrote: > > Hiya, > > I know we're not having a wg-forming BoF but there's a > thing I think I'd like to see discussed at or before > the BoF that'd normally be part of a wg-forming BoF but > is still worth doing now. (Discussing this on the list > since we've all read the draft is even better of > course:-) > > Assuming for the moment that we do go ahead and > standardise CT, how many documents (RFCs) ought be > used to document that? > > If the answer turns out to be one, then it might be more > efficient to process CT as an AD sponsored draft, so if > your answer to the above is 1, then I'd like input about > doing that or not doing that. > > If the answer is more than one, then what might those > be, and are there dependencies on other IETF WGs or > external groups? Clearly, if the answer is more than > one non-wg draft, that means that AD sponsoring is > less likely and a WG is likely needed. If you think > this is the case, it'd be good to see your suggestion > for what RFCs ought be produced. > > I guess I'm sort of asking for suggestions as to what > milestones a WG might adopt if we were to form one. > I do realise that this is only part of the discussion > that we need to have, and is contingent on us wanting > to do something with CT, but I've not seen it raised > so far, so thought I'd kick that off. > > If you're not sure about the process parts of the > above (e.g. "AD sponsored") please just ask. Paul > or I can answer that. > > Thanks, > S. > > PS: Its ok to give your answer to this even if you > think that CT should not be standardised in the IETF. > If that's the case maybe say so if you want. > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From benl@google.com Mon Oct 29 04:06:46 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF85521F85B6 for ; Mon, 29 Oct 2012 04:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx1UIEbXwt5t for ; Mon, 29 Oct 2012 04:06:45 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A38421F85FA for ; Mon, 29 Oct 2012 04:06:44 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2638098wey.31 for ; Mon, 29 Oct 2012 04:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=sdF+qxgVgXKZjt3ZMBwFN7ndkDHfwGWwBAsLC1/6oIc=; b=DhnBqOfMa4b1XDr5Izc7+RMf2fy+ME5CZeS8QJaamQwCm5Q9PHYU2viunApDZzW1Db EasWPYVnwMqE5PtW8BAxXpndlkd7n+7v3HmOLHhZcQW4vgddHAZi4aIPUwpZN6x3FMce iE4d/GO1gbuJ2UF0bhdzg8jgsGtbxqLHDcaS0yjBFe8Jdyf71VsuG0xAxlaNYJGJsiee ne+lqqHPYuRLEPAGHwKhYjOA8kIoAh4YWA7UNS2vb7NiKOENrKhhnNl5yAB84IGz+u+w n2xqEgzAX1IZvYktj9hn9yaJdSrzDZUxv7Q1cDNrfyGzkaPmwkyh9qJVpmki2O2CbLiF q6gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=sdF+qxgVgXKZjt3ZMBwFN7ndkDHfwGWwBAsLC1/6oIc=; b=pEBfC2HVKloPVm8iq1tVbvF7ApHeKhJ6RYPpeVwzawdDHok8nUSqw7WqfHvGm9CHPu OIhk2GnQVXD4ogULCkQpxUWUx0sGrUGG35hsXf2M5pOov6kz1aOx+zjqXECQ9e5Q+P6U lC6cUfA5ELuPrV7K91FdQ2oZibSMxuQAHvknjFvb2SMHbYWho6hO5C8M0ggF6USEWndz WqMg8LwpQL3xzXrwRZo7O6mmKHznFB0QKcuKWmAtY7Vs9/esb4ihDPN84zA9aEVOYpoh gHElNXBu+dk24vmE6E5fQ8P+Rnu7zrwiEsbhDif4yUXUgw9lHsO4oCBApUJuVI1FVRQ3 pymg== MIME-Version: 1.0 Received: by 10.180.101.230 with SMTP id fj6mr14523594wib.16.1351508797715; Mon, 29 Oct 2012 04:06:37 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Mon, 29 Oct 2012 04:06:37 -0700 (PDT) In-Reply-To: <508E61C9.2060001@comodo.com> References: <508AB760.7050803@cs.tcd.ie> <508E61C9.2060001@comodo.com> Date: Mon, 29 Oct 2012 11:06:37 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnk39w7q29SLG2YzCoB0xmNMEJOr5MRy138UGjVRzNMYAV0Zmr0k0qjMBg3HREQiVE4EspEatK5IKCd/TUDW33ahyvryw12ppsRPtkWUYBmUV1z0R2eJot+UJOZiqpFnx/4H/YxonSB+d8YPh/EilEEb8CaIeXqQ/0KjEemH4btqlZbfW8kIWFr1bj9a5xy4DPyQbbG Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] How many documents? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 11:06:46 -0000 On 29 October 2012 11:00, Rob Stradling wrote: > Hi Stephen. > > Last month Ben posted this: > "Emilia Kasper and I came up with a mechanism for providing revocation > transparency. We currently have no plans to implement it, but the > mechanism is interesting. > Blog post here: http://www.links.org/?p=1272 > Paper here: http://sump2.links.org/files/RevocationTransparency.pdf" > > And in his draft charter he wrote: > "Optionally, do the same for certificate revocations." > > CT will only be effective if: > 1. "browsers will refuse non-CTed certs" (to quote Ben). > 2. Effective revocation mechanisms exist, so that dodgy certs brought to > light by CT can be effectively dealt with. > > I think RT would definitely be a good project for a Transparency WG to take > on after CT. > > > I don't have a strong opinion about this, but I think it might make sense to > split up the CT standardization effort into multiple documents, because > different audiences will be interested in different aspects of CT. i.e. > - One document aimed at the people who will implement and/or operate CT > log servers. > - One document aimed at CAs who will implement pre-certs and/or embed > proofs into OCSP Responses. > - One document aimed at browser authors who will write code to verify > proofs. > - One document aimed at webserver authors who will need to understand the > importance of implementing RFC5878 and/or OCSP Stapling (RFC6066). > - One document aimed at auditors who will need to know how to verify that > a CT log has not been compromised. > - One document aimed at domain owners who will need to know i) how to > discover if any certs have been misissued to their domain names and ii) what > to do about any detected misissuances. TBH, I disagree - the reason being that almost all of these documents will be identical (i.e. describing the cryptographic structure of the log) and the only differences will be which parts of the protocol they use - some of which will inevitably overlap. Right now the document is lacking a few of these areas, but it is by no means unwieldy. I think splitting across multiple documents will create a lot of pointless duplication and effort. > Given the imminent closure of the PKIX WG, I'm tempted to also suggest... > - One document that will define requirements for "Effective revocation > mechanisms". Not against that at all, but it sounds like a different WG to me. > > > > On 26/10/12 17:16, Stephen Farrell wrote: >> >> >> Hiya, >> >> I know we're not having a wg-forming BoF but there's a >> thing I think I'd like to see discussed at or before >> the BoF that'd normally be part of a wg-forming BoF but >> is still worth doing now. (Discussing this on the list >> since we've all read the draft is even better of >> course:-) >> >> Assuming for the moment that we do go ahead and >> standardise CT, how many documents (RFCs) ought be >> used to document that? >> >> If the answer turns out to be one, then it might be more >> efficient to process CT as an AD sponsored draft, so if >> your answer to the above is 1, then I'd like input about >> doing that or not doing that. >> >> If the answer is more than one, then what might those >> be, and are there dependencies on other IETF WGs or >> external groups? Clearly, if the answer is more than >> one non-wg draft, that means that AD sponsoring is >> less likely and a WG is likely needed. If you think >> this is the case, it'd be good to see your suggestion >> for what RFCs ought be produced. >> >> I guess I'm sort of asking for suggestions as to what >> milestones a WG might adopt if we were to form one. >> I do realise that this is only part of the discussion >> that we need to have, and is contingent on us wanting >> to do something with CT, but I've not seen it raised >> so far, so thought I'd kick that off. >> >> If you're not sure about the process parts of the >> above (e.g. "AD sponsored") please just ask. Paul >> or I can answer that. >> >> Thanks, >> S. >> >> PS: Its ok to give your answer to this even if you >> think that CT should not be standardised in the IETF. >> If that's the case maybe say so if you want. >> >> >> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > COMODO CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender by > replying to the e-mail containing this attachment. Replies to this email may > be monitored by COMODO for operational or business reasons. Whilst every > endeavour is taken to ensure that e-mails are free from viruses, no > liability can be accepted and the recipient is requested to use their own > virus checking software. > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From rob.stradling@comodo.com Mon Oct 29 04:18:02 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB87621F861E for ; Mon, 29 Oct 2012 04:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhfSj9VhOdQQ for ; Mon, 29 Oct 2012 04:18:02 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id DB43A21F8525 for ; Mon, 29 Oct 2012 04:18:01 -0700 (PDT) Received: (qmail 30278 invoked from network); 29 Oct 2012 11:18:00 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 29 Oct 2012 11:18:00 -0000 Received: (qmail 20310 invoked by uid 1000); 29 Oct 2012 11:18:00 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 29 Oct 2012 11:18:00 +0000 Message-ID: <508E65E8.1010906@comodo.com> Date: Mon, 29 Oct 2012 11:18:00 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ben Laurie References: <508AB760.7050803@cs.tcd.ie> <508E61C9.2060001@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] How many documents? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 11:18:02 -0000 On 29/10/12 11:06, Ben Laurie wrote: > On 29 October 2012 11:00, Rob Stradling wrote: >> I don't have a strong opinion about this, but I think it might make sense to >> split up the CT standardization effort into multiple documents, because >> different audiences will be interested in different aspects of CT. i.e. >> - One document aimed at the people who will implement and/or operate CT >> log servers. >> - One document aimed at CAs who will implement pre-certs and/or embed >> proofs into OCSP Responses. >> - One document aimed at browser authors who will write code to verify >> proofs. >> - One document aimed at webserver authors who will need to understand the >> importance of implementing RFC5878 and/or OCSP Stapling (RFC6066). >> - One document aimed at auditors who will need to know how to verify that >> a CT log has not been compromised. >> - One document aimed at domain owners who will need to know i) how to >> discover if any certs have been misissued to their domain names and ii) what >> to do about any detected misissuances. > > TBH, I disagree - the reason being that almost all of these documents > will be identical (i.e. describing the cryptographic structure of the > log) and the only differences will be which parts of the protocol they > use - some of which will inevitably overlap. Right now the document is > lacking a few of these areas, but it is by no means unwieldy. I think > splitting across multiple documents will create a lot of pointless > duplication and effort. OK, scrap that idea then. :-) >> Given the imminent closure of the PKIX WG, I'm tempted to also suggest... >> - One document that will define requirements for "Effective revocation >> mechanisms". > > Not against that at all, but it sounds like a different WG to me. Maybe so. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From stephen.farrell@cs.tcd.ie Mon Oct 29 04:58:30 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C808F21F85C6 for ; Mon, 29 Oct 2012 04:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBBz2r6GebnS for ; Mon, 29 Oct 2012 04:58:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DF22E21F8554 for ; Mon, 29 Oct 2012 04:58:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BCCABC7AD; Mon, 29 Oct 2012 11:58:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbrV6kfrNSks; Mon, 29 Oct 2012 11:58:03 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.42.30.34]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EF4B5C7AE; Mon, 29 Oct 2012 11:58:02 +0000 (GMT) Message-ID: <508E6F4A.20809@cs.tcd.ie> Date: Mon, 29 Oct 2012 11:58:02 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: Rob Stradling References: <508AB760.7050803@cs.tcd.ie> <508E61C9.2060001@comodo.com> <508E65E8.1010906@comodo.com> In-Reply-To: <508E65E8.1010906@comodo.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Ben Laurie Subject: Re: [therightkey] How many documents? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 11:58:30 -0000 On 10/29/2012 11:18 AM, Rob Stradling wrote: > On 29/10/12 11:06, Ben Laurie wrote: >> On 29 October 2012 11:00, Rob Stradling wrote: > >>> I don't have a strong opinion about this, but I think it might make >>> sense to >>> split up the CT standardization effort into multiple documents, because >>> different audiences will be interested in different aspects of CT. i.e. >>> - One document aimed at the people who will implement and/or >>> operate CT >>> log servers. >>> - One document aimed at CAs who will implement pre-certs and/or embed >>> proofs into OCSP Responses. >>> - One document aimed at browser authors who will write code to verify >>> proofs. >>> - One document aimed at webserver authors who will need to >>> understand the >>> importance of implementing RFC5878 and/or OCSP Stapling (RFC6066). >>> - One document aimed at auditors who will need to know how to >>> verify that >>> a CT log has not been compromised. >>> - One document aimed at domain owners who will need to know i) how to >>> discover if any certs have been misissued to their domain names and >>> ii) what >>> to do about any detected misissuances. >> >> TBH, I disagree - the reason being that almost all of these documents >> will be identical (i.e. describing the cryptographic structure of the >> log) and the only differences will be which parts of the protocol they >> use - some of which will inevitably overlap. Right now the document is >> lacking a few of these areas, but it is by no means unwieldy. I think >> splitting across multiple documents will create a lot of pointless >> duplication and effort. > > OK, scrap that idea then. :-) Well.... maybe not quite so quickly. I think its a real issue that a single document might be difficult for all those audiences. Now, I don't think the IETF actually ought try address all of those audiences, since RFCs are for the folks writing code, and mostly not for auditors or CA/web site operators, though we do do some of the latter sometimes. But I still wonder if 1 or >1 document is right, and as Ben says the current draft is a bit sketchy in some areas that might or might not be better separated out. Perhaps the right answer will turn out to be to look at the draft later when those areas are more developed, but I'm asking now anyway:-) >>> Given the imminent closure of the PKIX WG, I'm tempted to also >>> suggest... >>> - One document that will define requirements for "Effective >>> revocation >>> mechanisms". >> >> Not against that at all, but it sounds like a different WG to me. > > Maybe so. Right, or a later milestone after a re-charter if we end up with a WG. At this point, I'd guess that anyone wanting revocation considered sooner would need to be yelling (and since they haven't written an I-D, they'd need to be quite convincing as to why yelling with no I-D is appropriate). S. From benl@google.com Mon Oct 29 11:23:41 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED6721F8702 for ; Mon, 29 Oct 2012 11:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U5H30B309nF for ; Mon, 29 Oct 2012 11:23:40 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id D012C21F86EA for ; Mon, 29 Oct 2012 11:23:39 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so2038304wib.13 for ; Mon, 29 Oct 2012 11:23: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:x-system-of-record; bh=XFSerc+uI/In+9xGqt7ytnTAxmTnYWMe0Xp0DS/BWbw=; b=eyqqTg1oFXyNuSL8+7ay4sjIqy2dMRK/nB1qDnFDlKPTE0RIvdtqjwCT2EhO1scXLt JVA6dvOh933JR8rSMWFXlSQjWc9M7hc106dbnTppSHRLJFav6ynzCCkQuqPPHBecZeaP 5QL5qoe+kDZhB2KTydI7GNGyXAv1ezk8QGVbAyeLdymhOxqzKG0rGxxQ5PmoaZ8uhHW+ RiRdlGTZ6W/HyW+chJNt4/3Ozfxfcd1EFcX7TkGmFQ6UT4CrfYW0tLdLH3InZEqTcQvd yGJ2y6JJRKlGNevm36jnIrZkFLEuqA+sZ1ol3fFoJysmI6LQLyuI5SoxkOlQRCBBEQnr B0tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=XFSerc+uI/In+9xGqt7ytnTAxmTnYWMe0Xp0DS/BWbw=; b=Ad/uvm0AMObQSjhRYPUJnna+XeVSVmOx3wUWTtx1p8SkfKIHasStY8rfwVmlPtG7oo KWTmgSn5D1Sda1dsqDh8nIJnR45gHatKZv3DOQGygCA/vQ6fao2leP+gd2tghhmqHVue pMo4nUnK9iADSL485Yw2I2LEb3sdnPMQJvEI9QBLlaP4W9uJNY8GP60r0rqo3koQsteO cNDYVecjr8JIe72wsLWkNf7fIUIrm36eaKJcwiU40/vO+B8qjt4CgrY87xGfAFVmIuxQ E0HOXoniAvoH8B6eKh66GSt5sb0QRTzb0kLEdwGq4eWUZ1DMFrqa49Fq1f+PPItctZCI 7yJQ== MIME-Version: 1.0 Received: by 10.181.11.167 with SMTP id ej7mr16566866wid.11.1351535018902; Mon, 29 Oct 2012 11:23:38 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Mon, 29 Oct 2012 11:23:38 -0700 (PDT) In-Reply-To: <508E6F4A.20809@cs.tcd.ie> References: <508AB760.7050803@cs.tcd.ie> <508E61C9.2060001@comodo.com> <508E65E8.1010906@comodo.com> <508E6F4A.20809@cs.tcd.ie> Date: Mon, 29 Oct 2012 18:23:38 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm9BNg9uF/Kub3+qDF8Rs2nnFbiMIBYKrToQcweeOQ3Ev4hME1TU/P4c3whR7CwFcC5RlL333GwqCxgX07YAHT8jEA7qwzkFVgRv7p6XgMq1ukv6ia3OGhgpqiQ+Z6TRWYcbTGtz8+RdQIXeL8oke5mHDM84LiFyf15S6obRlSA27djNZNIAJJJ4AJN49uDBZ5DGjsC Cc: "therightkey@ietf.org" , Rob Stradling Subject: Re: [therightkey] How many documents? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 18:23:41 -0000 On 29 October 2012 11:58, Stephen Farrell wrote: > > > On 10/29/2012 11:18 AM, Rob Stradling wrote: >> On 29/10/12 11:06, Ben Laurie wrote: >>> On 29 October 2012 11:00, Rob Stradling wrote: >> >>>> I don't have a strong opinion about this, but I think it might make >>>> sense to >>>> split up the CT standardization effort into multiple documents, because >>>> different audiences will be interested in different aspects of CT. i.e. >>>> - One document aimed at the people who will implement and/or >>>> operate CT >>>> log servers. >>>> - One document aimed at CAs who will implement pre-certs and/or embed >>>> proofs into OCSP Responses. >>>> - One document aimed at browser authors who will write code to verify >>>> proofs. >>>> - One document aimed at webserver authors who will need to >>>> understand the >>>> importance of implementing RFC5878 and/or OCSP Stapling (RFC6066). >>>> - One document aimed at auditors who will need to know how to >>>> verify that >>>> a CT log has not been compromised. >>>> - One document aimed at domain owners who will need to know i) how to >>>> discover if any certs have been misissued to their domain names and >>>> ii) what >>>> to do about any detected misissuances. >>> >>> TBH, I disagree - the reason being that almost all of these documents >>> will be identical (i.e. describing the cryptographic structure of the >>> log) and the only differences will be which parts of the protocol they >>> use - some of which will inevitably overlap. Right now the document is >>> lacking a few of these areas, but it is by no means unwieldy. I think >>> splitting across multiple documents will create a lot of pointless >>> duplication and effort. >> >> OK, scrap that idea then. :-) > > Well.... maybe not quite so quickly. I think its a real issue > that a single document might be difficult for all those audiences. > > Now, I don't think the IETF actually ought try address all of > those audiences, since RFCs are for the folks writing code, and > mostly not for auditors or CA/web site operators, though we do do > some of the latter sometimes. I should point out that in this context an auditor is a technical term - an agent that, given some alleged entries from a log, audits that the log actually contains those entries, or given an alleged past snapshot of the log audits that it is consistent with the current log. Clients may well be auditors, too, but technically the roles can be separated. > But I still wonder if 1 or >1 document is right, and as Ben says > the current draft is a bit sketchy in some areas that might or > might not be better separated out. Perhaps the right answer will > turn out to be to look at the draft later when those areas are > more developed, but I'm asking now anyway:-) I am still holding out for a single document :-) > >>>> Given the imminent closure of the PKIX WG, I'm tempted to also >>>> suggest... >>>> - One document that will define requirements for "Effective >>>> revocation >>>> mechanisms". >>> >>> Not against that at all, but it sounds like a different WG to me. >> >> Maybe so. > > Right, or a later milestone after a re-charter if we end up > with a WG. At this point, I'd guess that anyone wanting revocation > considered sooner would need to be yelling (and since they > haven't written an I-D, they'd need to be quite convincing as to > why yelling with no I-D is appropriate). > > S. > From hallam@gmail.com Mon Oct 29 11:53:26 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223D421F8678 for ; Mon, 29 Oct 2012 11:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onO8eWs2+R-t for ; Mon, 29 Oct 2012 11:53:25 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0B3521F852A for ; Mon, 29 Oct 2012 11:53:24 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so5548469obq.31 for ; Mon, 29 Oct 2012 11:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fbCOqEIjuDDc6m/RuLqQbAzzBcCSxWI0paOq5eSRc+A=; b=EbRQdvT7XYWOyo/DQhynBNbRNj6Yl3lZ732L2M3J3KAMxZgTgbDnn27aVm2cBq2s4K +F+NC3iGC1j0yQlhlIMCb1gCpBZQwCfsl2wtiU73T2za0J72RxdtaneFjOZAjm8m7pYJ dSKLIkLO+0bBhvycGQXe13DmnE1jVXl5hL6iWSDdr8QMd6YM53Tw99CY2+VMmccwaVJ8 U7NKJD0G85C6RNJA2tSlET1PAx9LPk42I8lkKZWidT2OJz0TWpvWFSrgWZlHvlpImPwg +QLUWbwwdqyc+8TxBQcctwcX8YEd0f9Pd8b9/tALNX2M+lsYi3h9plZ2x/0HTXmJwtkP Kfxg== MIME-Version: 1.0 Received: by 10.182.113.5 with SMTP id iu5mr25782997obb.36.1351536804582; Mon, 29 Oct 2012 11:53:24 -0700 (PDT) Received: by 10.76.27.103 with HTTP; Mon, 29 Oct 2012 11:53:24 -0700 (PDT) In-Reply-To: References: <508AB760.7050803@cs.tcd.ie> <508E61C9.2060001@comodo.com> <508E65E8.1010906@comodo.com> <508E6F4A.20809@cs.tcd.ie> Date: Mon, 29 Oct 2012 14:53:24 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=f46d0447f1882355ab04cd372fbb Cc: "therightkey@ietf.org" , Rob Stradling , Stephen Farrell Subject: Re: [therightkey] How many documents? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 18:53:26 -0000 --f46d0447f1882355ab04cd372fbb Content-Type: text/plain; charset=ISO-8859-1 I very much doubt we will manage to get a finished spec with anything less than four documents since I can't remember offhand any case when we have not. But equally, I can't see a need for a split now. Going through four documents rather than one is tedious. In the longer term I see the parts of the spec that describe the notary formats and structure as being potentially re-usable in other contexts and that it will make sense to separate those out from the discussion of certs, PKI and such. On Mon, Oct 29, 2012 at 2:23 PM, Ben Laurie wrote: > On 29 October 2012 11:58, Stephen Farrell > wrote: > > > > > > On 10/29/2012 11:18 AM, Rob Stradling wrote: > >> On 29/10/12 11:06, Ben Laurie wrote: > >>> On 29 October 2012 11:00, Rob Stradling > wrote: > >> > >>>> I don't have a strong opinion about this, but I think it might make > >>>> sense to > >>>> split up the CT standardization effort into multiple documents, > because > >>>> different audiences will be interested in different aspects of CT. > i.e. > >>>> - One document aimed at the people who will implement and/or > >>>> operate CT > >>>> log servers. > >>>> - One document aimed at CAs who will implement pre-certs and/or > embed > >>>> proofs into OCSP Responses. > >>>> - One document aimed at browser authors who will write code to > verify > >>>> proofs. > >>>> - One document aimed at webserver authors who will need to > >>>> understand the > >>>> importance of implementing RFC5878 and/or OCSP Stapling (RFC6066). > >>>> - One document aimed at auditors who will need to know how to > >>>> verify that > >>>> a CT log has not been compromised. > >>>> - One document aimed at domain owners who will need to know i) how > to > >>>> discover if any certs have been misissued to their domain names and > >>>> ii) what > >>>> to do about any detected misissuances. > >>> > >>> TBH, I disagree - the reason being that almost all of these documents > >>> will be identical (i.e. describing the cryptographic structure of the > >>> log) and the only differences will be which parts of the protocol they > >>> use - some of which will inevitably overlap. Right now the document is > >>> lacking a few of these areas, but it is by no means unwieldy. I think > >>> splitting across multiple documents will create a lot of pointless > >>> duplication and effort. > >> > >> OK, scrap that idea then. :-) > > > > Well.... maybe not quite so quickly. I think its a real issue > > that a single document might be difficult for all those audiences. > > > > Now, I don't think the IETF actually ought try address all of > > those audiences, since RFCs are for the folks writing code, and > > mostly not for auditors or CA/web site operators, though we do do > > some of the latter sometimes. > > I should point out that in this context an auditor is a technical term > - an agent that, given some alleged entries from a log, audits that > the log actually contains those entries, or given an alleged past > snapshot of the log audits that it is consistent with the current log. > Clients may well be auditors, too, but technically the roles can be > separated. > > > But I still wonder if 1 or >1 document is right, and as Ben says > > the current draft is a bit sketchy in some areas that might or > > might not be better separated out. Perhaps the right answer will > > turn out to be to look at the draft later when those areas are > > more developed, but I'm asking now anyway:-) > > I am still holding out for a single document :-) > > > > >>>> Given the imminent closure of the PKIX WG, I'm tempted to also > >>>> suggest... > >>>> - One document that will define requirements for "Effective > >>>> revocation > >>>> mechanisms". > >>> > >>> Not against that at all, but it sounds like a different WG to me. > >> > >> Maybe so. > > > > Right, or a later milestone after a re-charter if we end up > > with a WG. At this point, I'd guess that anyone wanting revocation > > considered sooner would need to be yelling (and since they > > haven't written an I-D, they'd need to be quite convincing as to > > why yelling with no I-D is appropriate). > > > > S. > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > -- Website: http://hallambaker.com/ --f46d0447f1882355ab04cd372fbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I very much doubt we will manage to get a finished spec with anything less = than four documents since I can't remember offhand any case when we hav= e not. But equally, I can't see a need for a split now. Going through f= our documents rather than one is tedious.

In the longer term I see the parts of the spec that describe= the notary formats and structure as being potentially re-usable in other c= ontexts and that it will make sense to separate those out from the discussi= on of certs, PKI and such.


On Mon, Oct 29, 2012 at 2= :23 PM, Ben Laurie <benl@google.com> wrote:
On 29 October 2012 11:58, Stephen F= arrell <stephen.farrell@cs.= tcd.ie> wrote:
>
>
> On 10/29/2012 11:18 AM, Rob Stradling wrote:
>> On 29/10/12 11:06, Ben Laurie wrote:
>>> On 29 October 2012 11:00, Rob Stradling <rob.stradling@comodo.com> wrote:
>> <snip>
>>>> I don't have a strong opinion about this, but I think = it might make
>>>> sense to
>>>> split up the CT standardization effort into multiple docum= ents, because
>>>> different audiences will be interested in different aspect= s of CT. =A0i.e.
>>>> =A0 =A0- One document aimed at the people who will impleme= nt and/or
>>>> operate CT
>>>> log servers.
>>>> =A0 =A0- One document aimed at CAs who will implement pre-= certs and/or embed
>>>> proofs into OCSP Responses.
>>>> =A0 =A0- One document aimed at browser authors who will wr= ite code to verify
>>>> proofs.
>>>> =A0 =A0- One document aimed at webserver authors who will = need to
>>>> understand the
>>>> importance of implementing RFC5878 and/or OCSP Stapling (R= FC6066).
>>>> =A0 =A0- One document aimed at auditors who will need to k= now how to
>>>> verify that
>>>> a CT log has not been compromised.
>>>> =A0 =A0- One document aimed at domain owners who will need= to know i) how to
>>>> discover if any certs have been misissued to their domain = names and
>>>> ii) what
>>>> to do about any detected misissuances.
>>>
>>> TBH, I disagree - the reason being that almost all of these do= cuments
>>> will be identical (i.e. describing the cryptographic structure= of the
>>> log) and the only differences will be which parts of the proto= col they
>>> use - some of which will inevitably overlap. Right now the doc= ument is
>>> lacking a few of these areas, but it is by no means unwieldy. = I think
>>> splitting across multiple documents will create a lot of point= less
>>> duplication and effort.
>>
>> OK, scrap that idea then. =A0:-)
>
> Well.... maybe not quite so quickly. I think its a real issue
> that a single document might be difficult for all those audiences.
>
> Now, I don't think the IETF actually ought try address all of
> those audiences, since RFCs are for the folks writing code, and
> mostly not for auditors or CA/web site operators, though we do do
> some of the latter sometimes.

I should point out that in this context an auditor is a technic= al term
- an agent that, given some alleged entries from a log, audits that
the log actually contains those entries, or given an alleged past
snapshot of the log audits that it is consistent with the current log.
Clients may well be auditors, too, but technically the roles can be
separated.

> But I still wonder if 1 or >1 document is right, and as Ben says > the current draft is a bit sketchy in some areas that might or
> might not be better separated out. Perhaps the right answer will
> turn out to be to look at the draft later when those areas are
> more developed, but I'm asking now anyway:-)

I am still holding out for a single document :-)

>
>>>> Given the imminent closure of the PKIX WG, I'm tempted= to also
>>>> suggest...
>>>> =A0 =A0- One document that will define requirements for &q= uot;Effective
>>>> revocation
>>>> mechanisms".
>>>
>>> Not against that at all, but it sounds like a different WG to = me.
>>
>> Maybe so.
>
> Right, or a later milestone after a re-charter if we end up
> with a WG. At this point, I'd guess that anyone wanting revocation=
> considered sooner would need to be yelling (and since they
> haven't written an I-D, they'd need to be quite convincing as = to
> why yelling with no I-D is appropriate).
>
> S.
>
_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey



--
= Website: http://hallambaker.com/
--f46d0447f1882355ab04cd372fbb-- From paul.hoffman@vpnc.org Mon Oct 29 12:02:28 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9F921F8738 for ; Mon, 29 Oct 2012 12:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0da-GpTXZ4Lx for ; Mon, 29 Oct 2012 12:02:28 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D595921F8739 for ; Mon, 29 Oct 2012 12:02:27 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9TJ2PjN059709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 29 Oct 2012 12:02:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Mon, 29 Oct 2012 12:02:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <508AB760.7050803@cs.tcd.ie> <508E61C9.2060001@comodo.com> <508E65E8.1010906@comodo.com> <508E6F4A.20809@cs.tcd.ie> To: "therightkey@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: [therightkey] Non-WG forming BoF X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 19:02:28 -0000 On Oct 29, 2012, at 11:53 AM, Phillip Hallam-Baker = wrote: > I very much doubt we will manage ... As a point of reference, the charter of this BoF is: This non-WG forming BoF will discuss plans to specify mechanisms and techniques that allow Internet applications to monitor and verify the issuance of public X.509 certificates such that all issued certificates are available to applications, and each certificate seen by an application can be efficiently shown to be in the log of issued certificates. Furthermore, it should be possible to cryptographically verify the correct operation of the log. Until that changes, there is really no "we" for doing anything: the = proposal about individual submission or independent submission = documents. Stephen's question about number of documents was for the = current authors, not for a pre-WG (unless he has changed his mind = without telling me...). --Paul Hoffman, BoF chair for the next 8 days, and hopefully not much = longer= From stephen.farrell@cs.tcd.ie Mon Oct 29 12:11:43 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F4E21F8540 for ; Mon, 29 Oct 2012 12:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 894bqNRQ43dg for ; Mon, 29 Oct 2012 12:11:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3F05921F8510 for ; Mon, 29 Oct 2012 12:11:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A85D1C786; Mon, 29 Oct 2012 19:11:15 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5HACjSdgPB2; Mon, 29 Oct 2012 19:11:15 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.42.183.189]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 370FCC77B; Mon, 29 Oct 2012 19:11:15 +0000 (GMT) Message-ID: <508ED4D3.8050508@cs.tcd.ie> Date: Mon, 29 Oct 2012 19:11:15 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121017 Thunderbird/16.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <508AB760.7050803@cs.tcd.ie> <508E61C9.2060001@comodo.com> <508E65E8.1010906@comodo.com> <508E6F4A.20809@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Non-WG forming BoF X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 19:11:43 -0000 On 10/29/2012 07:02 PM, Paul Hoffman wrote: > Until that changes, there is really no "we" for doing anything: the proposal about individual submission or independent submission documents. Stephen's question about number of documents was for the current authors, not for a pre-WG (unless he has changed his mind without telling me...). I tell you everything:-) I'm interested in folks' opinions generally though. Reason for that is to help evaluate the feasibility of the option of just AD sponsoring a single draft. If there were a justifiable widespread opinion that >1 doc is needed that doesn't fit any current WG then that sort of takes the AD sponsoring route off the table. Cheers, S. From paul.hoffman@vpnc.org Mon Oct 29 12:18:53 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00E921F8661 for ; Mon, 29 Oct 2012 12:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn9D8vAH+zVs for ; Mon, 29 Oct 2012 12:18:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 28C7C21F85F3 for ; Mon, 29 Oct 2012 12:18:53 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9TJIaU3060293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 12:18:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <508AB760.7050803@cs.tcd.ie> Date: Mon, 29 Oct 2012 12:18:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0FCF1A1E-6DB7-459D-ADE9-4CB21A91E192@vpnc.org> References: <508AB760.7050803@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1499) Cc: "therightkey@ietf.org" Subject: Re: [therightkey] How many documents? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 19:18:53 -0000 On Oct 26, 2012, at 9:16 AM, Stephen Farrell = wrote: > Assuming for the moment that we do go ahead and > standardise CT, how many documents (RFCs) ought be > used to document that? 1. It needs to be written so that both CAs and browser vendors can read = it, but that's the only requirement. Extra points for a = generally-readable summary and maybe an appendix for the layperson, but = the definition of the scheme can live in a single document. --Paul Hoffman= From benl@google.com Mon Oct 29 12:19:37 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666A421F8669 for ; Mon, 29 Oct 2012 12:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFEofvWcI3uz for ; Mon, 29 Oct 2012 12:19:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA47A21F85F3 for ; Mon, 29 Oct 2012 12:19:36 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2890013wey.31 for ; Mon, 29 Oct 2012 12:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=92sASYGhA+qzWWfDASACJqh1V1epg+Tz0NniHlwzGYU=; b=UdNIKBLisbmp06UwjZUVK/K+FneOzzwzu4zagx1/cxkaLlE9zIyB64haxDYPcnt/Ri Og/cyg14wtmwsNxc1LOst1dNhLQ2Z+CHGnblm38KPiv81i6khjvj6kqG5ZHWqX2dpFvW TjPauYKsMkKEjY91/1kPyFz32WbDNCleuviqewnSBIPPHzDNUGSRxEZj7zYRTZjjpUjR IF8qU5BpozMpH/ECmTeILuuoBNPZ3tfd+GzAyyfjBLUM2q6GUgC9ZIfxXewYhXyiBLDW 4n+LgDjZU9fzqfa5WZ8IFQMhU+U/ButDfXjXaEGEf8a1LT8xS6lo3+xR2zLls8RjYRjz Xtpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=92sASYGhA+qzWWfDASACJqh1V1epg+Tz0NniHlwzGYU=; b=GTHaIB9I8+94fmIT6iGiZAMRt5vYpqwG+f9La5BJJWkNc/Dv/+JIZf7QGsKN85jYTS cuyiYXoXVDxb/8L2A1JSB7OUc6nelZtYgnJJy8WqTvQFA42fwEQcMYrU+4GAh6ZPdn79 FIKeBWAV7ICjj+j5HN2vOsFeftYqM3T0ad4UkKcBISz4U8G9mjx6dx5ob9RjdVfXRyFN 8dwAOJNA60OJ1E7LqFyPITOPJtB/08Z3W/uTQZpOTKSF6QjNfjEHycuVXcNQBQKxrsda mp4Y7IHV/ciLYM/olyBrm08hK9hxzTGVERR/ZJiSVLXShMiYap/UkvBMuMnaAGzaW/4t vlRA== MIME-Version: 1.0 Received: by 10.216.193.220 with SMTP id k70mr17690606wen.35.1351538375688; Mon, 29 Oct 2012 12:19:35 -0700 (PDT) Received: by 10.194.76.170 with HTTP; Mon, 29 Oct 2012 12:19:35 -0700 (PDT) In-Reply-To: <0FCF1A1E-6DB7-459D-ADE9-4CB21A91E192@vpnc.org> References: <508AB760.7050803@cs.tcd.ie> <0FCF1A1E-6DB7-459D-ADE9-4CB21A91E192@vpnc.org> Date: Mon, 29 Oct 2012 19:19:35 +0000 Message-ID: From: Ben Laurie To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlWg94iMhxKL91bxW9opTitD8GOZfCW73+laQ6HX+BWR6YMTRVacpHCnSjdGKohp8rFy61jLC/0n0Rl3NrBoK3d1hv5wNFkZVhRiwe6gvS+aqKgQmxemY0NwDC8mREVcirPtJRVVjtze9iW+YMiQ/8L8IywMi+txx1HjBlmYmPJ9/pB2AW3ujo1DEhe+ve69+ViKcT6 Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] How many documents? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 19:19:37 -0000 On 29 October 2012 19:18, Paul Hoffman wrote: > On Oct 26, 2012, at 9:16 AM, Stephen Farrell = wrote: > >> Assuming for the moment that we do go ahead and >> standardise CT, how many documents (RFCs) ought be >> used to document that? > > 1. It needs to be written so that both CAs and browser vendors can read i= t, but that's the only requirement. Extra points for a generally-readable s= ummary and maybe an appendix for the layperson, but the definition of the s= cheme can live in a single document. Actually, there are monitors, too. > > --Paul Hoffman > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From paul.hoffman@vpnc.org Mon Oct 29 13:35:20 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990B021F86F9 for ; Mon, 29 Oct 2012 13:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQstIY1TBdtq for ; Mon, 29 Oct 2012 13:35:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1A21421F86EB for ; Mon, 29 Oct 2012 13:35:20 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9TKZIrm062399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 29 Oct 2012 13:35:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Mon, 29 Oct 2012 13:35:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <508AB760.7050803@cs.tcd.ie> <0FCF1A1E-6DB7-459D-ADE9-4CB21A91E192@vpnc.org> To: "therightkey@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [therightkey] How many documents? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 20:35:20 -0000 On Oct 29, 2012, at 12:19 PM, Ben Laurie wrote: > On 29 October 2012 19:18, Paul Hoffman wrote: >> On Oct 26, 2012, at 9:16 AM, Stephen Farrell = wrote: >>=20 >>> Assuming for the moment that we do go ahead and >>> standardise CT, how many documents (RFCs) ought be >>> used to document that? >>=20 >> 1. It needs to be written so that both CAs and browser vendors can = read it, but that's the only requirement. Extra points for a = generally-readable summary and maybe an appendix for the layperson, but = the definition of the scheme can live in a single document. >=20 > Actually, there are monitors, too. Yes, but if I am going to trust a monitor, they had better damn well at = least as technically capable as the CAs and the browsers. My personal = hope is for a small number of obviously-trusted monitors, not a thousand = flowers blooming. --Paul Hoffman= From Rick_Andrews@symantec.com Wed Oct 31 16:57:42 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF6321F849A for ; Wed, 31 Oct 2012 16:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOkV0GUdesyT for ; Wed, 31 Oct 2012 16:57:41 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA3721F8457 for ; Wed, 31 Oct 2012 16:57:41 -0700 (PDT) X-AuditID: d80ac3f1-b7f656d000001deb-c8-5091baf41ccc Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 1D.7A.07659.4FAB1905; Wed, 31 Oct 2012 23:57:41 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1TTiAG-0005qT-9H; Wed, 31 Oct 2012 23:57:40 +0000 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([172.24.185.246]) with mapi; Wed, 31 Oct 2012 16:57:40 -0700 From: Rick Andrews To: Ben Laurie Date: Wed, 31 Oct 2012 16:57:38 -0700 Thread-Topic: [therightkey] Other solutions to the problem Thread-Index: Ac21vZxKSDtF9NCrRIeVwR1KM10N+QCBP83Q Message-ID: <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <70E51AD3-D937-416E-8F3C-60B6156190DC@vpnc.org> <42F98BCB-17F8-427E-8E9D-33A04978A339@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsXCZeB6SvfrrokBBuv+M1ls+HyNzeLW+i+s FosaF7NafLzwk8WBxePSktmMHgs2lXosWfKTyePz7KvMASxRXDYpqTmZZalF+nYJXBnH5rax FcyTq1j3fAJjA+N18S5GTg4JAROJhoY/LBC2mMSFe+vZuhi5OIQE3jFKfG5fyQ6SEBJ4xSix vDEMIrGKUeLUh2msIAk2AT2JLY+vgBWJCChIXP3XwwJSxCzQzCix9v0/ZpAEi4CqxJJ/pxlB bGEBS4mDRz6zQTRYSXzb08QIYRtJvH/eC1bPKxAlce3kVGaIzRc5JT7/jwCxOQUCJbZ/WQe2 jBHo1O+n1jCB2MwC4hK3nsxngnhBQGLJnvPMELaoxMvH/1gh6kUl7rSvZ4So15FYsPsTG4St LbFs4WuovYISJ2c+YZnAKD4LydhZSFpmIWmZhaRlASPLKkaZktJiw+LckvzSkoLUCgNDveLK 3ERgLCbrJefnbmIExuMNrsMfdzBeX6p4iFGAg1GJh7d848QAIdbEMqDKQ4wSHMxKIryPu4FC vCmJlVWpRfnxRaU5qcWHGKU5WJTEeQWdogOEBNITS1KzU1MLUotgskwcnFINjJvfM524XG++ KPDlaj1xv5OuJnofOZXDFvaaPdhSwMz7TZJj/6LCoxzd3y2b/KOVV0mFGk+q4j7/ZcXSpfYP t0xY9um9YfmxvywdzZ03zqUckXatPJi+/o3bJUMn7cvFCheWLbs67/uhZQGnZARefNr/rsO5 eoOUrZb9q6UiO6xnza+TdJwp8V+JpTgj0VCLuag4EQDzcSViwwIAAA== Cc: "therightkey@ietf.org" , Rob Stradling , Paul Hoffman Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 23:57:42 -0000 > -----Original Message----- > From: Ben Laurie [mailto:benl@google.com] > Sent: Monday, October 29, 2012 3:10 AM > To: Rick Andrews > Cc: Rob Stradling; therightkey@ietf.org; Paul Hoffman > Subject: Re: [therightkey] Other solutions to the problem >=20 > On 26 October 2012 22:31, Rick Andrews > wrote: > >> -----Original Message----- > >> From: Ben Laurie [mailto:benl@google.com] > >> Sent: Friday, October 26, 2012 1:51 AM > >> To: Rob Stradling > >> Cc: Rick Andrews; therightkey@ietf.org; Paul Hoffman > >> Subject: Re: [therightkey] Other solutions to the problem > >> > >> On 26 October 2012 09:24, Rob Stradling > >> wrote: > >> > On 26/10/12 00:58, Rick Andrews wrote: > >> > > >> > > >> >> AFAICT, for CT to really work it will require participation from > >> every CA > >> >> whose roots are in browsers. I think you're underestimating how > hard > >> it will > >> >> be to achieve that. > >> > > >> > > >> > Rick, > >> > > >> > Ultimately, assuming the RFC5878 TLS extension gains widespread > >> support in > >> > server and client software, CT won't _require_ participation from > any > >> CA. > >> > Each certificate holder will be able to configure their server to > >> send their > >> > certificate's CT proof to each client. > > > > I see, so the certificate holder can submit their newly-minted > certificate to a log server to get a CT proof. Instead of requiring the > participation of every CA, you now require the participation of every > certificate holder. >=20 > No, it is an option. I understand that. I was trying to point out that for CT to be effective, y= ou either need all CAs to participate, or for every CA that doesn't partici= pate, their customers who want protection have to participate directly. I f= eel that's a pretty high bar to surmount. > >You might say that not every certificate holder will need or want CT, > but I would guess that the number that would want the protection would > be far greater than the number of CAs. >=20 > Given that the plan is browsers will refuse non-CTed certs, I imagine > most holder of certificates used by the public will want CT. Do you have agreements with the major browser vendors to do this? It's poss= ible that not all of them will be on board. > >> > But with participation from the CAs, it should be possible to > realize > >> the CT > >> > dream far sooner. And (even in a future world where RFC5878 is > >> supported > >> > everywhere) if the CA takes care of CT proof distribution, then > that > >> makes > >> > life easier for the certificate holder. > >> > > >> > > >> >> Further, no one has yet brought up the privacy issue. CAs sell a > lot > >> of > >> >> certificates to companies for their internal use. Some of them > may > >> object to > >> >> publishing all their internal domain names. > >> > > >> > > >> > This has been a concern for Comodo too, so I spoke to AGL about it > a > >> few > >> > weeks ago. AIUI, the plan is that CT clients will have a user- > >> configurable > >> > whitelist (empty by default) of domain names for which CT proofs > will > >> not be > >> > required. Participating CAs should allow customers to opt-out > from > >> having > >> > their certs automatically logged with CT. > > > > I believe in your plan each browser will be a CT client. Aside from > the fact that the white list is an attractive target for hackers, I > don't see how the average user is going to know how to configure this > white list. I'm reminded of Adam's arguments against Convergence > (http://www.imperialviolet.org/2011/09/07/convergence.html). >=20 > This is why I think the best solution is to issue private certs > through a name constrained intermediate which is logged. I agree. From stephen.farrell@cs.tcd.ie Wed Oct 31 17:06:58 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6796321F877F for ; Wed, 31 Oct 2012 17:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES33ISMsA0IC for ; Wed, 31 Oct 2012 17:06:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BE12621F870B for ; Wed, 31 Oct 2012 17:06:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A6A17C092; Thu, 1 Nov 2012 00:06:34 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUs8zM3OnC6Z; Thu, 1 Nov 2012 00:06:34 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.44.75.237]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DCD25BE38; Thu, 1 Nov 2012 00:06:33 +0000 (GMT) Message-ID: <5091BD09.7040605@cs.tcd.ie> Date: Thu, 01 Nov 2012 00:06:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Rick Andrews References: <7500672F-5BDE-4EBE-ABC3-1AFEF2972D95@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D3FBAE8@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069D5FC685@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <6DD8CB4F-1233-403D-A27E-F3F80310390F@vpnc.org> <544B0DD62A64C1448B2DA253C0114146069D5FC79B@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <508A48C5.9070005@comodo.com> <544B0DD62A64C1448B2DA253C0114146069D76E5FC@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC. COM> In-Reply-To: <544B0DD62A64C1448B2DA253C0114146069F66F830@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" , Rob Stradling , Ben Laurie , Paul Hoffman Subject: Re: [therightkey] Other solutions to the problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 00:06:58 -0000 Just on this point: On 10/31/2012 11:57 PM, Rick Andrews wrote: > Do you have agreements with the major browser vendors to do this? It's possible that not all of them will be on board. We're discussing a draft submitted for a BoF that might or might not become a WG or get AD sponsored eventually producing a proposed standard RFC. None of that requires guaranteed ubiquitous deployment. Nothing even near that is required in fact. The IETF might be justifiably criticised for being slow in doing stuff, but we ought also note that part of the reason for that could be the extreme targets we set out for ourselves. Cheers, S.