From nobody Tue Apr 1 01:30:38 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4301F1A095B for ; Tue, 1 Apr 2014 01:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1t9_KqlqD1VT for ; Tue, 1 Apr 2014 01:30:33 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 31F9C1A08E8 for ; Tue, 1 Apr 2014 01:30:32 -0700 (PDT) Received: from [192.168.0.100] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 9BC8CF20DA; Tue, 1 Apr 2014 01:30:28 -0700 (PDT) Message-ID: <533A7923.9040302@mozilla.org> Date: Tue, 01 Apr 2014 10:30:27 +0200 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Thunderbird/30.0a2 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <533986E8.6040201@bbn.com> In-Reply-To: <533986E8.6040201@bbn.com> X-Enigmail-Version: 1.7a1pre OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/oZlEHulgQvb7xvn_Wg1vPUzuilk Subject: Re: [Trans] RFC6962 BIS Log file encodings. X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 08:30:35 -0000 On 31/03/14 17:16, Stephen Kent wrote: > know how to process ASN.1), and since the consumers of the data are > browsers who already > process certs, it seems reasonable to stick with ASN.1. AIUI, when a browser receives a cert, it will need to reconstruct the pre-cert in order to check that the SCT (which is a signature over the pre-cert) is valid. If that is the case, is it not true that browsers will need to develop some way of _encoding_ ASN.1 which they did not need to have before? (I may well be wrong about this; please correct me if so.) Gerv From nobody Tue Apr 1 01:30:45 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563641A095B for ; Tue, 1 Apr 2014 01:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lojl7X4JKFPG for ; Tue, 1 Apr 2014 01:30:36 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id E5BAB1A08E8 for ; Tue, 1 Apr 2014 01:30:36 -0700 (PDT) Received: from [192.168.0.100] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 3640EF212C; Tue, 1 Apr 2014 01:30:33 -0700 (PDT) Message-ID: <533A7928.4050502@mozilla.org> Date: Tue, 01 Apr 2014 10:30:32 +0200 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Thunderbird/30.0a2 MIME-Version: 1.0 To: Stephen Kent , trans@ietf.org References: <533986E8.6040201@bbn.com> In-Reply-To: <533986E8.6040201@bbn.com> X-Enigmail-Version: 1.7a1pre OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4foF7kt5Q4JjSpZV_O06KBzlf0o Subject: Re: [Trans] RFC6962 BIS Log file encodings. X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 08:30:38 -0000 On 31/03/14 17:16, Stephen Kent wrote: > know how to process ASN.1), and since the consumers of the data are > browsers who already > process certs, it seems reasonable to stick with ASN.1. AIUI, when a browser receives a cert, it will need to reconstruct the pre-cert in order to check that the SCT (which is a signature over the pre-cert) is valid. If that is the case, is it not true that browsers will need to develop some way of _encoding_ ASN.1 which they did not need to have before? (I may well be wrong about this; please correct me if so.) Gerv From nobody Tue Apr 1 02:25:42 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DFD1A098C for ; Tue, 1 Apr 2014 02:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laltWcrh6tig for ; Tue, 1 Apr 2014 02:25:38 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7FC1A7032 for ; Tue, 1 Apr 2014 02:25:36 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id b6so8711579yha.16 for ; Tue, 01 Apr 2014 02:25:32 -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=FSj6Y4uus0qf4JnBvEb/7HAtrvQdn8w3nMJgulnRLYQ=; b=vcq7rBQJWuIlDKkKCY4L0Z/T5eYs2tPCBUn0jh3owIQqLOtDJx6OnaqOFX7si7OyB4 tc8KpykFllz2c6miJaC7o/E2dAzsJ/9ta+I/vqgOd0z1MtBLI1GGwm3wD7p8Fu5E/bqr O+jkt96GLgShW9ZVJCcsFWXGre2s0jqTdHVAK8XbIkG7W8aujXscideE5jEnu2+qgnfF GYoCY+dquMM5jTc3m9beeyNd9NbR0m3tk96sXL+tkRbo6tlWdzOPN2dAFMX7Py8OBLHr e/vaNd46qfFstXrHKC0bU4nZIXT/NinQAndEzsJFRwN/0M7cYyqST1R91Dp/TC8crBvj Nl7A== MIME-Version: 1.0 X-Received: by 10.236.175.37 with SMTP id y25mr9975079yhl.100.1396344332833; Tue, 01 Apr 2014 02:25:32 -0700 (PDT) Received: by 10.170.220.193 with HTTP; Tue, 1 Apr 2014 02:25:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Apr 2014 13:25:32 +0400 Message-ID: From: Dmitry Belyavsky To: Ben Laurie Content-Type: multipart/alternative; boundary=20cf305b0abcf1568f04f5f7bf6c Archived-At: http://mailarchive.ietf.org/arch/msg/trans/yAbUCPio4aHAElQUWLTPDuur4Gs Cc: "trans@ietf.org" Subject: Re: [Trans] Fwd: Certificate Transparency with Russian GOST algorithms X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 09:25:40 -0000 --20cf305b0abcf1568f04f5f7bf6c Content-Type: text/plain; charset=UTF-8 Hello Ben, On Mon, Mar 31, 2014 at 2:51 PM, Ben Laurie wrote: > On 31 March 2014 09:21, Dmitry Belyavsky wrote: > > Dear Ben, > > > > Sorry for my late response. > > > > 18.03.2014 18:20, Ben Laurie wrote: > >> As I mentioned elsewhere, in our view you change algorithm by starting > >> a new log. > > > > Ok. What about a way to find out the algorithm in use? > > That is metadata that clients must discover outside the protocol > (along with things like MMD, log URL, etc). > I think that whether we have to discover the log URL outside the protocol, it will be better to specify URL like https:///ct/meta/ to find out the concrete setting f the log server. > > >> It seems to me there shouldn't be any difficulty accommodating GOST > >> like this - I guess we'd have to add the rule that non-GOST > >> certificates MUST NOT use GOST logs. Not sure whether we should > >> require the opposite, though (i.e. GOST certificates MUST NOT use > >> EC/SHA logs)? > > > > What is expected to be a right behaviour in case when a certificate has > SCT > > from some different log servers, if some of the SCT signatures can't be > > verified? If they are to be just ignored, I'm not sure we need such a > > limitation. > > Fair point. > So it seems to me that this (or any other reasonable) behaviour should be specified somewhere in the section describing TLS client behaviour. Thank you! -- SY, Dmitry Belyavsky --20cf305b0abcf1568f04f5f7bf6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Ben,=C2=A0


On Mon, Mar 31, 2014 at 2:51 PM, Ben Laurie <benl@goog= le.com> wrote:
On 31 March 2014 09:21, Dmitry Belyavsky &= lt;beldmit@gmail.com> wrote: > Dear Ben,
>
> Sorry for my late response.
>
> 18.03.2014 18:20, Ben Laurie wrote:
>> As I mentioned elsewhere, in our view you ch= ange algorithm by starting
>> a new log.
>
> Ok. What about a way to find out the algorithm in use?

That is metadata that clients must discover outside the protocol
(along with things like MMD, log URL, etc).

=
I think that whether we have to discover the log URL outside the proto= col, it will be better to specify URL like=C2=A0https://<log server>/ct/meta/ to find out the con= crete setting f the log server.
=C2=A0

>> It seems to me there shouldn't be any difficulty accommodating= GOST
>> like this - I guess we'd have to add the rule that non-GOST >> certificates MUST NOT use GOST logs. Not sure whether we should >> require the opposite, though (i.e. GOST certificates MUST NOT use<= br> >> EC/SHA logs)?
>
> What is expected to be a right behaviour in case when a certificate ha= s SCT
> from some different log servers, if some of the SCT signatures can'= ;t be
> verified? If they are to be just ignored, I'm not sure we need suc= h a
> limitation.

Fair point.

So it seems to me t= hat this (or any other reasonable) behaviour should be specified somewhere = in the section describing TLS client behaviour.

Thank you!

