On M= on, Feb 24, 2014 at 4:00 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.ne= t> wrote:

On Thu 2014-02-20 12:06:08 -= 0500, Melinda Shore wrote:
> I've uploaded a first crack at an agenda to
> http://www.ietf.org/proceedings/89/agenda/agenda-89-trans= .
> Please let me know if anything is missing, or if you'd like
> to request some time on the agenda.

Thanks for organizing, Melinda! =A0I'd like to try to make a bit = of time
in the agenda to talk about the use of CT in the SMTP+STARTTLS
environment.

Given the current opportunistic mode that TLS is used for in SMTP, we
may decide that there is no reasonable intersection at all today, but i
think it would be worth putting the issue on people's radar with a brie= f
discussion.

For example, brief discussion of any of these questions might be useful:

What these all come down to is the = question of using the CT log infrastructure as a potential source for autho= ritative security policy.

It is a completely valid approach and one that I am loo= king at but in the context of SMTP with S/MIME and PGP.

Whether or not these is time at the meeting, I suggest this is a disc= ussion we continue on therightkey because I have a feeling that Melinda is = going to kick us out pretty quick if we get into discussion of approaches. = I would kick me out.

This is why I think it is important to d= istinguish between keeping notary logs for issue of certificates by CAs sep= arate from the issue of how notarize the notary logs. The way I see it we w= ill end up eventually with some collection of 'meta-notaries' which= cross notarize at regular intervals making defection or failure of a meta-= notary of little concern. Every meta-notary will cross notatrize every othe= r within a 24hour period so they are interchangable from a trust point of v= iew.

I would see CT logs of SSL cert issue to be one input t= o the meta notaries, CT logs of S/MIME certs another, PGP key signings anot= her, security policy statements another and so on.

--
Website: http://h= allambaker.com/