<= br>
--
SY, Dmitry Belyavsky
--20cf305b0abcf1568f04f5f7bf6c-- From nobody Tue Apr 1 02:31:35 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCBD1A7016 for ; Tue, 1 Apr 2014 02:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymzC43xLusdm for ; Tue, 1 Apr 2014 02:31:30 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE061A0985 for ; Tue, 1 Apr 2014 02:31:29 -0700 (PDT) Received: (qmail 11058 invoked by uid 1000); 1 Apr 2014 09:31:24 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 01 Apr 2014 10:31:24 +0100 Message-ID: <533A876C.60408@comodo.com> Date: Tue, 01 Apr 2014 10:31:24 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Doug Beattie , 'Peter Bowen' References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53393F1F.6080005@comodo.com> <5339752C.7020808@comodo.com> <063901cf4d2d$41c859b0$c5590d10$@globalsign.com> In-Reply-To: <063901cf4d2d$41c859b0$c5590d10$@globalsign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/YIB0ceYopN46el1lmM2IZX_53f0 Cc: trans@ietf.org, 'Rick Andrews' Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 09:31:34 -0000 On 31/03/14 23:04, Doug Beattie wrote: > I agree with Peter on this one, why are we making a long human readable > string for a cert that basically no-body will ever look at and will be used > only by the browser to validate the SCT (and the CA to create the SCT > extension)? I sincerely hope that the end result of the CT effort is _not_ that "no-body will ever look at" Precertificates. If nobody performs the Monitor role (i.e. watching the CT logs for Precertificates of interest) then CT won't achieve its potential as an effective mechanism for detecting certificate mis-issuance! Like I said, I'm not too bothered about what string literal we end up using. But since there doesn't seem to be any real need to optimize for size, let's prioritize clarity. Do both "?." and "(PRIVATE)." convey the intending "private subdomain(s)" meaning equally well? > When the browser tries to validate an SSL certificate they need > an indication that the SCTs were computed normally or via the Private > algorithm. Aren't all the SANs either private or not in a cert, and not a > mix? (sorry if this is in a spec or an email that I missed). I think we should support a mixture of private and non-private SANs in a cert. > It seems like the indicator to the browser should be at the SCT extension > level, not on every SAN entry (there could be hundreds), so we could omit > any indication of private at the per-san level. If it needs to be at the > SAN level (for some reason), then put in a valid PrintableString character > (maybe 2) we'd never expect to see in the wild. > > I'm sure I'm missing a key point. The Certificate needs to indicate, _for each SAN_, the number of domain components that are masked in the Precertificate, so that the browser is able to reconstruct the Precertificate precisely. An indicator at the SCT extension level, rather than for each SAN, just wouldn't be enough. > Doug > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Peter Bowen > Sent: Monday, March 31, 2014 10:57 AM > To: Rob Stradling > Cc: trans@ietf.org; Rick Andrews > Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1) > > On Mon, Mar 31, 2014 at 7:01 AM, Rob Stradling > wrote: >> On 31/03/14 14:44, Peter Bowen wrote: >>> If _completely_hidden_ is the requirement, then I agree that any >>> option that is no f(x) = 1 (for fixed values of 1) fails. >>> >>> Why have the long string "(PRIVATE)" at all then? Would a single '?' >>> not be adequate? I don't think you will ever find '?' in a real >>> dNSName. >> >> >> "PRIVATE" seemed a good choice of string literal from the point of >> view of explaining the idea clearly, but I'm not bothered what string >> literal we end up using. >> >> Why does the length of the string literal concern you? > > I guess it does not really matter. I was thinking about the future, when CT > is used for the CDN certificates with hundreds of SANs. > Moving "www" -> "(PRIVATE)" for 200 names increases the size 1200 bytes. > Maybe additional size is not a big deal. > > Thanks, > Peter > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. From nobody Tue Apr 1 02:33:25 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121E71A86DD for ; Tue, 1 Apr 2014 02:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiJTAZDhtnOD for ; Tue, 1 Apr 2014 02:33:24 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1631A86FD for ; Tue, 1 Apr 2014 02:33:23 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id lh14so9184869vcb.20 for ; Tue, 01 Apr 2014 02:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZkYHmqDyZahM2ASqAv0BKfErWMEookOlXSHkF5TOCVk=; b=cggd3MFf8JsKvh/GDGqm/myxCRfeMG0X06vJ5yfl5OqF5jn91sCtQGsZev6u4ordmM HkrEe4wVMIzIjY5OyS91GX2Q6A5HDjiCDDOs4WHvgCtXDyBl/pz6sMPwL+HIHXa+mmnj Hp3EMfEPSURmn1QpJiPLNxKazGytveBTqcI+qNLUbpji0HMOO5RGvMMx4VypylZZzI3W qpwy/F5sFZFrTcgZsQ3dhjhCg2yE2FU68soRlx/ENAjtdB+n4dfMfnvtLwfruVXvL+TW 0IPkRv7tvhp7K7kN4JAg4njw0/fEkyru9SdUHMIOemukkgVIVWfAMBweegbc0C4tf3w+ hLUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZkYHmqDyZahM2ASqAv0BKfErWMEookOlXSHkF5TOCVk=; b=k3BEKTyFoy0TmSwkqerGl6yvQzPbh2ztFKV9C+Lsy8aOhLVtDYpF772SN6xCPWIaY0 4b+p39Tax7dumOG4tdv0qD6l+MB/JE//FKNNBjx5h6Jeh3cVG0D7VzDIbVaFeiSi2MAC uoiYsZ+cJh7K6zx9HgWfyGRNzXDHDqU3BBv1mMjVP5heyUczJOjuwduGUs6cZ2ateV56 Op1ZEArbZ32QUTQO2QEKkSwwlvGXC2Bl9wnHon39hHo8cXF0QmctTl1ux6DhtUE2R+vl nGQ8wvneQUO4sx1/M3DnQ+tYX698IinX8hvc8SNzSXlesONGx5uiYqrAgKFPGry2u8ad YnYg== X-Gm-Message-State: ALoCoQkZcBshqMSOXCCcnZogQEppfq1q/Q/kRkk9godyG7OsinLGW9mtaU2O1Fs1BqY3wSmaXI5PjOjSWBkc8Z74GqPczQIInMjn3mMb9T0abj3jz8vxQHOTkHaXvMe69BId9kRQEZ0s1yyZ2QKAwL9Y6PIQ/hvw8EJUCHy2R3YABEWJqPohfmfqbjrRwIE0TwATvgNUpGEP MIME-Version: 1.0 X-Received: by 10.220.167.2 with SMTP id o2mr27779273vcy.8.1396344800175; Tue, 01 Apr 2014 02:33:20 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Tue, 1 Apr 2014 02:33:20 -0700 (PDT) In-Reply-To: <533A7923.9040302@mozilla.org> References: <533986E8.6040201@bbn.com> <533A7923.9040302@mozilla.org> Date: Tue, 1 Apr 2014 10:33:20 +0100 Message-ID: From: Ben Laurie To: Gervase Markham Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/eTQQEnk_O3oTIzztipVGKH_cEV8 Cc: "trans@ietf.org" , Stephen Kent Subject: Re: [Trans] RFC6962 BIS Log file encodings. X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 09:33:25 -0000 On 1 April 2014 09:30, Gervase Markham wrote: > On 31/03/14 17:16, Stephen Kent wrote: >> know how to process ASN.1), and since the consumers of the data are >> browsers who already >> process certs, it seems reasonable to stick with ASN.1. > > AIUI, when a browser receives a cert, it will need to reconstruct the > pre-cert in order to check that the SCT (which is a signature over the > pre-cert) is valid. If that is the case, is it not true that browsers > will need to develop some way of _encoding_ ASN.1 which they did not > need to have before? > > (I may well be wrong about this; please correct me if so.) No, you are right. From nobody Tue Apr 1 02:35:23 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4171A0481 for ; Tue, 1 Apr 2014 02:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BCZdrwAnOaN for ; Tue, 1 Apr 2014 02:35:20 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7278D1A0985 for ; Tue, 1 Apr 2014 02:35:20 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hu19so9637426vcb.1 for ; Tue, 01 Apr 2014 02:35: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; bh=bdUSs4JwAolgnANA4PAfr889qi9DhyI1710g04OqYpI=; b=Drx12/fAc+81UDpLDrWpuVDviBytg2dzgg4+TTvWE9WUK/SUsciloDwbe8FEQ/jaiM u/wG7xVOaKOBTCkavRFOgObdanuS5B6SgbmjxiXyC0riFdMKJjGI/hc+x+litvHDtpix vUGm4SvELoIZhZP9maWBh42v95WgKtAv7gzVytfzXUvmZPQvzx1D1SwAy/9W/uIOpVKb +95dPdiPl+PB3coq+ld0Kj78Cj/DNn3Bm4/vb4+J/VXDwn+/FQyncuuPy0YmR6sNEH2I Zpx9bV4UXXPaqt+yrZYQLnCPlyMnEAyS4cbC62DcRAKxX2N3uegXjqxXPFVB/vrT4BQY eBGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bdUSs4JwAolgnANA4PAfr889qi9DhyI1710g04OqYpI=; b=UyIsX2EWEdoBerkRHezZbZ/86316xaLTja6q2ni9UY8Bba2FiPTIW0rL6Xn1jIWJMQ EGQPO+je69+by0bJPzqJNcCcknFQMHMPVP9nJmfvqXhoaCK9IOTw6fMkhXLA5z0WvHuB UaH/QcrSASF5Kip06/KtmDDs/f9MU0UeJuHfqAMYRuAS86aRzD3dz443Zn177mI/gOMX FKM1qVEcjSauu4yaEHDxOEl231OzQ5pfozRBhfuifjHr2W/mb8JzR5IgyKCqY3TMuS8N JfI9l++s0jJtkcBCKq2rvSqCFqPUUmOdCIEYFDsRF+jiQOfoAnizK2uhYz1WxiEymcSg jllQ== X-Gm-Message-State: ALoCoQlZTYbztvd6MWLgIZxTla7s95Ek/h1f0xMJKH/KSqyizyJQ5qDJ/wAZ6iK4/6XX0yvXTiVf4Z5QTP94zqvQ/fumuyLwWBv1a4ZtA97MIAihtCCPLsYJTzQQ7m5iOxiXoxjTrhQda1WzJ931heGV/zh++4Qjry7Ypn+LL0qg1nwvJVXxfP8MpYFipkhFMykmBWTYU05v MIME-Version: 1.0 X-Received: by 10.52.12.36 with SMTP id v4mr10322357vdb.20.1396344916800; Tue, 01 Apr 2014 02:35:16 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Tue, 1 Apr 2014 02:35:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Apr 2014 10:35:16 +0100 Message-ID: From: Ben Laurie To: Dmitry Belyavsky Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/xDzwOSjAxxxWJEC9qPWV5Bk1-c0 Cc: "trans@ietf.org" Subject: Re: [Trans] Fwd: Certificate Transparency with Russian GOST algorithms X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 09:35:21 -0000 On 1 April 2014 10:25, Dmitry Belyavsky wrote: > Hello Ben, > > > On Mon, Mar 31, 2014 at 2:51 PM, Ben Laurie wrote: >> >> On 31 March 2014 09:21, Dmitry Belyavsky wrote: >> > Dear Ben, >> > >> > Sorry for my late response. >> > >> > 18.03.2014 18:20, Ben Laurie wrote: >> >> As I mentioned elsewhere, in our view you change algorithm by starting >> >> a new log. >> > >> > Ok. What about a way to find out the algorithm in use? >> >> That is metadata that clients must discover outside the protocol >> (along with things like MMD, log URL, etc). > > > I think that whether we have to discover the log URL outside the protocol, > it will be better to specify URL like https:///ct/meta/ to find > out the concrete setting f the log server. That seems like a bad idea, because then log servers could, for example, vary their promised MMD. >> >> It seems to me there shouldn't be any difficulty accommodating GOST >> >> like this - I guess we'd have to add the rule that non-GOST >> >> certificates MUST NOT use GOST logs. Not sure whether we should >> >> require the opposite, though (i.e. GOST certificates MUST NOT use >> >> EC/SHA logs)? >> > >> > What is expected to be a right behaviour in case when a certificate has >> > SCT >> > from some different log servers, if some of the SCT signatures can't be >> > verified? If they are to be just ignored, I'm not sure we need such a >> > limitation. >> >> Fair point. > > > So it seems to me that this (or any other reasonable) behaviour should be > specified somewhere in the section describing TLS client behaviour. Perhaps you could file a ticket on the issue tracker? -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Tue Apr 1 05:58:29 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BF71A06CE for ; Tue, 1 Apr 2014 05:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O88ZHH_oCyr for ; Tue, 1 Apr 2014 05:58:25 -0700 (PDT) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id C4D951A06BE for ; Tue, 1 Apr 2014 05:58:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 3CF83507F09A; Tue, 1 Apr 2014 05:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2t8c+J4Jrgqy; Tue, 1 Apr 2014 05:58:13 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 36005507F08C; Tue, 1 Apr 2014 05:58:10 -0700 (PDT) Received: from [10.12.52.21] ([83.97.14.218]) by keys.merrymeet.com (PGP Universal service); Tue, 01 Apr 2014 05:58:13 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 01 Apr 2014 05:58:13 -0700 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Jon Callas In-Reply-To: Date: Tue, 1 Apr 2014 05:58:07 -0700 Message-Id: <498EFA2E-3BC9-4A49-950A-57900932AC34@callas.org> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/trans/7sTR30c5Lip250XTG43wjQS4VTw Cc: "trans@ietf.org" Subject: Re: [Trans] Comments on RFC6962 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 12:58:27 -0000 On Mar 10, 2014, at 5:18 PM, Phillip Hallam-Baker = wrote: > Adding tags in JSON is straightforward and existing applications = SHOULD simply ignore them. But we should probably make some sort of = explicit statement. The above sounds pretty explicit to me. Who has the pen on the relevant = documents? Jon From nobody Tue Apr 1 06:54:19 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844201A096B for ; Tue, 1 Apr 2014 06:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsZaDQXJPpNc for ; Tue, 1 Apr 2014 06:54:16 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id E4ED31A06DE for ; Tue, 1 Apr 2014 06:54:15 -0700 (PDT) Received: from [192.168.0.125] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id CC777F2475; Tue, 1 Apr 2014 06:54:10 -0700 (PDT) Message-ID: <533AC501.30206@mozilla.org> Date: Tue, 01 Apr 2014 15:54:09 +0200 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Thunderbird/30.0a2 MIME-Version: 1.0 To: Rob Stradling , Peter Bowen , Rick Andrews References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53393F1F.6080005@comodo.com> In-Reply-To: <53393F1F.6080005@comodo.com> X-Enigmail-Version: 1.7a1pre OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/b81iHhdJOicGSfdKc2Jx8-V5kd4 Cc: "trans@ietf.org" Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 13:54:17 -0000 On 31/03/14 12:10, Rob Stradling wrote: > How long would it take an attacker to perform a dictionary attack to > discover that "6f993bb2" corresponds to "mail.corp" ? If only some correlation is desired, then you could just use e.g. the last two digits of the checksum. This allows a correct match when in possession of the correct cert, but also one can imagine many non-existent certs which would also match. Gerv From nobody Tue Apr 1 13:26:42 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4E61A08C2 for ; Tue, 1 Apr 2014 13:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpRafy5SG9nV for ; Tue, 1 Apr 2014 13:26:38 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 32ABE1A06BC for ; Tue, 1 Apr 2014 13:26:37 -0700 (PDT) Received: (qmail 16186 invoked by uid 1000); 1 Apr 2014 20:26:32 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 01 Apr 2014 21:26:32 +0100 Message-ID: <533B20F8.10803@comodo.com> Date: Tue, 01 Apr 2014 21:26:32 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Gervase Markham , Peter Bowen , Rick Andrews References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53393F1F.6080005@comodo.com> <533AC501.30206@mozilla.org> In-Reply-To: <533AC501.30206@mozilla.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/O_gOGYUgVdfdWENg1zZuOOKSH3s Cc: "trans@ietf.org" Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:26:41 -0000 On 01/04/14 14:54, Gervase Markham wrote: > On 31/03/14 12:10, Rob Stradling wrote: >> How long would it take an attacker to perform a dictionary attack to >> discover that "6f993bb2" corresponds to "mail.corp" ? > > If only some correlation is desired, then you could just use e.g. the > last two digits of the checksum. This allows a correct match when in > possession of the correct cert, but also one can imagine many > non-existent certs which would also match. Hi Gerv. I don't think this is desirable. Only the domain owner needs to know what the unmasked subdomains are, and they can do this by simply looking at the corresponding Certificate. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Apr 1 13:28:57 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C5C1A08C2 for ; Tue, 1 Apr 2014 13:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.278 X-Spam-Level: X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go7hw_mCSTPU for ; Tue, 1 Apr 2014 13:28:53 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 246E91A06BC for ; Tue, 1 Apr 2014 13:28:52 -0700 (PDT) Received: from [192.168.0.125] (93.243.187.81.in-addr.arpa [81.187.243.93]) (Authenticated sender: gerv@mozilla.org) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id E3CEAF2183; Tue, 1 Apr 2014 13:28:47 -0700 (PDT) Message-ID: <533B217E.90103@mozilla.org> Date: Tue, 01 Apr 2014 21:28:46 +0100 From: Gervase Markham User-Agent: Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Thunderbird/30.0a2 MIME-Version: 1.0 To: Rob Stradling , Peter Bowen , Rick Andrews References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53393F1F.6080005@comodo.com> <533AC501.30206@mozilla.org> <533B20F8.10803@comodo.com> In-Reply-To: <533B20F8.10803@comodo.com> X-Enigmail-Version: 1.7a1pre OpenPGP: id=9DF43DBB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/98r0MOFLWsMAgY7cx-gc_8AM7vk Cc: "trans@ietf.org" Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:28:55 -0000 On 01/04/14 21:26, Rob Stradling wrote: > Hi Gerv. I don't think this is desirable. > > Only the domain owner needs to know what the unmasked subdomains are, > and they can do this by simply looking at the corresponding Certificate. Does it not help with your combinatorial explosion, because it's then much easier to match up a potential cert with its logged precert? Or am I mistaken? Gerv From nobody Tue Apr 1 13:41:19 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3FA1A09CA for ; Tue, 1 Apr 2014 13:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YStSIs1eO0lK for ; Tue, 1 Apr 2014 13:41:15 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 05DD61A08C1 for ; Tue, 1 Apr 2014 13:41:14 -0700 (PDT) Received: (qmail 3717 invoked by uid 1000); 1 Apr 2014 20:41:10 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 01 Apr 2014 21:41:10 +0100 Message-ID: <533B2466.1090309@comodo.com> Date: Tue, 01 Apr 2014 21:41:10 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Gervase Markham , Peter Bowen , Rick Andrews References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53393F1F.6080005@comodo.com> <533AC501.30206@mozilla.org> <533B20F8.10803@comodo.com> <533B217E.90103@mozilla.org> In-Reply-To: <533B217E.90103@mozilla.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/BWGBtJnpPWeLqwaODpeIgM4PLe4 Cc: "trans@ietf.org" Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:41:17 -0000 On 01/04/14 21:28, Gervase Markham wrote: > On 01/04/14 21:26, Rob Stradling wrote: >> Hi Gerv. I don't think this is desirable. >> >> Only the domain owner needs to know what the unmasked subdomains are, >> and they can do this by simply looking at the corresponding Certificate. > > Does it not help with your combinatorial explosion, because it's then > much easier to match up a potential cert with its logged precert? > > Or am I mistaken? A TLS client will see only the Certificate, and from that it needs to reconstruct the Precertificate. Yes, the Precertificate is publicly logged, but this doesn't help a TLS client that is not allowed to perform blocking side-channel lookups during TLS handshakes. So no, I'm afraid it wouldn't help with the combinatorial explosion. (So I'll stick with my original idea for solving that). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Apr 1 13:42:45 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4448F1A08C1 for ; Tue, 1 Apr 2014 13:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du8skJKKtUgm for ; Tue, 1 Apr 2014 13:42:34 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) by ietfa.amsl.com (Postfix) with ESMTP id EDB021A06BC for ; Tue, 1 Apr 2014 13:42:33 -0700 (PDT) X-AuditID: d80ac3f3-b7f258e000006064-04-533b24b53583 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 5F.17.24676.6B42B335; Tue, 1 Apr 2014 20:42:30 +0000 (GMT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1WV5Vt-0001Dl-Mj; Tue, 01 Apr 2014 16:42:29 -0400 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Tue, 1 Apr 2014 13:42:21 -0700 From: Rick Andrews To: Gervase Markham , Rob Stradling , Peter Bowen Date: Tue, 1 Apr 2014 13:42:20 -0700 Thread-Topic: [Trans] Angle brackets in the PRIVATE option (Ticket #1) Thread-Index: Ac9N6P42g5QXkVtjQVa+0FlGz5ahIAAAbU9Q Message-ID: <544B0DD62A64C1448B2DA253C011414607C89CA6BE@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> References: <544B0DD62A64C1448B2DA253C011414607C85F3902@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM> <53393F1F.6080005@comodo.com> <533AC501.30206@mozilla.org> <533B20F8.10803@comodo.com> <533B217E.90103@mozilla.org> In-Reply-To: <533B217E.90103@mozilla.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsXCZeB6SnebinWwwYOrohZ7dlxjsvj/4CWL xaLGxawWax9fZHFg8bi0ZDajx85Zd9k9liz5yeSx+tIV1gCWKC6blNSczLLUIn27BK6MSX9u MhY84qjY9rWNpYHxCEcXIyeHhICJxJalc1ggbDGJC/fWs3UxcnEICbxjlDgw8QEjhPOKUeLZ 5MlQzkpGiUf9V8Fa2AT0JLY8vsIOYosIFEs8vPSCEcRmFlCV2Hb0KVicRUBF4sPHBawgtrCA q8Ttxz8YIerdJN4uWMMKYRtJPF34hRnE5hWIkuh93wm1bCaTxKfL98ASnAKaEtMmXAYbygh0 6/dTa5gglolL3HoynwniBwGJJXvOM0PYohIvH/9jhagXlbjTvh5oKAdQvabE+l36EK2KElO6 H7JD7BWUODnzCcsERvFZSKbOQuiYhaRjFpKOBYwsqxhlSkqLDYtzS/JLSwpSKwyM9YorcxOB sZisl5yfu4kRGI83uA5/3sH4e4/jIUYBDkYlHt4iSetgIdbEMqDKQ4wSHMxKIrzbmIBCvCmJ lVWpRfnxRaU5qcWHGKU5WJTEeUM+GgYLCaQnlqRmp6YWpBbBZJk4OKUaGD1MHXaKPri3LLXC VlpodaJK0omP8ww7ZKqU/6k+PWRjtnqx/pUNrbPuRO9uy/N0r1JneX+issYv8cOtqkrfhQY7 1BOK6msy1NZ5iU849D5YYtqqrQFF780u1h44MavAVftDyKc7G349Kwr8ZFGiPiGvUFRv8ZfI M4LKB9KaGN+tm213h+ugihJLcUaioRZzUXEiAPCZtgLDAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/trans/xBOoB3AEwOwD5hadMCTeln3X_2M Cc: "trans@ietf.org" Subject: Re: [Trans] Angle brackets in the PRIVATE option (Ticket #1) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:42:38 -0000 SSB3b3VsZCBpbWFnaW5lIHRoYXQgZG9tYWluIG93bmVycyB3b3VsZCBzaW1wbHkgdXNlIHRoZSBJ c3N1ZXIgTmFtZSBhbmQgU2VyaWFsIE51bWJlciBjb21iaW5hdGlvbiB0byBtYXRjaCB0aGUgcHJl Y2VydCB0byB0aGUgYWN0dWFsIGNlcnQuIA0KDQotUmljaw0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogR2VydmFzZSBNYXJraGFtIFttYWlsdG86Z2VydkBtb3ppbGxhLm9yZ10g DQpTZW50OiBUdWVzZGF5LCBBcHJpbCAwMSwgMjAxNCAxOjI5IFBNDQpUbzogUm9iIFN0cmFkbGlu ZzsgUGV0ZXIgQm93ZW47IFJpY2sgQW5kcmV3cw0KQ2M6IHRyYW5zQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW1RyYW5zXSBBbmdsZSBicmFja2V0cyBpbiB0aGUgUFJJVkFURSBvcHRpb24gKFRpY2tl dCAjMSkNCg0KT24gMDEvMDQvMTQgMjE6MjYsIFJvYiBTdHJhZGxpbmcgd3JvdGU6DQo+IEhpIEdl cnYuICBJIGRvbid0IHRoaW5rIHRoaXMgaXMgZGVzaXJhYmxlLg0KPiANCj4gT25seSB0aGUgZG9t YWluIG93bmVyIG5lZWRzIHRvIGtub3cgd2hhdCB0aGUgdW5tYXNrZWQgc3ViZG9tYWlucyBhcmUs IA0KPiBhbmQgdGhleSBjYW4gZG8gdGhpcyBieSBzaW1wbHkgbG9va2luZyBhdCB0aGUgY29ycmVz cG9uZGluZyBDZXJ0aWZpY2F0ZS4NCg0KRG9lcyBpdCBub3QgaGVscCB3aXRoIHlvdXIgY29tYmlu YXRvcmlhbCBleHBsb3Npb24sIGJlY2F1c2UgaXQncyB0aGVuIG11Y2ggZWFzaWVyIHRvIG1hdGNo IHVwIGEgcG90ZW50aWFsIGNlcnQgd2l0aCBpdHMgbG9nZ2VkIHByZWNlcnQ/DQoNCk9yIGFtIEkg bWlzdGFrZW4/DQoNCkdlcnYNCg== From nobody Fri Apr 4 08:29:27 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF071A01B5 for ; Fri, 4 Apr 2014 08:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibjkEirXWe2s for ; Fri, 4 Apr 2014 08:29:21 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id D5DE01A01A9 for ; Fri, 4 Apr 2014 08:29:20 -0700 (PDT) Received: (qmail 30039 invoked by uid 1000); 4 Apr 2014 15:29:12 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 04 Apr 2014 16:29:12 +0100 Message-ID: <533ECFC8.8090405@comodo.com> Date: Fri, 04 Apr 2014 16:29:12 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/FkJAE4WA-V8N8B7NlX_jEJu81B4 Subject: [Trans] Drafting text for 6962bis Issue 1 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 15:29:25 -0000 FYI, we're working on it here... https://codereview.appspot.com/83200047/ -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Apr 7 07:01:05 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887111A0708; Mon, 7 Apr 2014 07:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owwoVP8OWT5G; Mon, 7 Apr 2014 07:00:57 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC7D1A0713; Mon, 7 Apr 2014 07:00:56 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8C8FC480F8; Mon, 7 Apr 2014 14:00:50 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 77F08480E3; Mon, 7 Apr 2014 14:00:50 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 355789803E; Mon, 7 Apr 2014 14:00:50 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 7 Apr 2014 10:00:39 -0400 From: "Salz, Rich" To: "trans@ietf.org" Date: Mon, 7 Apr 2014 10:00:37 -0400 Thread-Topic: [saag] draft-iab-crypto-alg-agility-00 Thread-Index: Ac9SQ1iCuderyUe5RjO1bTZuczG+EAAJhb3w Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.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 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/nIJY5E-8U-I-yMKBna5hmLzOmoA Cc: "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 14:01:01 -0000 (Adding trans@ietf.org) Me: > CT should not be a special case exemption from the agility spec. Ben: > I think it should, and here's why: normally you want agility so endpoints= can change their crypto in an orderly way, so as to phase out weak algorit= hms. In CT the endpoint is the enemy: you don't want it to be able to choos= e algorithms that suit it. What is the endpoint? The log server? I don't understand the point. And as I said, why can't you get the same effect with proper use of ALL CAP= S words in the RFC? /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Mon Apr 7 09:24:18 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833DE1A072C; Mon, 7 Apr 2014 07:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWGnl2rcbt9q; Mon, 7 Apr 2014 07:37:39 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 750911A044C; Mon, 7 Apr 2014 07:37:16 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id i8so6426026qcq.37 for ; Mon, 07 Apr 2014 07:37:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DuEApVu0ykD3cfqzV6qn6JTomxq14bPw+VEOChzc06Y=; b=bAdVdu+4fpHGkMfyxH/wk3325AewW/Vu+N+OHWGuSL+7fDjQxyI3NKkJIJSKUoJUcS CwqnxCmMYIZ44n7Tpb84aIlAeVrQoJpkHMj3fUWEkYvTESUlM6xU8JqGN+D/mhhaVAeL 74+xWl3WtBMKrL8VVFsHID6C3S5sVShV/MWuuqnVzp9CQOwoMQl511NCLknjYG7LhWXp GwdQXxrAVKlC0rEii/OQER1u0c8o8L8vjK4X4ohtpUhlrZjsGB1zfUiP2tVbrPApbhwQ 65zOehXw1vLnuJolB8FjYHUkcpmyXQSc48aJ+RWMTQf/s/gQfhT4BSfkckFatOdeHHTV 2q4w== MIME-Version: 1.0 X-Received: by 10.224.147.77 with SMTP id k13mr16010750qav.64.1396881430593; Mon, 07 Apr 2014 07:37:10 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.157.137 with HTTP; Mon, 7 Apr 2014 07:37:10 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> Date: Mon, 7 Apr 2014 15:37:10 +0100 X-Google-Sender-Auth: rqKQwVGdGvQgg68cu3AaF4IbQ0s Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RcKVIeSS9QhLUVilP5FeRyvDISA X-Mailman-Approved-At: Mon, 07 Apr 2014 09:24:13 -0700 Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 14:37:43 -0000 On 7 April 2014 15:00, Salz, Rich wrote: > (Adding trans@ietf.org) > > Me: >> CT should not be a special case exemption from the agility spec. > > Ben: >> I think it should, and here's why: normally you want agility so endpoints can change their crypto in an orderly way, so as to phase out weak algorithms. In CT the endpoint is the enemy: you don't want it to be able to choose algorithms that suit it. > > What is the endpoint? The log server? I don't understand the point. Yes, the log server. > And as I said, why can't you get the same effect with proper use of ALL CAPS words in the RFC? What effect? You mean define an algorithm that the log server MUST use? From nobody Mon Apr 7 12:08:21 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4637B1A07D2; Mon, 7 Apr 2014 12:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZadV4h_jCEb4; Mon, 7 Apr 2014 12:08:14 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7519C1A0862; Mon, 7 Apr 2014 12:08:14 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 23969475C5; Mon, 7 Apr 2014 19:08:07 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 5F1F9475C7; Mon, 7 Apr 2014 19:08:06 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 00A122035; Mon, 7 Apr 2014 19:08:05 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Mon, 7 Apr 2014 15:08:05 -0400 From: "Salz, Rich" To: Ben Laurie Date: Mon, 7 Apr 2014 15:08:04 -0400 Thread-Topic: [saag] draft-iab-crypto-alg-agility-00 Thread-Index: Ac9Sbt3APIV6Sn3hQzGAAemoYAyUqgAAA0Pg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.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 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/L-NC0E8Q8D76VyMGZU0-PQiX6Vc Cc: "trans@ietf.org" , "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 19:08:19 -0000 So the concern is log servers that are going to reserve the right to "go ro= gue" by using weak crypto that could be subverted? Or is there a different= concern? =20 I believe this can be addressed by leaving the data formats future-proof, b= ut mandating the crypto in the RFC. For example, put a hash identifier (OID= , TLS id, whatever) in the hash entry, but the RFC says "MUST use SHA-256."= To make it even stronger, you could set up an IANA registry. Being pragma= tic, nobody's going to implement anything other than what Chrome supports, = at least at first. And by making log data self-identifying, you can (quietl= y) perform experiments on new crypto types. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From nobody Tue Apr 8 07:08:22 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B031A03F6 for ; Tue, 8 Apr 2014 07:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt10lSelvYqZ for ; Tue, 8 Apr 2014 07:08:19 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 460741A03FB for ; Tue, 8 Apr 2014 07:08:12 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ld13so781733vcb.5 for ; Tue, 08 Apr 2014 07:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WOHk3q3zeh+/RuxLpGOaX/FppL+U8P5eXCPlclEEoGo=; b=Pj1OAJ6Maualo6g1NZJ7+dK+TAKgdPINu32DilWyFjJnEdGfVeJp7cSHP2l+/+Wrrl BHjP25Yhf4GEmjnoFOGdSDxGGYpKueKo4ABsznvkqPL2+DGvBekG8892pIGpwzXYOyhn 6b871w642AHhR3EwSs/0vfmhAZHeEx4fDxNi3I2ygHI8DAq7fNDsfOfQ5Ksq4sPcZCiZ J7wtKCcEca7KAvshyDb+svOtPWw3mQpds24tddpYwJmXgEKSiMczEyNFd+EqxzYSy/6K hHeMxpbPTiEU01Qu8nk6v7CEhma1JqN1yZbXo+4m+Q6OfRd+Q7mNw8en1lafVbR3MHgP /siA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WOHk3q3zeh+/RuxLpGOaX/FppL+U8P5eXCPlclEEoGo=; b=mhsNdeIT6x9hf56dAGfQZMGuni5QjsfRV82MZP+DKOYezHibNpkM8CE3TvQY+6+QcF jJ3Anc46jYeNZWGiPVDZ7Sy/29AI7h7bCHiMDPsjr9bUp+lfJ6sbMLJPY4EkRMsNRqUz P897qiy52vBYLzBMCDrX5phDiAW8Fjx+SVR8/9aTqEVccva3euMB5ajWpZkeYM94PX5Q QwQry7O9FWwf9uY8ldtxxaDrZWuhgm9yE8zdIFs8asp3BPWbibFW41c4G3IkrWu9A0zb xxO36K6DjZJ8qwjKVdYloYkodJbokuAfnwswidg23xfEdyP+clTLpVmZE4Zl+6yxTBZj UiIA== X-Gm-Message-State: ALoCoQk8heoZPwS3U04pRLwsDxENbFdwe1Cfj/kK3DCA4V0z1qiqH8PpqtEP6P+WoSex2SXxBzUjgnO0ltxqXxljz3F0jruanttilor0SKj2Ofi+8G5mdW+aGucufMhjRuKK9xQ23/8MXCzfwxrNyvvt+gPkY2+YF/GmJo+sfk9hPbmE1FZbgnwCuXrkRLWxlG10y/s8Qhhc MIME-Version: 1.0 X-Received: by 10.58.31.136 with SMTP id a8mr3601978vei.20.1396966091996; Tue, 08 Apr 2014 07:08:11 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Tue, 8 Apr 2014 07:08:11 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> Date: Tue, 8 Apr 2014 15:08:11 +0100 Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/trans/9XC_j8YjYlX6RDndjjS9IIuKuIQ Cc: "trans@ietf.org" , Ben Laurie , "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:08:20 -0000 On 7 April 2014 20:08, Salz, Rich wrote: > So the concern is log servers that are going to reserve the right to "go = rogue" by using weak crypto that could be subverted? Or is there a differe= nt concern? Right, that's the concern. > I believe this can be addressed by leaving the data formats future-proof,= but mandating the crypto in the RFC. For example, put a hash identifier (O= ID, TLS id, whatever) in the hash entry, but the RFC says "MUST use SHA-256= ." To make it even stronger, you could set up an IANA registry. Being prag= matic, nobody's going to implement anything other than what Chrome supports= , at least at first. And by making log data self-identifying, you can (quie= tly) perform experiments on new crypto types. As I responded to Steve, I agree that there should be an identifier, but it belongs in the metadata about the logs. The RFC does not (and arguably should not) specify how logs get that metadata, nor what format it is in. > > /r$ > > -- > Principal Security Engineer > Akamai Technology > Cambridge, MA > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --=20 Certificate Transparency is hiring! Let me know if you're interested. From nobody Tue Apr 8 07:10:15 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F001B1A03E4; Tue, 8 Apr 2014 07:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.472 X-Spam-Level: X-Spam-Status: No, score=-4.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIGn9CH16EE4; Tue, 8 Apr 2014 07:10:07 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1F72C1A03F6; Tue, 8 Apr 2014 07:10:03 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B460A284A8; Tue, 8 Apr 2014 14:10:02 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 9FC6528441; Tue, 8 Apr 2014 14:10:02 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 792768003C; Tue, 8 Apr 2014 14:10:02 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 8 Apr 2014 10:10:02 -0400 From: "Salz, Rich" To: Ben Laurie Date: Tue, 8 Apr 2014 10:10:01 -0400 Thread-Topic: [Trans] [saag] draft-iab-crypto-alg-agility-00 Thread-Index: Ac9TM/8HsmFpMT5DRZeb66rjILytWgAACODg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.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 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/IOwWbffdnBLKYIRgOzKuVbD-3Nk Cc: "trans@ietf.org" , Ben Laurie , "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:10:11 -0000 PiBBcyBJIHJlc3BvbmRlZCB0byBTdGV2ZSwgSSBhZ3JlZSB0aGF0IHRoZXJlIHNob3VsZCBiZSBh biBpZGVudGlmaWVyLCBidXQgaXQgYmVsb25ncyBpbiB0aGUgbWV0YWRhdGEgYWJvdXQgdGhlIGxv Z3MuDQoNCkkgZG8gbm90IHVuZGVyc3RhbmQgd2h5IG1ldGFkYXRhIGlzIG1vcmUgc2VjdXJlIHRo ZW4gdGhlIGRhdGEgaXRzZWxmLg0KDQpJIHN0cm9uZ2x5IGRpc2FncmVlIHRoYXQgQ1Qgc2hvdWxk IGJlIGEgc3BlY2lhbCBjYXNlIGZyb20gdGhlIGdlbmVyYWwgYWdpbGl0eSBkb2MuDQoNCgkvciQN Cg0KLS0gIA0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkgVGVjaG5vbG9neQ0K Q2FtYnJpZGdlLCBNQQ0K From nobody Tue Apr 8 07:15:56 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEDE1A041E for ; Tue, 8 Apr 2014 07:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wmq3z5mDvkpi for ; Tue, 8 Apr 2014 07:15:47 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id A09B91A0416 for ; Tue, 8 Apr 2014 07:14:24 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id jw12so788394veb.41 for ; Tue, 08 Apr 2014 07:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VpNSm6Z6nzrBiWVXdU/FpiwgH4+VCRqNuL4L3ihoRoQ=; b=cCQSIoy7VyJLiPU9/TFhT+ODC3U3a+PVGHon6qAxwifX53L9faOApSN8p61CGsXUsc zQlWt3xSPszCphDh8ArfRhcphhrYeq4s6vhvjiAB8DxtW6SaWwU+r/VmxMfvVdDubn9e odd+p19kxIeQixhyUc+C338UXPRPz0H5FlEa7WnMgk3sh63PBERDcWbWhg7DaJN3d367 R+sezRkKiz0tThVe6MNBTJ6FUB2Mv9y9Ibref12sp6jerO+05pfzOB/5yDuXxpbqSkoU JcJ+hHUZycFa90bgHV+/8tWDV/uKbT7IZKqFKrDxJ2HE69bhuRjKFdi7lsmr/U89LnNl n7gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VpNSm6Z6nzrBiWVXdU/FpiwgH4+VCRqNuL4L3ihoRoQ=; b=jz8DRVOWeHcAFqAnXltOk2hlbt6Uor2Sd0yh1mg3e3AG86DjngjHop3HXjf5m9Hf7h 4467amSDNBR+OcnwhAcc/pqdTaHiRz26d93ak1HW0EDxfT9vS/qBUFu9Mx3W0TcFVh+f 6/ew822QgFydlAHJtSx5Hf8fA7L1aXmWXLoPXXI05ipflgujouuzCi0sdYyw7UnGsK8k 2vdiYPVTviS1yaBKvSg2ysGdabKKC+tD9h63ZwXWauplgbjuRlGGpPcWalFpO18Q3bMw m+ZUQiD5OqgfmBjM5u0HmYfwD8B22E6QHvvyOgPvVZw8+8IKdRHkfm0Mn30rp9G5m8FY YJvA== X-Gm-Message-State: ALoCoQnYMe1oef8j4jGuFm5H76NZHLbU59LI0QZs7sdSJ8ybnG4txuX9rl8H0bG30EYEqMDQyTzba8R/EiddSF7v4I93hKq45fpUikH2rtup+aaxNGQ5x9XaPy6c0DmUH7ScPteGkazlBMI24KDXcMtlXun4rOxBjaR3i97gTy2a4DgSKl2ur/hPVO1t2KbE/1UEyznA1ZfG MIME-Version: 1.0 X-Received: by 10.58.49.10 with SMTP id q10mr3347372ven.5.1396966464417; Tue, 08 Apr 2014 07:14:24 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Tue, 8 Apr 2014 07:14:24 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> Date: Tue, 8 Apr 2014 15:14:24 +0100 Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/keh1FiXM77siYEiDOF7smFwhvUI Cc: "trans@ietf.org" , Ben Laurie , "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:15:48 -0000 On 8 April 2014 15:10, Salz, Rich wrote: >> As I responded to Steve, I agree that there should be an identifier, but it belongs in the metadata about the logs. > > I do not understand why metadata is more secure then the data itself. It is created by a different authority. > I strongly disagree that CT should be a special case from the general agility doc. I am not saying it is a special case, I am disputing where the agility should happen. :-) -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Tue Apr 8 07:18:22 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6C41A03FB; Tue, 8 Apr 2014 07:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXnHRw3h-XfJ; Tue, 8 Apr 2014 07:18:19 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id A9EB71A03E1; Tue, 8 Apr 2014 07:18:19 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 63C4F474CC; Tue, 8 Apr 2014 14:18:19 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (unknown [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 57381474CB; Tue, 8 Apr 2014 14:18:19 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 54AD780044; Tue, 8 Apr 2014 14:18:19 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 8 Apr 2014 10:18:19 -0400 From: "Salz, Rich" To: Ben Laurie Date: Tue, 8 Apr 2014 10:18:18 -0400 Thread-Topic: [Trans] [saag] draft-iab-crypto-alg-agility-00 Thread-Index: Ac9TNNoaN52++GhqSbC+6HoeEfP1NwAAHp2Q Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.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 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/-YXul5esS7pxuocypb6nWTbEoNw Cc: "trans@ietf.org" , Ben Laurie , "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:18:21 -0000 PiA+IEkgZG8gbm90IHVuZGVyc3RhbmQgd2h5IG1ldGFkYXRhIGlzIG1vcmUgc2VjdXJlIHRoZW4g dGhlIGRhdGEgaXRzZWxmLg0KDQo+IEl0IGlzIGNyZWF0ZWQgYnkgYSBkaWZmZXJlbnQgYXV0aG9y aXR5Lg0KDQo/ICBJcyB0aGlzIGluIHRoZSBwYXJ0IG9mIHRoZSBSRkMgdGhhdCBpcyBzdGlsbCBU QkQ/DQoNCgkvciQNCg0KLS0gIA0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyDQpBa2FtYWkg VGVjaG5vbG9neQ0KQ2FtYnJpZGdlLCBNQQ0KDQo= From nobody Tue Apr 8 07:21:40 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DDB1A03FE for ; Tue, 8 Apr 2014 07:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEmebKp7rK4v for ; Tue, 8 Apr 2014 07:21:38 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id ADA0E1A0429 for ; Tue, 8 Apr 2014 07:21:28 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id db12so796736veb.24 for ; Tue, 08 Apr 2014 07:21: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; bh=rUWchDoKIMDjx7REd1lDAGgAk6m7IYhNTvpHswB7DEc=; b=OF+PZBPNwzRl2kKWU8h7J0o/NvO5iPeSXW0dOr/8recnz7aRJ+5s9TiCKUe0uHq+Id VhpM/2TZTk3Q48AJc2cFURN1HHHQDzOZUhEkMe/2EGDze8pO+ySkkJassrzx4YmbMeN3 gaidZFc/S4XKSAet2Gjpnb9Jds4PuIfvjFf/bcOU5R2i4Vr5dyKg0+4NTzqz53wUv6ox RQaOKPWX7qIvgdtkDvQ3RI0ghKtcCp/ifSgxGR7M/mnZUpXJkSRN1NCzvdvmXh3sUOhG r3ZxwvNHOHooN5iEuoQvhM66+KmKja+7creYCFuFjABLq3hrQTwXi6orNIq1DLrqjX+b kw2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rUWchDoKIMDjx7REd1lDAGgAk6m7IYhNTvpHswB7DEc=; b=cG4ephVO0bCLRuVgMYfFkn2gfXF8oXJuqqSK4OQuzWb0i0vvule7X81RWLpjELObSb tpIL+t5R5rd6Hoq4rSCM+lR6gPiVDyE8r1GofEh2N1m9ccN8sWTwv49AmcS3QdNC4JzR W6zInhleJhFLN5mpBnf3ZGdqfitmil1p3+EruAHpzgoDaXpiFaYNg1vfhS6zqkCokwyn 0gMmHB/lVE3TIITMvvG8SUc6TTmnEoEGA7XyTeYNogfTUEgPbIXXbamaqbu2wBCyU2j5 AX1gnoJYr4qQGJ7jDReXBx2VBmpQAlxJmDGRMlU7OfKe/yJc0ndTAXZ7DnSGDMXQnATY 6v2g== X-Gm-Message-State: ALoCoQn2Lw8UmMLalSGKlp6A6OSizH54s4APJNClOQ5/h0H4xy+3opw3tVs5z7S4zdmQmjJP0e49Yvn6ijhrCYyMSuH7tAxzJAaqxOpc2LLM+XxTndQ4M2YBJ61VKmV/q4E9cw7/2lfqf2ZBeMT3BSBsSBO7RdHiiTXPoEoITirp87vl1EGSiYSC1QJI4x3FaQqlLHO2qgDY MIME-Version: 1.0 X-Received: by 10.221.26.10 with SMTP id rk10mr3524522vcb.0.1396966888424; Tue, 08 Apr 2014 07:21:28 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Tue, 8 Apr 2014 07:21:28 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> Date: Tue, 8 Apr 2014 15:21:28 +0100 Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/uT690CJEQUuEg8dg5MirOjCzQsE Cc: "trans@ietf.org" , Ben Laurie , "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:21:39 -0000 On 8 April 2014 15:18, Salz, Rich wrote: >> > I do not understand why metadata is more secure then the data itself. > >> It is created by a different authority. > > ? Is this in the part of the RFC that is still TBD? The RFC describes how logs work and how clients work. It does not describe how clients decide what logs they are prepared to accept. I am not sure it should. But whoever does also decides whether the algorithms in use by the logs are acceptable and tells the client what those algorithms are (along with other things, like the log's key, base URL and MMD). -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Tue Apr 8 07:28:56 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64AE1A040A; Tue, 8 Apr 2014 07:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h07902V4Lblo; Tue, 8 Apr 2014 07:28:52 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CE1FC1A0415; Tue, 8 Apr 2014 07:28:51 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id q9so864053ykb.16 for ; Tue, 08 Apr 2014 07:28:51 -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=UgBaXS/icUxVU2t8r9yTc2fYXjbd0fNiFgvBJCVhkYc=; b=xfQNQhgYKQqj0ZLB6CLKFpf+wGosiRMd1c/vfzQ8YAZncCz9xk1q+Ui6wFoFxjVctY vazAzUAB6iCTY7HTwPEAhDROwRMi9E8FCjAFkta/30Buzre2FSRzVn7W+72dSDFWWVza BshhmRA6G2JwuwQ5yBcQ9bpEmmQHOH25Fes4WCWSaCU0uM9lMIyyN4EjU12Iy96OofPb Zg7I4A9pW7RuQ7F6tAW2BEPyNQr0m4a5IeUdNRP7grSUJ5tahDk+W/6Ihr/D2lDFBlv4 npwHPNFGs2LP/REEA7ndX4lN6Ggbhm0XU4AcQRTMdrGqHU5agIxLBQRnbDg6YND7L2X2 uegg== MIME-Version: 1.0 X-Received: by 10.236.4.225 with SMTP id 61mr3442558yhj.108.1396967331519; Tue, 08 Apr 2014 07:28:51 -0700 (PDT) Received: by 10.170.220.193 with HTTP; Tue, 8 Apr 2014 07:28:51 -0700 (PDT) In-Reply-To: References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> Date: Tue, 8 Apr 2014 18:28:51 +0400 Message-ID: From: Dmitry Belyavsky To: Ben Laurie Content-Type: multipart/alternative; boundary=089e013cc12a8ee2ce04f688cde1 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/XKIInnxjoRPuuLaH7wP9OenmifE Cc: "Salz, Rich" , "trans@ietf.org" , "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 14:28:53 -0000 --089e013cc12a8ee2ce04f688cde1 Content-Type: text/plain; charset=UTF-8 Hello Ben, On Tue, Apr 8, 2014 at 6:21 PM, Ben Laurie wrote: > On 8 April 2014 15:18, Salz, Rich wrote: > >> > I do not understand why metadata is more secure then the data itself. > > > >> It is created by a different authority. > > > > ? Is this in the part of the RFC that is still TBD? > > The RFC describes how logs work and how clients work. It does not > describe how clients decide what logs they are prepared to accept. I > am not sure it should. > > But whoever does also decides whether the algorithms in use by the > logs are acceptable and tells the client what those algorithms are > (along with other things, like the log's key, base URL and MMD). > > I think that the client should be able to find out the algorithm used by log because it cant'be changed during the log lifetime. And if the RFC specifies the URIs for certificate submit, it seems to me that it's reasonable to specify the URI for finding out the algorithm. But I prefer to leave out of band of the protocol only the data that can't be passed using it. Thank you! -- SY, Dmitry Belyavsky --089e013cc12a8ee2ce04f688cde1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Ben,


On Tue, Apr 8, 2014 at 6:21 PM, Ben Laurie = <benl@google.com> wrote:
On 8 April 2014 15:18, Salz,= Rich <rsalz@akamai.com> wrot= e:
>> > I do not understand why metadata is more secure then the data= itself.
>
>> It is created by a different authority.
>
> ? =C2=A0Is this in the part of the RFC that is still TBD?

The RFC describes how logs work and how clients work. It does not
describe how clients decide what logs they are prepared to accept. I
am not sure it should.

But whoever does also decides whether the algorithms in use by the
logs are acceptable and tells the client what those algorithms are
(along with other things, like the log's key, base URL and MMD).

I= think that the client should be able to find out the algorithm used by log= because it cant'be changed during the log lifetime. And if the RFC spe= cifies the URIs for certificate submit, it seems to me that it's reason= able to specify the URI for finding out the algorithm. But I prefer to leav= e out of band of the protocol only the data that can't be passed using = it.

Thank you!

--
SY, Dmitry = Belyavsky
--089e013cc12a8ee2ce04f688cde1-- From nobody Tue Apr 8 17:49:34 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3A91A074B; Tue, 8 Apr 2014 17:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdF6atps0HeQ; Tue, 8 Apr 2014 17:49:31 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4F91A0192; Tue, 8 Apr 2014 17:49:30 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id mz13so1640496bkb.3 for ; Tue, 08 Apr 2014 17:49:30 -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=8LOIVsN/+D8j127nMPTBFGSuEqyGAQR8QAnOM8hR4L4=; b=VzFIw3k4QV0jNUPQGDIdTT9XID7V8cAmjWku1vUXm7xxBpLTYdYGKxCyKXiRNbahe4 5gks2Sw8l6VMZco/gNlGKmgOVCExfG7VdEtuYBWadTCJG1yDK2/ZxAOAsIiSD/gRO2Rq 8Xmaaui1U5yodRgQdjGXLpGb4+XrAYclP+2ZUjl5TVpZ7ie9JS9bCmzDBEM00Z/jGP0g FjSMC4NQUyXTorWKOnQLG6BGcV/Dd08yoC3moC0WuG22UWP3FoR9d5fENqO7PE4qCsnv ehmZOmL65JCuHjFGWcouTfaYpcSJldpKShKTOb+9Z6hq2PS7+RaejSfCnD3axARLhBi9 I5kA== MIME-Version: 1.0 X-Received: by 10.112.150.233 with SMTP id ul9mr4854444lbb.2.1397004570250; Tue, 08 Apr 2014 17:49:30 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Tue, 8 Apr 2014 17:49:30 -0700 (PDT) In-Reply-To: References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> Date: Tue, 8 Apr 2014 20:49:30 -0400 Message-ID: From: Phillip Hallam-Baker To: Dmitry Belyavsky Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Cr8V4IUP2HBok7X_bByR3DdtGNE Cc: "Salz, Rich" , "trans@ietf.org" , Ben Laurie , "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 00:49:33 -0000 Since TRANS is joined to X.509 at the hip, how about we just shovel all the metadata describing the configuration of the notary into the certificate that signs the notary log outputs periodically? I am assuming here that the signing hierarchy for the log has an offline key that periodically signs the online key. The cert for the online key can specify the notary algorithm by OID (its ASN.1 after all) and any other parameters that might be useful. Probably want to allow for different accumulation strategies in case we ever decide a binary tree isn't the only choice. Might have some other options. Might want to be able to specify the CPS/CP equivalents for the notary, etc. On Tue, Apr 8, 2014 at 10:28 AM, Dmitry Belyavsky wrote: > Hello Ben, > > > On Tue, Apr 8, 2014 at 6:21 PM, Ben Laurie wrote: >> >> On 8 April 2014 15:18, Salz, Rich wrote: >> >> > I do not understand why metadata is more secure then the data itself. >> > >> >> It is created by a different authority. >> > >> > ? Is this in the part of the RFC that is still TBD? >> >> The RFC describes how logs work and how clients work. It does not >> describe how clients decide what logs they are prepared to accept. I >> am not sure it should. >> >> But whoever does also decides whether the algorithms in use by the >> logs are acceptable and tells the client what those algorithms are >> (along with other things, like the log's key, base URL and MMD). >> > I think that the client should be able to find out the algorithm used by log > because it cant'be changed during the log lifetime. And if the RFC specifies > the URIs for certificate submit, it seems to me that it's reasonable to > specify the URI for finding out the algorithm. But I prefer to leave out of > band of the protocol only the data that can't be passed using it. > > Thank you! > > -- > SY, Dmitry Belyavsky > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > -- Website: http://hallambaker.com/ From nobody Wed Apr 9 06:13:18 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64421A02B8 for ; Wed, 9 Apr 2014 06:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.051 X-Spam-Level: X-Spam-Status: No, score=-1.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZKXDS5hfdCW for ; Wed, 9 Apr 2014 06:13:11 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A96CB1A028C for ; Wed, 9 Apr 2014 06:13:09 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lg15so2106292vcb.30 for ; Wed, 09 Apr 2014 06:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ol2/cMDcbtzX2AY07wYah3anWfsPclipdO56r6VP3jU=; b=jd/0YV7oV0x0Yp8HUEhmqIFMKMhAWSF9/xVFqiFh6g09GVvCzG0BzJNjQMVJRuDM8b 7pdAQZw0LW5VyEKDeBxkheSRwJVuRHnT7bLI14WB85W1wwy7JNUICFBExCGxZUz5Isyz XuJUmOsGxRVj7ga01WoLbX2TKw2JIrfPQCMVQnTMkW9/e5Oh3SRYfx1EwA8ohKNG1NCn Bitl4l9LeKT7tAZjqXXp56FFdC9DmPPi+zZmVs9nqZyPh3uRGczs+m+PTtkTcmiMOD7a I/1Hssu+S/gWjqQGlOEl32pb908EIjT2Dsloe/AbgKenaUc5a0Gnzl4CoyVQOHIULjkH os6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ol2/cMDcbtzX2AY07wYah3anWfsPclipdO56r6VP3jU=; b=DQxbE3IIE4qDFHCepaQX/BQ9bfAmBeXdzQgJC0ZF/LVu0SifYe3oaM8OlqPhcsdkO8 gpzbkAi+EYgehC3ajM5t9mXuk3pUZckP1v4wvB/uzu/FFw5ig+NZKhNdr9DVrmOdZhTw NRqzwVGrOL/MmUT86jkhcE+Nju5JlYZZkJ/n6C2TKuh9M8ofK6Q8tefRCCo2PD26r/Yn HmnVEobPmrI5dro/3JOrx+VUGToircrqlz0LTvZnNgh2RwqCb3zKtx5X8zLsz4a3HIKh b8vQBJ2D70lSBQnMfxyLiHke/3V1dwGSr06hXm8Aq2DUPppgFp3psZuIJWYeNgTwmb/J u3RQ== X-Gm-Message-State: ALoCoQnq78Qgt+hnD7f3HdL9j2zn1naoCqYxkFKfBN3h1veu2hzCU2VpNI/K9aTs6ZYMKvY3miWasAPZws7s5dvyKVP2LsP37GPtaemUp8gNDL4Oxb+gLRLgPKwzufkn+E87OJf8fN9cEGZdkfD76PxUh3a8CAW2XLrtVdLd8nxiGccBoK6ulnTJ/6usBad8x3+FYcCjPkHw MIME-Version: 1.0 X-Received: by 10.52.249.105 with SMTP id yt9mr450422vdc.34.1397049188968; Wed, 09 Apr 2014 06:13:08 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Wed, 9 Apr 2014 06:13:08 -0700 (PDT) In-Reply-To: References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> Date: Wed, 9 Apr 2014 14:13:08 +0100 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/3JApeM87JO_9kIryyYgG6x3iSjM Cc: "Salz, Rich" , "trans@ietf.org" , Dmitry Belyavsky , "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 13:13:15 -0000 On 9 April 2014 01:49, Phillip Hallam-Baker wrote: > Since TRANS is joined to X.509 at the hip, how about we just shovel > all the metadata describing the configuration of the notary into the > certificate that signs the notary log outputs periodically? I guess if you are a CA everything looks like a certificate. Currently, logs do not use certificates to manage their own keys. I guess they could. But I thought you preferred JSON for new stuff? > I am assuming here that the signing hierarchy for the log has an > offline key that periodically signs the online key. Again, currently, no. Seems to me that you can introduce a lot of complication this way not needed for the only known client use case (deployment in Chrome). Not against specifying it, to be clear, but unsure it should live in the same doc. Or hold it up. > The cert for the > online key can specify the notary algorithm by OID (its ASN.1 after > all) and any other parameters that might be useful. Probably want to > allow for different accumulation strategies in case we ever decide a > binary tree isn't the only choice. Might have some other options. > Might want to be able to specify the CPS/CP equivalents for the > notary, etc. > > > > On Tue, Apr 8, 2014 at 10:28 AM, Dmitry Belyavsky wrote: >> Hello Ben, >> >> >> On Tue, Apr 8, 2014 at 6:21 PM, Ben Laurie wrote: >>> >>> On 8 April 2014 15:18, Salz, Rich wrote: >>> >> > I do not understand why metadata is more secure then the data itself. >>> > >>> >> It is created by a different authority. >>> > >>> > ? Is this in the part of the RFC that is still TBD? >>> >>> The RFC describes how logs work and how clients work. It does not >>> describe how clients decide what logs they are prepared to accept. I >>> am not sure it should. >>> >>> But whoever does also decides whether the algorithms in use by the >>> logs are acceptable and tells the client what those algorithms are >>> (along with other things, like the log's key, base URL and MMD). >>> >> I think that the client should be able to find out the algorithm used by log >> because it cant'be changed during the log lifetime. And if the RFC specifies >> the URIs for certificate submit, it seems to me that it's reasonable to >> specify the URI for finding out the algorithm. But I prefer to leave out of >> band of the protocol only the data that can't be passed using it. >> >> Thank you! >> >> -- >> SY, Dmitry Belyavsky >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> > > > > -- > Website: http://hallambaker.com/ -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Thu Apr 10 17:55:32 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247FB1A03A7; Thu, 10 Apr 2014 17:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkwAU1FyMcZ3; Thu, 10 Apr 2014 17:55:08 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 10A911A03A1; Thu, 10 Apr 2014 17:55:06 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id q8so2939680lbi.14 for ; Thu, 10 Apr 2014 17:55: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=AKmOZQDPIFme3IxhVEhUPT8JOKQREuw4RSbU4ocv1q8=; b=jtSv0+Oqt9sM+gwBiF84azkZr2s0PQLQAxXr72OkO3Mkm530TPYbBYp1BxKWolpeUP RPoW9STdjPZkouwVMClwvXbxZSBSNuh+/PADDmgvpjQd3i6iXwsAI0GjCXId2BSjkVHm m6Nl7WtnCQG8zISpdMp8a+WlaTp1/F2R0UrI2m5s3YNkQrREYM/K6U23VNgYRnR4B4mm 9GF9Dr/VrkQbysWMPAmTM0HSi5WTjlakAGbyC6PfFy8O1qsuKgLxsN/lRH22ce4o4ymQ i+anLIaDi/Vh4Nqm/UnhZS0o0lCYbmmW8VRG+TQpWnwsjiktnI3i7Z9qAcJj6ZnswZ2g p3gA== MIME-Version: 1.0 X-Received: by 10.112.201.1 with SMTP id jw1mr4805lbc.47.1397177705193; Thu, 10 Apr 2014 17:55:05 -0700 (PDT) Received: by 10.112.234.229 with HTTP; Thu, 10 Apr 2014 17:55:04 -0700 (PDT) In-Reply-To: References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED14@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC18663@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188A7@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120AC188BB@USMBX1.msg.corp.akamai.com> Date: Thu, 10 Apr 2014 20:55:04 -0400 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/mTn4qqsd0bLo7WmcxjwsxKvl_So Cc: "Salz, Rich" , "trans@ietf.org" , Dmitry Belyavsky , "saag@ietf.org" Subject: Re: [Trans] [saag] draft-iab-crypto-alg-agility-00 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 00:55:18 -0000 On Wed, Apr 9, 2014 at 9:13 AM, Ben Laurie wrote: > On 9 April 2014 01:49, Phillip Hallam-Baker wrote: >> Since TRANS is joined to X.509 at the hip, how about we just shovel >> all the metadata describing the configuration of the notary into the >> certificate that signs the notary log outputs periodically? > > I guess if you are a CA everything looks like a certificate. > Currently, logs do not use certificates to manage their own keys. I > guess they could. But I thought you preferred JSON for new stuff? I do, but I also prefer to avoid long discussions that I don't think I am going to win. As a general matter, most mechanisms that manage keys are likely to generate X.509v3 certificates or CRSs as a by product. Even some of the DNSSEC stuff generates them. >> I am assuming here that the signing hierarchy for the log has an >> offline key that periodically signs the online key. > > Again, currently, no. Seems to me that you can introduce a lot of > complication this way not needed for the only known client use case > (deployment in Chrome). Not against specifying it, to be clear, but > unsure it should live in the same doc. Or hold it up. I tend to think that anyone who would check cert status against TRANS is already doing X.509v3 and bar -- Website: http://hallambaker.com/ From nobody Wed Apr 16 09:59:31 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9521A0282; Wed, 16 Apr 2014 09:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOJHw-WUq5Dd; Wed, 16 Apr 2014 09:59:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4551A026B; Wed, 16 Apr 2014 09:59:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140416165926.7738.79394.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 09:59:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hsWkWAwgv3O3z3B7-DSZnYZzUCQ Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-01.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:59:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-01.txt Pages : 30 Date : 2014-04-16 Abstract: This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 16 10:02:04 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0501A00FB for ; Wed, 16 Apr 2014 10:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjjmCvR2tT6L for ; Wed, 16 Apr 2014 10:02:02 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 557F11A0279 for ; Wed, 16 Apr 2014 10:01:57 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so11165792veb.15 for ; Wed, 16 Apr 2014 10:01: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 :content-type; bh=5fahJnvlMQJ9LPMgpddoNcVuDXZz4zXBAsMXY6kl/cg=; b=eHaVV8nCSTYRlU5wwS27dR1FUh7SBdIHyk4JLbaSBXu+XJpUb7s2MUoK1E8IcgUBWn E20cfqSDkmTXwlBgtN3KDJ2tgoBNbYvAJw2rmn/EjhJzlMWDsRIjwjLG01RyA0EUXogu AKSs1O2QJ5EID8Ig2Q5rRlaSDUEDDm8vI51Od5A6d143LTF1r2wVlgeylvllX8s8g5HA clUdrQvMlmW2uDIRAU2yfBVXJOdGqzmvQtVxrXsdMaZAHIOn8X42oLgJ7wYsj8npfGjs ZymlRJ2cNei+Z2USD6qJ1ZwYFWFOiGyQjBGyxIX6lPylwXsWuFbh2HNYl2KUxFmmHMn1 hBWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=5fahJnvlMQJ9LPMgpddoNcVuDXZz4zXBAsMXY6kl/cg=; b=WJHBBL9r4fnkKCk34L8TryrAtPVszVtyqfXywgWJHv0V448AZKz+UP2MmBLm6Nsv47 gnu8uCASGoiKb0wwRwsXUlBJCKmq2bGOCbV5+WsScoE9qoBYvZk1h+lAcoLiUnSuSKYc PDmHHICIA8b4hTCK/GjgyifU8DYaVRFtoKUo80AwHzXrgprjzLLqasg7GT3uCoPPXmqA ggq0A50jFMmBmydSatgIqJxcwl18baVjp7RC3z4dqTzQUHsQ/Q9H46Te+tvQeoasQYmN 72VR8I+Z+MZh8ZJ2E+xlZ/AWEzIRX9vPWL/dhyn7KqDxfFq537L4Rmk6c1N4ZYnmeINg Vo5A== X-Gm-Message-State: ALoCoQneMn9YRCl+9ai7AZMia48HxBYOJ80aZ74eRCyZoLuLDyPW70FNsPvJVWh42DJ+4CS/7n4id6p9K0lZFnFzkDwQ2vVUflxNmbxNAPOnGREalUVyGpigCXEEu87k2gHMOyAQIEfoIZGMIcvL4lq0QcpPD+NNqet5UEPpmfFjZOw7haoC6Yn92I+r8al+5tyTz+HIvAmZ MIME-Version: 1.0 X-Received: by 10.221.74.200 with SMTP id yx8mr3761083vcb.3.1397667713751; Wed, 16 Apr 2014 10:01:53 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Wed, 16 Apr 2014 10:01:53 -0700 (PDT) In-Reply-To: <20140416165926.7738.79394.idtracker@ietfa.amsl.com> References: <20140416165926.7738.79394.idtracker@ietfa.amsl.com> Date: Wed, 16 Apr 2014 18:01:53 +0100 Message-ID: From: Ben Laurie To: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/pe2Qkgzj6UbYAoLKpbDD4vIlDDI Subject: Re: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-01.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:02:03 -0000 This new I-D contains our proposed language for name-constrained intermediates and name-hiding pre-certs. Please supply feedback, especially CAs that wanted this defined. On 16 April 2014 17:59, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Public Notary Transparency Working Group of the IETF. > > Title : Certificate Transparency > Authors : Ben Laurie > Adam Langley > Emilia Kasper > Rob Stradling > Filename : draft-ietf-trans-rfc6962-bis-01.txt > Pages : 30 > Date : 2014-04-16 > > Abstract: > This document describes an experimental protocol for publicly logging > the existence of Transport Layer Security (TLS) certificates as they > are issued or observed, in a manner that allows anyone to audit > certificate authority (CA) activity and notice the issuance of > suspect certificates as well as to audit the certificate logs > themselves. The intent is that eventually clients would refuse to > honor certificates that do not appear in a log, effectively forcing > CAs to add all issued certificates to the logs. > > Logs are network services that implement the protocol operations for > submissions and queries that are defined in this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Thu Apr 17 05:47:47 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FD21A0152; Thu, 17 Apr 2014 05:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWqK_IF-Oh2q; Thu, 17 Apr 2014 05:47:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA82D1A013B; Thu, 17 Apr 2014 05:47:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140417124744.27722.52773.idtracker@ietfa.amsl.com> Date: Thu, 17 Apr 2014 05:47:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/FcfYKgXoZ5xVlpsI9hUvT85RzsU Cc: trans@ietf.org Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-02.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 12:47:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public Notary Transparency Working Group of the IETF. Title : Certificate Transparency Authors : Ben Laurie Adam Langley Emilia Kasper Rob Stradling Filename : draft-ietf-trans-rfc6962-bis-02.txt Pages : 30 Date : 2014-04-17 Abstract: This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 17 05:53:04 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9B91A017A for ; Thu, 17 Apr 2014 05:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.63 X-Spam-Level: X-Spam-Status: No, score=-0.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrXJaRU8AMld for ; Thu, 17 Apr 2014 05:53:02 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3BACA1A0158 for ; Thu, 17 Apr 2014 05:53:02 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id lf12so418896vcb.39 for ; Thu, 17 Apr 2014 05:52:58 -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:cc :content-type; bh=mFL9JZvZxXuQ7d2gPIqaGcOtJW8qtrPpASB1jqRYSz0=; b=VJ3/lSEmi8o8NLqdVMwYr+6TKMsFs+dNRoNf9QuczVMkd4R0be45yrOi6tz6yPentH oz5HlhFAxtN6UvGb4x9UGDW2iDl27wbYLMuonNUHTM6s9GRvzfcy42yxq0uAQ0OEVUks u1hcYLM/QTqUqbyr04WhZdAg0J9JKop2SucHktNthOGvaoZqK0qCKGCCXm3+K6FAMOsx KCTua4SitHQDJc8XCMSSwJghunoRbCsFfL1KUDqml0gIBc/oRYzBuDSnP40DQGcCH74H e/M4dxzpDkx6b2K/4wIeXTlFGAPgR+u4V7rBzNGldPM5a/R9NZHs5HFhTP5xi22WIB19 ns6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=mFL9JZvZxXuQ7d2gPIqaGcOtJW8qtrPpASB1jqRYSz0=; b=AgHYrfFOt0TZUe+SnRGX6Jsg0ZEuz7sZUCJrN+P0Zax27Nh6tbQWJHovct5/o//3V/ K5nlg4SPUF1pzHlK3EDF4jnC05UZj/6mCN0zkhGmIXr7pSUAabDMh8nWRIDmupG2+QBR Jlm4+lRHC35T+mPVJdKaLSlfi5q527OOUuZl5ygJU5jaEZyMvFaTIL62Z2jAfTMFI/1s Iu2Ai9kGxrCGbtO8n8fTCacI2bpOO/Oic7Ei8pW1Kh9Mf0dhn+bPRNm13XPpClt5mw4w C2AfH/gInA6dFUKp7Z4Gesbtt0Ce/cWoQp7Q43cAKoFr93iZXKar9w1B4919hIqXrKGM dNdg== X-Gm-Message-State: ALoCoQkVqHQit1w5zERaNIcWJLi0X8X8Ve3+5krT6x3vKDrOouerUAEZco5n5DLeHFYfwz9OO8V0dI7SRh5C3RsMmY1AArUJmUcaoArKVNfHaCcUUEDCjF3X5Yq4qy0H8WrEBJ1onqmy8wcSIwNXP5rB5d3HqWK42MTXhn0qrHHsZThiF/hsczgyXwEhVOuxr5ZdMDCtXt5m MIME-Version: 1.0 X-Received: by 10.58.195.202 with SMTP id ig10mr448768vec.33.1397739178290; Thu, 17 Apr 2014 05:52:58 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Thu, 17 Apr 2014 05:52:58 -0700 (PDT) In-Reply-To: <20140417124744.27722.52773.idtracker@ietfa.amsl.com> References: <20140417124744.27722.52773.idtracker@ietfa.amsl.com> Date: Thu, 17 Apr 2014 13:52:58 +0100 Message-ID: From: Ben Laurie Cc: "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/fULDzKdHnDTGJReuKg8DTXkYhXw Subject: Re: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-02.txt X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 12:53:03 -0000 This version assigned the OIDs I forgot to assign. On 17 April 2014 13:47, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Public Notary Transparency Working Group of the IETF. > > Title : Certificate Transparency > Authors : Ben Laurie > Adam Langley > Emilia Kasper > Rob Stradling > Filename : draft-ietf-trans-rfc6962-bis-02.txt > Pages : 30 > Date : 2014-04-17 > > Abstract: > This document describes an experimental protocol for publicly logging > the existence of Transport Layer Security (TLS) certificates as they > are issued or observed, in a manner that allows anyone to audit > certificate authority (CA) activity and notice the issuance of > suspect certificates as well as to audit the certificate logs > themselves. The intent is that eventually clients would refuse to > honor certificates that do not appear in a log, effectively forcing > CAs to add all issued certificates to the logs. > > Logs are network services that implement the protocol operations for > submissions and queries that are defined in this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Thu Apr 17 10:08:05 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2364B1A0270 for ; Thu, 17 Apr 2014 10:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79EpBdS-OaSm for ; Thu, 17 Apr 2014 10:08:02 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7D11A0202 for ; Thu, 17 Apr 2014 10:08:02 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id sa20so802784veb.36 for ; Thu, 17 Apr 2014 10:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jOpv0VESc1r595XGe8mSI7ZryejnA9YS81i8Y9k9ArU=; b=bYcRmZ+FYPGEZB6xFQsAEj5wTbX8AePefceu3WUkga93o4GCHh4NY7mMeuwvIcLbVH 5cNCQ2OdsBrEGiLpSF6VHev0ZFuDvBSPtyZl30bk3HwdQLwKXFlFsOdKHD6EHsRTHWCE TwGiE3THFIEMUB01ZX+f5H54nTIc+QcpReKR6L7yYBKmolaTaXaUXcjWUbU2MR9HzNg7 ELO5Ct0evQR1GF2jxsNAP8R21+HpXTk8vMPFDKt+PHkv5G3xey0xaBP+1v9xhgd7s7vY cbBlEHMVy/ESsai0snDHVXb8+XuqHM+Ee4DU2oJKIbin2vx5UxE8c4810zCAit2dylu8 LHOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=jOpv0VESc1r595XGe8mSI7ZryejnA9YS81i8Y9k9ArU=; b=hY/8Tv0aFSXwdEbay+LYRXlWaYwiq2YWdGUTDcT3+9SSEvYXBg/iXP3o57VwmyQU7h yGCbj3R24Lrw1jSMspydg2wKHtom5/5TnMidRczrhyX8KmCl31DSEO0pcTb0JzUI61bv +AQvhrJ2E7qpYjyDH+5S6DfVlRyeaSUSH29fa4vH+RuLWprvwhuqG+RmRfJSa9SkICO2 ab29MPyRXM1NjeG1UXGyViEMacOyD4QBa4An42rJ0rZ64AqF23erjIOe1g8QCzeBQNDs TRgElGluzDT05qpDg4z7uvilD5JMGSp/Hi/QZjy7BFh0ZsB42/FEYrVnlrJ0NADItNOr YT0A== X-Gm-Message-State: ALoCoQl+j+wf2kg3UwgxcJXbR/tsWgwJglyJ7gJoMcZakhHyZw6R/xiW0b5DUg6VU4gvKE7VIR993260k3sRM++giZZaBootXilm6Qxk7XXT9U+usz9fYHvz+b/e5PxQNLdbPSVRMhSN/evRyA3w6cTGXrAY4k5HKMsMfjDrUG72sw0kw6xjWlgsyehKcvBta+6aVVC5nH/d MIME-Version: 1.0 X-Received: by 10.58.111.163 with SMTP id ij3mr8019461veb.26.1397754478305; Thu, 17 Apr 2014 10:07:58 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Thu, 17 Apr 2014 10:07:58 -0700 (PDT) Date: Thu, 17 Apr 2014 18:07:58 +0100 Message-ID: From: Ben Laurie To: CABFPub , "trans@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4wz4ssZjbRAwqkLaC-57SsroVK8 Subject: [Trans] Infrastructure for logs? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 17:08:03 -0000 My team is considering doing some work on the open source log implementation to make it less of a reference implementation and more something that you could consider running in (or adapting for) a production environment. It would help guide our thinking of those CAs (and others) who are considering running logs would give us some hints about the kind of production environment they would like to run in. In particular: 1. Operating systems. 2. Database managers. 3. Any other constraints you might have on a production environment. Public discussion would be useful, but if you would rather tell me privately that is also fine. Bear in mind that what we learn will probably influence open source code, though that's obviously very unlikely to reveal anything about anyone in particular. -- Certificate Transparency is hiring! Let me know if you're interested. From nobody Thu Apr 17 21:46:35 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F971A0130 for ; Thu, 17 Apr 2014 21:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzOswUWYOEIt for ; Thu, 17 Apr 2014 21:46:29 -0700 (PDT) Received: from mail.primekey.se (mail.primekey.se [213.179.18.11]) by ietfa.amsl.com (Postfix) with ESMTP id 88CAE1A0088 for ; Thu, 17 Apr 2014 21:46:29 -0700 (PDT) Received: from mail.primekey.se (localhost [127.0.0.1]) by mail.primekey.se (Postfix) with ESMTP id 25BBD45C00D3; Fri, 18 Apr 2014 06:48:14 +0200 (CEST) Received: from android-7a7abba8d299d61e (h-24-169.a328.priv.bahnhof.se [46.59.24.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.se (Postfix) with ESMTPSA id 10F7E45C00D2; Fri, 18 Apr 2014 06:48:14 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----ZWPFRPZY28HIXAH5X9Q6V9XUZEKFJP" Content-Transfer-Encoding: 8bit From: Tomas Gustavsson Date: Fri, 18 Apr 2014 06:45:47 +0200 To: Ben Laurie , CABFPub , "trans@ietf.org" Message-ID: <30c40f8d-6232-4a57-b950-e56dfc43bc1c@email.android.com> X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/trans/4zceCT55aPlFX_K4Ah_HfFePTe8 Subject: Re: [Trans] Infrastructure for logs? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 04:46:34 -0000 ------ZWPFRPZY28HIXAH5X9Q6V9XUZEKFJP Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 If we would set up a log today we would go for: 1. Linux (Ubuntu or RHEL) 2. MariaDB Galera 3. Stateless load balancing? IPv4/v6? Possible to test on one core (I mention this because some products are not). Cheers, Tomas On April 17, 2014 7:07:58 PM CEST, Ben Laurie wrote: >My team is considering doing some work on the open source log >implementation to make it less of a reference implementation and more >something that you could consider running in (or adapting for) a >production environment. > >It would help guide our thinking of those CAs (and others) who are >considering running logs would give us some hints about the kind of >production environment they would like to run in. In particular: > >1. Operating systems. > >2. Database managers. > >3. Any other constraints you might have on a production environment. > >Public discussion would be useful, but if you would rather tell me >privately that is also fine. Bear in mind that what we learn will >probably influence open source code, though that's obviously very >unlikely to reveal anything about anyone in particular. > >-- >Certificate Transparency is hiring! Let me know if you're interested. > >_______________________________________________ >Trans mailing list >Trans@ietf.org >https://www.ietf.org/mailman/listinfo/trans -- PrimeKey Solutions AB Internet: www.primekey.se Twitter: twitter.com/primetomas Mob: +46 (0)707421096 ------ZWPFRPZY28HIXAH5X9Q6V9XUZEKFJP Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit If we would set up a log today we would go for:

1. Linux (Ubuntu or RHEL)

2. MariaDB Galera

3. Stateless load balancing? IPv4/v6? Possible to test on one core (I mention this because some products are not).

Cheers,
Tomas


On April 17, 2014 7:07:58 PM CEST, Ben Laurie <benl@google.com> wrote:
My team is considering doing some work on the open source log
implementation to make it less of a reference implementation and more
something that you could consider running in (or adapting for) a
production environment.

It would help guide our thinking of those CAs (and others) who are
considering running logs would give us some hints about the kind of
production environment they would like to run in. In particular:

1. Operating systems.

2. Database managers.

3. Any other constraints you might have on a production environment.

Public discussion would be useful, but if you would rather tell me
privately that is also fine. Bear in mind that what we learn will
probably influence open source code, though that's obviously very
unlikely to reveal anything about anyone in particular.

--
PrimeKey Solutions AB
Internet: www.primekey.se
Twitter: twitter.com/primetomas
Mob: +46 (0)707421096 ------ZWPFRPZY28HIXAH5X9Q6V9XUZEKFJP-- From nobody Fri Apr 18 06:20:56 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0061A0158 for ; Fri, 18 Apr 2014 06:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ5dRtbRw5oU for ; Fri, 18 Apr 2014 06:20:53 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 95CD61A0152 for ; Fri, 18 Apr 2014 06:20:53 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f10so1455194yha.3 for ; Fri, 18 Apr 2014 06:20:49 -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=QGXBEhDJscSyEKReJgNtg4B5YnJgxUo5qshATDwNSXk=; b=qGC25eePqschGx7EE57yB4EORKgMRlyI+n3TsRnLtbAde4GI/pm9/YIyphNejfk4w2 N5/uYtq/AC3x4dRs8uSnD852+Z87vWKY7zWZP1D9xDr15Hk8RP/CqMW1jbLG7+nAvOaB BD0QErTQ1ZpdTv+qayzowquIiMRVJIc7RKFo2DCk4mMLWMOJUvyQHRZ4Jn9ysXQGncTa TxT+9NAG2NBf0wQvYaAgoSsnzofjvNIGGeHXAq3sPyGnMR67rRI7hceee1egZUY3T3tm ba03fNz9bDc0P8blaiNzjA22AJxx8de9L7O/45Rhl12HRpjX+jo6janIqfoLOv/C++P8 h0RQ== MIME-Version: 1.0 X-Received: by 10.236.46.5 with SMTP id q5mr30180257yhb.21.1397827249624; Fri, 18 Apr 2014 06:20:49 -0700 (PDT) Received: by 10.170.220.193 with HTTP; Fri, 18 Apr 2014 06:20:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Apr 2014 17:20:49 +0400 Message-ID: From: Dmitry Belyavsky To: Ben Laurie Content-Type: multipart/alternative; boundary=047d7b5d8391abda1c04f7510401 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hrfyd_IfbYd14iR_jq_z0LqY_Mw Cc: "trans@ietf.org" , CABFPub Subject: Re: [Trans] Infrastructure for logs? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 13:20:55 -0000 --047d7b5d8391abda1c04f7510401 Content-Type: text/plain; charset=UTF-8 Hello Ben, On Thu, Apr 17, 2014 at 9:07 PM, Ben Laurie wrote: > My team is considering doing some work on the open source log > implementation to make it less of a reference implementation and more > something that you could consider running in (or adapting for) a > production environment. > > It would help guide our thinking of those CAs (and others) who are > considering running logs would give us some hints about the kind of > production environment they would like to run in. In particular: > > 1. Operating systems. > > 2. Database managers. > > 3. Any other constraints you might have on a production environment. > > Public discussion would be useful, but if you would rather tell me > privately that is also fine. Bear in mind that what we learn will > probably influence open source code, though that's obviously very > unlikely to reveal anything about anyone in particular. > > 1. Linux (We prefer Debian). 2. PostgreSQL, MySQL? 3. It seems to be not a constraint but there should be a list of Nagios/Icinga checks for the log instance. Thank you! -- SY, Dmitry Belyavsky --047d7b5d8391abda1c04f7510401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Ben,


On Thu, Apr 17, 2014 at 9:07 PM, Ben Laurie <benl@google.c= om> wrote:
My team is considering doing some work on th= e open source log
implementation to make it less of a reference implementation and more
something that you could consider running in (or adapting for) a
production environment.

It would help guide our thinking of those CAs (and others) who are
considering running logs would give us some hints about the kind of
production environment they would like to run in. In particular:

1. Operating systems.

2. Database managers.

3. Any other constraints you might have on a production environment.

Public discussion would be useful, but if you would rather tell me
privately that is also fine. Bear in mind that what we learn will
probably influence open source code, though that's obviously very
unlikely to reveal anything about anyone in particular.

=C2=A0
1. Linux (We prefer Debian).
2. Post= greSQL, MySQL?
3. It seems to be not a constraint but there s= hould be a list of Nagios/Icinga checks for the log instance.
=C2=A0
Thank you!
--
SY, Dmitry= Belyavsky
--047d7b5d8391abda1c04f7510401-- From nobody Mon Apr 21 14:22:33 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C421A02C3 for ; Mon, 21 Apr 2014 14:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.274 X-Spam-Level: X-Spam-Status: No, score=-5.274 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nzQrijDFhNo for ; Mon, 21 Apr 2014 14:22:28 -0700 (PDT) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4391A02CA for ; Mon, 21 Apr 2014 14:22:27 -0700 (PDT) X-AuditID: d80ac3f2-b7f828e0000045d3-d9-53558c0e0e67 Received: from ecl1mtahubpin02.ges.symantec.com (ecl1mtahubpin02.ges.symantec.com [10.48.69.202]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id AF.32.17875.E0C85535; Mon, 21 Apr 2014 21:22:22 +0000 (GMT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1WcLfS-0006WI-5J; Mon, 21 Apr 2014 17:22:22 -0400 Received: from TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM ([155.64.220.147]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Mon, 21 Apr 2014 14:22:20 -0700 From: Rick Andrews To: Ben Laurie , CABFPub , "trans@ietf.org" Date: Mon, 21 Apr 2014 14:22:19 -0700 Thread-Topic: [Trans] Infrastructure for logs? Thread-Index: Ac9aX5lm4UqgmlR5R7axLjB/SYgx0ADR/N3A Message-ID: <544B0DD62A64C1448B2DA253C011414607C96F9B1F@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+NgFprBIsWRmVeSWpSXmKPExsXCZeB6SpevJzTYYN5fY4sNn6+xWUx5vobZ Yu3jiywOzB7rZp5l9liwqdRjyZKfTAHMUVw2Kak5mWWpRfp2CVwZy04eZCl4wV3R9P4iWwPj Jc4uRk4OCQETiRXNdxkhbDGJC/fWs3UxcnEICbxjlJj27y6U84pR4tG3tawQzipGifs/H7OD tLAJ6ElseXwFyObgEBFIkZj9LBskzCKgKjHn3xJWEFtYQFfi9IdPbCC2CFD5z18t7BC2kcSf ra/B4rwCURKfzj5iAhkjJBAgceCQLUiYUyBQ4tWejcwgNiPQcd9PrWECsZkFxCVuPZnPBHG0 gMSSPeeZIWxRiZeP/7FC1ItK3GlfzwhRryOxYDfECcwC2hLLFr5mhlgrKHFy5hOWCYxis5CM nYWkZRaSlllIWhYwsqxilCkpLTYszi3JLy0pSK0wMNIrrsxNBMZWsl5yfu4mRmB83eA6/GkH 48y9jocYBTgYlXh4f7aFBguxJpYBVR5ilOBgVhLhXZsGFOJNSaysSi3Kjy8qzUktPsQozcGi JM573ds6WEggPbEkNTs1tSC1CCbLxMEp1cCYp5tYsv7hFNtlZzfLeMfzX8zWlxCqbReOTwot lmZSmJ/4VKMnsdVyysmPcwO385uzc8/1OvT3TKi1pcDyzrPlks3H91YVbps18e2mJVcrv0fn bN9b83get92GY0+EOiqZrs4RkWOo7M9huZlxY+/Pbe+TE07sX/knWmO1nUj2yge+/DylPReU WIozEg21mIuKEwGSf7xHqwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/trans/RBmrgi8IO2emIMt9Emum-Js_fhM Subject: Re: [Trans] Infrastructure for logs? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 21:22:30 -0000 1. Web Server - Apache on Linux; App Server - Tomcat (Web application - jav= a based REST APIs) on Linux 2. Oracle db 3. Stateless load balancing so that machines can be brought up and down at = will without missing any certs or corrupting the logs -Rick -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Ben Laurie Sent: Thursday, April 17, 2014 10:08 AM To: CABFPub; trans@ietf.org Subject: [Trans] Infrastructure for logs? My team is considering doing some work on the open source log implementatio= n to make it less of a reference implementation and more something that you= could consider running in (or adapting for) a production environment. It would help guide our thinking of those CAs (and others) who are consider= ing running logs would give us some hints about the kind of production envi= ronment they would like to run in. In particular: 1. Operating systems. 2. Database managers. 3. Any other constraints you might have on a production environment. Public discussion would be useful, but if you would rather tell me privatel= y that is also fine. Bear in mind that what we learn will probably influenc= e open source code, though that's obviously very unlikely to reveal anythin= g about anyone in particular. -- Certificate Transparency is hiring! Let me know if you're interested. _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Mon Apr 21 15:36:02 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D4B1A02B8 for ; Mon, 21 Apr 2014 15:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goQ953_i5c5d for ; Mon, 21 Apr 2014 15:35:56 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 295511A02FA for ; Mon, 21 Apr 2014 15:35:56 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id um1so4213863pbc.30 for ; Mon, 21 Apr 2014 15:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=c/n7mW9Fr3nB44nnjFNQuowEJr5LL/VOlESfGuU1AK4=; b=MMqUw+cbKFeoAXj7RhNcCBJPFz+iDX/HTT5OckUSCWfHFotWLJLej7B4cthghUJdVj TfAHk+lwq5zO2f5rSQV4/b8i83S5OWRN5+80QHWEkypIbNnhvhtp/8UHpQyY7L7QblFm pa3uC7CwQAq3IpXTKtFcnORyv0KkVck7hR/APaNhdcnR616HlEiM6lIhBnVBQLIN8xdN xnJr+1lmysbduLfMwx7FLS+x2VGokiweLAp8qJcVSO4drHpwz8xJI9lMOut7rIY9BuE2 l6vxlqOEqo6HHQbQcepyGcfEJx7G2EmQ4zBdYiHzEZKRoW9NV/mE7DofEUuGwtq1ZEpq KwzA== X-Received: by 10.66.136.71 with SMTP id py7mr41074354pab.2.1398119751085; Mon, 21 Apr 2014 15:35:51 -0700 (PDT) Received: from spandex.local (209-193-46-203-rb1.sol.dsl.dynamic.acsalaska.net. [209.193.46.203]) by mx.google.com with ESMTPSA id et3sm80355758pbc.52.2014.04.21.15.35.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 15:35:50 -0700 (PDT) Message-ID: <53559D3B.1090504@gmail.com> Date: Mon, 21 Apr 2014 14:35:39 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/uZQjoJZ9-RqHa3wn9Vxfhdggk6M Subject: [Trans] IETF 90 scheduling X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 22:35:59 -0000 We just received notification that working group session scheduling for the July meeting is now open. This is a good time to be thinking about what needs to be done between now and then and how session time will be spent. Right now my sense is that a single two-hour session will be more than enough, but I'll hold off until we get a better sense of what will need to be done during the session. Melinda From nobody Tue Apr 22 07:28:23 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CC01A04AA for ; Tue, 22 Apr 2014 07:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj4lwgyBpMlH for ; Tue, 22 Apr 2014 07:28:18 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id B95461A047E for ; Tue, 22 Apr 2014 07:28:16 -0700 (PDT) Received: (qmail 1393 invoked by uid 1000); 22 Apr 2014 14:28:10 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Tue, 22 Apr 2014 15:28:10 +0100 Message-ID: <53567C7A.5010503@comodo.com> Date: Tue, 22 Apr 2014 15:28:10 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ben Laurie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/DWsD0gn1WokxXgXu8K38YBAEQkU Cc: "trans@ietf.org" Subject: Re: [Trans] Infrastructure for logs? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 14:28:20 -0000 1. Linux (Gentoo and/or Debian). 2. PostgreSQL. 3. Stateless load balancing. On 17/04/14 18:07, Ben Laurie wrote: > My team is considering doing some work on the open source log > implementation to make it less of a reference implementation and more > something that you could consider running in (or adapting for) a > production environment. > > It would help guide our thinking of those CAs (and others) who are > considering running logs would give us some hints about the kind of > production environment they would like to run in. In particular: > > 1. Operating systems. > > 2. Database managers. > > 3. Any other constraints you might have on a production environment. > > Public discussion would be useful, but if you would rather tell me > privately that is also fine. Bear in mind that what we learn will > probably influence open source code, though that's obviously very > unlikely to reveal anything about anyone in particular. > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Apr 23 03:00:17 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CA31A004E for ; Wed, 23 Apr 2014 03:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9ElDoLaNR1l for ; Wed, 23 Apr 2014 03:00:12 -0700 (PDT) Received: from ektmail2iron2.euskaltel.es (ektmail2iron2.euskaltel.es [212.142.144.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2611A0197 for ; Wed, 23 Apr 2014 03:00:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAPmNV1PUNwgN/2dsb2JhbABZg1W9T4c6gS10giYBAQQBAQEtDAExGwIBCCIGFwEGASYfEQEBBRIIiD0BCM8mEwSOJziDJIEVAQOYdZJVgzM X-IPAS-Result: AqIEAPmNV1PUNwgN/2dsb2JhbABZg1W9T4c6gS10giYBAQQBAQEtDAExGwIBCCIGFwEGASYfEQEBBRIIiD0BCM8mEwSOJziDJIEVAQOYdZJVgzM X-IronPort-AV: E=Sophos;i="4.97,911,1389740400"; d="scan'208";a="145861421" Received: from ektmail1mta2.euskaltel.es (HELO correo.euskaltel.es) ([212.55.8.13]) by ektmail2iron2.euskaltel.es with ESMTP; 23 Apr 2014 11:46:52 +0200 Received: from ejlp023.ejgv ([195.77.108.247]) by ektmail1mta2.euskaltel.es (Sun Java System Messaging Server 6.2-9.09 (built Jan 8 2008)) with ESMTP id <0N4H00FOGAG3P5D0@ektmail1mta2.euskaltel.es> for trans@ietf.org; Wed, 23 Apr 2014 12:00:04 +0200 (CEST) Received: from AFE03.ejsarea.net (afe03 [10.200.192.20]) by ejlp023.ejgv (8.13.1/8.13.1) with ESMTP id s3NA03rf029223; Wed, 23 Apr 2014 12:00:03 +0200 Received: from AEX06.ejsarea.net ([10.200.198.15]) by AFE03.ejsarea.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Apr 2014 12:00:03 +0200 Date: Wed, 23 Apr 2014 12:00:02 +0200 From: i-barreira@izenpe.net In-reply-to: To: benl@google.com, public@cabforum.org, trans@ietf.org Message-id: <763539E260C37C46A0D6B340B5434C3B093F1CBC@AEX06.ejsarea.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [Trans] Infrastructure for logs? Thread-index: Ac9aX5nnG7kAL7lPQuOVYjfpK6bBfQEeuRVg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-OriginalArrivalTime: 23 Apr 2014 10:00:03.0675 (UTC) FILETIME=[CC1392B0:01CF5EDA] Archived-At: http://mailarchive.ietf.org/arch/msg/trans/wOsE_63dv3xoWu7GbwbGuXYevsI Subject: Re: [Trans] Infrastructure for logs? X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 10:00:15 -0000 Hi Ben, 1.- Linux (CentOS, Ubuntu) 2.- MySQL 3.- none at this moment I=F1igo Barreira Responsable del =C1rea t=E9cnica i-barreira@izenpe.net 945067705 ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta = egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada = (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, = korreo honi erantzuna. KONTUZ! ATENCION! Este mensaje contiene informacion privilegiada o confidencial = a la que solo tiene derecho a acceder el destinatario. Si usted lo = recibe por error le agradeceriamos que no hiciera uso de la informacion = y que se pusiese en contacto con el remitente. -----Mensaje original----- De: Trans [mailto:trans-bounces@ietf.org] En nombre de Ben Laurie Enviado el: jueves, 17 de abril de 2014 19:08 Para: CABFPub; trans@ietf.org Asunto: [Trans] Infrastructure for logs? My team is considering doing some work on the open source log = implementation to make it less of a reference implementation and more = something that you could consider running in (or adapting for) a = production environment. It would help guide our thinking of those CAs (and others) who are = considering running logs would give us some hints about the kind of = production environment they would like to run in. In particular: 1. Operating systems. 2. Database managers. 3. Any other constraints you might have on a production environment. Public discussion would be useful, but if you would rather tell me = privately that is also fine. Bear in mind that what we learn will = probably influence open source code, though that's obviously very = unlikely to reveal anything about anyone in particular. -- Certificate Transparency is hiring! Let me know if you're interested. _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Wed Apr 23 05:21:09 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A281A0345 for ; Wed, 23 Apr 2014 05:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.05 X-Spam-Level: * X-Spam-Status: No, score=1.05 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iP2Oowv8Ghx for ; Wed, 23 Apr 2014 05:21:07 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1991A036F for ; Wed, 23 Apr 2014 05:21:05 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id uy5so921632obc.13 for ; Wed, 23 Apr 2014 05:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=k5+Rv0IPUB1vVeVRyS9QBhfJQfUhiB4JD9f0VTNHSRA=; b=lhzYPsfd7bRFRp98FwximsjlTOzkoIJAGvnpnC9cVR2HKJ5bYcUsmh2udBkOPq0Ire adYl4o8I7rP68yUHl6pSnt1ZvO81MbUEzaWYjgz8ulps4WK/UyEMzIcAB4rhBR4JFhGU bkpJO8w3/Jc4c5sJNRe1sWcHrWi03g+nNRTeABuMgqm8V0fmXCOoQRWz2M+wbNk5y4sV e3SW2wQFwaWQW7Nav73B0B57IfizrRgQxRjdXg/QDQGt2BZyyssQEFzMApEGYTsaq5r1 MFkmIZRxHnpwIL8epcy0Y43ULra35A6shXz2yOCBs/HUmeI7CN5nFF4QpUkXwICN4ZGJ PhnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=k5+Rv0IPUB1vVeVRyS9QBhfJQfUhiB4JD9f0VTNHSRA=; b=ksIDv2caySgLyFteIyFT/A5BqQiBmcaLxSx7YGbKSrDNSxeC5txiIfQ/kgywqnhrGA Q3o6q61L6IaS/VjA9r+/Ax0yxbfcbPg9tcob+TEcSuGeeF7ZF3So4Q/0WUiZaAohUAfE bo8ofHce49KlbfWj6cKELnFLqD0ZxGCmX4JNE5ZxQrKEfRxvRCDquJh7sdW/WTirLpyC ExNDr+rpolKSML4vA/R+pfISIWfFhtJS2lbfTtIYyuSNAG5YpbZG7Bu7Mj21qqMuqIOI Pd3Uc/FgOVBorDIbO26G7PTwmT44kOSYPg4SZ6/mr8DQvV+J1TcoaGL84ailO92w/2Yx TmKw== X-Gm-Message-State: ALoCoQlJc/P9xImJuBdVkBCg55jv6IIo5EJfgpqQfmTwk2ER0tc5NQBCmq70IBK+dmNycacCY8fn3aHTDR/gsqvbLzX3wlpt8KamLqaL8hpNsE+bdi3Toz8Qoy1SnwWWJmgwqZCmzbLPPm0hFSWNQ7iEBJVhbNK7U3wmIUQKvxxfJ/TcD2HgKVofFCIo+Mb6szcE8FRDMBpX MIME-Version: 1.0 X-Received: by 10.60.65.1 with SMTP id t1mr42674315oes.7.1398255659189; Wed, 23 Apr 2014 05:20:59 -0700 (PDT) Received: by 10.182.93.141 with HTTP; Wed, 23 Apr 2014 05:20:59 -0700 (PDT) Date: Wed, 23 Apr 2014 13:20:59 +0100 Message-ID: From: Eran Messeri To: certificate-transparency@googlegroups.com, "trans@ietf.org" Content-Type: multipart/alternative; boundary=001a11c257a4df773304f7b4c3c5 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/C3_4muujK21yvg-9IXZNLhJVBsk Subject: [Trans] Last Call: Certificate Transparency - Second Hack Day: May 7th, 2014 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 12:21:08 -0000 --001a11c257a4df773304f7b4c3c5 Content-Type: text/plain; charset=UTF-8 Gentlefolk, If you intend to attend the second CT hack day, please sign up here by *Friday, May 2nd*. One of the issues that came up repeatedly recently was logs' infrastructure and using the open-source log implementation in production environments. If that's an interesting topic for you, the hack day would be a very suitable forum to discuss it. Regards, Eran ---------- Forwarded message ---------- From: Eran Messeri Date: Thu, Mar 27, 2014 at 10:55 AM Subject: Re: Certificate Transparency - Second Hack Day: May 7th, 2014 To: certificate-transparency@googlegroups.com, "trans@ietf.org" < trans@ietf.org> The Certificate Transparency team at Google invites interested parties to the second CT hack day at Google's London office on Wednesday, May 7th, 2014. The agenda is open, though we have some suggestions: - Improving open-source C++ and Python monitors. - Draft (I-D) editing for RFC6962-bis. - Updates on Chrome support and Google's production logs. - Gossip: brainstorming communication channels and implementation. Members of the trans WG are welcome to attend and collaborate (but it's not a trans WG meeting). We'll break into coding/discussion streams, like last time. Register your interest and propose agenda items here (by May 2nd). Eran, on behalf of the Certificate Transparency team at Google On Thu, Mar 27, 2014 at 10:30 AM, Eran Messeri wrote: > The Certificate Transparency team at Google invites interested parties to > the second CT hack day at Google's London officeon Wednesday, May 7th, 2014. > The agenda is open, though we have some suggestions:* Improving > open-source C++ and Python monitors.* Draft (I-D) editing for RFC6962-bis.* > Updates on Chrome support and Google's production logs.* Gossip: > brainstorming communication channels and implementation.Members of the > trans WG are welcome to attend and collaborate (but it's not a trans WG > meeting).We'll break into coding/discussion streams, like last time. > Register your interest and propose agenda items here (by > May 2nd). If you can't attend in-person, let us know so we may set up a > video conference for remote participants. > Eran, on behalf of the Certificate Transparency team at Google > --001a11c257a4df773304f7b4c3c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gentlefolk,
If you intend to attend the= second CT hack day, please sign up=C2=A0here<= /a>=C2=A0by=C2=A0Friday, May 2nd.

One of the issues that came up repeatedly recently was = logs' infrastructure and using the open-source log implementation in pr= oduction environments. If that's an interesting topic for you, the hack= day would be a very suitable forum to discuss it.

Regards,
Eran

---------- Forwarded message ----------
From: Eran Messeri <eranm@google.com>
Date: Thu, Mar 27, 2014 at 10:55 AM
Subject: Re: Certificate Transparenc= y - Second Hack Day: May 7th, 2014
To: certificate-transparency@googlegroups.com, = "trans@ietf.org" <trans@ietf.org>


The Certificate Transparency team at Google = invites interested parties to the second CT hack day at=C2=A0Goog= le's London office=C2=A0on Wednesday, May 7th, 2014.

The agenda is open, though= we have some suggestions:
  • <= span style=3D"font-family:arial,sans-serif;font-size:13px">Improving open-s= ource C++ and Python monitors.
  • Draft= (I-D) editing for RFC6962-bis.
  • Updates on Chrome support = and Google's production logs.
  • Gossip: brainstorming communication channels and implementation.=
Members of the trans WG are welcome to attend and c= ollaborate (but it's not a trans WG meeting).
We'll = break into coding/discussion streams, like last time.

Register your inter= est and propose agenda items=C2=A0here<= /a>=C2=A0(by Ma= y 2nd).


On Thu, Mar 27, 2014 at 10:30 AM, Eran M= esseri <eranm@google.com> wrote:
The Certificate Transparency team at Google invites intere= sted parties to the second CT hack day at Google= 9;s London office on Wednesday, May 7th, 2014.
The agenda is open, though we have some suggestions:* Improving open-source= C++ and Python monitors.* Draft (I-D) editing for RFC6962-bis.* Updates on= Chrome support and Google's production logs.* Gossip: brainstorming co= mmunication channels and implementation.Members of the trans WG are welcome= to attend and collaborate (but it's not a trans WG meeting).We'll = break into coding/discussion streams, like last time.
Register your interest and propose agenda items here=C2=A0(by May 2nd). If you can't attend = in-person, let us know so we may set up a video conference for remote parti= cipants.
Eran, on behalf of the Certificate Transparency team at Google


--001a11c257a4df773304f7b4c3c5-- From nobody Wed Apr 23 07:51:19 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83B61A03D6 for ; Wed, 23 Apr 2014 07:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqxQJmjSSiKh for ; Wed, 23 Apr 2014 07:51:14 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B23A81A0096 for ; Wed, 23 Apr 2014 07:51:13 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id cc10so5037757wib.8 for ; Wed, 23 Apr 2014 07:51:07 -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=psvuPfyLvyCkXD+1JZeie5YNbNVPZ9lBO7et4IcXOO4=; b=Kjk8Ex8g9xRccul50RThyXew6vASsRDQlv+mUxVRaIMY0bvRum4xaFZwRvta3rXVZ8 dgNaA1vvYHlvBdZvEyQIx0Or6WfXV1tVSPBu/ACcDi2SD48KbqaEu1aCrqq9HmtmoAV1 le26KFueYTxHXfgNqBH9mA8scFcc5ou0cE/opAPwF+hf80X/IUwIVKfcjm9I6DVZbgfw 5puV7CSpV1KzNjH3a1EvlKPOqrJJdf2ieJEdckUH/JbqFhSt7uqhlSe/VVyCtbOrNdOG M6zj5G2Ws/eyDgTCXLVrLGfvbNpIr4e6vapIYsZgUQOyUObrbYRWwzd0XV39re8wy6S1 dXOg== MIME-Version: 1.0 X-Received: by 10.180.105.132 with SMTP id gm4mr2113532wib.39.1398264667585; Wed, 23 Apr 2014 07:51:07 -0700 (PDT) Received: by 10.217.107.137 with HTTP; Wed, 23 Apr 2014 07:51:07 -0700 (PDT) In-Reply-To: <53559D3B.1090504@gmail.com> References: <53559D3B.1090504@gmail.com> Date: Wed, 23 Apr 2014 16:51:07 +0200 Message-ID: From: Jean-Michel Combes To: Melinda Shore Content-Type: multipart/alternative; boundary=f46d044280ead0425604f7b6dc67 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/IwgrcYErfj8GK2qd_FxNJUM8e_k Cc: "trans@ietf.org" Subject: Re: [Trans] IETF 90 scheduling X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 14:51:17 -0000 --f46d044280ead0425604f7b6dc67 Content-Type: text/plain; charset=UTF-8 Hi, I have actually two technical comments with the current specifications of CT: #1 Log server identification Currently, if I am correct, the identity of the log server providing the SCT is based on its public key (in fact, the hash of it), which is also stored in the TLS client. As with the public key pinning mechanism (cf. draft-ietf-websec-key-pinning), I am afraid about a potential complexity (from a technical/business point of view) to add a new public key in the TLS client (e.g., web browser), to be able to set up/manage a new log server. So, I am wondering, instead (or in parallel) of using log server's public key as log server's ID, if that would be easier to use URI for new log servers deployment. #2 Interaction between TLSA RR and CT At first, from my point of view, using TLSA RR means "prevention" and using CT means "repression". Now, if I want only do "prevention", the current CT specifications will not allow me to do it. Indeed, as specified in Section 3, TLS clients MUST reject certificates that do not have a valid SCT for the end-entity certificate, enforcing the use of CT by the TLS server. Maybe, replacing the MUST by a SHOULD, when TLSA RR is deployed, would relax this enforcement. I would appreciate any feedback from the WG regarding these comments. Thanks in advance for your replies. Best regards, JMC. 2014-04-22 0:35 GMT+02:00 Melinda Shore : > We just received notification that working group session > scheduling for the July meeting is now open. This is a good > time to be thinking about what needs to be done between > now and then and how session time will be spent. Right now > my sense is that a single two-hour session will be more than > enough, but I'll hold off until we get a better sense of > what will need to be done during the session. > > Melinda > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --f46d044280ead0425604f7b6dc67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
<= br>
I have actually two technical comments with the current specificat= ions of CT:

#1 Log server identification

Currentl= y, if I am correct, the identity of the log server providing the SCT is bas= ed on its public key (in fact, the hash of it), which is also stored in the= TLS client. As with the public key pinning mechanism (cf. draft-ietf-webse= c-key-pinning), I am afraid about a potential complexity (from a technical/= business point of view) to add a new public key in the TLS client (e.g., we= b browser), to be able to set up/manage a new log server.

So, I am wondering, instead (or in parallel) of using log server&= #39;s public key as log server's ID, if that would be easier to use URI= for new log servers deployment.

#2 Interaction between TLSA R= R and CT

At first, from my point of view, using TLSA RR means "preven= tion" and using CT means "repression". Now, if I want only d= o "prevention", the current CT specifications will not allow me t= o do it. Indeed, as specified in Section 3, TLS clients MUST reject certifi= cates that do not have a valid SCT for the end-entity certificate, enforcin= g the use of CT by the TLS server.

Maybe, replacing the MUST by a SHOULD, when TLSA RR is deployed, = would relax this enforcement.


I would appreciate any feedb= ack from the WG regarding these comments.

Thanks in advance fo= r your replies.

Best regards,

JMC.

2014-04-22 0:35 GMT+02:00 Melinda Shore <melinda.shore@gmail.com>:
We just received notification that working g= roup session
scheduling for the July meeting is now open. =C2=A0This is a good
time to be thinking about what needs to be done between
now and then and how session time will be spent. =C2=A0Right now
my sense is that a single two-hour session will be more than
enough, but I'll hold off until we get a better sense of
what will need to be done during the session.

Melinda

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

--f46d044280ead0425604f7b6dc67-- From nobody Thu Apr 24 07:52:09 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4DB1A033E for ; Thu, 24 Apr 2014 07:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cbpD7wnA91b for ; Thu, 24 Apr 2014 07:52:05 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9E10A1A032E for ; Thu, 24 Apr 2014 07:52:05 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id il7so3125267vcb.32 for ; Thu, 24 Apr 2014 07:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1Vtu4/rggeziTMbhnXZHB8fZACVVG531Gdcbs4Ea+ao=; b=Rusjyn56h979yMbnID2UkhTdfuHZ/uA+tNZD9MnqDLQl2JTGljN3IB8LQjPb0/rWe/ WMKN8BhivVftN+4wm2RQ8foCv6cZwnRlVjHV3evVuajefb18ng8ws8ZRyoRqrCWqySRl c1fnNW5CP6EchVOZyafgDfZR4JpsE8ommfefNVJWd/x2FZkS4lrXSIa1o0UjlG3yh9O4 rMDRyaUy+FUtCENttYYHOClOcgO5MyfZl2XvQ0HCGYZ8RQ0s7duipv73yWcRDecl0FVg Dj2D8238Lce8MsX7u60PKinyyQ9BHM4cDXy1rj8GjmVqINC274RqjrLFCRUdzqhFgrM7 OgjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1Vtu4/rggeziTMbhnXZHB8fZACVVG531Gdcbs4Ea+ao=; b=kv5JWPVORns6Z5wMl8wrf/1SzdEA+9ewiW1C/3VXawhsdjbHfNNPSf5SMImuOoRcc6 HWBbmSGPYs6FxqjotTDvCIk9iXRRaIuXu/H8r5VqaVXEzncwGiT74BaKqWG30pj0YGDl A17CM0zoPxsN9kcsVCM89zk75Hc1dUldXEtw6wy597dzNMWK6v9jqmfhlEgWh2FxbCgS LztVZvLi/GT2ekID9uTUBiU4NMqeN6Ieu2DZKCySj59J4OdSlBikAE4g5h+FQQ22gidg plKIGVzsWwy3eN+dNHgUO8bxWq8vuIVpMi2I1drnPlXok0xRA1u9ot0a9lhtGgVs0DhJ BAIw== X-Gm-Message-State: ALoCoQnelzaglmxNb9fLBCMIB2P/CxZQnyEGLcHehSEbSeg08StTiksgfgC4R7I2G+/HT3A5EmmvBzXyY4xt1Sa8Zhmp1V37raiizAwnom7tcg5an19b4vECtkc/2GLOzwH4NL267k7a9Ss7FF/hhOHPpi0+8xHy8eig/4+NVxJQIby/eqFhf1PPDmYUrOeKFL9gjXS4Nj2x MIME-Version: 1.0 X-Received: by 10.58.132.228 with SMTP id ox4mr666133veb.54.1398351119292; Thu, 24 Apr 2014 07:51:59 -0700 (PDT) Received: by 10.52.119.179 with HTTP; Thu, 24 Apr 2014 07:51:59 -0700 (PDT) In-Reply-To: References: <53559D3B.1090504@gmail.com> Date: Thu, 24 Apr 2014 15:51:59 +0100 Message-ID: From: Ben Laurie To: Jean-Michel Combes Content-Type: multipart/alternative; boundary=047d7b6da0eabcbc7d04f7cafd3c Archived-At: http://mailarchive.ietf.org/arch/msg/trans/h-NDjq2v7ZUQ4DdMvRrXyqxM0Tk Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] IETF 90 scheduling X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 14:52:07 -0000 --047d7b6da0eabcbc7d04f7cafd3c Content-Type: text/plain; charset=UTF-8 On 23 April 2014 15:51, Jean-Michel Combes wrote: > Hi, > > I have actually two technical comments with the current specifications of > CT: > > #1 Log server identification > > Currently, if I am correct, the identity of the log server providing the > SCT is based on its public key (in fact, the hash of it), which is also > stored in the TLS client. As with the public key pinning mechanism (cf. > draft-ietf-websec-key-pinning), I am afraid about a potential complexity > (from a technical/business point of view) to add a new public key in the > TLS client (e.g., web browser), to be able to set up/manage a new log > server. > > So, I am wondering, instead (or in parallel) of using log server's public > key as log server's ID, if that would be easier to use URI for new log > servers deployment. > There's already been a fairly extensive discussion on this, perhaps still not resolved. But my position continues to be that the TLS client needs to know various things about the log - public key, URL, MMD. I don't see the problem in those things being communicated in a data structure (e.g. in JSON). Indeed we will shortly be defining such a structure for Chrome's valid logs. Whether this should form part of the RFC is up to the WG. > > #2 Interaction between TLSA RR and CT > > At first, from my point of view, using TLSA RR means "prevention" and > using CT means "repression". Now, if I want only do "prevention", the > current CT specifications will not allow me to do it. Indeed, as specified > in Section 3, TLS clients MUST reject certificates that do not have a valid > SCT for the end-entity certificate, enforcing the use of CT by the TLS > server. > That is correct. > > Maybe, replacing the MUST by a SHOULD, when TLSA RR is deployed, would > relax this enforcement. > No, because this gives an attacker a way to evade CT. I would appreciate any feedback from the WG regarding these comments. > > Thanks in advance for your replies. > > Best regards, > > JMC. > > > 2014-04-22 0:35 GMT+02:00 Melinda Shore : > > We just received notification that working group session >> scheduling for the July meeting is now open. This is a good >> time to be thinking about what needs to be done between >> now and then and how session time will be spent. Right now >> my sense is that a single two-hour session will be more than >> enough, but I'll hold off until we get a better sense of >> what will need to be done during the session. >> >> Melinda >> >> _______________________________________________ >> Trans mailing list >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> > > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > > -- Certificate Transparency is hiring! Let me know if you're interested. --047d7b6da0eabcbc7d04f7cafd3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 23 April 2014 15:51, Jean-Michel Combes <jeanmichel.c= ombes@gmail.com> wrote:
Hi,

I have actually two technical comme= nts with the current specifications of CT:

#1 Log server identification

Currently, if I am corr= ect, the identity of the log server providing the SCT is based on its publi= c key (in fact, the hash of it), which is also stored in the TLS client. As= with the public key pinning mechanism (cf. draft-ietf-websec-key-pinning),= I am afraid about a potential complexity (from a technical/business point = of view) to add a new public key in the TLS client (e.g., web browser), to = be able to set up/manage a new log server.

So, I am wondering, instead (or in parallel) of using log server&= #39;s public key as log server's ID, if that would be easier to use URI= for new log servers deployment.

There's already been a fairly ex= tensive discussion on this, perhaps still not resolved. But my position con= tinues to be that the TLS client needs to know various things about the log= - public key, URL, MMD. I don't see the problem in those things being = communicated in a data structure (e.g. in JSON).

Indeed we will shortly be defining such a structure for= Chrome's valid logs. Whether this should form part of the RFC is up to= the WG.
=C2=A0

#2 Interaction bet= ween TLSA RR and CT

At first, from my point of view, using TLSA RR means "preven= tion" and using CT means "repression". Now, if I want only d= o "prevention", the current CT specifications will not allow me t= o do it. Indeed, as specified in Section 3, TLS clients MUST reject certifi= cates that do not have a valid SCT for the end-entity certificate, enforcin= g the use of CT by the TLS server.

That is corr= ect.
=C2=A0
=

Maybe, replacing the MUST by a SHOULD, when TLSA RR is deployed, = would relax this enforcement.
=
No, because this gives an attacker a way to evade CT.

I = would appreciate any feedback from the WG regarding these comments.

=
Thanks in advance for your replies.

Best regards,

JMC.

2014-04-22 0:35 GMT+02:00 Melinda Shore <melinda.shore@gmail.com>:

We just received notification that working g= roup session
scheduling for the July meeting is now open. =C2=A0This is a good
time to be thinking about what needs to be done between
now and then and how session time will be spent. =C2=A0Right now
my sense is that a single two-hour session will be more than
enough, but I'll hold off until we get a better sense of
what will need to be done during the session.

Melinda

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


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




--
Certific= ate Transparency is hiring! Let me know if you're interested.
--047d7b6da0eabcbc7d04f7cafd3c-- From nobody Thu Apr 24 07:56:54 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2EF1A02A6 for ; Thu, 24 Apr 2014 07:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCDtRx8x5TqM for ; Thu, 24 Apr 2014 07:56:49 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 596801A0298 for ; Thu, 24 Apr 2014 07:56:49 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 16E9E165634; Thu, 24 Apr 2014 14:56:43 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 0BB74165633; Thu, 24 Apr 2014 14:56:43 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id CE0AB2FD65; Thu, 24 Apr 2014 14:56:42 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Thu, 24 Apr 2014 10:56:42 -0400 From: "Salz, Rich" To: Ben Laurie , Jean-Michel Combes Date: Thu, 24 Apr 2014 10:56:41 -0400 Thread-Topic: [Trans] IETF 90 scheduling Thread-Index: Ac9fzMSg206CPWNBT02IveFFJ5GuwgAAFDFA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1@USMBX1.msg.corp.akamai.com> References: <53559D3B.1090504@gmail.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: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/SZc8Tsml-dHuSTXFp9Djmczbh48 Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] IETF 90 scheduling X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 14:56:51 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1USMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFRoZXJlJ3MgYWxyZWFkeSBiZWVuIGEgZmFpcmx5IGV4dGVuc2l2ZSBkaXNjdXNzaW9uIG9u IHRoaXMsIHBlcmhhcHMgc3RpbGwgbm90IHJlc29sdmVkLiBCdXQgbXkgcG9zaXRpb24gY29udGlu dWVzIHRvIGJlIHRoYXQgdGhlIFRMUyBjbGllbnQgbmVlZHMgdG8ga25vdyB2YXJpb3VzIHRoaW5n cyBhYm91dCB0aGUgbG9nIC0gcHVibGljIGtleSwgVVJMLCBNTUQuIEkgZG9uJ3Qgc2VlIHRoZSBw cm9ibGVtIGluIHRob3NlIHRoaW5ncyBiZWluZyBjb21tdW5pY2F0ZWQgaW4gYSBkYXRhIHN0cnVj dHVyZSAoZS5nLiBpbiBKU09OKS4NCg0KLi4gYW5kIGNyeXB0byBtZWNoYW5pc21zIGJlaW5nIHVz ZWQuIEF0IElNSE8sIHRoaXMgaXMgbm90IHJlc29sdmVkLg0KDQoNCsOYICBJbmRlZWQgd2Ugd2ls bCBzaG9ydGx5IGJlIGRlZmluaW5nIHN1Y2ggYSBzdHJ1Y3R1cmUgZm9yIENocm9tZSdzIHZhbGlk IGxvZ3MuIFdoZXRoZXIgdGhpcyBzaG91bGQgZm9ybSBwYXJ0IG9mIHRoZSBSRkMgaXMgdXAgdG8g dGhlIFdHLg0KDQpZZXMsIGF0IGxlYXN0IHRoZXJlLiAgSSB0aGluayB0aGUgc3RydWN0dXJlIHNo b3VsZCBiZSBlbWJlZGRlZCBpbiB0aGUgbG9n4oCZcyByb290LCBmb3Igc2ltcGxpY2l0eSBvZiBk ZXBsb3ltZW50IGV2b2x1dGlvbiwgYW5kIGFpZGluZyBhZnRlci10aGUtZmFjdCBhdWRpdGluZy4N Cg0KICAgICAgICAgICAgICAgIC9yJA0KDQotLQ0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVy DQpBa2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1BDQpJTTogcnNhbHpAamFiYmVyLm1l PG1haWx0bzpyc2FsekBqYWJiZXIubWU+OyBUd2l0dGVyOiBSaWNoU2Fseg0KDQo= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1USMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMDQyMDUzNDc2Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDcyNzg1NDEyIDQ1NTYxMjIyNCA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjI7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJv ZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OldpbmdkaW5ncyc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+w5g8 c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7IDwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGVyZSdzIGFscmVhZHkgYmVlbiBhIGZhaXJseSBleHRl bnNpdmUgZGlzY3Vzc2lvbiBvbiB0aGlzLCBwZXJoYXBzIHN0aWxsIG5vdCByZXNvbHZlZC4gQnV0 IG15IHBvc2l0aW9uIGNvbnRpbnVlcyB0byBiZSB0aGF0IHRoZSBUTFMgY2xpZW50IG5lZWRzIHRv IGtub3cgdmFyaW91cyB0aGluZ3MgYWJvdXQgdGhlIGxvZyAtIHB1YmxpYyBrZXksIFVSTCwgTU1E LiBJIGRvbid0IHNlZSB0aGUgcHJvYmxlbSBpbiB0aG9zZSB0aGluZ3MgYmVpbmcgY29tbXVuaWNh dGVkIGluIGEgZGF0YSBzdHJ1Y3R1cmUgKGUuZy4gaW4gSlNPTikuPG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4u LiBhbmQgY3J5cHRvIG1lY2hhbmlzbXMgYmVpbmcgdXNlZC4gQXQgSU1ITywgdGhpcyBpcyBub3Qg cmVzb2x2ZWQuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OldpbmdkaW5ncyc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+ w5g8c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7IDwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JbmRlZWQgd2Ugd2lsbCBzaG9ydGx5IGJlIGRlZmlu aW5nIHN1Y2ggYSBzdHJ1Y3R1cmUgZm9yIENocm9tZSdzIHZhbGlkIGxvZ3MuIFdoZXRoZXIgdGhp cyBzaG91bGQgZm9ybSBwYXJ0IG9mIHRoZSBSRkMgaXMgdXAgdG8gdGhlIFdHLjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5ZZXMsIGF0IGxlYXN0IHRoZXJlLsKgIEkgdGhpbmsgdGhlIHN0cnVjdHVyZSBzaG91bGQgYmUg ZW1iZWRkZWQgaW4gdGhlIGxvZ+KAmXMgcm9vdCwgZm9yIHNpbXBsaWNpdHkgb2YgZGVwbG95bWVu dCBldm9sdXRpb24sIGFuZCBhaWRpbmcgYWZ0ZXItdGhlLWZhY3QgYXVkaXRpbmcuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgL3IkPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz4tLcKgIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5QcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QWth bWFpIFRlY2hub2xvZ2llcywgQ2FtYnJpZGdlLCBNQTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JTTogPGEgaHJlZj0ibWFpbHRv OnJzYWx6QGphYmJlci5tZSI+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPnJzYWx6QGphYmJlci5t ZTwvc3Bhbj48L2E+OyBUd2l0dGVyOiBSaWNoU2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1USMBX1msgcorp_-- From nobody Thu Apr 24 08:00:51 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F061A032E for ; Thu, 24 Apr 2014 08:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAdKWQbkNO1E for ; Thu, 24 Apr 2014 08:00:47 -0700 (PDT) Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFB81A031E for ; Thu, 24 Apr 2014 08:00:46 -0700 (PDT) Received: (qmail 13632 invoked by uid 1000); 24 Apr 2014 15:00: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 (AES128-SHA encrypted) ESMTPSA; Thu, 24 Apr 2014 16:00:37 +0100 Message-ID: <53592714.4080502@comodo.com> Date: Thu, 24 Apr 2014 16:00:36 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Salz, Rich" , Ben Laurie , Jean-Michel Combes References: <53559D3B.1090504@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/c3IXK0jFcvkruUd2U69zqcqKCI4 Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] IETF 90 scheduling X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:00:50 -0000 "the log's root"? Root certificate? Each log has a raw public/private key, not a root certificate. Or do you mean something else? On 24/04/14 15:56, Salz, Rich wrote: > ØThere's already been a fairly extensive discussion on this, perhaps > still not resolved. But my position continues to be that the TLS client > needs to know various things about the log - public key, URL, MMD. I > don't see the problem in those things being communicated in a data > structure (e.g. in JSON). > > .. and crypto mechanisms being used. At IMHO, this is not resolved. > > ØIndeed we will shortly be defining such a structure for Chrome's valid > logs. Whether this should form part of the RFC is up to the WG. > > Yes, at least there. I think the structure should be embedded in the > log’s root, for simplicity of deployment evolution, and aiding > after-the-fact auditing. > > /r$ -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Apr 24 08:01:31 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160451A032E for ; Thu, 24 Apr 2014 08:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDPLZ5LwE_SX for ; Thu, 24 Apr 2014 08:01:28 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 00CBF1A031E for ; Thu, 24 Apr 2014 08:01:28 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0D8B6165641; Thu, 24 Apr 2014 15:01:22 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (unknown [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 02408165639; Thu, 24 Apr 2014 15:01:22 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id DC59898042; Thu, 24 Apr 2014 15:01:21 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Thu, 24 Apr 2014 11:01:20 -0400 From: "Salz, Rich" To: Rob Stradling , Ben Laurie , Jean-Michel Combes Date: Thu, 24 Apr 2014 11:01:19 -0400 Thread-Topic: [Trans] IETF 90 scheduling Thread-Index: Ac9fzfZ9rWDMy22fSSGrHlvO4nFv+wAAAwcw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B4@USMBX1.msg.corp.akamai.com> References: <53559D3B.1090504@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1@USMBX1.msg.corp.akamai.com> <53592714.4080502@comodo.com> In-Reply-To: <53592714.4080502@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/IUxVL4cMVJHuXANaXqpytGsCXl0 Cc: Melinda Shore , "trans@ietf.org" Subject: Re: [Trans] IETF 90 scheduling X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 15:01:30 -0000 The root block of the tree. -- =20 Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rsalz@jabber.me; Twitter: RichSalz From nobody Fri Apr 25 06:02:55 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0834D1A04A3 for ; Fri, 25 Apr 2014 06:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M2fXE5S92U0 for ; Fri, 25 Apr 2014 06:02:52 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4971A047E for ; Fri, 25 Apr 2014 06:02:51 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id h18so2217113igc.0 for ; Fri, 25 Apr 2014 06:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bwYRErIfloA5OEUOKcSkr5NPEfiZwQm8GD4cAgZC734=; b=pV1rB2m0mu+ujUNMnR4nheauA4BKuw9ogiptSLCdaePzJoI0BMLxfQVz6PZnBbVCNe hdqt9N0QpSJwjOmqOlBnRcSakGUEf9E/TZUHjoE0DPi+pA8aec97GHGJSb9l3FagOwgh kieg8tHvNAlQ3uws1mlE9k0xNrnHrUTN8OWY5eczP2zwp5/dXt5/hxoL9iOlPAhTV7tz sJUmm9SUMviUxTmMJk3Ft57MoWGMvS1Pj9Ay+e8HbCB/Y1AB3yKUQwmzD1y/0nqsrbyp Q730HeRwirVSiNQha57EaeDEatYLr01YnuoDV7GooFUhQ5dmOAk8Yq/pWERsmqySVoJ7 F3nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bwYRErIfloA5OEUOKcSkr5NPEfiZwQm8GD4cAgZC734=; b=hYquL5Wx+I/EO5JvoKE14dUtopvjIQ674LzoTT52e2J3w6oxXWlcgm2NFUy5aJUtX/ Ds4xXhvCxy/mB8tMl3C85xkvsr0p8v/uia1gUqy4WAXO2Ql5EwZD5zUhUG++6wTs1VhC E0MA6hZ5WVdQkNO7vBiIW68h2rkih/7Qlgnieff7tyzvbrhCXRdV+7NVRCPRYD9TYIUN YsnzPF3wltiwiJRbEciLlNd3nN8BKhe+TJ5p9gFU2o6Z/sHDBw0N8hSBXDo3wxgEv48u ifKq3yJ4iCbBB/CIGlIBqjQRTUQPV4oD3U8tLi1TKtnE4bRlli648YeSZFQoYxOMD9G9 dCEA== X-Gm-Message-State: ALoCoQnE/6B6DvLQU/JLaaXnPc6KpbdvCR8nkO3l/5xY90mb95p3H8p+O5XDtwVVQmxb3MjUy8Uj2W9+HKX21uNJZb4cB2/He+ACS7I3FSS4NHL/UgIwgqckccu4PD55fa0h7XqvsBJdmQOFidj6cOGsN4Mj4jLcbmZDxrKkI29W1P+sMalUqbPKo2T3NZ25rIzBc+XW02us MIME-Version: 1.0 X-Received: by 10.50.25.67 with SMTP id a3mr4858593igg.28.1398430958767; Fri, 25 Apr 2014 06:02:38 -0700 (PDT) Received: by 10.64.147.42 with HTTP; Fri, 25 Apr 2014 06:02:38 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B4@USMBX1.msg.corp.akamai.com> References: <53559D3B.1090504@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1@USMBX1.msg.corp.akamai.com> <53592714.4080502@comodo.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B4@USMBX1.msg.corp.akamai.com> Date: Fri, 25 Apr 2014 14:02:38 +0100 Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: multipart/alternative; boundary=047d7bd74a2c8a697604f7dd94f5 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/R_SRPjg6NHgQjTxhVYyuCz1lB54 Cc: Rob Stradling , "trans@ietf.org" , Melinda Shore , Jean-Michel Combes Subject: Re: [Trans] IETF 90 scheduling X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 13:02:53 -0000 --047d7bd74a2c8a697604f7dd94f5 Content-Type: text/plain; charset=UTF-8 On 24 April 2014 16:01, Salz, Rich wrote: > The root block of the tree. > Hmm. I don't really object to that. How would we identify the logs to clients in your scheme? It seems to me that logs should be allowed to change their URL (not recommended, but possibly could be needed), so the URL doesn't seem like a good identifier. We need something that allows clients to gossip so they can verify that the parameters they see in the root are as expected. -- Certificate Transparency is hiring! Let me know if you're interested. --047d7bd74a2c8a697604f7dd94f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 24 April 2014 16:01, Salz, Rich <rsalz@akamai.com>= wrote:
The root block of the tree.
=

Hmm. I don't really object to that. How would we id= entify the logs to clients in your scheme? It seems to me that logs should = be allowed to change their URL (not recommended, but possibly could be need= ed), so the URL doesn't seem like a good identifier.

We need something that allows clients to gossip so they= can verify that the parameters they see in the root are as expected.
=

--
Certificate Transparency is hiring! Let me know= if you're interested.
--047d7bd74a2c8a697604f7dd94f5-- From nobody Fri Apr 25 06:25:29 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F5F1A04AE for ; Fri, 25 Apr 2014 06:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQS_N707YXou for ; Fri, 25 Apr 2014 06:25:23 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 78CE91A01D4 for ; Fri, 25 Apr 2014 06:25:23 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 02F34473DE; Fri, 25 Apr 2014 13:25:17 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id EA22647391; Fri, 25 Apr 2014 13:25:16 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id E0A92FE054; Fri, 25 Apr 2014 13:25:16 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Fri, 25 Apr 2014 09:25:16 -0400 From: "Salz, Rich" To: Ben Laurie Date: Fri, 25 Apr 2014 09:25:10 -0400 Thread-Topic: [Trans] IETF 90 scheduling Thread-Index: Ac9ghqj5EeYrYdJpTGao3KiZ2zdfhgAAsV2g Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E90C@USMBX1.msg.corp.akamai.com> References: <53559D3B.1090504@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1@USMBX1.msg.corp.akamai.com> <53592714.4080502@comodo.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B4@USMBX1.msg.corp.akamai.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: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E90CUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/InplLuZg5WhJEfgb1fuRUNNjk9A Cc: "trans@ietf.org" Subject: Re: [Trans] IETF 90 scheduling X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 13:25:25 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E90CUSMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEhtbS4gSSBkb24ndCByZWFsbHkgb2JqZWN0IHRvIHRoYXQuDQoNCkh1enphaCEgVGltZSB0 byByZWNhbGwgIGhlYXJ0YmxlZWQgYXMgYW4gYXR0ZW1wdCB0byB3ZWFyIHlvdSBkb3duIOKYuiAg KFRvbyBzb29uPykNCg0KDQrDmCAgV2UgbmVlZCBzb21ldGhpbmcgdGhhdCBhbGxvd3MgY2xpZW50 cyB0byBnb3NzaXAgc28gdGhleSBjYW4gdmVyaWZ5IHRoYXQgdGhlIHBhcmFtZXRlcnMgdGhleSBz ZWUgaW4gdGhlIHJvb3QgYXJlIGFzIGV4cGVjdGVkLg0KDQoNClNvbWV0aGluZyBpbiBVUkwgc3lu dGF4IHRvIGlkZW50aWZ5IHRoZSBsb2csIGV2ZW4gaWYgaXTigJlzIG5vdCB0aGUgYWN0dWFsIFVS TD8gIExpa2UgYW4gWE1MTlMgc3RyaW5nPw0KDQotLQ0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2lu ZWVyDQpBa2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1BDQpJTTogcnNhbHpAamFiYmVy Lm1lPG1haWx0bzpyc2FsekBqYWJiZXIubWU+OyBUd2l0dGVyOiBSaWNoU2Fseg0K --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E90CUSMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxODg2Njc2NDM4Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQ0NjM2NzQ5OCA2NjkxNDM0ODIgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxi b2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0 aW9uMT48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEJz48 c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz7DmDxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJU aW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkht bS4gSSBkb24ndCByZWFsbHkgb2JqZWN0IHRvIHRoYXQuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkh1enphaCEgVGltZSB0byByZWNhbGwgwqBoZWFydGJsZWVkIGFz IGFuIGF0dGVtcHQgdG8gd2VhciB5b3UgZG93biA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QnPko8L3NwYW4+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz7CoCAoVG9vIHNvb24/KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0nZm9udC1mYW1pbHk6V2luZ2RpbmdzJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdu b3JlJz7DmDxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsg PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPldlIG5lZWQgc29tZXRoaW5nIHRoYXQgYWxs b3dzIGNsaWVudHMgdG8gZ29zc2lwIHNvIHRoZXkgY2FuIHZlcmlmeSB0aGF0IHRoZSBwYXJhbWV0 ZXJzIHRoZXkgc2VlIGluIHRoZSByb290IGFyZSBhcyBleHBlY3RlZC48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPlNvbWV0aGluZyBpbiBVUkwgc3ludGF4IHRvIGlkZW50aWZ5IHRoZSBsb2csIGV2ZW4gaWYg aXTigJlzIG5vdCB0aGUgYWN0dWFsIFVSTD/CoCBMaWtlIGFuIFhNTE5TIHN0cmluZz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPi0twqAgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlByaW5jaXBhbCBTZWN1cml0eSBFbmdpbmVlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5Ba2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1BPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklNOiA8YSBocmVmPSJt YWlsdG86cnNhbHpAamFiYmVyLm1lIj48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+cnNhbHpAamFi YmVyLm1lPC9zcGFuPjwvYT47IFR3aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E90CUSMBX1msgcorp_-- From nobody Fri Apr 25 06:41:16 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C611A01D5 for ; Fri, 25 Apr 2014 06:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaMs7gmJ2Yg9 for ; Fri, 25 Apr 2014 06:41:12 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A2B371A01D2 for ; Fri, 25 Apr 2014 06:41:12 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ld13so4748004vcb.33 for ; Fri, 25 Apr 2014 06:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=840taZBpO6mRzc5alaDr9oH6SFAolyU+0oE5Yq1eR48=; b=cc7p/3h96DkNDJF6X30cWBnapZNCO6VzSOIwg7qpArZav5g6dAEqs+uwzMY15E5DX5 Q+Yg0zZdnp8qs6/3pfVh97HsQRtwTbLOebdMc6sm1YtdsfR2FKZXPc0l5AQL5Es10twr l1THO3Bo8k40E6o//C1f6WLkG2UOoxzEwTgzA5SsXPLAAxjAZ4YMgtNBp2cQWZPUl0t9 H7L6Q60TYV7g5c8RQHjVzeBdT5ClfUcchsavmqW8il7iMKh1eswy9VBLhY45Hjpw9lnK P36l7l/bZ/qYgXNsvYKiAdfp3Rg8qqq7rYhXTZKRh44IkCDXGW8dQT6IyCYyCVY9oZ8B 8a4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=840taZBpO6mRzc5alaDr9oH6SFAolyU+0oE5Yq1eR48=; b=gFf+x11hcCr9aH8PwkEgXS/s06t8uyRjR3dxlZSaE5RnWSt7aVCiddTs6ee7TAvfcg HOqzku1xdm1MJai8OHwiE96YSnmsZ2Y72CFa9v8sjYFNFNbCVMT3rM5lf3m7XwsviPLL TBHJG4bQUuW6Fuy4GL/UzW3VvP3DegAe3o60koGIMir1OC2zfSbMJi1sONBQ6Xi8IFHf 2YuIYJ/Kym3Nwk2DoJLjf2hWLKHXbLVYl2g05dOb43gVuAH0BlTvCY/4MON20awZ0jdZ /RjBqoABt0ylXNxErPWHH2SfvUy4Z9ep93uqjEZVEfF8vf2gVKdwamxh8BxqmplUUcZa Yblg== X-Gm-Message-State: ALoCoQkHvQV+LE0FH6JGE7LLGkQ4KbmIRC0AT/Ld/1IYKJrigZ1IqaC2ppZ0pk7a15ipRhQM6KLabCsvvGXbh/xk/t0kk5qDGoAlubm1CtdLNLlXA263E+cudMTUjA8Kl663xtFX0as+WbTwdz/gLMCQCDzZZgxZS6sSj06iWX8NQGbOiKajU/WnM4p763vAsG2Ekb9jXFJn MIME-Version: 1.0 X-Received: by 10.220.162.6 with SMTP id t6mr6971424vcx.12.1398433265238; Fri, 25 Apr 2014 06:41:05 -0700 (PDT) Received: by 10.52.100.4 with HTTP; Fri, 25 Apr 2014 06:41:05 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E90C@USMBX1.msg.corp.akamai.com> References: <53559D3B.1090504@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1@USMBX1.msg.corp.akamai.com> <53592714.4080502@comodo.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B4@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E90C@USMBX1.msg.corp.akamai.com> Date: Fri, 25 Apr 2014 14:41:05 +0100 Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11c214ec046b1604f7de1e24 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/_a_kUPWCIBreuHCeokZJbxhpRU4 Cc: "trans@ietf.org" Subject: Re: [Trans] IETF 90 scheduling X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 13:41:14 -0000 --001a11c214ec046b1604f7de1e24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25 April 2014 14:25, Salz, Rich wrote: > =C3=98 Hmm. I don't really object to that. > > > > Huzzah! Time to recall heartbleed as an attempt to wear you down J (Too > soon?) > ;-) > > > =C3=98 We need something that allows clients to gossip so they can verif= y > that the parameters they see in the root are as expected. > > > > Something in URL syntax to identify the log, even if it=E2=80=99s not the= actual > URL? Like an XMLNS string? > Hmm. We already have three ways to structure data. Do we need to introduce XML, too? :-) --=20 Certificate Transparency is hiring! Let me know if you're interested. --001a11c214ec046b1604f7de1e24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 25 April 2014 14:25, Salz, Rich <rsalz@akamai.com>= wrote:

=C3=98=C2=A0 Hmm. I don't really object t= o that.

=C2=A0

Huzzah! Time to rec= all =C2=A0heartbleed as an attempt to wear you down J=C2=A0 (Too soon?)


;-)
=C2=A0

= =C2=A0

=C3=98=C2=A0 = We need something that allows clients to gossip so they can verify that the= parameters they see in the root are as expected.

=C2=A0

Something in URL syntax to identify the= log, even if it=E2=80=99s not the actual URL?=C2=A0 Like an XMLNS string?<= /span>


Hmm. We already have three way= s to structure data. Do we need to introduce XML, too? :-)

--
Certificate Transparency is hiring! Let me know if you'= ;re interested.
--001a11c214ec046b1604f7de1e24-- From nobody Fri Apr 25 06:43:30 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619891A01D5 for ; Fri, 25 Apr 2014 06:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlIbpH0p2ppm for ; Fri, 25 Apr 2014 06:43:24 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id AC4321A01D2 for ; Fri, 25 Apr 2014 06:43:24 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1B6C148201; Fri, 25 Apr 2014 13:43:18 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 0FDF048194; Fri, 25 Apr 2014 13:43:18 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id D5ED02FD65; Fri, 25 Apr 2014 13:43:17 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Fri, 25 Apr 2014 09:43:17 -0400 From: "Salz, Rich" To: Ben Laurie Date: Fri, 25 Apr 2014 09:43:16 -0400 Thread-Topic: [Trans] IETF 90 scheduling Thread-Index: Ac9gjAbu4QHwB31mSFqngiAMSmc21wAACIhg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E931@USMBX1.msg.corp.akamai.com> References: <53559D3B.1090504@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1@USMBX1.msg.corp.akamai.com> <53592714.4080502@comodo.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B4@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E90C@USMBX1.msg.corp.akamai.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: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E931USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/EOpKxZNq-eMwEGBrSKkPpvbMYTs Cc: "trans@ietf.org" Subject: Re: [Trans] IETF 90 scheduling X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 13:43:27 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E931USMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEhtbS4gV2UgYWxyZWFkeSBoYXZlIHRocmVlIHdheXMgdG8gc3RydWN0dXJlIGRhdGEuIERv IHdlIG5lZWQgdG8gaW50cm9kdWNlIFhNTCwgdG9vPyA6LSkNCg0KTm8sIEkganVzdCBtZWFudCBh IFVSSSBzdHJpbmcgdGhhdCBtaWdodCBub3QgYmUgZGVyZWZlcmVuY2FibGUuDQoNCklzIGl0IHRv byBvbmVyb3VzIHRvIHNheSB0aGF0IGlmIGEgbG9n4oCZcyBVUkwgY2hhbmdlcywgdGhlbiBhIG5l dyBsb2cgbXVzdCBiZSBjcmVhdGVkPw0KDQotLQ0KUHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVy DQpBa2FtYWkgVGVjaG5vbG9naWVzLCBDYW1icmlkZ2UsIE1BDQpJTTogcnNhbHpAamFiYmVyLm1l PG1haWx0bzpyc2FsekBqYWJiZXIubWU+OyBUd2l0dGVyOiBSaWNoU2Fseg0K --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E931USMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjE1NDEwODcyOw0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo2MDY0MDM2NjYgLTE0 MDUyMDkwMTQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1z dGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2 IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEnPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpXaW5nZGluZ3MnPjxzcGFuIHN0eWxlPSdtc28t bGlzdDpJZ25vcmUnPsOYPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SG1tLiBXZSBhbHJlYWR5IGhh dmUgdGhyZWUgd2F5cyB0byBzdHJ1Y3R1cmUgZGF0YS4gRG8gd2UgbmVlZCB0byBpbnRyb2R1Y2Ug WE1MLCB0b28/IDotKTxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5ObywgSSBqdXN0IG1lYW50IGEgVVJJIHN0cmluZyB0 aGF0IG1pZ2h0IG5vdCBiZSBkZXJlZmVyZW5jYWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklzIGl0 IHRvbyBvbmVyb3VzIHRvIHNheSB0aGF0IGlmIGEgbG9n4oCZcyBVUkwgY2hhbmdlcywgdGhlbiBh IG5ldyBsb2cgbXVzdCBiZSBjcmVhdGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS3CoCA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ UHJpbmNpcGFsIFNlY3VyaXR5IEVuZ2luZWVyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFrYW1haSBUZWNobm9sb2dpZXMsIENh bWJyaWRnZSwgTUE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+SU06IDxhIGhyZWY9Im1haWx0bzpyc2FsekBqYWJiZXIubWUiPjxz cGFuIHN0eWxlPSdjb2xvcjpibHVlJz5yc2FsekBqYWJiZXIubWU8L3NwYW4+PC9hPjsgVHdpdHRl cjogUmljaFNhbHo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7120C35E931USMBX1msgcorp_-- From nobody Fri Apr 25 08:21:15 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F318D1A04F1 for ; Fri, 25 Apr 2014 08:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfBYqApU1ZyC for ; Fri, 25 Apr 2014 08:21:10 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D5B7E1A0345 for ; Fri, 25 Apr 2014 08:21:09 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lg15so4935254vcb.16 for ; Fri, 25 Apr 2014 08:21: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; bh=UGRl8LmnVac09kaN5uWHAu9Ufl0xuHgEkVzISsVceyo=; b=Wk3B/GCjMQUY06jDYUVsj4Y+QWTZdEHNHS8DfkpcOkSJW7tUl6UKs/uFgD3uIACr/m OEtRIAL0h1JQhw0JLqGKDNRdDhJHoEJMpNEmImJqwapZ/9EGvyDErGogGYWtO44N6NDG SYnwjTIF+5v09C7Ihs6UGhmznwvUg91HOzayRY/0LLA/8VlAmN5K+RsRGAaPUCYAsgkM 4ZykGc6Adq7Y+O2FzFQkbKfRlgu//kKqty42qjb+7CSQDjSLgU70o2NiP154LLu+/OUT BuV4GDyPDW/eezZ0Q21IBXeDad/yYigOM6yUifgLwIobXpgia0xzqGG3R3ltJs54kzt+ uONQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UGRl8LmnVac09kaN5uWHAu9Ufl0xuHgEkVzISsVceyo=; b=VNXmHEGMt4ICUgcdMVZW9P/ctiH58GsFQvFlhsUgxz+SHO5Obb3PFgySxLhwwO+k7d IeMJcHi0/GF6oreMmewCg/qcO1N4iVMLDeD4mFe73/yyetE1dwHu1WB+V9aGR5Rzj6ej EsHt6m1j7blr2Rnos3h2BvL8k4reEl3bmvcbw7YxYvKhiNBd1TG5GJnIkzYRVGEHoS5H 7QfAg3V/KckkLjEuIqvQtDQsHUr9yBk62PU5I9q0JyyTQhnFI+omR49ZY/X7gVHehSa2 iqcBewT2J+wQ+clAvp8Q7PEbQ8vPRPZIsWDu02iydg4DIS6NTI1DwFlIl5WAS6tLNbXc ys9g== X-Gm-Message-State: ALoCoQnnwKtTE1dxR0IGUiiJpZ2SfUhh7+IogoMkOUrQ9OAdYXfJLZQWExvFgyEKtpgMZW/YcRj0m2lI4l3R2/MQxwU/DWQ0k/6oxsfOoAmH11z/54NZ4r4bzWNXQDbs9sNl+0pm/XiZJCkqZFq1GppCkBSi+XNXTEEG0etSmKqmD4YPGUkG/zaXvi5xrPg2LDxpHuYOyJGT MIME-Version: 1.0 X-Received: by 10.52.240.140 with SMTP id wa12mr52070vdc.52.1398439262997; Fri, 25 Apr 2014 08:21:02 -0700 (PDT) Received: by 10.52.100.4 with HTTP; Fri, 25 Apr 2014 08:21:02 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E931@USMBX1.msg.corp.akamai.com> References: <53559D3B.1090504@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B1@USMBX1.msg.corp.akamai.com> <53592714.4080502@comodo.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E5B4@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E90C@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120C35E931@USMBX1.msg.corp.akamai.com> Date: Fri, 25 Apr 2014 16:21:02 +0100 Message-ID: From: Ben Laurie To: "Salz, Rich" Content-Type: multipart/alternative; boundary=20cf3078130c82fe0804f7df8307 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/fA3gj-zWKNmDMeNWg2K8UUsxNqM Cc: "trans@ietf.org" Subject: Re: [Trans] IETF 90 scheduling X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 15:21:11 -0000 --20cf3078130c82fe0804f7df8307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 25 April 2014 14:43, Salz, Rich wrote: > =C3=98 Hmm. We already have three ways to structure data. Do we need to > introduce XML, too? :-) > > > > No, I just meant a URI string that might not be dereferencable. > > > > Is it too onerous to say that if a log=E2=80=99s URL changes, then a new = log must > be created? > Maybe not. > > > -- > > Principal Security Engineer > > Akamai Technologies, Cambridge, MA > > IM: rsalz@jabber.me; Twitter: RichSalz > --=20 Certificate Transparency is hiring! Let me know if you're interested. --20cf3078130c82fe0804f7df8307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 25 April 2014 14:43, Salz, Rich <rsalz@akamai.com>= wrote:

=C3=98=C2=A0 Hmm. We already have three ways to structure data. Do we need t= o introduce XML, too? :-)

=C2=A0

No, I just meant a = URI string that might not be dereferencable.

=C2=A0

Is it too onerous t= o say that if a log=E2=80=99s URL changes, then a new log must be created?<= /span>


Maybe not.
=C2=A0

=

= =C2=A0

--=C2=A0

Principal Securi= ty Engineer

Akamai Technologies, Camb= ridge, MA

IM: rsalz@jabber.me; Twitter: RichSalz




-= -
Certificate Transparency is hiring! Let me know if you're interes= ted.
--20cf3078130c82fe0804f7df8307-- From nobody Fri Apr 25 19:35:53 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F03E1A0432 for ; Fri, 25 Apr 2014 19:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy3ODY0w1MVf for ; Fri, 25 Apr 2014 19:35:47 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 214C11A0427 for ; Fri, 25 Apr 2014 19:35:47 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y13so2824269pdi.14 for ; Fri, 25 Apr 2014 19:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=oMsAEW8GwUHHY5Rg53Hw4jK7zL+KhMG6Rr2+72LV9Qw=; b=anm+PwGNOtHFL6aGvg3KHrg8rO/S5RXp7B+iHMPuLzcEnTWj0hXvI5Mqhu7zXb6LvV /kt7bOpvbaVUR/SEzKQXLyFIg6Bjaf37lDfm1FgDJEXb7g6ZHJNfpVeh4V6hLSW7TB3n PGJTeVjYDXGF7UG7eFtGpA9vaf660I17QLTVxJAbUc7YgJA5G4lR+cKOsFvyQ5Bw/muX G7l4AgszDwSqMQbG8tSuoiGIHLvAjWnojiE46ca+huwmyW6PIbfgo800PUvexGdjn49v eSGhMUzvdfqGFpmOdw6w+gys/PijzIA3EBdxiOh50oaRNn8FsalQNA9Qfbtk3IFbSBBR ndsw== X-Received: by 10.69.20.107 with SMTP id hb11mr11334510pbd.99.1398479740579; Fri, 25 Apr 2014 19:35:40 -0700 (PDT) Received: from spandex.local (63-140-81-156.nwc.dsl.dynamic.acsalaska.net. [63.140.81.156]) by mx.google.com with ESMTPSA id oe4sm19095405pbb.33.2014.04.25.19.35.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Apr 2014 19:35:40 -0700 (PDT) Message-ID: <535B1B7A.8090002@gmail.com> Date: Fri, 25 Apr 2014 18:35:38 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ZtHR0oWwbpk0tGGvlPCgSKH-SXY Subject: [Trans] Checkpointing X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 02:35:48 -0000 I thought this might be a good time to ask folks to take a look at the contents of the issue tracker, make sure that issues that need to be resolved to get the document to publication are included, that what's in there is legit and does need to be resolved, etc. If you haven't taken a look at it yet, this might also be a good time to scan it and see if there's some particular item (or items) that you feel you can help close. The URI is: http://tools.ietf.org/wg/trans/trac/report/1 Thanks, Melinda From nobody Tue Apr 29 07:56:35 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA63A1A0923 for ; Tue, 29 Apr 2014 07:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lagf9XMkJQ7f for ; Tue, 29 Apr 2014 07:56:25 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC9B1A0924 for ; Tue, 29 Apr 2014 07:56:25 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id fa1so348121pad.20 for ; Tue, 29 Apr 2014 07:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ge5MQioc+KGQjckImOpnhZvqYfnkA00UFQyJHRuAJfI=; b=Tkreo45TywpuGq33Zz5Z0Mj5zhPGbzk63WWvOG6PfvcemW1+t37FIbQMFo04cBjtQU 8VkKKs8dKhsDKaEYa2QOkaS1QesVrvxiN15O1Z/5CcEyP7EFEpdKyGleHIgJvaz8HmZa IhtZsRV1OrtKr8aVd9cMAMJpnq8+LdD4x30rxwu1kdfx050PnUij7k5eqdeTrM7kwG3k Prh/ej4ZWssViVNC/TEcIBFc/Uh9fMkHYlZyQjCltvGGNA4euQpMVw2DiyAczHZO8fqQ 1PMUXnKI9QuoFojwGH9FTC7YTmo6ZCbfqiS4g4ySZn5Ww6Fso10E/rtRAVFMFV1y2XKS 9zvA== X-Received: by 10.66.254.166 with SMTP id aj6mr34648257pad.11.1398783382146; Tue, 29 Apr 2014 07:56:22 -0700 (PDT) Received: from spandex.local (63-140-94-85.dynamic.dsl.acsalaska.net. [63.140.94.85]) by mx.google.com with ESMTPSA id nw13sm89103834pab.37.2014.04.29.07.56.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 07:56:21 -0700 (PDT) Message-ID: <535FBD92.7020701@gmail.com> Date: Tue, 29 Apr 2014 06:56:18 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "trans@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/AHImX0XWH0PU5SJ87Ep_Co9sMAU Subject: [Trans] Toronto session X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 14:56:32 -0000 I need to get a session request in for the Toronto meeting. I have a strong preference for using face to face meeting time for discussion and for resolving issues that have been raised on the mailing list or in the issue tracker. Right now things seem to be going smoothly, but I'd like to get a sense from the people actually doing the work of what they feel would benefit from face-to-face discussion, how much time they think is needed, whether or not there are outstanding issues that need more explanation, etc. Trying to figure out how much time to request, as well. The options are 1 hour, 2 hours, 2.5 hours, and some combination in multiple sessions. Right now my feeling is that we wouldn't need more than two hours but I'm open to requesting more if there's a need. Melinda From nobody Wed Apr 30 04:45:54 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F15B1A0723 for ; Wed, 30 Apr 2014 04:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTfq-DINY2nU for ; Wed, 30 Apr 2014 04:45:43 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5EED71A6F4B for ; Wed, 30 Apr 2014 04:45:43 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id lf12so2055969vcb.27 for ; Wed, 30 Apr 2014 04:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yzX/nmXM+/YpYHG4oV6aie6JHfsG6G5fROVITcU7HkE=; b=mmB0SzWrED+yyFaIlxOF0rJlRc9Mf9H9qhfVkXoPjQmYjcdvS+BsX6Ray5RDX18C5n VGLYiqZQepXGCptBql4VLlsNxrpx27o8pi/CpBNXQTFd4TWjSKsNHGMWreiOY9o8LQRu TEkrM6UmgKc1AOUaZNjSh9g6Wo6T7pz5GnnPi1ukiFfOkUOeXOudyUwvxRcdUhNrd0Vo Upz7BC/PqyAzbwg5lkcUldM5cRdrYTajdw9vR5JGXeSY3vV2eE1mi58fvK+ewvY9KqGF YOMUfmLh1vTv6OtEAEBPWjOXyCt1CAVg/cws7fMSvs+p60w6ofVCHf1qIgJtLSXqpdv0 2s5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yzX/nmXM+/YpYHG4oV6aie6JHfsG6G5fROVITcU7HkE=; b=iTzePF8qIFuM6HQMfIWwA/J3rlaPJfxOcvGjA7aj8xuKuMaLoaag6jox0I8YCLt/BZ PNJRlOn+SQvOh9ZGYYIGmhqcXIU05BbCo9YZpUvvw2nV3MFeCBw8sArQIJsjr0SErc3K Su6AqOwCZM9LDjVIejJapsdaGTDzdIeyBZGM3Jycfjgkp5BbtBRo5m/v/mAzFpRQV+u9 zgDF7N/d4p9KWeo0rhpcPCXqPzZMAt0iolLwLXLbKIV1stOVIYNuaqSzDcKy+dde8wyd 1yjkC/AflU1juD3ek8Izk2hmIiaAOTEP7aN7MJf4ezr1QRHTiUBPRxPXw29KDlNTz+V4 RAvA== X-Gm-Message-State: ALoCoQnAUCJGMYnt5xayMMwgZQWCTcRWV09CH+GUy0QFtO539RwjGYzCblP8oKAQc+UsNqOQyVTnJZM2kjYRX1oGDwprvNKgCcsqBxT4vvsiAPJ1DNiov98oFrOQDDJBesWVSc8xUA5mcDIBx4H7qP5366sJ6KIEzPLNT1mRAB8IlP0I4khUeK8UTAYbydlyl1B3zU1GgVkb MIME-Version: 1.0 X-Received: by 10.221.26.10 with SMTP id rk10mr3633975vcb.0.1398858341598; Wed, 30 Apr 2014 04:45:41 -0700 (PDT) Received: by 10.52.100.4 with HTTP; Wed, 30 Apr 2014 04:45:41 -0700 (PDT) In-Reply-To: <535FBD92.7020701@gmail.com> References: <535FBD92.7020701@gmail.com> Date: Wed, 30 Apr 2014 12:45:41 +0100 Message-ID: From: Ben Laurie To: Melinda Shore Content-Type: multipart/alternative; boundary=001a11339ae48ae67904f84116a3 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/EheV2ZVdQRTMN8k-1wuxLO5iz10 Cc: "trans@ietf.org" Subject: Re: [Trans] Toronto session X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 11:45:46 -0000 --001a11339ae48ae67904f84116a3 Content-Type: text/plain; charset=UTF-8 On 29 April 2014 15:56, Melinda Shore wrote: > I need to get a session request in for the Toronto meeting. > I have a strong preference for using face to face meeting time > for discussion and for resolving issues that have been raised on > the mailing list or in the issue tracker. Right now things > seem to be going smoothly, but I'd like to get a sense from > the people actually doing the work of what they feel would benefit > from face-to-face discussion, how much time they think is > needed, whether or not there are outstanding issues that need > more explanation, etc. > > Trying to figure out how much time to request, as well. The > options are 1 hour, 2 hours, 2.5 hours, and some combination > in multiple sessions. Right now my feeling is that we wouldn't > need more than two hours but I'm open to requesting more > if there's a need. > What's the deadline for this? We have the CT Hack Day coming up next week, and we might have a better view, at least from our end, on what's left after that. We intend to do some work on the I-D. Which reminds me, I put the wrong OIDs into -02, I need to push a new version. -- Certificate Transparency is hiring! Let me know if you're interested. --001a11339ae48ae67904f84116a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 29 April 2014 15:56, Melinda Shore <melinda.shore@gmail.c= om> wrote:
I need to get a session request in for the T= oronto meeting.
I have a strong preference for using face to face meeting time
for discussion and for resolving issues that have been raised on
the mailing list or in the issue tracker. =C2=A0Right now things
seem to be going smoothly, but I'd like to get a sense from
the people actually doing the work of what they feel would benefit
from face-to-face discussion, how much time they think is
needed, whether or not there are outstanding issues that need
more explanation, etc.

Trying to figure out how much time to request, as well. =C2=A0The
options are 1 hour, 2 hours, 2.5 hours, and some combination
in multiple sessions. =C2=A0Right now my feeling is that we wouldn't need more than two hours but I'm open to requesting more
if there's a need.

What's the d= eadline for this? We have the CT Hack Day coming up next week, and we might= have a better view, at least from our end, on what's left after that. = We intend to do some work on the I-D.

Which reminds me, I put the wrong OIDs into -02, I need= to push a new version.

--
Certificate Transp= arency is hiring! Let me know if you're interested.
--001a11339ae48ae67904f84116a3-- From nobody Wed Apr 30 11:02:41 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E141A0952 for ; Wed, 30 Apr 2014 11:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcU3lRxr3CyL for ; Wed, 30 Apr 2014 11:02:38 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 576011A0852 for ; Wed, 30 Apr 2014 11:02:38 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id z10so730888pdj.0 for ; Wed, 30 Apr 2014 11:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Nxur91Q1APFzc0u6yLkLN1wmViTX4ynAzfEMz3O911s=; b=Zv7XzIU3PG4cWU/DDX/KxNjwbvpk9p1ApYjMrPV7vbayAorwMD+sL4KtP7nPBCtVCI hQ0KJ0uYd4N1tpSlM7LOQpu4M0eY0xdeXJlCV0brmd55u2Jksah1nwGQctSnQvfHCg4U PK5nEY9H3Hj5SGvZYrIQ7OF33igRhKZGK47V4avyzVZ6emEWz+noH2lliz3JJrr7vEG+ +L5/yXrk9AuPbLmtnT31+fA+zg+nEWw2ql6XnimkWcTXIsv4cFgWlDfXotkQDrShd/Uz 154cl5nRekBMOed1iYoeABQMbG1ZWKK36H6aeHYqzeLUwKRMF3wNy9XscMFZAYrEMxX/ P7sQ== X-Received: by 10.66.136.103 with SMTP id pz7mr11228140pab.140.1398880953421; Wed, 30 Apr 2014 11:02:33 -0700 (PDT) Received: from spandex.local (209-112-214-47-rb1.nwc.dsl.dynamic.acsalaska.net. [209.112.214.47]) by mx.google.com with ESMTPSA id lr3sm139968965pab.4.2014.04.30.11.02.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Apr 2014 11:02:32 -0700 (PDT) Message-ID: <53613AA7.2070109@gmail.com> Date: Wed, 30 Apr 2014 10:02:15 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ben Laurie References: <535FBD92.7020701@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hRSYguHeNgXWtx7dNQ_pyoNdYDI Cc: "trans@ietf.org" Subject: Re: [Trans] Toronto session X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 18:02:39 -0000 On 4/30/14 3:45 AM, Ben Laurie wrote: > What's the deadline for this? We have the CT Hack Day coming up next > week, and we might have a better view, at least from our end, on what's > left after that. We intend to do some work on the I-D. I went ahead and requested 1.5 hours. We can modify that if it becomes clear that we need more/less time. Scheduling remains open until June 6. Melinda