--001a1134cbfcb4d70d04f32d6f81-- From nobody Mon Feb 24 13:26: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 E23141A01EE for ; Mon, 24 Feb 2014 13:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvaZ8mjkMZRL for ; Mon, 24 Feb 2014 13:25:59 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id ADB391A0193 for ; Mon, 24 Feb 2014 13:25:59 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id lj1so7087401pab.12 for ; Mon, 24 Feb 2014 13:25:59 -0800 (PST) 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=4LYZcYmL3Vb1NSGaGgk0KBjLfO6nb4uW3pqCDGSpDeU=; b=ILQA7KXTWQgK2d3buyu7oZzYz6uuRkpZNgC8rLzrMVcAJFw+Ocy+SgW+sQutzUU462 Dyc8AB0NPZ3SR8E/qCmOqSyNKLe+TDAMN+F6NoISxsHt5MOHKWxYrdz9nnRrP+/JqoG1 fJf20i+ahkRkpLcmk2G3svWTOE/VMZmDGkJYwntGCaoTIZDHedlt9mKSO1rHFLGOMEQA m3oXb0Q+MC0fA8cT5uCDatFn0qdUYOBX3Dzg9whtBtgWfpy5zmq5OgrwJuMGADk06IeG gPPeB7lMKXTPYGsFL/2Q+ZbbYwIpYTD1c4N+YRgt58AYpwp6G4rqlbPkot9gQSmtx02J X7Bw== X-Received: by 10.68.171.99 with SMTP id at3mr1952981pbc.109.1393277159214; Mon, 24 Feb 2014 13:25:59 -0800 (PST) Received: from spandex.local (63-140-68-38-rb2.sol.dsl.dynamic.acsalaska.net. [63.140.68.38]) by mx.google.com with ESMTPSA id pp5sm3165341pbb.33.2014.02.24.13.25.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 13:25:58 -0800 (PST) Message-ID: <530BB8E3.30303@gmail.com> Date: Mon, 24 Feb 2014 12:25:55 -0900 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: Phillip Hallam-Baker References: <53063600.4020102@gmail.com> <878ut0usxw.fsf@alice.fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/K4eLqMu83zD5-6f5gtfXifB4ZRw Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] Draft agenda 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, 24 Feb 2014 21:26:01 -0000 On 2/24/14 12:12 PM, Phillip Hallam-Baker wrote: > Whether or not these is time at the meeting, I suggest this is a > discussion we continue on therightkey because I have a feeling that > Melinda is going to kick us out pretty quick if we get into discussion > of approaches. I would kick me out. We have a very short session scheduled in London, and I feel pretty strongly about IETF meetings as working meetings. As for relevance, right now therightkey is the best place for discussion of other approaches to fixing PKI, while trans is specifically for discussion of certificate transparency. The only thing that's in our charter at the moment is 6962bis. That doesn't mean that other applications of CT are out-of- scope, but that we'd need to recharter to take them on as work items. It's a bit early for that. Probably the best way to keep these proposals alive is to get internet drafts posted. I'd like to stay focused on getting 6962bis done, but won't stomp on discussion of other CT applications unless they take over the mailing list. And otherwise I am completely agnostic on the question of whether those discussions happen here or on therightkey. Melinda From nobody Mon Feb 24 13:35:26 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD95C1A01E5 for ; Mon, 24 Feb 2014 13:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.41 X-Spam-Level: * X-Spam-Status: No, score=1.41 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 R06uDUulbC3r for ; Mon, 24 Feb 2014 13:35:21 -0800 (PST) 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 B6B8D1A0193 for ; Mon, 24 Feb 2014 13:35:20 -0800 (PST) Received: (qmail 10659 invoked by uid 1000); 24 Feb 2014 21:35:18 -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; Mon, 24 Feb 2014 21:35:18 +0000 Message-ID: <530BBB15.5000600@comodo.com> Date: Mon, 24 Feb 2014 21:35:17 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: trans@ietf.org, Ben Laurie References: <530637C7.303@gmail.com> In-Reply-To: <530637C7.303@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/3yjIOttkSZ0LEnY7H-exbkc6JOs Cc: Melinda Shore Subject: Re: [Trans] Milestones 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, 24 Feb 2014 21:35:23 -0000 On 20/02/14 17:13, Melinda Shore wrote: > One of the first things we need to do is to establish milestones > for working group deliverables, specifically a target date for > getting 6962bis through working group last call. It's my > sense right now that things are going pretty smoothly and there > are no major points of contention. If we shoot for November > 2014 for wglc we'd be able to discuss problems that come up > during last call at the November meeting. So: > > Does November 2014 seem reasonable for working group last > call for 6962bis? Ben, does November 2014 work for you, given the milestones dated earlier than that in Google's EV/CT roll-out plan? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Mon Feb 24 13:43:10 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA4A1A025F for ; Mon, 24 Feb 2014 13:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_48=0.6] 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 bKkQsw_4-e7O for ; Mon, 24 Feb 2014 13:43:07 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 20BC31A0165 for ; Mon, 24 Feb 2014 13:43:07 -0800 (PST) Received: from [192.168.23.229] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 0251AF984 for ; Mon, 24 Feb 2014 16:43:04 -0500 (EST) Message-ID: <530BBCE6.1070100@fifthhorseman.net> Date: Mon, 24 Feb 2014 16:43:02 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: "trans@ietf.org" References: <53063600.4020102@gmail.com> <878ut0usxw.fsf@alice.fifthhorseman.net> <530BB8E3.30303@gmail.com> In-Reply-To: <530BB8E3.30303@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="G1bDoRl58K23HoQBu3GCp4bT8A5t3btU5" Archived-At: http://mailarchive.ietf.org/arch/msg/trans/uXSEKSCtgvDvwwa4HotWPNVnk9E Subject: Re: [Trans] Draft agenda 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, 24 Feb 2014 21:43:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --G1bDoRl58K23HoQBu3GCp4bT8A5t3btU5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 02/24/2014 04:25 PM, Melinda Shore wrote: > As for relevance, right now therightkey is the best place > for discussion of other approaches to fixing PKI, while trans > is specifically for discussion of certificate transparency. > The only thing that's in our charter at the moment is 6962bis. > That doesn't mean that other applications of CT are out-of- > scope, but that we'd need to recharter to take them on > as work items. I think you're saying you want the slot in London to focus on getting the mechanism right, and not trying to propose policy, which is completely reasonable. I'm happy to stay focused. There's nothing in RFC 6962 (and i hope there won't be in 6962bis) that is HTTPS-specific, though; it's defined as a mechanism for logging X.509 certificates for use in TLS, regardless of the application layer traffic within the TLS session. So i hope that the use of CT in SMTP+STARTTLS isn't seen as an "other application" -- it's still TLS. If we suspect that CT is somehow valid only for X.509 certs used by HTTPS servers, we should make that more explicit in the draft (but i hope we don't!) Regards, --dkg --G1bDoRl58K23HoQBu3GCp4bT8A5t3btU5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJTC7zmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcr0kP+gPwFYsEBpNYElzeWFChtsjh M/mkCwVdkCPoC8maTF0xrHGpxMjr9XLIYFHCCHOS0iNIkQCQsthjcZ5/cYELNGeZ q3jV8XvR509FUEuPwORKGnV9AtffMSGBGaIyXjok8DT6XAa5SF1Y7W0pX8chbWWC rLi2g3/H1wPMsjzmOtDV0ewFmafZvgzy8P3T5RY8WplwC1oQTrSH2wWc7Qg6MhWV 7yBirUgW/8emEZTCrGexKOlg9EhA4N9xKcIdYPi7rFZrr1nI2KxmBQkYO/8smUR5 Bc64SzC8Li+P8fua9GdVYU+ygU7nR7wydri94JeL+U9V7z+WXe+Z4j+MRmlEsPi6 rkuO/fiNj9n6XDvq/teCMv37h8vlG6NbqHfEyuB+P0tuIV59Skqo16xceYSWh/W+ Hbo5ehU8hSpVFSNmWKjyFkRpJXZHeViqOJOWnEGNTXVgoFA8wMD8l8RNarmZJpix EWPzGD9y5Is/pyZ/G2maAyQW4ORMMpGcTmN+Fkv3rmwIQBIxTerUhhWvsIbcImyI Bpp4qZ2uyLQ/hOWIGL0K+Nu13ENAY4E7Tnv5mmeUwBXZx2KRF0GNhvLQOELCT52Y b16yvl3h16DNedxh2Zxwq5AYqhtCrviAXQmXBIlkrPuxZiQnsVCETdaknZUUvgrx mTIm/plcZGKAGaEvI6KN =gHtK -----END PGP SIGNATURE----- --G1bDoRl58K23HoQBu3GCp4bT8A5t3btU5-- From nobody Mon Feb 24 18:01: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 AD09A1A0398; Mon, 24 Feb 2014 18:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mu2dKxOkSdYE; Mon, 24 Feb 2014 18:01:12 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5BB1A0221; Mon, 24 Feb 2014 18:01:11 -0800 (PST) Received: from BL2PR03MB467.namprd03.prod.outlook.com (10.141.92.23) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 02:01:09 +0000 Received: from BL2PR03MB467.namprd03.prod.outlook.com ([10.141.92.23]) by BL2PR03MB467.namprd03.prod.outlook.com ([10.141.92.23]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 02:01:09 +0000 From: Anoosh Saboori To: Melinda Shore , "trans@ietf.org" Thread-Topic: Dealing with fraudulent certificates via certificate reputation Thread-Index: Ac8xzK0o1YcgswOlSnSDIRHhJZhbwQ== Date: Tue, 25 Feb 2014 02:01:09 +0000 Message-ID: <873b20cac6834d9cb347dee1e131dad2@BL2PR03MB467.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.227.155.230] x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(81686001)(81816001)(33646001)(15975445006)(85852003)(56776001)(85306002)(83072002)(80976001)(4396001)(94316002)(83322001)(19580395003)(74876001)(74502001)(74662001)(31966008)(87936001)(2656002)(65816001)(66066001)(87266001)(56816005)(90146001)(80022001)(92566001)(47446002)(49866001)(94946001)(69226001)(81542001)(47976001)(47736001)(74316001)(63696002)(76786001)(76576001)(59766001)(77982001)(86362001)(76176001)(76796001)(74366001)(15202345003)(74706001)(50986001)(53806001)(54356001)(86612001)(93516002)(93136001)(81342001)(79102001)(51856001)(54316002)(76482001)(95416001)(46102001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB467.namprd03.prod.outlook.com; CLIP:71.227.155.230; FPR:7272C748.9AB064C6.43DB0D43.D85A3729.2012E; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/N2qUJXUtZjASHMjFQPr3nV1WlTw Cc: Magnus Nystrom , Anthony Nadalin , "therightkey@ietf.org" , Nelly Porter Subject: [Trans] Dealing with fraudulent certificates via certificate reputation 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, 25 Feb 2014 02:01:13 -0000 Hello, We would like to introduce certificate reputation, which was shipped as par= t of IE 11. This feature aims to address some of the issues with Web PKI t= hat were raised by Diginotar and Comodo incidents. We asked to take few min= utes on the trans WG meeting in the next IETF meeting to present this featu= re and chairs requested us to start a thread on this in WG mailing list. Pl= ease see below for description of this feature. http://blogs.technet.com/b/pki/archive/2014/02/22/a-novel-method-in-ie11-fo= r-dealing-with-fraudulent-digital-certificates.aspx=20 Thank you, Anoosh From nobody Mon Feb 24 23:19:36 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AA71A050E for ; Mon, 24 Feb 2014 23:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 F0PFsbO30C8X for ; Mon, 24 Feb 2014 23:19:32 -0800 (PST) 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 DC5A01A0312 for ; Mon, 24 Feb 2014 23:19:31 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id im17so6943720vcb.19 for ; Mon, 24 Feb 2014 23:19:30 -0800 (PST) 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=//eV/ulsFhe+5tFFQEmTNHXOrVvyxCMavyqyyIDO8O8=; b=CkJRrs5zDvRqdhPyYStw23ak6tOqmE88JGbZQ+IQ8V802kLyDqxI1NVUAiqwwcldUn wRka9yZ5vVTTQrFRy4Py5LSlhsQy7hCQjgtl0sfUMz3BcWH3lWNSMPwt/5a0lT6Dh76r ZqCgAmjF0hajwbgZiuws8b+ygBYNy2nd6BZWWwrTtRW6ceuhWV9RjmheNpJ0pLjE1kt0 gqX38rblZm2YsQCMod0x3cQ1kJokoDIBAvXBXZW6TSltPauoSA5GADbGASl+w1eKkktS ct1+B3WT4Dop/aIXdr5o8udYwkzuUpeJP+fkdn7P5iWg8OErLkqpKC0/h5/fD2KIEReF Y9OQ== 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=//eV/ulsFhe+5tFFQEmTNHXOrVvyxCMavyqyyIDO8O8=; b=gbYnAAZaYCW+Wq8oDxF4qCGlZbcwvMRtTaGftC//MJYF2H8ELKluhtntGT862z5VUl tdC8hIlaHwvni5mT1KrpumXtZDPHta8cb+IveXAuPrNZSZKHbh0KxJIMse/4H03yT7L6 d3HKUBbrewbfbO7mzf3BaXTlIV1uAbLLyy3ajWI6AZ/6ro6MyIws8PnZx7GDFbHUUwYj fwvljl/gf0NOsRuKaqXtPvk/dIv13YIs+QzCseUkxyzU5uxHE6wPDnDWzOBqONTSZpIc MWsDBp89yBXBmqcjmopn26WTFLP4vt850mn6ZgkWyknzJzOctLHCuZ65RSYLiXDZ56G9 GyjQ== X-Gm-Message-State: ALoCoQldWiggVy8W7P7xjBNiieK47Mh4RmR4cU3ELUPUFoI2o5FOIxIcmqTa7uoZI8/7elbgBAJDKOnq25J4fQ+rXUGKwvxftkdzUSmK520d6M28ryiA68OaJH8QD4gTIZ0JZ42/zZMX6s7t710IwnmBo2Fc4QjP5qFu4Of94nM8QbX/GfkhaLT+3rfbEXmMe3jcb1GxVOJE MIME-Version: 1.0 X-Received: by 10.220.252.134 with SMTP id mw6mr20861vcb.51.1393312770846; Mon, 24 Feb 2014 23:19:30 -0800 (PST) Received: by 10.52.230.105 with HTTP; Mon, 24 Feb 2014 23:19:30 -0800 (PST) In-Reply-To: <530B966E.2030900@gmail.com> References: <53063600.4020102@gmail.com> <530B86F6.5040201@gmail.com> <530B966E.2030900@gmail.com> Date: Tue, 25 Feb 2014 07:19:30 +0000 Message-ID: From: Ben Laurie To: Melinda Shore Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/NHe9aWitFnZgfkHblxpi3mCWSSk Cc: Eran Messeri , "trans@ietf.org" Subject: Re: [Trans] Draft agenda 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, 25 Feb 2014 07:19:33 -0000 On 24 February 2014 18:58, Melinda Shore wrote: > On 2/24/14 9:21 AM, Ben Laurie wrote: >> Precertificates already share serial numbers with certificates. The >> intent of 5280 is not violated by this practice, but perhaps needs >> amending to permit it. > > If it turns out that there's agreement with this proposal > we'll need to make sure that this is highlighted somewhere > in our documents and that it's run past pkix. By the way, CT does offer a 5280 compliant route (use a sub-CA for the precertificate) but that doesn't actually provide any useful function except ritual adherence to the RFC. From nobody Mon Feb 24 23:23:39 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D6C1A050E for ; Mon, 24 Feb 2014 23:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 Adb_9MJNalSk for ; Mon, 24 Feb 2014 23:23:35 -0800 (PST) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 99B811A0350 for ; Mon, 24 Feb 2014 23:23:35 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id pa12so3732veb.21 for ; Mon, 24 Feb 2014 23:23:34 -0800 (PST) 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=uAq8TcMZSIZOJRqO69EDfxuYsGEDRJLf1s/+hPsDczQ=; b=EZvAFkqSLUM5BjVOFc/gBr8/p4BF1CvO141ytEciWVbZL3laivuI3cZDhTqhSebyyo rNYA+ft82onrc0Tg9GnK/dXwCge8PeNodrmjXxeH3lAa7I44pyYorZKBybdmcOiR27qk SycVVn//5Leb/y8oilWC64pnoZL1IjRemkD0I2SBhLmh7Ru2kxmGB4awKmw/1Q2CmPbl yiARBLhHZ7ljx5qZAr5luhiW/YbS81q1jW+i750Opes/F34xncbMfp/cgQkxoS8UoZov TUZN0n2TPb+Fn1NB7tig6cOoXQgSlhaSKgLAzIwX8YGxN4HdmP/FaD4oQFscesKq/T9a n9nw== 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=uAq8TcMZSIZOJRqO69EDfxuYsGEDRJLf1s/+hPsDczQ=; b=EFChtsyI3kZn3Ib7x3aWdU4YvmyU5RX5xjbpWqMF6a/TJ3M0b5DF72gNFmECC8NY38 C6uLDIIzDUbESLEQvjRwpyGycNuqURobQKFLqOljhLaoqfKyo4bVYUEmAIjR0bfGd8qo n4/JV3nvLvvZUzmxiNZD2UBqNdBO2X5jPKNkkmSoejpd69fxa01R+ltByziO2HBFb/iL 10Y2oob2K3KlxoRzyBk8nnjs6vB9exUOlSsh6pK80xgofzJOx+tRBWoBuglEKWcZyJMJ MnlS5H3jHr7vooxz7oeQEPfBRTy+tMDQaT1YX9wt/E4/JyBYmt+kekBBEzHnPox9BDhl NVXQ== X-Gm-Message-State: ALoCoQl+RYE/Fnap8GfGddR+ZqFQQVqGiBcYVbAPXMnNXYJSk+/kjoyDUHrS3J7iPiJZDlG4FIaoVI3zZ/OaO3knWr6gTpb5teRjUIhy5ddHc0/cjkCECBPBn7ot9bCpg/9tH/036XZYztOInvZs7Mzpt+HrhvvCLh7+XlenfR2pzGltJNV+8ACfyPVO0kgJCCsiBt9I+rg7 MIME-Version: 1.0 X-Received: by 10.58.96.114 with SMTP id dr18mr19722veb.79.1393313014698; Mon, 24 Feb 2014 23:23:34 -0800 (PST) Received: by 10.52.230.105 with HTTP; Mon, 24 Feb 2014 23:23:34 -0800 (PST) In-Reply-To: References: <53063600.4020102@gmail.com> <530B86F6.5040201@gmail.com> Date: Tue, 25 Feb 2014 07:23:34 +0000 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/xii2jwJknBSJrI_9BNnGVEQEifM Cc: Melinda Shore , "trans@ietf.org" , Eran Messeri Subject: Re: [Trans] Draft agenda 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, 25 Feb 2014 07:23:37 -0000 On 24 February 2014 19:17, Phillip Hallam-Baker wrote: > What exactly is a 'precertificate'. Either something is a cert or it is not. > > If it parses as an X.509v3 certificate then it is an X.509v3 certificate and > thats an end to it. Indeed, and a precertificate is a certificate. RFC 6962 defines what exactly it is. Not sure where you're going with this. > If it is not then it is probably a CSR which would seem to be the existing > PKIX structure that fits its purpose. Not really - a precertificate needs to be signed. From nobody Mon Feb 24 23:28:50 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 A9E5E1A0538 for ; Mon, 24 Feb 2014 23:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.573 X-Spam-Level: X-Spam-Status: No, score=0.573 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_48=0.6, RP_MATCHES_RCVD=-0.547, 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 eIBvnyh0XqUe for ; Mon, 24 Feb 2014 23:28:47 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 83BBE1A0537 for ; Mon, 24 Feb 2014 23:28:47 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so6865347vcb.31 for ; Mon, 24 Feb 2014 23:28:46 -0800 (PST) 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=ZOS86nVk0pt+LGGVvIBFLg2cWOflmjMUYHIivWrtfOI=; b=N3ZF9jIqM+kMO8zOWHe8c6UzRJ8iiAPJ6HASKtE1gmSGuOfHQjz07zpfKYyAKQJG4l oEPvXaD6V+RQlNjywnBRDPFVZ2fcB0GAtUS9cAH+fEW6jwltTIztReuSPz1am+NouAIZ TBsNsMtADkeYYszDTc2K1A5klgnLf1hRsa+4CiXSWeCFEiugrwdMSKEVW1xcEkXD8lCR GtPnP13iFtFzYmTXNWEKpsPKBeuHylU8LWoj3u/BdsEQajK3YzNuft+WAPQgd3FiM4dH cGxyP4DNqgk89ZjwchwTGqycMBuM/ACtmEYFrhXxsrL2kFwvhfFWg7Fmwc9hKaS65XP/ wDZw== 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=ZOS86nVk0pt+LGGVvIBFLg2cWOflmjMUYHIivWrtfOI=; b=J6Vx3hPeOTw5NHaj7rln/cCtBZJnSVMz6c+3Y99Cjtn05dkPd/7qay0y9vVdWNkfgw XuINWNXVJvj+eXC3qI/V0jNcYSpai9Fh93B68PzMZHqbllaIdm37YV2wHQgFHb5pnJ58 smF71fOu0SVqmpUl6Ks1Ga2aot+ZbVhl7EN4RMVV+rbrR9M+2KJK4XKsNTstm34IHIwV f+McEb+HtMQq680Zl+UJKmXtxO3ekvNyAFL07GOKfmPrkOkd/trKx8B5eDRu868vRXHA 9UC67wzw7eJpm1/o4w9J/A8aaU3FvezvjG/hfCcvySYVDPv2XNp3ReH3RiPrK/b/5Cub gfPw== X-Gm-Message-State: ALoCoQmRA/XCbHiYXP2eA1I5KsdmxlX8qjAJR+X+ZTJFwSEN/Pz5j0uKXHVnBmz2d6E+quqQ7hymhwyG1ztzpoIqSoLkB5iVFFY/F7v4vdIHNRCmMRDmd6f/xnRFarmesm25/WhPLqX1UIT42aUXd2cruE6gbz2SXQmIpvaLFVqeGuD3iJZelYKycjNYNM6Ecw8n7XebahMe MIME-Version: 1.0 X-Received: by 10.52.22.105 with SMTP id c9mr2721vdf.57.1393313326565; Mon, 24 Feb 2014 23:28:46 -0800 (PST) Received: by 10.52.230.105 with HTTP; Mon, 24 Feb 2014 23:28:46 -0800 (PST) In-Reply-To: <530BBCE6.1070100@fifthhorseman.net> References: <53063600.4020102@gmail.com> <878ut0usxw.fsf@alice.fifthhorseman.net> <530BB8E3.30303@gmail.com> <530BBCE6.1070100@fifthhorseman.net> Date: Tue, 25 Feb 2014 07:28:46 +0000 Message-ID: From: Ben Laurie To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/5XiRu9L3_Uq_P7e4xAjFGLz7akQ Cc: "trans@ietf.org" Subject: Re: [Trans] Draft agenda 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, 25 Feb 2014 07:28:48 -0000 On 24 February 2014 21:43, Daniel Kahn Gillmor wrote: > On 02/24/2014 04:25 PM, Melinda Shore wrote: > >> As for relevance, right now therightkey is the best place >> for discussion of other approaches to fixing PKI, while trans >> is specifically for discussion of certificate transparency. >> The only thing that's in our charter at the moment is 6962bis. >> That doesn't mean that other applications of CT are out-of- >> scope, but that we'd need to recharter to take them on >> as work items. > > I think you're saying you want the slot in London to focus on getting > the mechanism right, and not trying to propose policy, which is > completely reasonable. I'm happy to stay focused. > > There's nothing in RFC 6962 (and i hope there won't be in 6962bis) that > is HTTPS-specific, though; it's defined as a mechanism for logging X.509 > certificates for use in TLS, regardless of the application layer traffic > within the TLS session. > > So i hope that the use of CT in SMTP+STARTTLS isn't seen as an "other > application" -- it's still TLS. If we suspect that CT is somehow valid > only for X.509 certs used by HTTPS servers, we should make that more > explicit in the draft (but i hope we don't!) I agree. One observation: CT as applied to HTTPS uses the CA signature as a spam limitation mechanism. I believe most SMTP certs are not CA issued, so the question arises: how would you propose to limit spam? I am open, by the way, to running CT logs at Google with alternate spam limitation mechanisms to allow this kind of usage. I think that not having a spam limitation mechanism is dangerous. From nobody Tue Feb 25 02:09:26 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB5D1A042A for ; Tue, 25 Feb 2014 02:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 f3Pwl5rY-nE8 for ; Tue, 25 Feb 2014 02:09:20 -0800 (PST) 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 0FDB91A0427 for ; Tue, 25 Feb 2014 02:09:19 -0800 (PST) Received: (qmail 1013 invoked by uid 1000); 25 Feb 2014 10:09:17 -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, 25 Feb 2014 10:09:17 +0000 Message-ID: <530C6BCD.7030801@comodo.com> Date: Tue, 25 Feb 2014 10:09:17 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ben Laurie , Phillip Hallam-Baker References: <53063600.4020102@gmail.com> <530B86F6.5040201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/FT4mD2AW_vnSkAeAX82qHveQ21A Cc: Melinda Shore , "trans@ietf.org" , Eran Messeri Subject: Re: [Trans] Draft agenda 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, 25 Feb 2014 10:09:23 -0000 On 25/02/14 07:23, Ben Laurie wrote: > On 24 February 2014 19:17, Phillip Hallam-Baker wrote: >> What exactly is a 'precertificate'. Either something is a cert or it is not. >> >> If it parses as an X.509v3 certificate then it is an X.509v3 certificate and >> thats an end to it. > > Indeed, and a precertificate is a certificate. RFC 6962 defines what > exactly it is. > > Not sure where you're going with this. > >> If it is not then it is probably a CSR which would seem to be the existing >> PKIX structure that fits its purpose. > > Not really - a precertificate needs to be signed. CSRs are signed. Self-signed, usually. I think Phill is suggesting that a Precertificate could be a CSR, generated and signed by the CA (rather than self-signed by the certificate applicant). The problem I see with this is that the CSR format doesn't contain some of the essential fields that MUST be present in a Precertificate: Serial Number, Issuer Name, etc. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Tue Feb 25 04:36: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 492461A06CC for ; Tue, 25 Feb 2014 04:36:27 -0800 (PST) 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 LQu9WyZdBmgH for ; Tue, 25 Feb 2014 04:36:25 -0800 (PST) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8DA1A03F0 for ; Tue, 25 Feb 2014 04:36:25 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id hr17so1198453lab.18 for ; Tue, 25 Feb 2014 04:36:24 -0800 (PST) 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=Du4qWlShtMwPRIK6LJoK113irVgrY4IWHMLx6kgSLUo=; b=xsy/lbg8DYL6CTqAR33N+IXMvwik1ZsBLxp2CY0Bw2P6K3RwuyzDCJnv0IQzc1050b 30j+S1RdpRzJNXu9bQXgJ9j+OCfKZlteNHULi9XoN3ZAhY1qSKP1PNLfK7VlTZjPK9yg mQVgDiqTbMR2ktye7TNzwSi7t+zKOxemDKA0I4AiCdc8wNgcsR2YENsRKsOkkntHz9rw zSXt4XUlfsdEk5kdf4XJCMHpWiJl5kM/2cyo0NBMb+nBkTQ3encZV46xTKja9Rep5COP VX+bbq5vr+htRFL1iRQnw2BPKoVNCSLibZYcUCKii+YlbWVWopcfCwj3s/JH4nVsAXsA BvlQ== MIME-Version: 1.0 X-Received: by 10.152.44.225 with SMTP id h1mr141775lam.71.1393331783946; Tue, 25 Feb 2014 04:36:23 -0800 (PST) Received: by 10.112.37.168 with HTTP; Tue, 25 Feb 2014 04:36:23 -0800 (PST) In-Reply-To: References: <53063600.4020102@gmail.com> <530B86F6.5040201@gmail.com> Date: Tue, 25 Feb 2014 07:36:23 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=089e0160b7be09560004f33a560c Archived-At: http://mailarchive.ietf.org/arch/msg/trans/LCfNzCS44NU86qekhX11C2jSvBM Cc: Melinda Shore , "trans@ietf.org" , Eran Messeri Subject: Re: [Trans] Draft agenda 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, 25 Feb 2014 12:36:27 -0000 --089e0160b7be09560004f33a560c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 25, 2014 at 2:23 AM, Ben Laurie wrote: > On 24 February 2014 19:17, Phillip Hallam-Baker wrote: > > What exactly is a 'precertificate'. Either something is a cert or it is > not. > > > > If it parses as an X.509v3 certificate then it is an X.509v3 certificate > and > > thats an end to it. > > Indeed, and a precertificate is a certificate. RFC 6962 defines what > exactly it is. > > Not sure where you're going with this. Ritual compliance with the existing PKIX spec. Having two end entity certs with the same serial number is going to be a problem. > > If it is not then it is probably a CSR which would seem to be the > existing > > PKIX structure that fits its purpose. > > Not really - a precertificate needs to be signed. > CSRs are signed. -- Website: http://hallambaker.com/ --089e0160b7be09560004f33a560c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 25, 2014 at 2:23 AM, Ben Laurie <<= a href=3D"mailto:benl@google.com" target=3D"_blank">benl@google.com>= wrote:

On 24 February 2014 19:17, P= hillip Hallam-Baker <hallam@gmail.co= m> wrote:
> What exactly is a 'precertificate'. Either something is a cert= or it is not.
>
> If it parses as an X.509v3 certificate then it is an X.509v3 certifica= te and
> thats an end to it.

Indeed, and a precertificate is a certificate. RFC 6962 defines what<= br> exactly it is.

Not sure where you're going with this.

= Ritual compliance with the existing PKIX spec.

Hav= ing two end entity certs with the same serial number is going to be a probl= em.

=A0

> If it is not then it is probably a CSR which would seem to be the exis= ting
> PKIX structure that fits its purpose.

Not really - a precertificate needs to be signed.

CSRs are signed.

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

--089e0160b7be09560004f33a560c-- From nobody Tue Feb 25 09:02:06 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B0B1A016C for ; Tue, 25 Feb 2014 09:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.152 X-Spam-Level: * X-Spam-Status: No, score=1.152 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_48=0.6] 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 FYNOTBE6SeAu for ; Tue, 25 Feb 2014 09:02:02 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C71C31A00EA for ; Tue, 25 Feb 2014 09:02:02 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1PH1uQd083767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 10:01:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Tue, 25 Feb 2014 09:01:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53063600.4020102@gmail.com> <878ut0usxw.fsf@alice.fifthhorseman.net> <530BB8E3.30303@gmail.com> <530BBCE6.1070100@fifthhorseman.net> To: Ben Laurie X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/ISeKvWU0PWy33Z2-hdB0XXJAxKI Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: [Trans] CT for opportunistic STARTTLS in SMTP 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, 25 Feb 2014 17:02:04 -0000 Sorry for using a valid subject line. :-) On Feb 24, 2014, at 11:28 PM, Ben Laurie wrote: > On 24 February 2014 21:43, Daniel Kahn Gillmor = wrote: >> On 02/24/2014 04:25 PM, Melinda Shore wrote: >>=20 >>> As for relevance, right now therightkey is the best place >>> for discussion of other approaches to fixing PKI, while trans >>> is specifically for discussion of certificate transparency. >>> The only thing that's in our charter at the moment is 6962bis. >>> That doesn't mean that other applications of CT are out-of- >>> scope, but that we'd need to recharter to take them on >>> as work items. >>=20 >> I think you're saying you want the slot in London to focus on getting >> the mechanism right, and not trying to propose policy, which is >> completely reasonable. I'm happy to stay focused. >>=20 >> There's nothing in RFC 6962 (and i hope there won't be in 6962bis) = that >> is HTTPS-specific, though; it's defined as a mechanism for logging = X.509 >> certificates for use in TLS, regardless of the application layer = traffic >> within the TLS session. >>=20 >> So i hope that the use of CT in SMTP+STARTTLS isn't seen as an "other >> application" -- it's still TLS. If we suspect that CT is somehow = valid >> only for X.509 certs used by HTTPS servers, we should make that more >> explicit in the draft (but i hope we don't!) >=20 > I agree. One observation: CT as applied to HTTPS uses the CA signature > as a spam limitation mechanism. >=20 > I believe most SMTP certs are not CA issued, so the question arises: > how would you propose to limit spam? At the earlier CT meeting, I think someone proposed that there could be = a check that the cert was in actual use at the place it said it was. > I am open, by the way, to running CT logs at Google with alternate > spam limitation mechanisms to allow this kind of usage. I think that > not having a spam limitation mechanism is dangerous. Spam limitation is needed for both attacks on CT to weaken it and = accidental misconfiguration that could look a lot like an attack. --Paul Hoffman= From nobody Tue Feb 25 09:36: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 586F11A0105 for ; Tue, 25 Feb 2014 09:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.573 X-Spam-Level: X-Spam-Status: No, score=0.573 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_48=0.6, RP_MATCHES_RCVD=-0.547, 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 ErDt88YJGBH7 for ; Tue, 25 Feb 2014 09:36:18 -0800 (PST) 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 180B91A000F for ; Tue, 25 Feb 2014 09:36:18 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id db12so804057veb.36 for ; Tue, 25 Feb 2014 09:36:17 -0800 (PST) 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=HHoFFha0tu587ttob+l8yaI1N2aZag5KMUlsxNQa+MY=; b=O9H4aoCotgpzq8MPMC+bnWr8MP49EB4Up2NFPQ0KgepBYa+5XdJpqmKyfB7w6nBct1 WkcFpD2v1EYzSlhmlxz509Bu2/evKTTXG6rqT71coR2fXOoAAHYqvyiTwNmbwsyHHH5C laMexTy2tp8DHDtw9C/89CZStbRFauYnvUszoqCgp+BEIu3/741Z496lqfnjd5eHzsoG rSOBokC95NcXFB2M8V7p3LpAWlrYKgr+pegfrfPfeyIL/vwug1d/xw3iXx0IOx+ANmJM +wBIg1AzXIfsNFA/grS+KkdAuNpZUvtZbzXIOAgQVt5SO70PksiQnIDbaFn6LPnnSJfS GXJA== 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=HHoFFha0tu587ttob+l8yaI1N2aZag5KMUlsxNQa+MY=; b=UURcdK59py45qltufUkrdeiXgicbW72AIY3oEKEjkWl7Tigpo1TmVIpr+vsusuIiET t2cUWDpRB3UlK64+pAiROAdRObHZ8adRJGP4Bb/ST7/Gnxzv/ofDX6i4Ymh81OMaa5Cq 1NVBZyvNq0YULwMVdBZOpUROVcRWwJne/63d9gbUR7NnH78fzD4cAi80HL7qucYthHLh 8gp9ljzNx6AwOG5XNvXdnI2e4n971e4J31yxwS+npFhfN9tl4h/5pxTCdgGaNPxbmUdN BLn2Cn5NQlLtmhd/oZLK8hthAkKKmGeKeZDBJ0oFgCkkpG7n74uaNXwtxxedEAlIZNr+ dChQ== X-Gm-Message-State: ALoCoQm5lcU7IcmAjyKGV2S4y/dwZx2C6IcdNsOGOCJ44aOOKMbQqM6yKGvr4keBknJ6085moByBe8OaGk0RL8hYT5o34ZYwJjzrobZOec16dsohMyjPUHolEechvqKlNBsuSpvW//XaXH5EVVBchgVWPwYTlw9cTKPM2Mzd6Ih5GvXUlStIm1NMiW4QX8tQZszfFN31hTvX MIME-Version: 1.0 X-Received: by 10.52.171.68 with SMTP id as4mr1645992vdc.0.1393349777005; Tue, 25 Feb 2014 09:36:17 -0800 (PST) Received: by 10.52.230.105 with HTTP; Tue, 25 Feb 2014 09:36:16 -0800 (PST) In-Reply-To: References: <53063600.4020102@gmail.com> <878ut0usxw.fsf@alice.fifthhorseman.net> <530BB8E3.30303@gmail.com> <530BBCE6.1070100@fifthhorseman.net>

Date: Tue, 25 Feb 2014 17:36:16 +0000 Message-ID: From: Ben Laurie To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/E57_iBEasTx6w_qO_3pPQobw16w Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP 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, 25 Feb 2014 17:36:19 -0000 On 25 February 2014 17:01, Paul Hoffman wrote: > Sorry for using a valid subject line. :-) > > On Feb 24, 2014, at 11:28 PM, Ben Laurie wrote: > >> On 24 February 2014 21:43, Daniel Kahn Gillmor wrote: >>> On 02/24/2014 04:25 PM, Melinda Shore wrote: >>> >>>> As for relevance, right now therightkey is the best place >>>> for discussion of other approaches to fixing PKI, while trans >>>> is specifically for discussion of certificate transparency. >>>> The only thing that's in our charter at the moment is 6962bis. >>>> That doesn't mean that other applications of CT are out-of- >>>> scope, but that we'd need to recharter to take them on >>>> as work items. >>> >>> I think you're saying you want the slot in London to focus on getting >>> the mechanism right, and not trying to propose policy, which is >>> completely reasonable. I'm happy to stay focused. >>> >>> There's nothing in RFC 6962 (and i hope there won't be in 6962bis) that >>> is HTTPS-specific, though; it's defined as a mechanism for logging X.509 >>> certificates for use in TLS, regardless of the application layer traffic >>> within the TLS session. >>> >>> So i hope that the use of CT in SMTP+STARTTLS isn't seen as an "other >>> application" -- it's still TLS. If we suspect that CT is somehow valid >>> only for X.509 certs used by HTTPS servers, we should make that more >>> explicit in the draft (but i hope we don't!) >> >> I agree. One observation: CT as applied to HTTPS uses the CA signature >> as a spam limitation mechanism. >> >> I believe most SMTP certs are not CA issued, so the question arises: >> how would you propose to limit spam? > > At the earlier CT meeting, I think someone proposed that there could be a check that the cert was in actual use at the place it said it was. That does not seem effective to me. >> I am open, by the way, to running CT logs at Google with alternate >> spam limitation mechanisms to allow this kind of usage. I think that >> not having a spam limitation mechanism is dangerous. > > Spam limitation is needed for both attacks on CT to weaken it and accidental misconfiguration that could look a lot like an attack. > > --Paul Hoffman From nobody Tue Feb 25 09:53:46 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49441A015E for ; Tue, 25 Feb 2014 09:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 dJ39o9u0m5z4 for ; Tue, 25 Feb 2014 09:53:41 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFED1A0158 for ; Tue, 25 Feb 2014 09:53:41 -0800 (PST) Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1PHrZgV093853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Feb 2014 10:53:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Paul Hoffman In-Reply-To: Date: Tue, 25 Feb 2014 09:53:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <200B1469-C0AB-4560-B799-F09D4C7221EA@vpnc.org> References: <53063600.4020102@gmail.com> <878ut0usxw.fsf@alice.fifthhorseman.net> <530BB8E3.30303@gmail.com> <530BBCE6.1070100@fifthhorseman.net>

To: Ben Laurie X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/trans/7nCbpp4QO0glUH2oiDaOHctcykQ Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP 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, 25 Feb 2014 17:53:42 -0000 On Feb 25, 2014, at 9:36 AM, Ben Laurie wrote: >> At the earlier CT meeting, I think someone proposed that there could = be a check that the cert was in actual use at the place it said it was. >=20 > That does not seem effective to me. It is more effective than doing nothing; it may not be effective enough = to prevent overwhelm by spam. I was just pointing it out as something = that was proposed, not well-thought-out. --Paul Hoffman= From nobody Tue Feb 25 12:20:36 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84041A0254 for ; Tue, 25 Feb 2014 12:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT4B1HD-bnfC for ; Tue, 25 Feb 2014 12:20:26 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.87]) by ietfa.amsl.com (Postfix) with ESMTP id 006A91A0275 for ; Tue, 25 Feb 2014 12:20:25 -0800 (PST) Received: from BL2SR01CA104.namsdf01.sdf.exchangelabs.com (10.255.109.149) by BL2SR01MB592.namsdf01.sdf.exchangelabs.com (10.255.109.163) with Microsoft SMTP Server (TLS) id 15.0.898.5; Tue, 25 Feb 2014 19:47:39 +0000 Received: from BY1FFOFD004.ffo.gbl (2a01:111:f400:7c00::87) by BL2SR01CA104.outlook.office365.com (2a01:111:e400:c01::21) with Microsoft SMTP Server (TLS) id 15.0.898.5 via Frontend Transport; Tue, 25 Feb 2014 19:47:38 +0000 Received: from hybrid.exchange.microsoft.com (131.107.159.99) by BY1FFOFD004.mail.o365filtering.com (10.1.16.61) with Microsoft SMTP Server (TLS) id 15.0.898.4 via Frontend Transport; Tue, 25 Feb 2014 19:47:38 +0000 Received: from DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) by DFM-TK5EDG15-01.exchange.corp.microsoft.com (157.54.27.96) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 25 Feb 2014 11:47:33 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com (157.54.109.44) by DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 25 Feb 2014 11:47:32 -0800 Received: from DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.15]) by DFM-TK5MBX15-05.exchange.corp.microsoft.com ([169.254.5.15]) with mapi id 15.00.0847.027; Tue, 25 Feb 2014 11:47:32 -0800 From: Trevor Freeman To: Paul Hoffman , Ben Laurie Thread-Topic: [Trans] CT for opportunistic STARTTLS in SMTP Thread-Index: AQHPMktUK1TcKUm7rUKelX8JKB3CNJrGwbEAgAAE1oD//5WxkA== Date: Tue, 25 Feb 2014 19:47:31 +0000 Message-ID: <2c3b987f362f479fa0d437513b65efa5@DFM-TK5MBX15-05.exchange.corp.microsoft.com> References: <53063600.4020102@gmail.com> <878ut0usxw.fsf@alice.fifthhorseman.net> <530BB8E3.30303@gmail.com> <530BBCE6.1070100@fifthhorseman.net>

<200B1469-C0AB-4560-B799-F09D4C7221EA@vpnc.org> In-Reply-To: <200B1469-C0AB-4560-B799-F09D4C7221EA@vpnc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.59.235.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.159.99; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(13464003)(51704005)(24454002)(377454003)(199002)(189002)(83072002)(81342001)(81686001)(79102001)(19580405001)(19580395003)(33646001)(93516002)(85852003)(90146001)(77096001)(77982001)(59766001)(15975445006)(50466002)(44976005)(81816001)(74706001)(56816005)(92566001)(76786001)(76796001)(74876001)(6806004)(54316002)(56776001)(81542001)(76482001)(80976001)(74502001)(47446002)(74662001)(53806001)(94946001)(93886001)(84676001)(54356001)(31966008)(94316002)(2656002)(87936001)(20776003)(63696002)(47776003)(80022001)(87266001)(65816001)(50986001)(93136001)(83322001)(46102001)(85306002)(49866001)(47736001)(74366001)(95666003)(23726002)(69226001)(95416001)(51856001)(46406003)(4396001)(66066001)(47976001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB592; H:hybrid.exchange.microsoft.com; FPR:3CF4CDBE.BF264FCA.BD6DB347.4AECDAFD.2025B; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Forefront-PRVS: 01334458E5 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/_PB2x36CIerkKYuZsTZlVyjGwBQ Cc: "trans@ietf.org" , Daniel Kahn Gillmor Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP 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, 25 Feb 2014 20:20:29 -0000 I don't see the relevance of CT to opportunistic STARTTLS. Opportunistic STARTTLS is a feature of the sender whereby the sender picks = STARTTLS if offered, but otherwise will send the email. If the alternative= was send unprotected over plain TCP, you may as well negotiate TLS if offe= red. Moreover, if TLS negotiation fails for whatever reason, the send reme= mbers the fact and done not attempt to negotiate next time.=20 The sender does have a list of SMTP domains where it requires TLS authentic= ation, but that is mandatory STARTTLS.=20 -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, February 25, 2014 9:54 AM To: Ben Laurie Cc: trans@ietf.org; Daniel Kahn Gillmor Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP On Feb 25, 2014, at 9:36 AM, Ben Laurie wrote: >> At the earlier CT meeting, I think someone proposed that there could be = a check that the cert was in actual use at the place it said it was. >=20 > That does not seem effective to me. It is more effective than doing nothing; it may not be effective enough to = prevent overwhelm by spam. I was just pointing it out as something that was= proposed, not well-thought-out. --Paul Hoffman _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans From nobody Tue Feb 25 13:48:28 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 8A6321A02CA for ; Tue, 25 Feb 2014 13:48:22 -0800 (PST) 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 eJamTC4HLFyL for ; Tue, 25 Feb 2014 13:48:17 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 01F991A02A0 for ; Tue, 25 Feb 2014 13:48:16 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id pv20so11959lab.30 for ; Tue, 25 Feb 2014 13:48:15 -0800 (PST) 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=TqvrMmJByGK1xNpiKGzvuhJz/5+xPi24l8t4ee6ccTM=; b=csnPrcyxIOLF5yXgf4B2DJ+CIvWfyu4q/ViFIvOmaVqA8DYz2GixOaBrM9pH57xlIm 55GWC0BLEeOrgG9bIb0/3JFnwEcRifj6lm3N4s7cofk3JGaJiK6hT2BrK2BZf8YrKDZw 2Zi/eI2CHSOCfSVeIb/W7jDjgzZpp0My/VbeOKhZq8cNbx2re+EkMBYX4i2ylRoV2Hf5 5aXUbzPdQwQJs9T+I7MITNDHqJ3nfYMYsrXBC4P8+d4druPzbN4Eq1LclkPLuVoU7jes gdOaTzLBGA1bZuzlo5DJHS1CmdiusVMZdNmmUCZsJxS73z5JXVdEhjIn5JDkf7nqbJWq CcwQ== MIME-Version: 1.0 X-Received: by 10.112.171.136 with SMTP id au8mr1138935lbc.0.1393364895384; Tue, 25 Feb 2014 13:48:15 -0800 (PST) Received: by 10.112.37.168 with HTTP; Tue, 25 Feb 2014 13:48:15 -0800 (PST) In-Reply-To: <2c3b987f362f479fa0d437513b65efa5@DFM-TK5MBX15-05.exchange.corp.microsoft.com> References: <53063600.4020102@gmail.com> <878ut0usxw.fsf@alice.fifthhorseman.net> <530BB8E3.30303@gmail.com> <530BBCE6.1070100@fifthhorseman.net>

<200B1469-C0AB-4560-B799-F09D4C7221EA@vpnc.org> <2c3b987f362f479fa0d437513b65efa5@DFM-TK5MBX15-05.exchange.corp.microsoft.com> Date: Tue, 25 Feb 2014 16:48:15 -0500 Message-ID: From: Phillip Hallam-Baker To: Trevor Freeman Content-Type: multipart/alternative; boundary=001a11c377a4a1c9fd04f3420b84 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/QdgFr4exE7fke4ogfP3hccbQAps Cc: "trans@ietf.org" , Ben Laurie , Paul Hoffman , Daniel Kahn Gillmor Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP 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, 25 Feb 2014 21:48:22 -0000 --001a11c377a4a1c9fd04f3420b84 Content-Type: text/plain; charset=ISO-8859-1 The idea seems to be that there is an append only log server that clients are gong to be checking. So we can use that to stuff security policy information into the system. The problem is that the client only checks the CT logs in the normal case after it has decided to use TLS. So there is certainly a value in using an append only log to publish security policy data and in fact I do this in PPE. But it is only a solution to the downgrade attack problem with a lot of extra infrastructure. For example an Omnibroker scanning the CT log and using that to build the connection profile. On Tue, Feb 25, 2014 at 2:47 PM, Trevor Freeman < trevorf@exchange.microsoft.com> wrote: > I don't see the relevance of CT to opportunistic STARTTLS. > > Opportunistic STARTTLS is a feature of the sender whereby the sender picks > STARTTLS if offered, but otherwise will send the email. If the alternative > was send unprotected over plain TCP, you may as well negotiate TLS if > offered. Moreover, if TLS negotiation fails for whatever reason, the send > remembers the fact and done not attempt to negotiate next time. > > The sender does have a list of SMTP domains where it requires TLS > authentication, but that is mandatory STARTTLS. > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Tuesday, February 25, 2014 9:54 AM > To: Ben Laurie > Cc: trans@ietf.org; Daniel Kahn Gillmor > Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP > > On Feb 25, 2014, at 9:36 AM, Ben Laurie wrote: > > >> At the earlier CT meeting, I think someone proposed that there could be > a check that the cert was in actual use at the place it said it was. > > > > That does not seem effective to me. > > It is more effective than doing nothing; it may not be effective enough to > prevent overwhelm by spam. I was just pointing it out as something that was > proposed, not well-thought-out. > > --Paul Hoffman > _______________________________________________ > 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 > -- Website: http://hallambaker.com/ --001a11c377a4a1c9fd04f3420b84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

The idea seems to be that there is an append only log serv= er that clients are gong to be checking. So we can use that to stuff securi= ty policy information into the system.

The problem is th= at the client only checks the CT logs in the normal case after it has decid= ed to use TLS.

So there is certainly a value in using an append only l= og to publish security policy data and in fact I do this in PPE. But it is = only a solution to the downgrade attack problem with a lot of extra infrast= ructure. For example an Omnibroker scanning the CT log and using that to bu= ild the connection profile.

On Tue, Feb 25, 2014 at 2:47 PM, Trev= or Freeman <trevorf@exchange.microsoft.com> wro= te:

I don't see the relevance of CT to oppor= tunistic STARTTLS.

Opportunistic STARTTLS is a feature of the sender whereby the sender picks = STARTTLS if offered, but otherwise will send the email. =A0If the alternati= ve was send unprotected over plain TCP, you may as well negotiate TLS if of= fered. =A0Moreover, if TLS negotiation fails for whatever reason, the send = remembers the fact and done not attempt to negotiate next time.

The sender does have a list of SMTP domains where it requires TLS authentic= ation, but that is mandatory =A0STARTTLS.

-----Original Message-----
From: Trans [mailto:trans-bounces= @ietf.org] On Behalf Of Paul Hoffman
Sent: Tuesday, February 25, 2014 9:54 AM
To: Ben Laurie
Cc: trans@ietf.org; Daniel Kahn Gillm= or
Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP

On Feb 25, 2014, at 9:36 AM, Ben Laurie <benl@google.com> wrote:

>> At the earlier CT meeting, I think someone proposed that there cou= ld be a check that the cert was in actual use at the place it said it was.<= br> >
> That does not seem effective to me.

It is more effective than doing nothing; it may not be effective enough to = prevent overwhelm by spam. I was just pointing it out as something that was= proposed, not well-thought-out.

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

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

--001a11c377a4a1c9fd04f3420b84-- From nobody Tue Feb 25 14:13: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 04DF91A0257 for ; Tue, 25 Feb 2014 14:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3Tz2YwAuTw2 for ; Tue, 25 Feb 2014 14:13:27 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.89]) by ietfa.amsl.com (Postfix) with ESMTP id CDA9C1A0298 for ; Tue, 25 Feb 2014 14:13:26 -0800 (PST) Received: from BL2SR01CA102.namsdf01.sdf.exchangelabs.com (10.255.109.147) by BL2SR01MB592.namsdf01.sdf.exchangelabs.com (10.255.109.163) with Microsoft SMTP Server (TLS) id 15.0.898.5; Tue, 25 Feb 2014 22:13:24 +0000 Received: from BY1FFOFD002.ffo.gbl (2a01:111:f400:7c00::90) by BL2SR01CA102.outlook.office365.com (2a01:111:e400:c01::19) with Microsoft SMTP Server (TLS) id 15.0.898.5 via Frontend Transport; Tue, 25 Feb 2014 22:13:24 +0000 Received: from hybrid.exchange.microsoft.com (131.107.147.100) by BY1FFOFD002.mail.o365filtering.com (10.1.16.84) with Microsoft SMTP Server (TLS) id 15.0.898.4 via Frontend Transport; Tue, 25 Feb 2014 22:13:23 +0000 Received: from DFM-TK5MBX15-08.exchange.corp.microsoft.com (157.54.109.47) by DFM-TK5EDG15-02.exchange.corp.microsoft.com (157.54.27.97) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 25 Feb 2014 14:13:13 -0800 Received: from DFM-TK5MBX15-07.exchange.corp.microsoft.com (157.54.109.46) by DFM-TK5MBX15-08.exchange.corp.microsoft.com (157.54.109.47) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 25 Feb 2014 14:13:13 -0800 Received: from DFM-TK5MBX15-07.exchange.corp.microsoft.com ([157.54.109.46]) by DFM-TK5MBX15-07.exchange.corp.microsoft.com ([169.254.7.103]) with mapi id 15.00.0847.030; Tue, 25 Feb 2014 14:13:13 -0800 From: Trevor Freeman To: Phillip Hallam-Baker Thread-Topic: [Trans] CT for opportunistic STARTTLS in SMTP Thread-Index: AQHPMktUK1TcKUm7rUKelX8JKB3CNJrGwbEAgAAE1oD//5WxkIAAq+CA//99JXA= Date: Tue, 25 Feb 2014 22:13:12 +0000 Message-ID: <4289ed5e74314d56ad59be2e92d0ccb3@DFM-TK5MBX15-07.exchange.corp.microsoft.com> References: <53063600.4020102@gmail.com> <878ut0usxw.fsf@alice.fifthhorseman.net> <530BB8E3.30303@gmail.com> <530BBCE6.1070100@fifthhorseman.net>

<200B1469-C0AB-4560-B799-F09D4C7221EA@vpnc.org> <2c3b987f362f479fa0d437513b65efa5@DFM-TK5MBX15-05.exchange.corp.microsoft.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.59.235.233] Content-Type: multipart/alternative; boundary="_000_4289ed5e74314d56ad59be2e92d0ccb3DFMTK5MBX1507exchangeco_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.147.100; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(13464003)(51704005)(24454002)(377454003)(15404003)(199002)(189002)(512954002)(19580395003)(19580405001)(83072002)(79102001)(81342001)(81686001)(33646001)(93516002)(85852003)(15395725004)(90146001)(77096001)(15975445006)(77982001)(44976005)(81816001)(74706001)(56816005)(92566001)(76786001)(76796001)(74876001)(6806004)(54316002)(56776001)(15202345003)(81542001)(76482001)(59766001)(80976001)(74502001)(47446002)(74662001)(19300405004)(53806001)(54356001)(94946001)(93886001)(84676001)(31966008)(94316002)(2656002)(87936001)(20776003)(63696002)(71186001)(80022001)(87266001)(65816001)(84326002)(50986001)(93136001)(83322001)(49866001)(85306002)(47736001)(46102001)(16236675003)(95666003)(69226001)(1411001)(95416001)(47976001)(51856001)(66066001)(4396001)(74366001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB592; H:hybrid.exchange.microsoft.com; FPR:BCFCF1BC.AFE64CCA.6DEDB347.4AECF871.203D2; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Forefront-PRVS: 01334458E5 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/trans/XyyfwPIAzz0c2qgFeN_9enmWocI Cc: "trans@ietf.org" , Ben Laurie , Paul Hoffman , Daniel Kahn Gillmor Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP 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, 25 Feb 2014 22:13:34 -0000 --_000_4289ed5e74314d56ad59be2e92d0ccb3DFMTK5MBX1507exchangeco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The point with opportunistic TLS is its OPPORTUNISTIC, if there is any fail= ure it will fall back to send without TLS. In opportunistic TLS the sender = does no checks whatsoever on the certificate so why would it care about CT? Besides the whole STARTTLS negation is already subject to downgrade attacks= . Some firewalls actively block the STARTTLS negotiation. From: Phillip Hallam-Baker [mailto:hallam@gmail.com] Sent: Tuesday, February 25, 2014 1:48 PM To: Trevor Freeman Cc: Paul Hoffman; Ben Laurie; trans@ietf.org; Daniel Kahn Gillmor Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP The idea seems to be that there is an append only log server that clients a= re gong to be checking. So we can use that to stuff security policy informa= tion into the system. The problem is that the client only checks the CT logs in the normal case a= fter it has decided to use TLS. So there is certainly a value in using an append only log to publish securi= ty policy data and in fact I do this in PPE. But it is only a solution to t= he downgrade attack problem with a lot of extra infrastructure. For example= an Omnibroker scanning the CT log and using that to build the connection p= rofile. On Tue, Feb 25, 2014 at 2:47 PM, Trevor Freeman > wrote: I don't see the relevance of CT to opportunistic STARTTLS. Opportunistic STARTTLS is a feature of the sender whereby the sender picks = STARTTLS if offered, but otherwise will send the email. If the alternative= was send unprotected over plain TCP, you may as well negotiate TLS if offe= red. Moreover, if TLS negotiation fails for whatever reason, the send reme= mbers the fact and done not attempt to negotiate next time. The sender does have a list of SMTP domains where it requires TLS authentic= ation, but that is mandatory STARTTLS. -----Original Message----- From: Trans [mailto:trans-bounces@ietf.org] = On Behalf Of Paul Hoffman Sent: Tuesday, February 25, 2014 9:54 AM To: Ben Laurie Cc: trans@ietf.org; Daniel Kahn Gillmor Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP On Feb 25, 2014, at 9:36 AM, Ben Laurie > wrote: >> At the earlier CT meeting, I think someone proposed that there could be = a check that the cert was in actual use at the place it said it was. > > That does not seem effective to me. It is more effective than doing nothing; it may not be effective enough to = prevent overwhelm by spam. I was just pointing it out as something that was= proposed, not well-thought-out. --Paul Hoffman _______________________________________________ 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 -- Website: http://hallambaker.com/ --_000_4289ed5e74314d56ad59be2e92d0ccb3DFMTK5MBX1507exchangeco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The point with opportunis= tic TLS is its OPPORTUNISTIC, if there is any failure it will fall back to = send without TLS. In opportunistic TLS the sender does no checks whatsoever on the certificate so why would it care about CT?

<= /p>

Besides the whole STARTTL= S negation is already subject to downgrade attacks. Some firewalls actively= block the STARTTLS negotiation.

<= /p>

From: Philli= p Hallam-Baker [mailto:hallam@gmail.com]
Sent: Tuesday, February 25, 2014 1:48 PM
To: Trevor Freeman
Cc: Paul Hoffman; Ben Laurie; trans@ietf.org; Daniel Kahn Gillmor Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP

The idea seems to be that there is an append only lo= g server that clients are gong to be checking. So we can use that to stuff = security policy information into the system.

The problem is that the client only checks the CT lo= gs in the normal case after it has decided to use TLS.

So there is certainly a value in using an append onl= y log to publish security policy data and in fact I do this in PPE. But it = is only a solution to the downgrade attack problem with a lot of extra infr= astructure. For example an Omnibroker scanning the CT log and using that to build the connection profile.

On Tue, Feb 25, 2014 at 2:47 PM, Trevor Freeman <= trevorf= @exchange.microsoft.com> wrote:

I don't see the relevance of CT to opportunistic STA= RTTLS.

Opportunistic STARTTLS is a feature of the sender whereby the sender picks = STARTTLS if offered, but otherwise will send the email. If the altern= ative was send unprotected over plain TCP, you may as well negotiate TLS if= offered. Moreover, if TLS negotiation fails for whatever reason, the send remembers the fact and done not attemp= t to negotiate next time.

The sender does have a list of SMTP domains where it requires TLS authentic= ation, but that is mandatory STARTTLS.

-----Original Message-----
From: Trans [mailto:trans-bounces= @ietf.org] On Behalf Of Paul Hoffman
Sent: Tuesday, February 25, 2014 9:54 AM
To: Ben Laurie
Cc: trans@ietf.org; Daniel Kahn Gillm= or
Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP

On Feb 25, 2014, at 9:36 AM, Ben Laurie <benl@google.com> wrote:

>> At the earlier CT meeting, I think someone proposed that there cou= ld be a check that the cert was in actual use at the place it said it was.<= br> >
> That does not seem effective to me.

It is more effective than doing nothing; it may not be effective enough to = prevent overwhelm by spam. I was just pointing it out as something that was= proposed, not well-thought-out.

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

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

--_000_4289ed5e74314d56ad59be2e92d0ccb3DFMTK5MBX1507exchangeco_-- From nobody Wed Feb 26 03: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 24B8A1A025A for ; Wed, 26 Feb 2014 03:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 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_48=0.6, RP_MATCHES_RCVD=-0.547, 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 YeA7SXWLV7uo for ; Wed, 26 Feb 2014 03:13:10 -0800 (PST) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0551A0256 for ; Wed, 26 Feb 2014 03:13:09 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id oz11so1981716veb.16 for ; Wed, 26 Feb 2014 03:13:08 -0800 (PST) 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=PDIQPxOt9Yklgud0Yz0og9hBfCLa+XMx0T+Rqv+ZV+s=; b=cXq3JXFfVNkTNSr2jYKzRTcAyTnLl9lJ0q8gRS2sgnle6fmCIWsez5IYu0zYAfy+uv ckZKXNSyx5Mg0373xiwm/nZaJgesunwtW2kjZPG57P15VL0ZKkqe9q8bkTK/mSk9MX00 GBU+wCtjkAf2f67r6tdGV/i11kD7LwhnFPaSMZYKjEhhyad31TLduAXVJ4Sfez7Qx09r R6Pr7Z8d6EHa/NAqsroO+lUNQTFnrw8GzrBh72vSPJFExeA23b9bN9k9gWBLH0Ao2pwi sjsBkUHzirI96SPPxXKqHyeEAo0JsqPXQu21nfjp5Y9jLXaGF+8wdwr/LAsM7suGEwgz Keeg== 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=PDIQPxOt9Yklgud0Yz0og9hBfCLa+XMx0T+Rqv+ZV+s=; b=UHbJCb3fv1VLxE8d0gtgMmYIWOY8cdIVIjNxVlG5CsQj5AsJo9/nMrmncvmOwC3okQ Ga5947OSIUwgZw2mO53AIreAuhE9uZgKdBVqEr8lVA22UyPuuBD/zuvqRRD7vKIRH+iA jidvXKueh9w6aqGR2GhNCZmcLxMWrNt5d/NlM3fcRrCL7qK4mv5zXAZpCfhzJ7dJmyOn 38hmpAACrmg5Re7ESNKHJdo86DUlVmlh5DOFFYOItnrh1szoahwu5LLArtz66Hkup+cB vGu/Hb6Pbwp17+JMXEFDhHyRSu9jP6kaEGKDpuXrC3eR+ZidnJq2ueh63SJlqeqQymZS I7Bw== X-Gm-Message-State: ALoCoQnD/RqzY6/GOg3eQkN4xFs8t4dAuRKqYxCFt+ZqGaJT6nw4dvdgYnJkbqTrNgEy/Si9ulUmk/BtPofUHSWE6afyMGKPW01gYZo8ZiStl7VE6QwgS+YbckV3HxCsJurrE/nDFZQBFQAWqsqGDKL6fZg05uxkyXpN7ZjBlO5bvG4YsKy5u3SS7OtuUARJly7u8da1kULW MIME-Version: 1.0 X-Received: by 10.58.59.100 with SMTP id y4mr5495980veq.4.1393413188665; Wed, 26 Feb 2014 03:13:08 -0800 (PST) Received: by 10.52.230.105 with HTTP; Wed, 26 Feb 2014 03:13:08 -0800 (PST) In-Reply-To: <4289ed5e74314d56ad59be2e92d0ccb3@DFM-TK5MBX15-07.exchange.corp.microsoft.com> References: <53063600.4020102@gmail.com> <878ut0usxw.fsf@alice.fifthhorseman.net> <530BB8E3.30303@gmail.com> <530BBCE6.1070100@fifthhorseman.net>

<200B1469-C0AB-4560-B799-F09D4C7221EA@vpnc.org> <2c3b987f362f479fa0d437513b65efa5@DFM-TK5MBX15-05.exchange.corp.microsoft.com> <4289ed5e74314d56ad59be2e92d0ccb3@DFM-TK5MBX15-07.exchange.corp.microsoft.com> Date: Wed, 26 Feb 2014 11:13:08 +0000 Message-ID: From: Ben Laurie To: Trevor Freeman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/veMCPgettwmQ5OgnAr-_B0Kgru0 Cc: "trans@ietf.org" , Phillip Hallam-Baker , Paul Hoffman , Daniel Kahn Gillmor Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP 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, 26 Feb 2014 11:13:13 -0000 On 25 February 2014 22:13, Trevor Freeman wrote: > The point with opportunistic TLS is its OPPORTUNISTIC, if there is any > failure it will fall back to send without TLS. In opportunistic TLS the > sender does no checks whatsoever on the certificate so why would it care > about CT? Then perhaps the word "opportunistic" should be removed from the question. What is the relevance of CT to SMTP+STARTTLS? > > > > Besides the whole STARTTLS negation is already subject to downgrade attacks. > Some firewalls actively block the STARTTLS negotiation. > > > > From: Phillip Hallam-Baker [mailto:hallam@gmail.com] > Sent: Tuesday, February 25, 2014 1:48 PM > To: Trevor Freeman > Cc: Paul Hoffman; Ben Laurie; trans@ietf.org; Daniel Kahn Gillmor > > > Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP > > > > The idea seems to be that there is an append only log server that clients > are gong to be checking. So we can use that to stuff security policy > information into the system. > > > > The problem is that the client only checks the CT logs in the normal case > after it has decided to use TLS. > > > > So there is certainly a value in using an append only log to publish > security policy data and in fact I do this in PPE. But it is only a solution > to the downgrade attack problem with a lot of extra infrastructure. For > example an Omnibroker scanning the CT log and using that to build the > connection profile. > > > > > > > > > > On Tue, Feb 25, 2014 at 2:47 PM, Trevor Freeman > wrote: > > I don't see the relevance of CT to opportunistic STARTTLS. > > Opportunistic STARTTLS is a feature of the sender whereby the sender picks > STARTTLS if offered, but otherwise will send the email. If the alternative > was send unprotected over plain TCP, you may as well negotiate TLS if > offered. Moreover, if TLS negotiation fails for whatever reason, the send > remembers the fact and done not attempt to negotiate next time. > > The sender does have a list of SMTP domains where it requires TLS > authentication, but that is mandatory STARTTLS. > > > -----Original Message----- > From: Trans [mailto:trans-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Tuesday, February 25, 2014 9:54 AM > To: Ben Laurie > Cc: trans@ietf.org; Daniel Kahn Gillmor > Subject: Re: [Trans] CT for opportunistic STARTTLS in SMTP > > On Feb 25, 2014, at 9:36 AM, Ben Laurie wrote: > >>> At the earlier CT meeting, I think someone proposed that there could be a >>> check that the cert was in actual use at the place it said it was. >> >> That does not seem effective to me. > > It is more effective than doing nothing; it may not be effective enough to > prevent overwhelm by spam. I was just pointing it out as something that was > proposed, not well-thought-out. > > --Paul Hoffman > _______________________________________________ > 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 > > > > > > -- > Website: http://hallambaker.com/ From nobody Wed Feb 26 03:29:07 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E076B1A0270 for ; Wed, 26 Feb 2014 03:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 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.547, 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 lGyfI5_9ocZm for ; Wed, 26 Feb 2014 03:29:01 -0800 (PST) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 018C71A0252 for ; Wed, 26 Feb 2014 03:29:00 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id jw12so2007888veb.32 for ; Wed, 26 Feb 2014 03:28:59 -0800 (PST) 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=FGhgWj24lgqHdAEaonaomUdzt3qTy5ogit2wW0yz61U=; b=UB7t5Za6Oov6Osd55DaETodJtWQ+cvIvdQF5BtQzZXw38F/k6GhE3oJEICwvplHtRL eLJT6z30lcJZZhrMVFv0ajNmoruIDz9EQeulLvlvCLtf81edTSrO9unjJiP+PKJhYotr 9YkxrmX5dojMRsUP5CYs9g6D/OXSwinVyBksbRzWK9e5E0Qv68dryUnB2qirCaDPvIAX bQNeC/uJYnjAyXvFMkymsthEuwmq9KEGZTVoSsekPv18fo2MK3bcx1Vmvem3xRsnCVzg HJx5XwkXyibMFarJwm9XQvbguRy6wKUheq2hIy9Pm/J0AtHmP9kOrBCZQ3erap6FIKNc 8SdQ== 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=FGhgWj24lgqHdAEaonaomUdzt3qTy5ogit2wW0yz61U=; b=gbSZHu0vbvQ8S+k4Y9CdxEal6cI72vuboPqqPBuiYz2VRgJv0TEKuA9B+CihKYqm6U +nDGtpcWb+3dhmAzayAJVIFOpzI34OAKMuO5VUL4kY3RGSr/7AOkdOjO1xwg/lB2YytW gbscSR+cMs/nIi01CN0rRvwgYifPZp57F9pLn5jn5d/eIHh4Fos29r3k5KNQCarlEO1p BGL9krERiNyHPBFVzkj5XP3MdVTniBDbdch8J2CzwGphOFtNiuCFsQg2UVEvrDQInWej mhj+/0d/0iM5c5Xo9HKrwesAdK2SOjEx9VtV/IlzVENTu5GlvDwzY+yZ75CovjSmt8pT Rp1A== X-Gm-Message-State: ALoCoQkK+BwM+NVrTeujjXEFFQAAXWX3M+Cr25rEwVu7uDcTKE0VLaLQpWoGa5jTeYGKIRzYmkA+7EFx4A/ocNPfVVrc8+wJ6bO/b40HkxwTM51ajdJfuDi9quhpDS2Pa3jR7VXraXg5GaKep+nxZBvzkbZq0fyYLkwB1DtzNvOmDvGZFPhs5no0NrWp7leD4A1A4aksJoN2 MIME-Version: 1.0 X-Received: by 10.221.37.1 with SMTP id tc1mr357198vcb.32.1393414139594; Wed, 26 Feb 2014 03:28:59 -0800 (PST) Received: by 10.52.230.105 with HTTP; Wed, 26 Feb 2014 03:28:59 -0800 (PST) In-Reply-To: References: <53063600.4020102@gmail.com> <530B86F6.5040201@gmail.com> Date: Wed, 26 Feb 2014 11:28:59 +0000 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/wAOevqKVfiYcCJjPs6_I-cYsFfs Cc: Melinda Shore , "trans@ietf.org" , Eran Messeri Subject: Re: [Trans] Draft agenda 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, 26 Feb 2014 11:29:04 -0000 On 25 February 2014 12:36, Phillip Hallam-Baker wrote: > > > > On Tue, Feb 25, 2014 at 2:23 AM, Ben Laurie wrote: >> >> On 24 February 2014 19:17, Phillip Hallam-Baker wrote: >> > What exactly is a 'precertificate'. Either something is a cert or it is >> > not. >> > >> > If it parses as an X.509v3 certificate then it is an X.509v3 certificate >> > and >> > thats an end to it. >> >> Indeed, and a precertificate is a certificate. RFC 6962 defines what >> exactly it is. >> >> Not sure where you're going with this. > > > Ritual compliance with the existing PKIX spec. > > Having two end entity certs with the same serial number is going to be a > problem. Not for ritual compliance. Same serial number _and issuer_ is a problem. CT does not require this. >> > If it is not then it is probably a CSR which would seem to be the >> > existing >> > PKIX structure that fits its purpose. >> >> Not really - a precertificate needs to be signed. > > CSRs are signed. But not by the right key - i.e. a change of spec would be required. I think you might be able to cram the missing fields into attributes in PKCS#10, though (which would also require additional spec). From nobody Wed Feb 26 03:57:59 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18D91A02B4 for ; Wed, 26 Feb 2014 03:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=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 Wseb4I4zI6yH for ; Wed, 26 Feb 2014 03:57:52 -0800 (PST) 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 9B09C1A02AC for ; Wed, 26 Feb 2014 03:57:51 -0800 (PST) Received: (qmail 31392 invoked by uid 1000); 26 Feb 2014 11:57:48 -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; Wed, 26 Feb 2014 11:57:48 +0000 Message-ID: <530DD6BC.8080207@comodo.com> Date: Wed, 26 Feb 2014 11:57:48 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ben Laurie , Phillip Hallam-Baker References: <53063600.4020102@gmail.com> <530B86F6.5040201@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/rrGTrB0khyfOqTQPibphiB9xbas Cc: Melinda Shore , "trans@ietf.org" , Eran Messeri Subject: Re: [Trans] Draft agenda 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, 26 Feb 2014 11:57:55 -0000 On 26/02/14 11:28, Ben Laurie wrote: > On 25 February 2014 12:36, Phillip Hallam-Baker wrote: >> On Tue, Feb 25, 2014 at 2:23 AM, Ben Laurie wrote: >>> On 24 February 2014 19:17, Phillip Hallam-Baker wrote: >>>> What exactly is a 'precertificate'. Either something is a cert or it is >>>> not. >>>> >>>> If it parses as an X.509v3 certificate then it is an X.509v3 certificate >>>> and thats an end to it. >>> >>> Indeed, and a precertificate is a certificate. RFC 6962 defines what >>> exactly it is. >>> >>> Not sure where you're going with this. >> >> Ritual compliance with the existing PKIX spec. >> >> Having two end entity certs with the same serial number is going to be a >> problem. > > Not for ritual compliance. Same serial number _and issuer_ is a > problem. CT does not require this. That's true, but CT does _permit_ same serial number and issuer. I think Phill is saying that he wants ritual compliance to be the only option available. >>>> If it is not then it is probably a CSR which would seem to be the >>>> existing PKIX structure that fits its purpose. Actually, I disagree with that. A Precertificate is not a certificate signing _request_. It's a certificate signing _promise_. >>> Not really - a precertificate needs to be signed. >> >> CSRs are signed. > > But not by the right key - i.e. a change of spec would be required. I > think you might be able to cram the missing fields into attributes in > PKCS#10, though (which would also require additional spec). That would involve reinventing several wheels and making the whole thing far more complicated. All just to achieve ritual compliance. But if we must have ritual compliance with 5280, then my preferred solution is to "poison" the Issuer Name in the Precertificate. For example... Certificate Issuer Name: C=GB, O=My CA Ltd., CN=My CA Precertificate Issuer Name: 1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA Sign both the Precertificate and the Certificate with the same CA private key. Use the same serial number for both. It wouldn't matter whether or not there exists a CA Certificate with the Subject Name "1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA". -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Feb 26 04:27:39 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED671A000A for ; Wed, 26 Feb 2014 04:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 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_12=0.6, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.547, 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 Wj_-4ZlScZXp for ; Wed, 26 Feb 2014 04:27:33 -0800 (PST) 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 0261F1A02DF for ; Wed, 26 Feb 2014 04:27:30 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id id10so849505vcb.27 for ; Wed, 26 Feb 2014 04:27:29 -0800 (PST) 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=effFkZTSEt3RJI60et8lsWDpE6/BJ3UEnw2czWCcSL4=; b=GDbaIKxskLj3ve8rkgT8Pg6KdDoC95GAgOqoXYya4nakD+m+Sx3aaj7wS39RJ6ZT3l zb/BVm2zmVPupCsxiat7ISdyzAY5lhj26O8vMiwamj3vot9gkOWGf/1Htd2dp3kDdWQx x7K1FyizoU8ZX5Ttcqma9vKyERtZSc8m5IOAWBEJ1ANlkdpzP/0bMNrXWLzr0a0lDb47 oP9XU6gcb9Gs4LhfzVqO6EvT2dLifL+9g8Gy7VNSM816MEgMDjdA238QIVKpmgTSHlSK xumZ6RfDNn3Q9gJ/fsnFCNjJx2jo7Up9WQ+YRdz99Udx0YEk1tp44d1KiJ0C4OKUzgUB Nl2Q== 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=effFkZTSEt3RJI60et8lsWDpE6/BJ3UEnw2czWCcSL4=; b=TQqiR96D3aS8FJHtWp9M/IxuHIvxRKO0vQbrATMY6ye6Tkbw6o70TxEIKWl1/kSL2a jcddO50tpYIMdoYCjqo23pWV96gwdLSsHxiUKyN2XvTFiSgj3vHCJNbMYXZrZtvv58+z HbL3LlpwK06uP7GGwTp2V2nwBY+jA2OkwjQrxd+qero7OZzDZr1lxUhVbRy58Lxuc7fu dq1HX+yp0Xzf0kNuoWG09x8y4MocizGlc6/plKSREkUStczvjoYacGmt5azsNNSiVWhy ykGvotCmGjWjZ0vMbC8QJ+QCyYX+Gyv6sVXO7yRXaGPlY6P4LSBFRR0QTaAkScOP2eq4 QprA== X-Gm-Message-State: ALoCoQm7jxJW3N1W/Z999TZIBlTbdn0HYAYAaW8LTqTAnvG4ea4N/EKCtPNSJWOWiPEPynbrrCSOP/lcr0U0k6TqUnveDKUN5pefiFsNQLrr+l7+2kHHV/6r3EDbgZNbG8rAcb6IOtoTH7hXpwkVdfbossF/B9HXs06GSk7UJvfnGU2MO9KCrKzX0ZoeAbb8k7dnY3uN1HRO MIME-Version: 1.0 X-Received: by 10.221.29.137 with SMTP id ry9mr5895881vcb.6.1393417649501; Wed, 26 Feb 2014 04:27:29 -0800 (PST) Received: by 10.52.230.105 with HTTP; Wed, 26 Feb 2014 04:27:29 -0800 (PST) In-Reply-To: <530DD6BC.8080207@comodo.com> References: <53063600.4020102@gmail.com> <530B86F6.5040201@gmail.com> <530DD6BC.8080207@comodo.com> Date: Wed, 26 Feb 2014 12:27:29 +0000 Message-ID: From: Ben Laurie To: Rob Stradling Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/trans/Y7s6_JwUeZESm_zrrlnPHEqswAU Cc: "trans@ietf.org" , Melinda Shore , Phillip Hallam-Baker , Eran Messeri Subject: Re: [Trans] Draft agenda 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, 26 Feb 2014 12:27:35 -0000 On 26 February 2014 11:57, Rob Stradling wrote: > On 26/02/14 11:28, Ben Laurie wrote: >> >> On 25 February 2014 12:36, Phillip Hallam-Baker wrote: >>> >>> On Tue, Feb 25, 2014 at 2:23 AM, Ben Laurie wrote: >>>> >>>> On 24 February 2014 19:17, Phillip Hallam-Baker >>>> wrote: >>>>> >>>>> What exactly is a 'precertificate'. Either something is a cert or it is >>>>> not. >>>>> >>>>> If it parses as an X.509v3 certificate then it is an X.509v3 >>>>> certificate >>>>> and thats an end to it. >>>> >>>> >>>> Indeed, and a precertificate is a certificate. RFC 6962 defines what >>>> exactly it is. >>>> >>>> Not sure where you're going with this. >>> >>> >>> Ritual compliance with the existing PKIX spec. >>> >>> Having two end entity certs with the same serial number is going to be a >>> problem. >> >> >> Not for ritual compliance. Same serial number _and issuer_ is a >> problem. CT does not require this. > > > That's true, but CT does _permit_ same serial number and issuer. > > I think Phill is saying that he wants ritual compliance to be the only > option available. > > >>>>> If it is not then it is probably a CSR which would seem to be the >>>>> existing PKIX structure that fits its purpose. > > > Actually, I disagree with that. A Precertificate is not a certificate > signing _request_. It's a certificate signing _promise_. > > >>>> Not really - a precertificate needs to be signed. >>> >>> >>> CSRs are signed. >> >> >> But not by the right key - i.e. a change of spec would be required. I >> think you might be able to cram the missing fields into attributes in >> PKCS#10, though (which would also require additional spec). > > > That would involve reinventing several wheels and making the whole thing far > more complicated. All just to achieve ritual compliance. > > But if we must have ritual compliance with 5280, then my preferred solution > is to "poison" the Issuer Name in the Precertificate. > > For example... > Certificate Issuer Name: C=GB, O=My CA Ltd., CN=My CA > Precertificate Issuer Name: 1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA > > Sign both the Precertificate and the Certificate with the same CA private > key. Use the same serial number for both. > > It wouldn't matter whether or not there exists a CA Certificate with the > Subject Name "1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA". Ah. I like that idea. Rather less than I like the idea of fixing the need for ritual compliance, though. From nobody Wed Feb 26 04:35:20 2014 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A856C1A02DF for ; Wed, 26 Feb 2014 04:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.809 X-Spam-Level: * X-Spam-Status: No, score=1.809 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=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 D5vbV9H2TX6D for ; Wed, 26 Feb 2014 04:35:15 -0800 (PST) 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 B1A181A02A2 for ; Wed, 26 Feb 2014 04:35:14 -0800 (PST) Received: (qmail 23055 invoked by uid 1000); 26 Feb 2014 12:35:09 -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; Wed, 26 Feb 2014 12:35:09 +0000 Message-ID: <530DDF7D.4040206@comodo.com> Date: Wed, 26 Feb 2014 12:35:09 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ben Laurie References: <53063600.4020102@gmail.com> <530B86F6.5040201@gmail.com> <530DD6BC.8080207@comodo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/bcy-a_VI_MZ3DtRS5qpNeYiRHuE Cc: Phillip Hallam-Baker , Melinda Shore , "trans@ietf.org" , Eran Messeri Subject: Re: [Trans] Draft agenda 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, 26 Feb 2014 12:35:17 -0000 On 26/02/14 12:27, Ben Laurie wrote: > On 26 February 2014 11:57, Rob Stradling wrote: >> But if we must have ritual compliance with 5280, then my preferred solution >> is to "poison" the Issuer Name in the Precertificate. >> >> For example... >> Certificate Issuer Name: C=GB, O=My CA Ltd., CN=My CA >> Precertificate Issuer Name: 1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA >> >> Sign both the Precertificate and the Certificate with the same CA private >> key. Use the same serial number for both. >> >> It wouldn't matter whether or not there exists a CA Certificate with the >> Subject Name "1.2.3.4=CT, C=GB, O=My CA Ltd., CN=My CA". > > Ah. I like that idea. Rather less than I like the idea of fixing the > need for ritual compliance, though. +1 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Feb 26 04:43:50 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 350C21A02E4 for ; Wed, 26 Feb 2014 04:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 7vNJab2JEUZs for ; Wed, 26 Feb 2014 04:43:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 960AA1A024D for ; Wed, 26 Feb 2014 04:43:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2E761BE74; Wed, 26 Feb 2014 12:43:35 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sui9TFMR90Ee; Wed, 26 Feb 2014 12:43:35 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 07B5ABE6E; Wed, 26 Feb 2014 12:43:35 +0000 (GMT) Message-ID: <530DE176.9020401@cs.tcd.ie> Date: Wed, 26 Feb 2014 12:43:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Rob Stradling , Ben Laurie References: <53063600.4020102@gmail.com> <530B86F6.5040201@gmail.com> <530DD6BC.8080207@comodo.com> <530DDF7D.4040206@comodo.com> In-Reply-To: <530DDF7D.4040206@comodo.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/trans/FeJ0EPbIHFZspEOCUxhk3dYfixo Cc: "trans@ietf.org" , Melinda Shore , Phillip Hallam-Baker , Eran Messeri Subject: [Trans] running code (was: Re: Draft agenda) 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, 26 Feb 2014 12:43:39 -0000 I'm not that keen on the phrase ritual compliance. There is a lot of PKI code in the world that assumes that issuer/serial is a unique identifier for a good X.509 certificate. It'd be best to not break such code by invalidating that assumption. If there's a good enough reason to do it, that might be ok, but I figure the burden to demonstrate that that is in fact ok should be on those arguing for such a change. S. PS: No hats, just a comment:-) From nobody Wed Feb 26 04:45:58 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 E3C3F1A02F8 for ; Wed, 26 Feb 2014 04:45:51 -0800 (PST) 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, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 NRbn8bcdYTwz for ; Wed, 26 Feb 2014 04:45:50 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9CABC1A02E3 for ; Wed, 26 Feb 2014 04:45:50 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id r5so1170952qcx.38 for ; Wed, 26 Feb 2014 04:45:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=y5rR/URGitC72AegSPXlFfHqfA3oSguAHN6nyqdFURM=; b=NIQlCc8tR3qkLnGfQOShg6G/uzXH/ArYFmTeSKJuQayCilKLkJxavKJZ2FNk6Q0qiP IK06aqE54wG9TiN8h+O3w2DWSkJjB1Z/dGmKhE6oZ6ekOwYfGhDdaDEn0BTl9Drvu7CB l8cdJQHbKYYJYd50pFpOo8zIATdbXc7fCKNpo3LG2kfymGGE0JunRwe+3x2ak0snUG3j xbn2TC7xJMde5rxPhTF4eQbG2YNkp5vX1x+rHWTAkVJzgM92HFoItsrmRkZYa7BFYDaF KvSvoFBTXVMURl7yIYeBA1fFefbEfd7XKC68rMswe5whl9BQH87OULQ+aUgHtH5Do/uW O/oQ== X-Gm-Message-State: ALoCoQnmkmNUpVwFCLZ84noqFBTzMLhgQCqZ0EPg+IMdDv6pp6lxtSXt1EAOdxdlbMj4HjCDzLO8 X-Received: by 10.224.98.212 with SMTP id r20mr7778567qan.0.1393418749073; Wed, 26 Feb 2014 04:45:49 -0800 (PST) Received: from [192.168.2.4] (pool-173-79-106-67.washdc.fios.verizon.net. [173.79.106.67]) by mx.google.com with ESMTPSA id q6sm2171162qax.11.2014.02.26.04.45.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 26 Feb 2014 04:45:48 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Wed, 26 Feb 2014 07:45:31 -0500 From: Carl Wallace To: Rob Stradling , Ben Laurie Message-ID: Thread-Topic: [Trans] Draft agenda References: <53063600.4020102@gmail.com> <530B86F6.5040201@gmail.com> <530DD6BC.8080207@comodo.com> <530DDF7D.4040206@comodo.com> In-Reply-To: <530DDF7D.4040206@comodo.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/trans/0KeDHW-RW9Ie2hPFePnhX9Rd35Y Cc: "trans@ietf.org" , Melinda Shore , Phillip Hallam-Baker , Eran Messeri Subject: Re: [Trans] Draft agenda X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Public Notary Transparency working group discussion list